OpenAI Codex Sites 完整解析：中小企業可不可以直接拿來做客戶網站交付？4 個能與不能、5 條合約紅線、3 個替代方案決策框架

最近我們在追蹤 OpenAI 的「Intelligence at Work」發表會時被一個東西卡住——Codex Sites。畫面上一個業務說「我要一個 8 頁的小型行銷網站」，三分鐘後 ChatGPT 回了一條 production URL，整站長得有模有樣。當天我們內部 Slack 立刻炸開：接案工作室的下半場到底還剩多少？中小企業老闆會不會明天就拿著這條連結來砍預算？

在我們內部 20+ 個 AI 流程裡，「AI 寫網站」這條已經跑了八個多月。從 Bolt.new、v0、Lovable 一路到 Replit Agent，我們把這些工具當成接案前期的快速 mockup 工具，幫業務第一次 demo 時不用等工程排程就能丟出畫面。Codex Sites 上線、又特別綁定 ChatGPT Business / Enterprise workspace 那一刻，我們知道這次的意義是 OpenAI 對「企業內部誰可以做網站」這件事的重新定義。

這篇寫給兩種人：中小企業老闆，正在評估要不要把官網、活動 LP、內部工具交給「會用 Codex Sites 的同事」做、預算壓到接案行情的三成以下；接案工作室主理人，正在想「客戶開始問 AI 能不能做了，接下來該怎麼定價、怎麼分工」。我們把這 12 天追下來的觀察、合約條款研究、跟內部 dog-fooding 經驗壓成一份「4 個能與不能、5 條合約紅線、3 個替代方案決策框架」，讀完你會知道現在能下手哪些、哪些再等一季、哪些根本不該碰。

先給你基本事實。OpenAI 在 6 月 2 日的「Intelligence at Work」場次正式發表 Codex Sites，使用者用自然語言描述需求，Codex 在 ChatGPT 對話內完成建構、跑測試、部署、回傳 production URL，preview 階段免費開放給 ChatGPT Business / Enterprise workspace；同場還推出 Codex Annotations 視覺化修改回饋、6 個業務角色 plugin（sales、marketing、finance、HR、product、ops）、Codex 內嵌 ChatGPT app 的能力。詳細功能拆解見 OpenAI 官方 newsroom，獨立分析則建議搭配 VentureBeat 的報導 一起看，後者把 Wix、Replit、Lovable、Base44、Figma、Webflow、Emergent 整套合作夥伴生態比對得比較完整。

接案工作室與中小企業數位團隊：客戶要快、預算少、品質要顧的三重壓力

我們最常聽到的客戶開場白是：「我們有個活動下週要上線，能不能先弄個 LP 就好？」這句話背後藏著三件事：預算不到正式案的三分之一、內部沒人會做、已經跟長官說「下週就會有」。接案方接到頭很大——接了壓縮到沒利潤，不接客戶轉身找下一家。

中小企業端的另一條更慘路徑：行銷主管自己用 Wix 拉拉看，第三天卡在表單跟 GA4 串接，求救行銷代理商收 8 萬處理三天，結果還是少了追蹤碼。兩邊都不開心。

這種三角壓力 2024 年就已經把 Webflow、Framer、Wix Studio 推上一波成長浪。Wikipedia 整理的 No-code 開發運動 顯示，2020 到 2025 年之間，企業端使用 no-code / low-code 工具完成內部專案的比例從 18% 跳到 65%。Codex Sites 出現的時間點剛好接在這波 no-code 紅利見頂的尾巴——當「拖拉式」也覺得慢，「對話式」就成為下一個合理選項。

但「對話式建網站」對企業端真正帶來的影響是組織職權的重新分配。原本要「行銷部寫 brief → 找代理商 → 工程拉 sprint」三段流程，現在 ChatGPT Business 帳號的任何一個人都能跳過前兩段直接出網站。對老闆是「省錢」的好消息，對接案方是「客戶下單動機從委外變成自製」的根本變化。

Codex Sites 是什麼、能做什麼、不能做什麼：先把產品邊界畫清楚

Codex Sites 本體是「ChatGPT 對話介面內建的 AI 網站建構器」。使用者打開 ChatGPT，輸入 @Sites 顯式呼叫，描述需求，Codex 會自動完成程式碼生成、執行測試、部署到 OpenAI 託管環境、最後回傳 production URL，整個過程不離開 ChatGPT 視窗。

