夜雨聆风6 月 2 日，OpenAI 在 Codex 里悄悄加了一个叫 Sites 的东西。
官方 changelog 只写了一段话：
"Use the Sites plugin to create, save, deploy, and inspect websites, dashboards, internal tools, web apps, and games hosted by OpenAI."
看起来像是给 Codex 加了个托管插件。但如果你把这件事放进 AI 编程的发展 timeline 里看，它释放的信号比大多数模型更新都要大。
AI 编程的三个阶段
先说结论：Sites 标志着 AI 编程进入了第三阶段。
第一阶段（2023-2024） AI 帮你写代码片段
│ GitHub Copilot 自动补全、ChatGPT 生成函数
│ 你是建筑师，AI 是搬砖的
│ → 效率提升约 30-50%
│
第二阶段（2024-2025） AI 帮你完成整个功能
│ Codex Agent、Claude Code、Cursor Composer
│ AI 能独立完成一个 feature 从设计到提交 PR
│ 你是项目经理，AI 是施工队
│ → 效率提升约 2-5x
│
第三阶段（2026→） AI 帮你拥有一个上线产品 ← 我们在这里
│ OpenAI Sites：说一句话，得到一个可访问的 URL
│ 不需要懂 Git、不需要配服务器、不需要管部署
│ 你是提需求的人，AI 是总承包商
│ → 效率提升？可能是 10x，也可能是重新定义"开发"这个阶段跃迁的核心变化不是"AI 写代码更厉害了"，而是 AI 开始触碰代码以外的事情——数据库、存储、身份认证、域名、HTTPS、权限控制。
这些东西过去属于后端工程师和 DevOps 的领地。现在 OpenAI 把它们全部打包进了 @Sites 一个命令里。
Sites 到底是什么？
用最直白的话说：
你在 Codex 里用自然语言描述一个应用，Codex 生成代码 + 自动配置数据库 + 配好文件存储 + 接入身份认证 + 部署上线，最后给你一个可以直接打开的 URL。
具体来说，Sites 做了五件事：
| # | 能力 | 过去怎么做 | 现在 |
|---|---|---|---|
| 1 | 生成应用 | 手写代码 / 用低代码平台拖拽 | @Sites 描述需求，Agent 生成 |
| 2 | 版本管理 | Git commit + PR review | 自动关联 Git，可审查的发布候选 |
| 3 | 部署上线 | 配 CI/CD、买域名、开 HTTPS | 一键发布为生产 URL |
| 4 | 后端服务 | 自己接数据库、对象存储、Auth 服务 | 内置 D1(数据库) + R2(存储) + 工作区身份 |
| 5 | 权限控制 | 写 RBAC 中间件、配 OAuth | 仅管理员/全工作区/自定义群组，密钥不进源码 |
举一个具体的例子。假设你是团队负责人，需要做一个内部任务看板：
你在 Codex 里输入：
"@Sites 帮我做一个团队任务看板，
支持按状态分类（待办/进行中/已完成），
能拖拽排序，数据要保存不会丢，
只有我们工作区的人能访问"接下来发生的事情：
第一步，Codex Agent 生成完整应用代码 前端看板界面 + 拖拽逻辑 + 后端 API + 数据库 Schema。
第二步，自动配置基础设施 D1 创建任务表（id、标题、状态、优先级、创建时间、负责人），R2 准备附件存储空间，接入工作区 OAuth 身份。
第三步，预览和迭代 你在 Codex 里看到实时预览，发现少了截止日期字段——直接在界面上标注 "这里加上 deadline"，Agent 立刻修改。
第四步，保存和部署 满意了点一下 "Deploy"，获得一个 https://xxx.site.openai.com 链接。团队成员打开就能用。
整个过程，你没有写过一行代码，没有碰过 Git，没有登录过任何云控制台。
架构拆解：Sites 底层用了什么？
这是最有意思的部分。根据公开文档和 TechCrunch 的报道，Sites 的底层技术栈长这样：
┌──────────────────────────────────────────┐
│ 用户 (自然语言) │
│ "@Sites 做一个 xxx" │
└────────────────────┬─────────────────────┘
↓
┌──────────────────────────────────────────┐
│ Codex Agent (GPT-5.3-Codex) │
│ 理解需求 → 生成代码 → 配置基础设施 │
└────────┬─────────┬──────────┬────────────┘
↓ ↓ ↓
┌────────┐ ┌──────────┐ ┌────────────┐
│ D1 │ │ R2 │ │ 工作区身份 │
│ 边缘SQL │ │ 对象存储 │ │ (Auth) │
│ │ │ │ │ │
│ • 任务表│ │ • 附件 │ │ • 登录验证 │
│ • 用户表│ │ • 截图 │ │ • RBAC │
│ • 配置表│ │ • 构建产物│ │ • 租户隔离 │
└────────┘ └──────────┘ └────────────┘
↘ ↙
┌──────────────────────────────────────────┐
│ OpenAI 托管运行时 (Cloudflare) │
│ 边缘计算 + 自动扩缩容 + HTTPS + CDN │
└──────────────────────────────────────────┘
↓
┌──────────────────────────────────────────┐
│ https://your-app.site.openai.com │
│ （生产环境 URL） │
└──────────────────────────────────────────┘三个关键组件值得展开说：
D1：不是随便选的数据库
D1 是 Cloudflare 出品的边缘关系型数据库（基于 SQLite，兼容 SQL 语法）。选择它而不是 PostgreSQL 或 MySQL，原因很聪明：
- 冷启动快：边缘节点就近执行查询，不用绕到中心数据中心 - 零配置：Agent 可以通过声明式 API 直接建表、迁移、查数据 - 按量计费：每个 Sites 应用自动隔离，多租户友好 - 够用就行：内部工具/看板/轻量 App 不需要 PostgreSQL 的全部能力
换句话说，D1 解决的是 "AI 生成的应用，数据放哪？" 这个最基础的问题。
R2：对象存储的必然选择
R2 是 Cloudflare 的 S3 兼容对象存储（出口流量免费）。真实应用一定会遇到文件：用户头像、图片附件、导入导出文件、前端构建产物。
如果没有默认的对象存储，Agent 就得为每个应用临时选方案、配权限、处理上传下载逻辑——生成链路会变得极不稳定。R2 让这一层变成"默认就有"。
身份认证：为什么重要？
Sites 不只是部署静态页面。它支持工作区身份——意味着生成的应用可以知道"谁在用它"。
这对企业场景至关重要：一旦生成的应用要给真实用户使用（哪怕只是团队内部），就必须有登录、权限、数据隔离。否则你做的只是一个所有人共享的演示页面，不是一个真正的工具。
和现有方案对比：Sites 在哪个位置？
市场上已经有不少"帮你做应用"的产品。Sites 跟它们有什么不同？
| 维度 | 传统开发 | 低代码平台 (钉钉宜搭/微搭) | Vercel + Supabase | OpenAI Sites |
|---|---|---|---|---|
| 输入方式 | 写代码 | 拖拽+配置 | 写代码 + CLI | 自然语言 |
| 谁在使用 | 开发者 | 业务人员/开发者 | 开发者 | 任何人 |
| 数据库 | 自己搭 | 平台内置 | 自己接 Supabase 等 | 内置 D1，自动建表 |
| 存储 | 自己接 S3/OSS | 平台内置 | 自己接 R2/S3 | 内置 R2 |
| 身份认证 | 自己接 Auth0 等 | 平台内置 | 自己接 Clerk 等 | 内置工作区身份 |
| 部署 | CI/CD + 运维 | 一键发布 | Git Push 自动部署 | 一键部署，无需 Git |
| 灵活性 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 上手门槛 | 极高 | 低 | 高 | 极低 |
| 适合场景 | 复杂 SaaS | 内部简单应用 | Web 应用/API | 轻量工具/看板/Dashboard |
关键区别不在功能列表，而在 交互范式：
- 低代码平台是"你告诉它每一步怎么做" - Sites 是"你告诉它你要什么，它自己搞定每一步"
这不是量变，是质变。
为什么国内云厂商昨天就急了？
腾讯云开发的公众号在 Sites 发布 几小时内 就发了一篇深度文章（《从 OpenAI Sites 到 CloudBase》），核心论点是：
国内版 Sites 的关键不是再做一个 Coding Agent，而是为已有 Agent 提供可被模型稳定调用的 Backend Cloud。
反应速度说明了两件事：
第一，他们看懂了 Sites 的本质。
Sites 的壁垒不在 Codex 的代码生成能力——那块国内大厂都在追。真正的壁垒在于 D1 + R2 + Auth + 托管部署 这套组合基础设施。谁先能把这套东西做成"AI 可调用的标准接口"，谁就能在国内复现 Sites 的体验。
第二，这个市场太大了。
如果"说一句话就能得到一个可用应用"真的走通了，那受影响的不仅仅是开发者工具市场——而是所有企业内部工具的生成方式：
- HR 不再等 IT 做招聘面板，自己用 AI 生成 - 销售不再等产出自定义 CRM，自己描述需求 - 运营不再等开发做活动页，@Sites 搞定
每一个原来需要"提需求→排期→开发→测试→上线"的流程，都可能被压缩成一句话。
但 Sites 也有明显的问题
作为一篇分析文章，不能只说好的。
第一，锁定效应极强。
你的应用跑在 OpenAI 的托管环境里，用的是他们的数据库、存储、身份系统。一旦业务复杂度超过 Sites 的能力边界，迁移成本会非常高——相当于要把整个基础设施重写一遍。这跟当年整个行业担心被 AWS/Azure 锁定是同一个问题，只不过这次锁定的是 AI 时代的"操作系统"。
第二，Preview 阶段的限制还很多。
目前只面向 ChatGPT Business 和 Enterprise，定价未公布，不能用自己的域名（只能用 .site.openai.com 子域），应用类型有限制（轻量 Web App，不是复杂 SaaS）。这些限制什么时候放开、怎么收费，都还是未知数。
第三，"AI 生成"的质量边界到底在哪？
简单看板、表单、Dashboard，AI 生成没问题。但涉及复杂业务逻辑、特殊合规要求、高性能需求的场景，@Sites 生成的代码大概率不够用——到时候你还是得找开发者来改。问题是：改 AI 生成的代码，往往比自己从头写更痛苦。
我的判断
Sites 不是又一个 AI 功能。它是 OpenAI 在回答一个更根本的问题：
当 AI 能写代码之后，下一步是什么？
答案是：让不需要写代码的人，也能拥有自己的数字工具。
这个方向不一定由 OpenAI 最终赢——国内的字节（豆包+Coze）、百度（智能体+千帆）、阿里（通义+云原生），都有类似的拼图。但 OpenAI 是第一个把"自然语言 → 上线应用"这条路走得这么完整的公司。
对开发者来说，短期不必恐慌——Sites 目前能替代的都是最简单的 CRUD 应用。但值得开始思考的问题是：如果你的核心竞争力是"能做简单的内部工具"，那这份竞争力可能只剩两三年了。
而对产品和运营同学来说，这是一个值得兴奋的信号——你们离"自己做出想要的东西"，从来没有这么近过。
