ChatGPT Sites 是 ChatGPT 中的託管網站工作流程:它可以建立、託管、修改並分享網站、Web 應用程式或小遊戲。它適合快速做內部工具、演示頁面和輕量產品原型,但不能把它當作「生成後無需檢查的一鍵上線」工具——每個部署 URL 都是生產環境位址。
本文依據 OpenAI 官方 Sites 文件 整理一套從需求描述到發布驗收的實用流程。 Sites 目前是公測功能,實際可用性會受到套餐、地區和工作區設置影響。
先分清:Sites、Codex 與普通 ChatGPT 對話
Sites 的職責是管理託管專案與發布。你可以在 ChatGPT Work 網頁端透過「更多 > Sites」進入,也可以在 ChatGPT 桌面端使用。 Codex CLI 與 IDE 擴充功能可以編輯、測試本機項目,但沒有獨立的 Sites 管理介面;需要建立、儲存、部署或調整存取權時,仍會回到 ChatGPT 網頁端或桌面端。
這意味著一個穩健的分工是:
- 用 Codex 在本地檢查程式碼、依賴與建置結果;
- 用 Sites 產生託管版本或連接相容的本機專案;
- 在 Sites 預覽中審查內容和資料處理;
- 確認受眾與權限後,再部署生產 URL。
不要把 Sites 與 ChatGPT Project 混為一談。 Site 是可以持續開啟、修改、設定和共享的託管產物;它可以在最初的 Work 任務結束後繼續保留。
創建前:把需求寫成可驗收的提示詞
提示詞至少要說明受眾、頁面用途、核心互動和資料來源。只說「做一個專案管理網站」通常不夠,最好補充誰使用、要保存什麼、權限如何控制。
例如,下面的提示詞把功能邊界與驗收條件寫清楚:
|
|
最後一句很重要:它明確要求先儲存版本而不是上線。若只是展示型落地頁,也應寫明“不需要持久化資料”,避免系統為臨時 UI 狀態引入不必要的儲存。
選擇正確的資料與身分能力
根據官方文檔,Sites 可以依產品形態存取不同能力:
| 需求 | 應明確提出的能力 |
|---|---|
| 落地頁、內容站 | 預設無需持久化狀態 |
| 使用者記錄、進度、分數 | D1 關係型資料庫 |
| 圖片、文件、音訊視訊上傳 | R2 物件存儲 |
| 上傳文件及其可搜尋元數據 | D1 保存元數據,R2 儲存文件 |
| 只供內部員工使用 | 工作區身分認證 |
| 面向公眾且需登入 | 啟用認證的 Site |
持久化資料的判斷標準很簡單:使用者是否期待下次造訪時仍能看到它。主題色、關閉過的橫幅等臨時展示狀態一般不需要;訂單、表單記錄、上傳檔案和遊戲分數則需要。
實際操作:描述、審查、修改、保存
一個可重複執行的工作流程如下:
- 描述 Site:輸入明確需求,附上參考文件、品牌材料或現有項目;
- 審查預覽:檢查頁面文字、互動、資料是否符合預期;
- 迭代修改:在預覽中選擇 Edit,用自然語言描述改動;必要時補截圖或文件;
- 儲存版本:讓 ChatGPT 建置可部署版本,但暫不發佈;
- 部署版本:僅在確認內容、權限與受眾後,要求部署已核准的保存版本。
「儲存版本」和「部署版本」是兩個階段。對於本機項目,已儲存的版本會關聯用於建置的 Git commit,因此在提交前先檢查工作區狀態,才能避免將未驗證的變更一起帶到線上。
如果要讓現有項目上線,可以這樣提問:
|
|
發布前的四項檢查
發布不是最後一步的按鈕操作,而是一輪驗收。至少檢查以下內容:
- 內容與行為:頁面是否使用了正確資料,表單、篩選、跳轉和錯誤狀態是否可用;
- 資料與文件:上傳內容、資料庫記錄和存取範圍是否符合預期;
- 存取權限:優先選擇最窄的共享範圍,例如僅自己、受邀成員、工作區成員,最後才是「持連結的任何人」;
- 真實存取測試:開啟共享後的生產 URL,以目標受眾的權限確認能否存取。
工作區管理員可以限制公開分享。即使獲得了分享鏈接,訪問者也只有瀏覽權限,不會自動擁有編輯 Site 的權限。
不要把金鑰交給提示詞
運行時環境變數和密鑰應在 Sites 的設定中新增、更新或移除。不要把金鑰放進提示字、附件、Site 內容、.openai/hosting.json 或 Git 提交中。
本機專案仍應使用 .env 與 .env.example 管理開發環境所需的變數名稱;.env.example 只保留鍵名稱和安全性範例,不放真實值。變更託管環境變數後,要重新部署已經審核過的版本,才能讓新配置在生產環境生效。
對連接了本機原始碼的項目,.openai/hosting.json 用於記錄託管項目關聯和選用儲存綁定,例如 project_id、D1 或 R2 的綁定名稱。它不是秘密配置檔案。
常見問題
為什麼我找不到 Sites?
Sites 仍處於公測,可用性與套餐、地區、工作區設置相關。先確認使用的是 ChatGPT Work 網頁端或 ChatGPT 桌面端;若在受管工作區中不可見,再向管理員確認功能和分享策略。
能否只用 Codex CLI 管理發布?
不能。 Codex CLI 可以修改和測試本機項目,但建立、儲存、部署與管理 Sites 都要在 ChatGPT 網頁端或桌面端完成。
為什麼「部署成功」後才發現內容不對?
因為部署 URL 已是生產位址。下次先要求儲存可審查版本,檢查預覽和原始程式碼改動後再部署;如果已上線,立即收緊存取範圍,再修復並發布新的已審查版本。
結語
ChatGPT Sites 的價值在於將「構思、生成、託管、迭代」放進同一工作流程,但發布責任仍在使用者中。將流程固定為“明確需求 → 保存版本 → 預覽審查 → 最小權限分享 → 真實訪問驗收”,能顯著降低原型直接暴露、資料配置不當和密鑰洩露的風險。