取得方式：免費，但門檻在 workspace 等級

Codex Sites 目前是 preview 階段免費開放，但僅限 ChatGPT Business / Enterprise workspace 使用。Business 預設啟用，Enterprise 需要 admin 在 Early Access 設定啟用，Plus、Pro、免費版用戶完全沒這個選項。這門檻設計很關鍵——OpenAI 把 Codex Sites 定位成企業內部生產力工具，未來商業化路徑很可能綁在 Business / Enterprise 訂閱費裡。

部署模式：託管在 OpenAI 環境，不給你原始碼

這是現階段最容易被忽略的限制。Codex Sites 生成的網站直接託管在 OpenAI 提供的 production URL 上，原始碼不會自動 export。想拿 source code、自己部署、自己上 CI/CD pipeline，目前官方答案是「之後會支援」——意思是現在不行。對中小企業老闆而言，這個技術細節決定一件事：你的官網是「租 OpenAI 的、租約失效就消失」還是「自己的、搬到哪都還在」。

合作夥伴生態：拼圖式整合，不是單一閉環

OpenAI 同時公布了 Codex Sites 的合作夥伴：Wix、Base44、Replit、Lovable、Figma、Webflow、Emergent。這份名單的真正意義是「Codex 在這些工具之間做橋接」，並非「Codex 取代了它們」。OpenAI 知道單靠自己一家不可能涵蓋所有企業使用場景，所以把 ChatGPT 變成「網站建構需求的入口」，背後實際生成、託管、編輯由合作夥伴完成。對採購評估者來說，這代表你最後拿到的網站可能跑在 Wix 上、可能跑在 Replit 上、可能跑在 OpenAI 自家環境——同一個 ChatGPT 對話入口背後不一定是同一個底層。

把這些事實放成一張表，採購評估者比較好對焦：

中小企業實際拿來交付的 4 個能與不能：分行業看哪些可以直接上、哪些只能當原型

先講結論——Codex Sites 現階段能做的事比看 demo 影片時想像得窄。把中小企業最常見的四種網站需求一個一個拆給你看：

能做：內部行銷頁、活動 LP、原型 demo、輕量內部工具

第一類：內部行銷頁。產品介紹頁、品牌故事頁、新方案介紹頁，這種「內容為主、互動為輔」的頁面 Codex Sites 表現很穩，業務拿去做 outbound 完全夠用。

第二類：活動 LP。雙 11 檔期、產品發表會、線下活動報名頁，活兩週就下架，需求重點是「快」和「美」。Codex Sites 的優勢是「ChatGPT 對話一句話改文案，30 秒部署上線」。

第三類：原型 demo。跟主管報告新產品、跟客戶 demo 概念驗證、跟投資人講商業模式，「能跑的網頁」比 PPT 更有說服力。我們公司內部這條路徑已經跑了八個多月，平均一個案子省 3-5 個工時。

第四類：輕量內部工具。內部報表查詢頁、員工自助查薪資頁、表單收集頁，這種使用者只有公司同事、流量不大、需求單純的工具，Codex Sites 完全 hold 得住。配合 Codex 內嵌 ChatGPT app 能力，可做查詢工具直接呼叫公司內部資料源（前提是 Enterprise workspace 已設好資料整合）。

不能：正式品牌官網、複雜電商、需要長期 SEO 累積的內容站、高合規行業

反過來，這四種需求現階段不該交給 Codex Sites：

第一，正式品牌官網。關鍵在於「託管在 OpenAI、不給原始碼」這件事讓品牌官網變成租賃資產。官網 SEO 權重通常累積 3-5 年才見效，未來想搬走等於從零開始，中小企業老闆容易被「免費 + 快」吸引而忽略這個 long-tail 成本。

第二，複雜電商。涉及金流、會員、庫存、訂單管理的電商網站，現階段 Codex Sites 沒有原生支援。即使透過合作夥伴 Wix 串接，責任歸屬、SLA、退款處理這些電商必備條款在 preview 階段都還沒有完整規範。把客戶金流資料交給「合約還沒談完的關係」，風險太大。

第三，需要長期 SEO 累積的內容站。部落格、知識庫、媒體站這類靠關鍵字排名累積流量的網站，需要極度細緻的技術 SEO 控制：sitemap.xml 自訂、canonical tag、結構化資料、Core Web Vitals 調優、CDN 配置——這些目前在 Codex Sites 都是黑盒子。寧可花一週用 Next.js 客製化（由 Claude Code / Codex 寫程式碼），也不要把長期 SEO 命脈交給一個對話框。

