500万用户背后，Codex Sites爆发

OpenAI Codex 正在从“开发者写代码的助手”，进一步转向“企业全员可用的 AI 工作流入口”。随着 Codex Sites 功能上线，用户不再需要从零搭建服务器、配置数据库、购买域名或处理 SSL 证书，只需要用自然语言描述需求，就能生成一个可托管、可访问、可协作的交互式企业网页或内部看板。

如果说过去的 Codex 更像一名“AI 编程搭档”，那么 Sites 的出现，则让它更接近一个面向企业场景的 AI 智能体构建平台。它不仅能理解用户需求，还能根据业务目标自动生成页面结构、交互逻辑、数据存储方式和访问权限，让运营、销售、产品、分析师等非技术岗位，也能在几分钟内搭建出可实际使用的内部工具。

据调查，Codex 目前已经拥有超过 500 万周活用户，其中非技术使用者占比达到 20%，并且增长速度是开发者用户的 3 倍。这组数据说明，AI 编程工具的使用边界正在迅速外扩：它不再只服务程序员，而是开始进入更广泛的企业岗位。Sites 被业内称为“打工人版 WordPress”，背后反映的正是企业内部工具开发方式的变化。

---

一、Sites是什么：不是生成网页，而是生成可运行的内部应用

很多 AI 工具都能生成 HTML、CSS 或 React 组件，但 Codex Sites 的重点并不只是“帮你写一个页面”。它真正的价值在于：生成的是一个可以托管、可以保存数据、可以分配权限、可以直接访问的交互式站点。

用户可以这样向 Sites 发出指令：

@Sites Build a project request dashboard for my operations team. Let team members submit requests, see who owns each one, update the status, and filter the list. Require people to sign in with workspace account, keep the request data saved between visits.

这段提示词的含义非常明确：为运营团队创建一个项目需求看板，团队成员可以提交请求、查看负责人、更新状态、筛选列表，并且必须通过工作区账号登录，同时保存每次访问之间的数据。

在传统开发流程里，这样一个小工具至少需要产品描述需求、前端开发页面、后端设计接口、数据库保存数据、权限系统控制访问，最后还要部署上线。但在 Sites 模式下，这些工作被压缩成了一段自然语言指令。用户不需要理解前端框架、数据库表结构或云部署流程，只要描述清楚业务目标，AI 智能体就能自动完成从页面到应用的基本搭建。

这也是 Sites 和普通“AI 代码生成器”的最大区别：它不是停留在代码层，而是向“应用层”进一步延伸。

---

二、底层架构：Cloudflare Workers + D1 + R2支撑可托管应用

Codex Sites 之所以不只是一个“网页生成器”，关键在于它背后有完整的云端运行能力。

据了解，Sites 的运行环境基于 Cloudflare Workers。这意味着生成的站点可以运行在全球边缘节点上，具备较好的访问速度和弹性扩展能力。相比传统服务器部署，边缘运行时更适合轻量级内部工具、看板页面和企业协作型应用。

在数据层面，Sites 采用了两类存储能力：

• D1 关系型数据库：适合保存结构化业务数据，例如请求列表、状态字段、负责人、提交时间等；
• R2 对象存储：适合保存图片、文档、附件等非结构化文件。

这种设计让 Sites 可以覆盖很多常见企业内部工具场景。例如项目需求管理、销售客户跟进、活动报名页面、部门资产登记表、数据仪表盘等，都不再只是一个静态页面，而是能够真正保存和更新数据的轻应用。

从技术视角看，Sites 把过去分散在前端、后端、数据库、对象存储、部署平台之间的复杂流程，封装到了一个由 AI 驱动的生成链路中。用户看到的是“一句话生成网页”，企业 IT 管理者看到的则是“低代码/零代码内部工具的自动化生产能力”。

---

三、Save与Deploy：两段式发布降低企业使用风险

企业内部工具最怕的不是“做不出来”，而是“未经审核就上线”。尤其当 AI 能够快速生成页面和功能时，发布流程如果缺少控制，很容易出现权限泄露、数据错误或合规风险。

因此，Sites 采用了两段式发布流程：

第一步是 Save。用户生成站点后，可以先保存项目，并绑定 Git 版本，用于内容审查、版本管理和团队确认。这个阶段相当于内部预览，不会直接变成正式线上应用。

第二步是 Deploy。确认功能、内容和权限无误后，再部署成正式访问链接，供团队成员使用。

这种设计非常重要。它说明 Sites 并不是简单地鼓励用户“生成即上线”，而是在 AI 自动化和企业治理之间保留了一道必要的审核关卡。对于企业来说，AI 智能体可以提高效率，但不能完全绕过内部管理流程。Save 与 Deploy 的分离，正是为了让自动生成能力与组织治理机制保持平衡。

---

四、三类权限控制：从个人预览到团队协作

Sites 还提供了三类访问权限，用于适配不同企业场景：

admins_only
workspace_all
custom

其中，admins_only 表示仅管理员可访问，适合测试阶段、敏感页面或初始配置页面；workspace_all 表示整个工作区成员都可以访问，适合公司公告、团队看板、通用流程页面；custom 则支持自定义白名单用户，更适合跨部门项目、特定小组协作或权限更细的业务页面。

这套权限模型虽然不算复杂，但已经覆盖了大部分轻量级内部工具的基本需求。对于非技术岗位来说，它降低了权限配置门槛；对于企业管理员来说，它也提供了最基础的可控边界。

