ChatGPT Sites 怎么用：从提示词到托管网站的发布与安全检查

Mon, 13 Jul 2026 07:39:00 +0800

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 任务结束后继续保留。

创建前：把需求写成可验收的提示词

提示词至少要说明受众、页面用途、核心交互和数据来源。只说“做一个项目管理网站”通常不够，最好补充谁使用、要保存什么、权限如何控制。

例如，下面的提示词把功能边界与验收条件写清楚：

1
2
3

为运营团队创建一个项目需求看板。成员可以提交需求、查看负责人、更新状态并按状态筛选。
仅限工作区成员登录；需求记录必须在刷新页面后保留。
先生成可审查版本，不要发布；同时列出需要我确认的数据字段和权限设置。

最后一句很重要：它明确要求先保存版本而不是上线。若只是展示型落地页，也应写明“不需要持久化数据”，避免系统为临时 UI 状态引入不必要的存储。

选择正确的数据与身份能力

根据官方文档，Sites 可以按产品形态接入不同能力：

需求	应明确提出的能力
落地页、内容站	默认无需持久化状态
用户记录、进度、分数	D1 关系型数据库
图片、文档、音视频上传	R2 对象存储
上传文件及其可搜索元数据	D1 保存元数据，R2 保存文件
只供内部员工使用	工作区身份认证
面向公众且需登录	启用认证的 Site

持久化数据的判断标准很简单：用户是否期待下次访问时仍能看到它。主题色、关闭过的横幅等临时展示状态一般不需要；订单、表单记录、上传文件和游戏分数则需要。

实际操作：描述、审查、修改、保存

一个可重复执行的工作流如下：

描述 Site：输入明确需求，附上参考文件、品牌素材或现有项目；
审查预览：检查页面文本、交互、数据是否符合预期；
迭代修改：在预览中选择 Edit，用自然语言描述改动；必要时补截图或文件；
保存版本：让 ChatGPT 构建可部署版本，但暂不发布；
部署版本：仅在确认内容、权限与受众后，要求部署已批准的保存版本。

“保存版本”和“部署版本”是两个阶段。对于本地项目，保存的版本会关联用于构建的 Git commit，因此提交前先检查工作区状态，才能避免把未验证的改动一起带到线上。

如果要让现有项目上线，可以这样提问：

1
2

检查当前项目能否生成兼容的 Sites 部署产物；修复必要的兼容性问题，
保存一个可审查版本并说明改动。不要部署，等我确认后再发布。

发布前的四项检查

发布不是最后一步的按钮操作，而是一轮验收。至少检查以下内容：

内容与行为：页面是否使用了正确资料，表单、筛选、跳转和错误状态是否可用；
数据与文件：上传内容、数据库记录和访问范围是否符合预期；
访问权限：优先选择最窄的共享范围，例如仅自己、受邀成员、工作区成员，最后才是“持链接的任何人”；
真实访问测试：打开共享后的生产 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 的价值在于把“构思、生成、托管、迭代”放进同一工作流，但发布责任仍在使用者。把流程固定为“明确需求 → 保存版本 → 预览审查 → 最小权限分享 → 真实访问验收”，能显著降低原型直接暴露、数据配置不当和密钥泄露的风险。

网站生成 on KnightLi的博客