第四，高合規行業。金融、醫療、教育補習班這些有特殊法規要求的行業，網站除了是行銷工具，更是合規載體。金管會對金融業官網的揭露要求、衛福部對醫療廣告的審核流程、教育部對補習班登記資訊的揭示——這些合規責任在 OpenAI 託管環境下歸誰、怎麼舉證、被裁罰時誰賠，現階段都不明。

如果你的需求是正式品牌官網、特別是 15-200 萬預算這個段位的客製化案，建議先看我們之前寫的 企業官網設計外包採購完整指南，裡面有六個關鍵決策跟三段報價區間的拆解，搭配本篇看，會比較清楚什麼時候該選哪條路。

我們不認同「所有中小企業現在都該用 Codex Sites 直接交付」這種說法

市場上一波又一波的「AI 顛覆接案」聲音，從 Bolt.new 紅起來到 Lovable 估值飆破 18 億美金，每隔兩個月就會重來一次。每次出現，我們都會收到客戶 LINE 來問「那我以後是不是不用找你們了」。直接給你我們團隊內部討論完的真實判斷：

中小企業現在直接拿 Codex Sites 交付客戶網站，會在 6 個月後集體撞牆。撞牆有三個具體形式：

第一種撞牆：搬家成本。原始碼不給 export，意味著你今天用 Codex Sites 做的網站，未來想換工具、換託管、換工程團隊，都得拿著 production URL 請新團隊重做一次。重做成本通常是當初省下成本的 3-5 倍。

第二種撞牆：合規責任。台灣中小企業的網站如果涉及金流、個資、廣告詞合規，被檢舉時主管機關問的是「網站架構、資料流、儲存位置」——你能從 OpenAI 那邊拿到一份完整的資料處理文件嗎？preview 階段答案是「拿不到」。被罰時責任會直接掉在公司負責人頭上。

第三種撞牆：客戶信任度。當你的競爭對手官網是專屬域名跑在 Cloudflare 上，你是 codex-sites-yourbrand.openai.com，在 B2B 銷售場合會被客戶質疑「這家公司聽起來像個 side project」。品牌信任是最難量化但最致命的成本。

所以我們的取捨是：Codex Sites 短期用在「活動 LP、內部 demo、原型驗證」，這三類用完即丟、不累積 SEO、不涉及合規的場景。涉及到任何「客戶會長期看到、會搜尋到、會關聯到品牌」的網站，現階段一律先走客製化或自架方案。這個立場跟反 AI 無關——核心是「在對的場景用對的工具」。我們公司自己內部也是這樣分工，活動 LP 跑 AI builder，正式品牌頁跑 Next.js 客製化。

5 條合約紅線：採購 Codex Sites 託管網站前必須在合約裡寫進去的條款

接下來給兩種人讀：接案工作室主理人——你之後可能用 Codex Sites 幫客戶做網站，合約怎麼簽會被客戶在 6 個月後告；中小企業老闆——你之後可能直接用 ChatGPT Business 帳號自己做網站，要怎麼跟公司法務解釋風險。

紅線 1：智慧財產權（IP）歸屬

OpenAI 服務條款明訂使用者擁有自己輸入與生成內容的權利，但「生成內容」這四個字在 Codex Sites 場景下涵蓋什麼，preview 階段沒清楚定義——你的網站程式碼算嗎？視覺設計算嗎？OpenAI 用來訓練下一代模型的權利保留到什麼程度？建議在客戶合約裡明寫「本網站使用 Codex Sites 生成，OpenAI 對生成內容的權利依其 service terms 為準」，把責任邊界先攤開。

紅線 2：原始碼歸屬與 export 權

preview 階段不給 export，這件事必須寫進客戶合約：「乙方交付之網站託管於 OpenAI Codex Sites 環境，現階段不提供原始碼 export，待 OpenAI 釋出對應功能後乙方協助轉移，轉移工時另計」。這條不寫，客戶 6 個月後問你「我要原始碼自己改」時你會卡死。

紅線 3：託管權與 SLA

OpenAI 對 Codex Sites preview 階段的 SLA 是 best effort，沒有保證 99.9% uptime、沒有保證恢復時間。你做給客戶的網站如果半夜掛掉、活動跑到一半當機，這責任在合約上是誰的？建議寫「本網站託管於 OpenAI Codex Sites，乙方不對 OpenAI 平台層級可用性負責，平台故障導致之損失依 OpenAI service terms 處理」，把責任邊界推到平台層。

