OpenAI Sites 今天发布:把 Codex 从“代码生产”推进到“基于语言的软件交付工具”

今天 OpenAI 发了 Codex Sites。

官方描述：Codex 可以把你的 work、ideas、plans 变成 interactive website or app，并生成一个 URL，让团队可以打开、使用和分享。

实际上隐藏了Codex Sites 的战略信号：OpenAI 正在压缩 idea → demo → production →feedback → delivery 的完整链路。

官方文档：https://developers.openai.com/codex/sites

语言正在成为 build 一切的起点。

Codex 更多解决的是“怎么写代码”。现在 Sites 开始解决另一个更靠近用户的问题：怎么把想法、计划和工作流，变成一个别人可以直接打开、点击、体验和反馈的产品结果。用户最终要的从来不是代码，而是一个能被使用的东西。团队最终讨论的也不应该只是文档，而应该是一个可以被体验的版本。

从产品视角看，这件事的重点不是“AI 又能写更多代码了”，而是产品交付链路正在改变。渲染出来的“表面”会越来越便宜，藏在底下的“控制面”会越来越值钱。

正文目录：

01 Site是什么？和Codex的关系是什么

02 Webpage终于要变成App了

03 AI会慢慢隐藏在结果背后

04入口会吃掉轻页面，重交互会留下来

05 未来表格可能就是最后一公里

06 再往后看，几个方向

刷到这条twi之前，今天和朋友聊，刚好聊到一个判断：以后大量网页应用，可能会被 AI 的"入口"直接吃掉，只有那些交互很重、体验很强的产品才留得下来。结果下午这条消息就发了出来。所以想趁热写写我的看法。

01 | Site是什么？和Codex的关系是什么？

Codex 原本更像一个软件工程 Agent。你可以让它读代码、改代码、修 bug、做功能、提 PR。它解决的是“把工程任务往前推进”的问题。

Sites 是 Codex 新增的一个能力。它让 Codex 的产出不再只停留在代码、文件、文档或 PR，而是可以变成一个可部署、可访问、可分享的网页或应用。

简单说，Codex 负责做，Sites 负责把做出来的东西变成一个可打开的结果。

官方文档给的例子很典型：

你可以让它给运营团队做一个项目申请看板，团队成员能提交申请、看到每件事谁负责、修改状态、筛选列表，同时要求用工作区账号登录，数据下次打开还在。说完这一句，出来的就不是一段代码说明，而是一个能给团队使用的内部工具。

过去很多 AI coding 或 vibe coding 工具，基本上是把页面快速生成出来。你能很快得到一个看起来不错的前端，一个能点的 Demo，一个可以展示的版本。

但很多时候，这个结果更像静态样板间：打开能看，过两天还是同一份内容。数据不会持续更新，状态不会自动流转，用户行为也很难进入后续业务流程。

Sites 这类能力往前走一步。它开始把“生成页面”推向“部署应用”。它关心的不只是页面能不能生成，也开始处理页面背后更接近产品化的问题：数据能不能保存，文件能不能上传，用户能不能登录，访问权限能不能控制，版本能不能保存和部署。

Sites产品的进一步拆解：

Sites 是 Codex 里的一个“轻应用生成 + 托管 + 权限 + 数据存储”能力。

让 Codex 可以把一句需求、一个现有项目，直接变成一个托管在 OpenAI 上、能保存数据、能控制访问权限、能拿到生产 URL 的网站 / Web App / 游戏。从“Codex 帮你写出代码”到“Codex 帮你把一个能用的应用发布出来”之间的最后一段距离。

它具体能干什么

根据官方文档，Sites 可以让 Codex create、save、deploy、inspect websites、web apps 和 games，并且这些应用由 OpenAI 托管。用户不需要自己搭一套额外的部署流程。

所以它不是只生成一段前端代码。

它和普通 vibe coding 最大的区别

普通 vibe coding 很多时候生成的是一个“能看的页面”或“能点的 Demo”。Sites 更进一步，它开始做“能运行的小应用”。

文档里明确提到，它支持几类应用形态

内容型网站或 landing page；

需要保存记录、用户进度、游戏分数的应用，可以用 D1 关系型数据库；

需要上传图片、文档、音频、视频等文件的应用，可以用 R2 对象存储；

需要文件和可搜索元数据的应用，可以同时用 D1 和 R2；

内部工具可以使用 workspace 用户身份；

