Codex 能直接部署云端服务了，互联网公司会怎么变？

OpenAI 在 2026 年 5 月给 Codex 加了一个功能，叫 Sites in Codex。

之前你用 Codex 写代码——写完跑在本地，或者 push 到 GitHub 再部署到 AWS。现在不一样了。Codex 写完代码，直接在 OpenAI 的服务器上帮你跑起来，给你一个 URL，立即可用。

财经负责人把一个 Excel 扔给 Codex，几分钟后得到一个交互式的情景规划器，高管在浏览器里直接调参数看结果。不需要前端开发、不需要运维部署、不需要买云服务器。

这个变化对互联网企业的影响，不是「少招几个开发」那么简单。

一、内部工具的开发和运维消失

大部分互联网公司里，业务团队的需求结构是这样的：80% 是内部工具——运营后台、数据看板、审批流程、报表系统。这些工具的逻辑不复杂，但占用了大量前端、后端、运维的产能。

Sites in Codex 直接干掉了这条链路。

以前做一个运营数据看板的流程是：运营提需求 → 产品出 PRD → 前端开发 → 后端写接口 → 运维部署 → 运营验收。周期两周起步。现在运营自己在 Codex 里描述需求，几分钟出一个能用的链接。

不是「效率提升」，是某些岗位的存在依据消失了。 内部工具的前端开发、部署运维——这两个角色在 Sites in Codex 覆盖的场景里没有增量价值。

二、云计算厂商失去了「内部工具」这块肉

互联网公司在 AWS、阿里云上的支出，有很大一块不是核心业务，是内部工具。几十个后台系统、上百个数据看板、数不清的一次性分析页面。

Sites in Codex 把这些负载从 AWS/阿里云转移到了 OpenAI 的服务器上。对云厂商来说，这不是流失了一两个大客户的问题——是长尾里的无数中小负载正在被 OpenAI 吃掉。

Sites 托管在 OpenAI，这意味着 OpenAI 从一个「卖 API 的模型公司」变成了一个「卖托管服务的云平台」。Alphabet 的推理云 + Codex Sites 的部署云——OpenAI 正在悄悄切进 AWS 的腹地。

三、对安全合规是噩梦，对业务是美梦

一个银行的数据分析师把敏感客户数据扔进 Codex 生成了一个交互看板，链接发给了全部门。安全团队不知道这个看板存在于 OpenAI 的服务器上，不知道数据经过了哪些模型，不知道链接有没有被外部访问。

Sites in Codex 创造了一个安全治理的黑洞。

Codex 的管理平台允许管理员集中控制 Sites 的开启和权限——但这个工具刚上线，大部分企业的安全策略还没跟上。在策略跟上前，Sites 是企业里最大的数据泄露风险之一。

对业务团队来说是天堂——想做什么几分钟搞定。对安全团队来说是地狱——他们甚至不知道天堂里发生了什么。

四、组织结构的隐形解构

Sites in Codex 不是技术变革，是组织变革。

以前一个需求从业务到交付，中间经过产品经理、前端、后端、运维——这些人构成了组织的中间层。Sites in Codex 让「描述需求」和「获得交付」之间的距离缩短到了一个对话。

结果是：中间层的存在价值被消解。不是「被裁了」，是「没有增量可以交付了」。一个运营自己十分钟搞定的看板，你告诉他要排两周的迭代——他不会觉得你在做质量把控，他会觉得你在挡他的路。

组织里最大的危机不是人太多，是人没有增量输出。Sites in Codex 加速了这一天的到来。

五、但别高估——它还有一个致命天花板

Sites in Codex 能跑的是无状态、无需持久化数据库、无需复杂认证的轻量应用。交互看板、情景规划器、一次性分析页面——这些可以。但一个有用户系统、需要事务性数据库、需要 API 网关的完整 SaaS 产品——不行。

OpenAI 在 Sites 的文档里写得很清楚：这是一个开发预览环境，没有持久化数据库、没有自定义域名、没有生产级 SSL。它和 Heroku、Vercel 的生产部署是两回事。

所以 Sites in Codex 真正吃掉的是三样东西：

• 内部工具开发的人力
• 云厂商的长尾负载
• 低代码平台的生态位

它不是要取代 AWS，是要让业务团队绕开开发团队。

最后一句

Sites in Codex 不会让互联网公司关门。但它会让公司内部问一个以前不会问的问题：你这个岗位，在「描述需求」和「获得交付」之间，到底提供了什么增量？