不过，这里也引出了一个现实问题：当越来越多员工可以自己生成工具时，企业内部可能出现大量未经统一规划的“影子 IT”。这些工具可能短期提高效率，但如果缺少统一审查、数据归属和生命周期管理，长期也可能带来安全与维护问题。

---

五、六大角色插件：AI智能体从写代码走向做业务

Sites 的意义不只是建站，它更像是 OpenAI 企业 Agent 战略中的一个展示窗口。Codex 同步上线了 6 类垂直角色插件，覆盖数据分析、创意、销售、产品设计、股权投资/投行等企业岗位，并打通 Snowflake、Salesforce 等数十款 SaaS 工具。

这些插件的价值在于：它们让 AI 智能体不再只是回答问题，而是可以进入真实业务系统中执行任务。

例如，数据分析插件可以连接 Snowflake、Databricks、Tableau，帮助用户用自然语言查数、生成报表和可视化图表；创意插件可以对接 Figma、Canva，批量生成营销素材；销售插件可以联动 Salesforce、HubSpot，自动整理客户档案、生成拜访资料；产品设计插件可以依托 Figma 快速迭代原型；股权投资与投行插件则可以接入 标普、穆迪、PitchBook，辅助整理财报、行业资料和尽调文档。

在这个流程中，插件负责连接业务数据和工具，Sites 负责把结果封装成可交互页面。两者组合起来，就形成了一个相对完整的 AI Agent 工作流： 获取数据 → 理解需求 → 生成内容 → 构建页面 → 分配权限 → 团队协作。

这也是企业 AI 应用的重要趋势。过去的 AI 工具更多是“聊天框”，用户问一句，模型答一句；而现在，AI 智能体开始具备任务编排能力，可以跨工具、跨数据源、跨部门完成连续动作。

在一些企业实践中，当团队需要同时调用不同大模型能力来处理报表总结、内容生成或格式转换时，也可以把 koalaapi 这类大模型 API 聚合平台作为模型调用链路的补充层，用来统一接入和切换不同模型能力，再将生成结果接入 Sites 页面，减少重复开发和接口适配成本。

---

六、与Vercel v0、Replit、Cursor相比，Sites瞄准的是非技术用户

从产品定位看，Codex Sites 与 Vercel v0、Replit、Cursor 并不是完全相同的竞争关系。

产品	核心定位	部署模式	目标用户
OpenAI Sites	自然语言一键建站	官方全托管	运营、销售、产品等非技术岗
Vercel v0	前端组件生成	需自主部署	专业前端开发者
Replit	全栈在线开发	平台托管	全栈工程师、学生开发者
Cursor	AI代码编辑器	自行部署服务	研发程序员

Vercel v0 更擅长生成前端组件，但后续仍需要开发者完成部署、后端对接和业务逻辑改造；Replit 更适合在线编程和全栈开发；Cursor 则主要服务于专业程序员的代码生产流程。

而 Sites 的差异化在于，它把目标用户放在了更广泛的企业员工身上。销售人员可以生成客户跟进看板，运营人员可以生成活动排期页面，产品经理可以生成需求池，分析师可以生成数据展示页。这些人不一定会写代码，但他们最懂业务流程，也最清楚自己需要什么工具。

这意味着，Sites 并不是要取代专业开发者，而是把一部分重复性强、规模较小、需求变化快的内部工具，从研发排期中释放出来。开发团队可以把精力放在核心系统、复杂架构和高安全等级业务上，而普通员工则可以通过 AI 智能体完成轻量应用搭建。

---

七、短板与边界：好用，但不能无边界滥用

尽管 Sites 的想象空间很大，但它目前仍存在明显限制。

首先，Sites 仅面向 Business 和 Enterprise 订阅用户开放，这意味着普通个人用户或免费用户无法直接使用。其次，Sites 的深度定制能力仍然弱于专业自研项目。对于复杂系统、多角色审批流、复杂权限矩阵、深度后端集成等场景，专业开发仍然不可替代。

更重要的是，官方也明确划定了合规红线：Sites 不支持用于处理 HIPAA 医疗数据、PCI 支付信息、数字货币相关业务开发。这说明它更适合企业内部管理、流程协作、轻量数据展示等场景，而不适合承载高风险、高合规要求或强交易属性的业务。

企业在使用 Sites 时，也需要建立相应的管理机制。例如，哪些岗位可以创建站点？哪些数据源可以接入？哪些页面需要审批？站点生命周期如何管理？如果没有这些规则，AI 智能体带来的效率提升，可能会伴随安全、权限和维护风险。

---

结语：从代码助手到企业AI智能体入口

Codex Sites 的上线，标志着 AI 编程工具正在进入一个新阶段。它不再只是帮助开发者补全代码、修复 Bug、生成函数，而是开始面向企业真实业务场景，帮助非技术用户快速创建可运行的内部应用。

当年 WordPress 降低了个人和中小企业建站门槛，如今 Sites 试图降低企业内部工具的开发门槛。它背后的变化，不只是“建站更简单了”，而是企业软件生产方式正在发生重构：需求方可以直接通过自然语言表达目标，AI 智能体负责生成应用雏形，企业再通过权限、审核和部署流程进行治理。

当然，Sites 还不是万能工具。它有订阅门槛，有定制限制，也有影子 IT 和合规风险。但对于项目看板、数据仪表盘、销售跟进页、活动管理工具等轻量场景来说，它已经展示出强烈的生产力价值。

未来，随着角色插件、SaaS 连接器和 AI Agent 工作流继续完善，企业内部工具开发可能会从“研发排期驱动”逐渐转向“业务需求即时生成”。而 Codex Sites，正是这一趋势中非常值得关注的信号。