公开登录场景也可以做 authentication-enabled Sites project。

我会把 Sites 拆成 5 个模块

1. Prompt-to-App

用自然语言描述网站、Dashboard、内部工具或游戏的需求。说清楚 audience、core experience 和 required data，例如谁使用、核心体验是什么、需要保存什么数据。

2. 托管与部署

Sites 会把项目变成 hosted site，并给你 production URL。每个 Sites deployment URL 都是生产部署。如果只是想 review，需要先让 Codex 保存版本，不要直接部署。

3. 版本管理

它区分 Save version 和 Deploy version。Save 是生成一个可审查的部署候选版本；Deploy 是把已保存版本发布出去，并返回生产 URL。

4. 数据与文件存储

D1 负责结构化持久数据，比如记录、进度、分数；R2 负责文件上传，比如图片、文档、音频、视频。

5. 权限与访问控制

部署前可以设置访问范围：仅 owner 和 admins、整个 workspace、或指定用户 / 用户组。文档也提醒，分享前要先确认内容、数据处理方式和目标受众。

02 | Webpage 终于要变成App了

我觉得 Sites 这件事最值得关注的地方，是它把 Webpage 和 Web App 之间的距离拉近了。

过去很多轻量网页，本质上是在卖一件事：把信息、一点逻辑、一个界面，固定在一个可以打开的网址上。

一个简单报名页，一个静态作品集，一个一次性活动看板，一个销售 Demo，一个客户专属展示页，一个轻量内部工具，都是这种形态。它们未必需要很复杂的系统，但它们解决了一个很具体的问题：让一个想法、一个方案、一个流程，快速变成别人能打开、能看、能操作的东西。

很多时候，一个网页就是一次转化的入口，一次客户沟通的抓手，一次落地前最快速的成果展示。

AI 生成页面之后，这部分成本开始下降。网页会越来越像 AI 入口随手生成的临时工作界面。

但 Sites 往前推了一步。

它的重点不只是让页面更快生成，也在尝试把页面接到更接近应用的底层能力上：数据库、文件存储、workspace identity、访问权限、版本、部署、环境变量和 secrets。

这些能力决定了一个页面能不能从“展示”继续走向“运行”。

比如一个报名页，如果只是展示活动信息，它是一个网页；如果它能保存报名数据、区分访问权限、上传附件、记录状态、下次打开数据还在，它就开始接近一个小应用。

一个销售 Demo，如果只是给客户看一套页面，它是一次展示；如果它能接客户数据、记录试用状态、根据权限展示不同内容、把反馈同步给团队，它就开始进入真实业务流程。

所以我觉得 Sites 打开的机会，主要在非技术用户这一侧。

产品经理、运营、销售、创作者、创业者过去都能描述需求，也知道业务应该怎么跑，但经常卡在“做出来”这一步。现在他们可以先把需求讲清楚，让 AI 生成一个能打开的版本，再进一步把数据、权限、文件、访问和部署接进去。

这会让很多想法更快进入验证阶段。这也是我觉得 Sites 值得关注的原因：它让“网页生成”开始靠近“应用生成”，也让更多非技术角色有机会直接参与产品创造。

03 | AI 会慢慢藏到结果背后

我觉得 AI 接下来会越来越像水电煤。它会变得非常基础，非常重要，但用户不会一直关心它本身。

就像我们打开灯的时候，不会讨论今天用了什么发电系统。我们只关心灯有没有亮，房间有没有变得更舒服。

AI 也会走向这个方向。很多用户不会一直关心这个产品是不是 AI-native，用了哪个模型，接了哪个 agent framework。大家会更关心结果：这个页面能不能用，这个工具能不能跑，这个流程有没有省时间，这个结果能不能交付。

这也是 Sites in Codex 这类产品有意思的地方。它把 AI 从“聊天窗口里的回答”，继续推向“可以打开的结果”。

这背后是一个很大的产品变化：AI 的价值正在从生成内容，走向交付结果。

04 | Agent入口会吃掉轻页面，重交互会留下来

过去我们上网，入口是浏览器和一个个网址。查天气开天气网站，记账开记账软件，报名开报名页，做客户管理开 CRM，做数据分析开 Dashboard。

一个需求，对应一个独立网站或 app。

现在的变化是，你可能不再一个个打开网站，而是直接对一个 AI 说话，让它帮你把事情推进。AI 正在成为新的入口。

