大家好，我是孟健。OpenAI 这次发 Sites，做的事情比表面看起来大：它在把建站、部署内部工具、跑原型验证这套动作，整体搬进 Codex 任务流里。
01｜先看它到底发了什么
Sites 是 Codex 的一个 plugin，不是独立产品。装上之后，你可以在 Codex 里 create、save、deploy、inspect 网站、Web 应用和游戏，OpenAI 负责托管和 URL。
用法很直接：给 prompt，出来一个 hosted site，有生产 URL，能访问，能分享给 workspace 成员。也支持把现有项目扔进来，让 @Sites 检查兼容性、做必要改动、给出部署地址。
当前是 preview 阶段，仅限 ChatGPT Business 和 Enterprise workspace。Business 默认开启；Enterprise 需要管理员手动在 RBAC 里授权。如果 Codex 里找不到 Sites，去 Plugins 手动添加，装完新开一个 thread 就能用。
官方文档建议写 prompt 时带三件事：audience（给谁用）、core UX（核心交互是什么）、required data or persistence needs（需要存什么数据）。这三个是把需求说清楚的最低门槛。有持久化数据或文件上传需求，要显式说明，Codex 不会猜。
文档里给了几个典型 prompt 示范：给运营团队做项目请求看板，支持提交请求、查看负责人、更新状态、按条件过滤，并要求用 workspace 账号登录；把现有项目交给 @Sites 检查兼容性并给出部署 URL；游戏应用里需要持久化存储玩家分数和头像上传。这三类覆盖了从轻量内容展示到带状态应用的主要场景，代表了 Sites 当前能承接的典型需求。
02｜真正关键的，是 save / deploy / permission
Sites 的机制里有一个细节值得单独说：每一次部署的 URL 都是生产部署（production deployment）。
没有测试环境。想先 review 再上线，要明确让 Codex "save a version"（不 deploy），看完再决定要不要发布。发布分两步：save version 先把 build 做好并关联 Git commit；deploy version 才是真正上线。这个设计强迫你在部署前想清楚这次改动值不值得发。
官方文档还把站点区分成几种类型，对应不同的存储方案：纯内容或落地页不需要持久化状态；需要保存记录、用户进度或游戏分数的，用 D1 关系型数据库；图片、视频、文档等文件用 R2 对象存储；需要可搜索元数据的文件上传场景，D1 和 R2 同时用。D1 和 R2 都来自 Cloudflare 生态。这说明 Sites 的后端存储能力接在 Cloudflare Workers 体系上，而不是只停留在前端页面生成。对开发者来说，这个信号很关键：它已经开始处理数据持久化、文件存储和部署边界。
.openai/hosting.json 这个文件存放项目的 linkage 和 storage binding names。这个细节说明 Sites 在管理项目、版本、存储绑定之间的关系------它有版本管理逻辑，不是临时生成一个页面就完事的工具。
权限层面：Business 和 Enterprise 的分层，说明 OpenAI 在往企业内部工具场景上想。团队协作、审查流程、访问控制，这些在里面都有位置。
这些机制放在一起，比"用 AI 生成了一个网页"要重得多。它在管的是：谁能发、发什么版本、绑了什么数据。
03｜它为什么会让 Lovable/Replit 难受
Lovable 和 Replit 的逻辑是：你主动去它们的平台做东西。
Codex Sites 的逻辑是：你在 Codex 里做任务，顺手把结果部署出来。
入口位置不同，整个工作流的重心就不同。一旦"做站"变成任务流里的一个步骤，用户就不用切换工具------选题、写内容、做原型、发布，都在同一个 agent 任务里完成。
OpenAI 官方公告（2026-06-02）里提到，Codex 每周用户超过 500 万，非开发者占比约 20%，这部分用户的增速是开发者的 3 倍以上。Codex 从编程工具起步，正在向非编程工作流渗透。Sites 是这个方向上的一步------让非程序员也能在 Codex 里产出可以访问的、可以演示的东西。
第三方评测的观察值得看一眼。Masset 有一篇评测，标题直接写的是：
"OpenAI's Codex Can Build You a Full App in 23 Minutes. It Just Won't Let You Share It."
做出来没问题，23 分钟。但当前分享和公开访问有限制，官方也没给出完整的对外发布路径。
这个限制短期是障碍，长期看可能是保护期。Business/Enterprise 范围内跑通，再扩开放，Codex 已有的 5M 周活用户基数就是正面优势。Lovable/Replit 面对的是入口层面的压力------用户用 Codex 做东西，自然就用 Codex Sites 发东西，平台切换的动力就消失了。
04｜我会怎么用它
我看完官方文档后，第一反应是：特定场景现在就能上手。
适合的场景：
- 内部工具（团队内访问，不依赖公网开放）
- 活动页、临时运营页
- 数据看板、指标展示
- 产品原型，给团队或投资人演示用
- 可丢弃的小应用，验证完就撤
现阶段不适合的场景：
- 需要掌控域名的工具站
- 要接支付、登录体系、SEO、边缘部署的正式产品
- 长期维护、有成本结构要求的项目
- 需要公开访问、SEO 导流的出海内容站
做工具站，或者任何靠搜索流量的产品，Sites 现阶段解决不了。你仍然需要 PRD、选词、设计、研发、QA、真实域名、分析埋点、数据复盘这整套闭环。Sites 更像是把最早 20% 的"原型验证成本"压下来------把"从想法到能演示的东西"这段路缩短。
但这个 20% 本来就是卡人最多的地方。很多项目死在"还没做出来就放弃"这一步，如果 Sites 能把这段路从两天缩到两小时，这个价值是实的。
往后程序员真正的分水岭，可能是能不能把任务范围、上下文边界、验证标准、部署条件说清楚。说清楚了，Codex + Sites 做的事情就精准；说不清楚，出来的东西再快也是废的。
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