Codex Sites 深度分析
自然語言建內部工具——誰會先被吃掉?

2026-06-22 · Codex 白領擴張系列第 2 篇 · 來源:OpenAI 官方、BuildFastWithAI、Tarek Alaaddin

OpenAICodex Sites內部工具 RetoolAirtableCloudflare
廣告位置 — AdSense 自動廣告

一句話摘要

Codex Sites 不是要取代 Lovable 和 Vercel——它是內部工具市場的原子彈。一句話生儀表板、內建 ChatGPT 身分驗證、跑在 Cloudflare Workers + D1 上。但「無自訂域名、無法外部分享、無法搬走程式碼」這三條限制讓它短期內吃不掉 Retool 和 Airtable 的核心用戶。

核心技術棧

先搞清楚 Sites 底層是什麼,才能判斷它能吃掉誰。OpenAI 沒有自建主機機房——它把整套基礎設施外包給了 Cloudflare:

技術做什麼你看得到的
ComputeCloudflare Workers (ES modules)在邊緣節點執行應用邏輯頁面回應速度極快,全球部署
DatabaseD1(SQLite 相容關聯資料庫)儲存結構化資料:用戶記錄、分數、設定跟 Postgres 比功能少,但對內部工具夠用
File StorageR2(物件儲存)處理圖片、文件、上傳無輸出流量費(這是打 S3 的關鍵差異)
AuthSign in with ChatGPT工作區範圍內的身分驗證500 人公司自動取得 500 人認證——零設定
Config.openai/hosting.json專案元數據、儲存綁定一個 JSON 檔,不複雜
SecretsSites 面板(Codex 側欄)環境變數、API 金鑰不進原始碼,合理的安全設計
關鍵洞察:這個技術棧選得非常巧妙。Cloudflare Workers + D1 + R2 的組合對於「內部工具」這個場景是完美的——它不需要 Postgres 的完整功能,但需要邊緣部署的速度和零運維。我認為這是 OpenAI 在技術選型上最清醒的一次決定。

兩階段部署模型:為什麼這對企業很重要

Codex Sites 不是「寫完直接上線」——它設計了一個 Save → Review → Deploy 的兩階段流程:

  1. Save a version:Codex 建好應用後,先綁定到一個 Git commit。這是審查檢查點。你可以檢查建置結果、測試功能、確認一切正常——此時只有你(Owner)看得到。
  2. Deploy a version:確認沒問題後,一鍵發布到生產環境。URL 立刻生效,工作區成員即可存取。

這個設計的聰明之處在於:它解決了企業 IT 部門對「AI 亂建東西」的恐懼。沒有這個中間檢查點,任何員工都可以在五分鐘內建出一個掛著公司資料的儀表板並公開網址。兩階段模型讓審查變成可能——這對於有合規需求的團隊是必需的。

存取控制:三種模式,沒有「公開」

模式誰能看適合場景
Admins only你(Owner)+ 工作區管理員還在開發中、敏感資料測試
Workspace all所有工作區活躍用戶全公司儀表板、團隊專案追蹤器
Custom指定用戶或群組(Owner 永遠保留存取權)跨部門工具、限特定團隊查看

沒有「anyone with the link」選項。每個訪客都必須是工作區成員,或透過已連接的身分提供者驗證。這是 Sites 的設計哲學核心,也是它跟所有 no-code 工具的根本差異——它不是面向公眾的建站工具,是面向組織的內部應用生成器。

正面對比:Codex Sites vs Retool vs Airtable vs Notion

維度Codex SitesRetoolAirtableNotion
建置方式自然語言 prompt拖放 UI 組件 + SQL/JS試算表式欄位設定區塊編輯器 + 資料庫
目標用戶非開發者(白領主管)工程師 + 技術 PM半技術營運人員所有人(偏文件協作)
資料來源D1(內建 SQLite)+ OAuth 串接外部直接連 PostgreSQL / MySQL / REST內建表格(上限 50 萬筆 / base)內建資料庫(API 3 req/s)
身分驗證ChatGPT 登入(零設定)SAML / OIDC / GoogleSAML / Google / 密碼SAML / Google / 密碼
程式碼可攜鎖死在 OpenAI 平台可匯出 React 程式碼API 匯出(非程式碼)API + CSV 匯出
自訂域名僅 OpenAI 管理 URL完全自訂部分方案支援部分方案支援
外部分享僅工作區成員公開 / 嵌入 / iframe公開表單 / 分享視圖公開頁面 / 訪客
合規SOC 2 / HIPAA eligible / EU data residencySOC 2 / HIPAA / GDPRSOC 2 / HIPAA / GDPRSOC 2 / GDPR
定價$30/人/月(ChatGPT Business)$10/使用者 + $5/終端用戶$20/人/月(Business)$10/人/月(Plus)

我的判斷:誰最危險,誰最安全

高風險:Google Sheets 到內部工具的灰色地帶

這才是最直接被 Sites 取代的。每個公司都有那種「從 Google Sheet 長出來的怪物」——行銷的活動追蹤表、人事的入職清單、財務的預算管理。這些東西以前有三條進化路徑:(1) 繼續堆公式→變成 20 個分頁的失控試算表、(2) 找工程師寫一個 Retool 應用、(3) 找一個 Notion 模板湊合。

Sites 給出了第四條路:用一段 prompt 生出專屬應用。不需要學 SQL、不需要想資料庫 schema、不需要處理部署。這就是 Google Sheets 重度用戶的終極出口。

中風險:Retool 的「簡單場景」用戶