这对很多轻网页会有冲击。因为市面上大量网站的本质，就是把一个流程搬到页面上。信息、操作、结果，被摆进一个界面里。用户点几下，提交一个表单，看到一个列表，下载一个结果。

那些需要深度交互、沉浸式体验和长期使用习惯的产品会留下来。

比如游戏就是一个很典型的例子。玩家进入游戏，不只是为了完成某个任务，而是在一个持续运行的世界里探索、成长、竞争和社交。它依赖实时反馈、视觉表现、操作手感、关卡设计、角色成长和情绪体验，这些都不是一句话生成一个页面就能替代的。

类似的还有一些专业创作工具、复杂协作产品以及需要长期积累用户行为和内容生态的平台。用户使用它们，不只是为了得到一个结果，而是在不断互动的过程中获得体验本身。

这些产品的价值往往来自持续的交互过程，而不是一次性的任务完成。

05｜未来表格可能就是最后一公里

页面好做，难的在后面。

用餐厅打个比方：菜单做得再漂亮，决定餐厅能不能转起来的，是后厨、库存、收银、排班、供应链。

软件也一样。一个页面生成出来，真正的问题才开始：数据存在哪、用户怎么登录、谁能看谁能改、怎么收钱、怎么发邮件、出错了怎么处理。这些加起来，才是"最后一公里"。

我一直有个看法：很多业务转一圈，结论都会落回一张表。

活动报名，最后是一张表：谁报了、什么身份、确认没、付款没、到场没。销售流程，客户是谁、预算多少、推进到哪一步、谁负责跟进。内容平台，谁交了稿、审核到哪、奖励多少、发了没。

所以我一直看好 Airtable 这类"多维表格"产品。表格这东西有三个好处：业务的人看得懂、机器（AI）读得动、状态改起来灵活。人用它看进度，AI 用它读数据、改状态、触发下一步。Notion 数据库、飞书多维表格、Supabase 这些，骨子里都在做同一件事——接住 AI 干完活之后的"业务状态"。

这里有个特别值得说的细节。这次 Sites 其实已经把"最后一公里"的一部分自己做了。

翻官方文档你会发现，它内置了两种存储：一种叫 D1，是关系型数据库，专门存结构化数据，说白了就是"表"；一种叫 R2，用来存图片、文件这类东西。它还支持用工作区账号登录、设置谁能访问（只给管理员、给全公司、或者指定的人），底层跑在 Cloudflare 的托管环境上。

Notion 数据库、飞书多维表格、Supabase、Retool、Zapier、Make、n8n，这些产品看起来形态不同，底层都在做一件事：接住业务状态，让流程可以继续跑。

这也是我为什么觉得表格的展示会成为 AI 时代很重要的交付层。

AI 负责生成和执行，表格负责承接状态。人可以看懂，Agent 可以操作，业务可以继续流转。

06 | 再往后看，几个方向

顺着"价值往下沉"这条线，几个我比较看好的方向。

关键控制权。页面底下真正的命脉，是登录、权限、数据、支付握在谁手里。前端决定"看得见"，后端决定"跑得动"，控制权决定"谁说了算"，最后这一个才是壁垒。

表格当 AI 的业务总账本。表会从"人用来记录的工具"，变成"人和 AI 共用的状态层"。

支付变成链接和交付的一部分。一个页面能打开只是第一步。它能不能收钱、分权限、记住用户、付款后自动进入下一步，决定了它是个玩具还是个产品。支付会和访问权限、用户身份、数据记录绑在一起，成为交付闭环的一环。

写在最后

说回今天这条消息。表面上，它就是 Codex 多了一个能生成网页和应用的功能。

往大里看，它说明一件事正在发生：做 App 的门槛，正从"会写代码"往"讲清楚需求、组织好数据、跑通交付"这个方向移动。

页面会越来越容易做，demo 会越来越容易分享，把一个想法变成一个网址会越来越快。真正值钱的东西会继续往后沉：后端、权限、支付、数据管理、行业 know-how，以及把这一切串起来的那张表。

AI 也会慢慢藏到结果背后，像水电煤一样。

我们打开灯的时候不会去想用了哪种发电方式，只关心灯亮没亮、屋里舒不舒服。

AI 最后也会走到这一步，大家关心的还是那几个朴素的问题：这玩意能不能用、跑不跑得起来、能不能真的交付出结果。