紅線 4：資料保護與隱私

Codex Sites 生成的網站如果有表單、會員、互動功能，使用者資料會儲存在哪裡？preview 階段預設儲存在 OpenAI 自家環境。如果你的客戶是台灣公司、收集台灣用戶資料，台灣個資法的「資料儲存位置告知」「跨境傳輸告知」這些義務都還在你身上。寫合約時建議要求客戶簽署「同意網站運作過程中之使用者資料儲存於 OpenAI 提供之環境」聲明書自保。詳細個資法義務可參考 國家發展委員會個資法說明。

紅線 5：退場與資料遷出

最後一條也是最容易漏的——如果 OpenAI 突然下架 Codex Sites（preview 產品死亡率不低，看 Google Optimize、IBM Watson Studio Free Tier 的下場就知道），客戶網站怎麼救、資料怎麼匯出、SEO 權重怎麼處理。建議寫一條退場條款：「如 OpenAI 停止 Codex Sites 服務，乙方在收到甲方書面通知 30 日內完成資料匯出與替代方案建議書，遷移工時另計」。

如果你想把這 5 條合約紅線跟 Codex 整體生態的部署選項一起看，建議搭配我們之前的 OpenAI 收購 Ona 與 Codex VPC 部署實況解析 一起讀，那篇拆解了 VPC 部署選項對中小企業 AI Coding 採購節奏的影響，跟本篇的合約紅線是同一條主軸的不同切面。

替代方案決策框架：Lovable、Bolt、v0、Replit、客製化開發——3 個維度幫你選對工具

這節是給中小企業老闆跟接案工作室主理人的工具選型地圖。市場上同類型 AI builder 至少有六家在打架，加上「全託管 SaaS」「客製化開發」「自架 + AI 輔助」三條傳統路徑，總共九個選項——直接列九個你也選不出來，先把判斷維度收斂到三個：

• 維度 1：網站的生命週期（短期活動 / 長期品牌）
• 維度 2：對技術獨立性的要求（要 source code / 不在意）
• 維度 3：團隊內 AI 熟練度（業務都會用 / 只有工程會）

依生命週期選

短期活動（< 3 個月、用完即丟）：Codex Sites、Lovable、Bolt.new、v0 都可，看團隊在哪個生態最順手。長期品牌（> 1 年、會累積 SEO）：客製化開發（Next.js / Astro / Hugo）+ AI 輔助（Claude Code、Codex CLI）。短期成本高，但 6 個月後的累積效應遠超 AI builder——我們公司跟客戶的正式品牌官網一律走這條。

依技術獨立性選

要 source code 的：Bolt.new（提供 download）、v0（提供 GitHub export）、Replit（完整 IDE 開放）、客製化開發（自己擁有）。願意省掉 source code 的：Codex Sites、Lovable、Webflow、Wix。本質是「成本意識」題——預計 1-2 年內可能換團隊就要 source code，能接受跟平台綁一輩子就省掉。

依團隊 AI 熟練度選

業務都會用：Codex Sites（綁在 ChatGPT 介面）、Lovable（最低門檻 UI）、Webflow（拖拉式）。只有工程會：v0（要懂 React）、Replit Agent（要懂前後端架構）、客製化開發（要懂完整 dev workflow）。

如果你想看 Lovable、Bolt.new、v0 這三家的深度比較（含真實接案場景試跑），我們之前寫過 Lovable vs Bolt.new vs v0 三家 AI App Builder 完整實測，那篇針對中小企業老闆與工程主管列了 5 個採購評估訊號，跟本篇的決策框架可以互補。

另外想理解 OpenAI 把 Codex 推到企業端的整體策略邏輯，建議讀 OpenAI Codex 6 個業務 plugin 完整解析，那篇拆解了 sales、marketing、finance、HR、product、ops 六個垂直 plugin 的採購節奏，跟 Codex Sites 是同一波發表的姊妹篇。

我們公司怎麼用 AI Builder：dog-fooding 8 個月後的實作筆記

這節是純 dog-fooding 自證——我們公司自己每天就跑 20+ 個 AI 流程，其中跟「AI 建網站」相關的有四條，可以對照自己公司情境想想哪條搬得過去。

流程 1：客戶 demo 前的視覺 prototype