Retool 的護城河是 直接連線到現有資料庫(PostgreSQL、MySQL、MongoDB)和 自訂程式碼邏輯。一個已經在跑 Retool 中型規模內部工具的團隊(有 50 個儀表板、串接了 8 個資料庫),不太可能只因為 Sites 比較快就遷移。

但 Retool 的邊緣用戶很危險。那種只用 Retool 做 2-3 個簡單儀表板的團隊——可能只有一個技術 PM 在維護——對他們來說,「用 prompt 生儀表板 + 內建 auth」比「花 $10/user 學 Retool」吸引力大太多了。

低風險:Airtable 的核心場景

Airtable 有一個 Sites 短期內無法複製的能力:試算表般的協作體驗。Airtable 的用戶習慣在同一個介面裡手動編輯資料、排序、篩選、分組。Sites 生出來的應用比較像「唯讀儀表板」——你可以看數據,但要在同一個頁面裡像編輯試算表一樣自由修改,目前還做不到。

另一個 Airtable 的護城河是 API 生態。數千家公司把 Airtable 當作後端資料庫,用 Retool、Softr 或自訂 React 應用當前端。這些用戶不會因為「用 prompt 生 UI」就放棄這個生態系。

最安全:Notion 的文件 + 資料庫混合場景

Notion 的核心價值不是「建內部工具」——是 「文件 + 資料庫 + 團隊 wiki 在同一處」。Sites 完全沒有文件編輯功能、沒有 wiki 協作、沒有知識庫的「可編輯性」。你可以用 Sites 建一個「入職流程追蹤器」,但你不會用 Sites 寫入職文件本身。這兩個是不同的東西。

適用場景評估表

場景Sites 適合度理由
銷售 pipeline 儀表板★★★★★展示為主 + 內建 auth = 完美
客戶會議準備頁面★★★★★自動聚合 CRM 數據 + 一鍵分享連結
財務情景規劃器★★★★互動參數調整適合,但需注意資料敏感度
客服 KPI 看板★★★★即時數據展示,唯讀模式足夠
專案進度追蹤(含手動更新)★★★可做,但不如 Airtable 靈活(缺乏試算表編輯體驗)
複雜工作流自動化★★無條件邏輯引擎,不如 n8n / Zapier
外部合作夥伴入口無外部分享功能,完全不合適
公開產品展示頁不適用不是設計目的,用 Lovable / Webflow

限制與風險

1. Preview 狀態——不可用於關鍵系統。OpenAI 明文保留「移除、取消發布、刪除或停用 ChatGPT Sites」的權利,無需通知。你的銷售儀表板可能明天就消失。GA 日期未公布。
2. 無自訂域名。你的 Site 網址是 OpenAI 管理的(類似 xxx.sites.openai.com)。你無法指向 tools.yourcompany.com。對於在意品牌形象的團隊,這是嚴重的限制。
3. 程式碼完全鎖死。不像 Lovable、Replit、Bolt 可以匯出全部程式碼部署到自己的基礎設施,Sites 的程式碼永遠留在 OpenAI 平台。如果哪天你想離開 OpenAI 生態系,你留下的不是程式碼,是重新開發的起點。
4. 無法外部分享。每個訪客都需要工作區憑證。如果你想讓外部合作夥伴、客戶、承包商看到某個儀表板——辦不到。這是設計選擇,不是 bug,但確實限制了使用場景。
5. 合規資料限制。OpenAI 明確禁止在 Sites 上存放支付卡資料(PCI DSS)、受保護健康資訊(HIPAA)、涉及 13 歲以下兒童的內容、金融交易資料。如果你的內部工具需要處理這些資料,Sites 不適合。
6. 僅限 Business / Enterprise 用戶。Plus ($20/月) 和 Free 用戶無法使用 Sites。這排除了大量個人和小團隊用戶。

我的觀察

坦白說,Codex Sites 不是技術奇蹟——Cloudflare Workers + D1 + R2 這個組合任何一個有能力的後端工程師都能搭出來。它的真正創新不在技術棧,在於 「整合體驗的簡化」

  1. 身分驗證預設內建:ChatGPT 登入自動解決了內部工具最煩人的第一步——「誰能看這個東西」。對比 Retool 需要手動設定 OIDC/SAML,Sites 的零設定體驗是真正的差異化優勢。
  2. 部署流程消失:沒有 Vercel 專案要連、沒有 CI/CD 管線要設、沒有 Cloudflare 帳號要註冊。對非開發者來說,這才是真正的 magic。
  3. 平台黏性設計精妙:「無程式碼匯出」不是技術限制——是故意的。OpenAI 在你開始使用 Sites 的那一刻就綁定了你。這是平台策略,不是產品限制。

長期來看,我認為 Codex Sites 會吃掉的是 「Google Sheets 進化到內部工具」的那一段需求,而非已成熟的企業低代碼平台市場。Retool 和 Airtable 的核心用戶(有工程團隊、有複雜資料庫、需要客製化邏輯)短期內不會跳船。但那些「只有一個技術 PM 在苦苦維護的三個 Retool 儀表板」的小型團隊——Sites 對他們來說是解脫。

一句話總結:Sites 不是平台戰爭的參賽者——它是讓平台戰爭變得無關緊要的武器。當建立內部工具的成本降到「一段 prompt」時,你不需要在 Retool 和 Airtable 之間做選擇——你只需要問自己:我需要別人也能存取這個工具嗎?如果需要,選 Retool。如果只有內部團隊——Sites 就夠了。

來源