OpenAI Sites 是什么？Codex 一键建站与托管能力解读
浏览：5
巴克励步
解读 OpenAI Sites 预览能力：如何用 Codex 从 Prompt 生成、保存、部署并托管网站与应用，以及版本管理、访问控制与发布前检查要点。
OpenAI 在 Codex 中推出的 Sites 能力，把「写一段需求 → 得到可访问的网址」压缩成一条工作流。它解决的不是「再做一个 CMS」，而是：在已有 ChatGPT 工作区内，用自然语言驱动 AI 生成 Web 应用，并由 OpenAI 完成托管与部署——无需单独搭建 CI/CD 或购买云主机。
本文基于 OpenAI 官方文档，梳理 Sites 的定位、上手流程、技术形态与治理要点，便于企业评估是否纳入内部工具链。
Sites 解决什么问题
传统建站或内部工具开发，往往要经历：选型框架 → 本地开发 → 配置数据库与对象存储 → 接入认证 → 编写部署脚本 → 维护域名与证书。对运营、产品或非专职前端同事来说，这条链路成本偏高。
Sites 的核心承诺是：
- 在 Codex 里通过 Sites 插件，用 Prompt 或兼容的现有项目，直接生成网站、Web 应用或小游戏；
- 保存版本（可审阅）与 部署版本（获得生产 URL）分阶段进行；
- 部署由 OpenAI 托管，每个部署 URL 即生产环境，无需自建发布流水线。
换句话说，Sites 偏向 「AI 生成 + 即时托管」，适合把想法快速变成可分享的在线地址，而不是替代完整的企业内容中台或长期演进的门户体系。
适用计划与权限
Sites 目前处于 预览（Preview） 阶段，可用范围如下：
工作区类型 | 默认状态 | 说明 |
|---|---|---|
ChatGPT Business | 默认开启 | 成员可按流程使用 Sites |
ChatGPT Enterprise | 需管理员开启 | 须在管理后台通过 RBAC（基于角色的访问控制） 为成员启用 Sites |
其他计划 | 陆续开放 | 官方称更多计划将在后续推出 |
Enterprise 场景下，管理员未在 RBAC 中打开 Sites 时，成员无法使用。这符合企业对工作区内「可对外发布资源」的管控预期。
上手五步流程
官方推荐的工作流可概括为五步：
- 启用 Sites
- Enterprise：管理员在后台 RBAC 中开启；
- Business：通常已默认可用。
- 在 Codex 应用中添加 Sites 插件
- 将 Sites 作为 Codex 的能力扩展安装。
- 用
@Sites启动任务- 在对话中
@Sites，用自然语言描述要建的站点或应用。
- 审阅：保存版本 vs 部署
- 保存版本：生成可审阅的构建，尚未对外上线；
- 部署版本：发布到生产 URL（每次部署 URL 均为生产环境）。
- 通过 Sites 侧栏回访
- 管理项目、历史版本、访问策略与密钥等。
若希望在上线前人工把关，应明确要求 Codex 「只保存版本、暂不部署」，避免未审阅的构建直接获得对外地址。
常见 Prompt 示例
官方给出的示例体现了 Sites 能覆盖的典型形态（以下为意译与归纳，便于团队内部复用）：
- 运营看板：为运营团队做一个 Dashboard，带工作区认证与持久化数据。
- 迁移既有项目：部署一个与 Sites 运行时 兼容的现有项目（需符合下文所述技术栈）。
- 带存储的小游戏：例如使用 D1 记录分数、R2 上传用户头像的轻量游戏。
这些示例的共同点是：有交互、有数据或文件、需要登录或权限——而不仅是静态展示页。
项目、版本与部署：两阶段机制
Sites 用本地配置文件把「代码仓库」与「托管实例」关联起来。
配置文件
项目根目录下的
.openai/hosting.json 用于关联本地项目与 OpenAI 托管，常见字段包括：project_id：Sites 侧的项目标识；- D1 / R2 绑定：声明持久化存储与文件存储的关联关系。
两阶段发布
阶段 | 动作 | 结果 |
|---|---|---|
Save version（保存版本） | 构建并留存快照 | 可在审阅面板检查，不自动获得对外生产 URL |
Deploy version（部署版本） | 将指定版本发布 | 获得 生产部署 URL，对外可访问 |
重要提醒：官方明确「每一次 Sites 部署 URL 都是生产部署」。没有单独的「预发环境」标签时，团队应把「保存版本」当作默认的安全阀。
支持的站点形态
Sites 托管的运行时与 Cloudflare Worker 兼容的 ES Module 模型对齐，可按数据与认证需求组合不同形态：
形态 | 典型用途 | 能力组合 |
|---|---|---|
内容站 | 落地页、说明文档、轻量门户 | 静态/服务端渲染内容 |
D1 | 结构化记录 | 分数、表单提交、配置项等 |
R2 | 文件与媒体 | 头像、附件、用户上传 |
D1 + R2 | 元数据 + 大文件 | 例如游戏档案 + 图片资源 |
Workspace auth | 仅工作区成员可访问 | 与 ChatGPT 工作区身份绑定 |
Public auth | 对外用户登录 | 面向公网访客的认证场景 |
选型时可根据「是否需要持久化」「文件是否上云」「受众是内部还是公网」三问快速收敛。
访问控制与密钥管理
访问策略
Sites 提供多种受众范围（具体选项以控制台为准），常见包括：
- admins_only：仅管理员可访问；
- workspace_all：工作区内成员可访问；
- custom：自定义访问范围。
适合内部运营工具、部门看板或限定的实验性应用；公网开放前务必与法务、安全流程对齐。
环境变量与密钥
- 环境变量应在 Sites 控制面板中配置，不要写入
hosting.json或提交进源码仓库。 - 发布前需确认：密钥未泄露、生产与测试凭据未混用、第三方 API Key 权限最小化。
这与常规云原生实践一致，但在「AI 生成代码」场景下更易被忽略——建议在团队规范中单独列出检查项。
发布前检查清单
官方 Review before share（分享前审阅） 可整理为团队可用的清单：
- 审阅面板（Review pane）：确认页面逻辑、文案与数据展示符合预期。
- 构建成功：确认 Save/Deploy 流程无报错，依赖与绑定（D1/R2）正确。
- 受众（Audience）：核对访问策略是否为
admins_only、workspace_all或custom中的预期项。 - 密钥不进源码：API Key、数据库连接串等仅在 Sites 面板配置。
- 确认部署 URL：核对最终地址是否应对外分享，避免误将内部工具发到公网渠道。
适合谁、不适合谁（简要）
更适合：
- 已在 ChatGPT Business/Enterprise 工作区、希望 快速验证 内部工具或活动页的团队；
- 需要 轻量持久化（D1/R2）的演示、小游戏、运营小面板；
- 不想维护独立部署流水线、接受 OpenAI 托管边界的场景。
需审慎评估：
- 强合规、数据主权、私有化部署为主的组织；
- 大规模多站点、多语言、长期内容治理与 DAM/KB 联动的企业门户；
- 需要与现有 CMS、SSO、审计体系深度耦合的生产级对外官网。
Sites 的价值在于 缩短从想法到可访问 URL 的路径；是否纳入正式技术栈，取决于组织对托管边界、锁定风险与内容生命周期的要求。
小结
OpenAI Sites 把 Codex 的生成能力与 OpenAI 侧的托管部署接在一起：Prompt → 保存版本 → 部署版本 → 生产 URL。技术上依托 Cloudflare Worker 生态（含 D1、R2）与多种认证形态；治理上依赖 RBAC、访问策略与面板级密钥管理。
若你正在评估「AI 建站」与「企业内容中台」如何分工，可结合团队场景阅读 companion 文章 OpenAI Sites VS Baklib：AI 建站与 AI 内容中台，怎么选？，从定位与互补关系做进一步对照。