業務跟客戶第一次開會前 30 分鐘，會在 Lovable 或 Bolt 跑一個對應行業的網站 demo，三頁 25 分鐘完成。開會時打開 demo 跟客戶說「假設做出來像這樣，你想保留哪些、改掉哪些」，比看靜態 mockup 多 3 倍的對話深度。Codex Sites 上線後我們會把這條流程切過去，因為公司本來就在用 ChatGPT Business，省一個工具學習成本。

流程 2：內部 RFC 配套的互動 demo

我們內部重要技術決策會寫 RFC，以前都是純文字。八個月前開始要求所有 RFC 至少附一個「能跑的 demo URL」——例如「客戶官網加 AI 問答功能」這條 RFC，作者先用 Lovable 跑 demo URL 讓其他人實際點點看再給意見。這個改動讓決策速度快 40% 以上。

流程 3：行銷活動 LP 內製

marketing 團隊做季度方案發表的活動 LP 全由 marketing 內部完成，不再丟給工程排程。流程是 marketing 寫 brief → 用 v0 跑第一版 → 自己改文案視覺 → 用 Cloudflare Pages 託管，從「工程排兩週」縮到「marketing 內部三天」。

流程 4：客戶提案附件的互動原型

傳統提案是 PPT + 報價單，這幾個月改成 PPT + 報價單 + 互動原型 URL。互動原型由 sales engineer 在 Bolt 上跑 30 分鐘出一個能模擬產品操作流程的網頁。客戶在內部討論預算時打開 URL 自己點點看，回饋是「對提案內容理解快很多」。

這四條流程的共通點是——AI builder 是「中介工具」而非「終端產品」，是讓溝通、決策、提案這些「軟流程」變快的槓桿。如果你公司有類似流程，可以想想 Codex Sites 能不能切進去。

60 天評估與導入行動清單：IT、採購、法務、業務四個角色的任務分配

最後給你一份可執行的 60 天行動清單。中小企業評估新技術最常見的問題是「老闆拍板要做，內部卻沒人知道從哪開始」——以下清單把責任切到四個角色，老闆轉發給對應主管就能直接執行。

第 1-15 天：IT 主管主導，技術可行性盤點

• 確認公司是否已有 ChatGPT Business / Enterprise workspace（Enterprise 需 admin 在 Early Access 啟用）
• 盤點公司現有網站資產（官網、活動 LP、內部工具），分類成「能搬」「不能搬」兩類
• 選 1-2 個低風險試點（建議從活動 LP 或內部小工具開始）
• 建立內部「AI 網站工具使用規範」初稿

第 16-30 天：採購 + 法務聯手，合約條款盤點

• 讀完 OpenAI Codex Sites service terms（IT 提供英文、法務翻成中文摘要）
• 對照本篇 5 條合約紅線，盤點客戶合約模板是否需要新增條款
• 接案工作室主理人更新對外報價單，把「AI builder 託管限制」寫進備註欄
• 建立「AI builder 採購評估表」，未來新案統一用這份表問客戶意願

第 31-45 天：業務 + 行銷實作試跑

• 業務團隊用 Codex Sites 做 2-3 個客戶 demo 原型，記錄產出時間、客戶反應
• 行銷團隊用 Codex Sites 做 1 個內部活動 LP（非公開上線版），記錄製作流程
• 蒐集試跑期間遇到的限制、bug、被綁定感受，整理成內部 retrospective

第 46-60 天：管理層 review + 全公司決策

• IT、採購、法務、業務、行銷一起開 review meeting
• 決定公司未來 12 個月 AI builder 採購策略：全面 / 限定場景 / 暫不採用
• 若決定採用，建立「AI builder 治理小組」（3-5 人跨部門）
• 決策結果跟採購規範同步全公司，避免單一部門私自決定

我們很樂意聽你聊聊 AI 網站交付這件事

看到這裡，如果你正在猶豫「公司的 AI builder 策略到底該怎麼定」、「接案合約要怎麼改才不會被告」、或「正式品牌官網要不要直接做客製化」——這幾個問題沒有標準答案，但有「適合你公司現況的答案」。我們很樂意聽你聊聊現在的實際情況，把客戶結構、技術能力、預算範圍攤開來，一起看看哪些做得起來。請直接連絡 我們的 AI 顧問服務 或 客製化網站與系統開發，先聊一下你公司現在的情況，我們會直接告訴你『這個值得做嗎、大概怎麼做最划算』。