摘要

OpenAI 在 2026 年 6 月 2 日连续放出两个 Codex 信号：一边说 Codex 已经有超过 500 万周活用户，知识工作者占比约 20%；另一边推出面向不同岗位的插件、Sites 和标注能力。这个变化值得开发者认真看一眼，因为它影响的不是“AI 会不会写代码”这么单一的问题，而是需求、数据分析、原型、报告、内部工具这些过去经常排到研发队列里的工作，正在被业务团队直接交给 Codex。本文不做发布会复述，只聊开发团队接下来最容易踩的坑，以及现在应该先补上的三件事。

正文

如果你还把 Codex 当成“帮我改一个 bug、写一个 PR”的工具，这两天的更新就容易被低估。

6 月 2 日，OpenAI 同时讲了两件事。第一件是 Codex 的使用面变宽了：官方报告里提到，Codex 已经超过 500 万周活用户，知识工作者约占 20%，增长速度还快于开发者。第二件是产品形态变了：新推出的 role-specific plugins、Sites 和 annotations，把 Codex 从“代码任务代理”往“工作产物代理”推了一步。

这几个词看起来有点产品味，但落到公司内部，其实很具体。

数据团队可以让 Codex 查数、解释指标、做 dashboard。销售团队可以拉 CRM、邮件和会议上下文，生成跟进计划。产品和设计团队可以从一个想法做出可交互原型。运营团队可以让 Codex 把活动计划变成一个可以共享的网页。以前这些需求常常以“帮我做个小工具”“帮我拉个页面”“帮我出个报表”的形式排到研发这里。现在，业务侧可能会直接先做出第一版。

开发者不是突然没事干了，而是要从“所有东西都亲手做”转到“把边界、权限、质量和可维护性管住”。

先看清楚这次到底变了什么

这次最核心的变化有三个。

第一个是插件。OpenAI 官方文章说，新插件会按岗位和工作流打包能力，里面可能包含 skills、apps、连接器和模板。官方公开的 role-based plugins 仓库也能看到类似方向：sales、data analytics、product design、financial markets 这些插件会把外部系统、工作说明和起始素材绑在一起。

换句话说，插件不是“多一个按钮”。它更像一套被包装好的工作方法：连接什么系统、读什么上下文、按什么步骤产出东西。对开发团队来说，问题也随之变成：谁能启用插件？插件能读哪些数据？能不能写回外部系统？出了错以后谁负责回滚？

第二个是 Sites。官方文档写得很直接：Sites 可以让 Codex 创建、保存、部署并检查由 OpenAI 托管的网站、Web 应用和小游戏。更关键的是，文档提醒每个 Sites deployment URL 都是生产部署。如果团队只想审核构建结果，需要先让 Codex 保存版本，而不是直接部署。

这点非常容易被忽略。以前业务同事说“帮我做个页面”，研发至少会经过测试环境、预发环境、权限判断。现在一个 Sites 任务如果描述不清楚，就可能直接生成一个可访问的页面。页面本身可能没问题，问题在于数据、受众、链接传播范围和后续维护。

第三个是标注能力。OpenAI 的文章把 annotations 描述成一种“指到哪里改哪里”的返工方式：你可以选中站点导航栏、报告中的某个论点、幻灯片里的图表标签，让 Codex 只改这一部分。这个交互很适合非技术人员，因为他们不用描述完整文件结构，也不用知道代码在哪里。

但对开发者来说，这会带来新的审核难题。以前我们 review 的是一次提交。现在可能要 review 一串局部修改：某个页面按钮换了文案，某个报告里的结论换了口径，某个 dashboard 的筛选条件被改了。每次改动都小，但小改动最容易绕过正常检查。

真正会影响开发者的不是“会写代码”，而是需求入口变了

我更担心的不是 Codex 抢走几个 CRUD 页面。CRUD 页面早就可以被低代码、模板和脚手架分走一部分了。真正麻烦的是需求入口变快了。

以前一个业务需求要进研发队列，大概会经过这些步骤：业务说明场景，产品整理需求，设计出原型，研发评估工作量，然后排期。这个链路慢，但它有一个好处：大家会在慢的过程中暴露问题。字段是不是缺了？权限是不是没想清楚？报表口径是不是和财务口径冲突？用户是不是根本不需要一个新页面？

Codex + 插件 + Sites 会把前面几步压得很短。业务同事可能下午想到一个活动复盘看板，晚上就用 Sites 做出初版。销售团队可能直接让插件从 CRM 和文档里拉上下文，做出一个客户风险页面。产品经理可能把会议纪要丢进去，让 Codex 做出一个可点击原型。

这类第一版会让讨论效率变高，也会让“半成品进入真实流程”的概率变高。

所以开发者接下来要改的第一件事，不是去学所有插件的用法，而是建立一份内部判断标准：哪些 Codex 产物可以直接用，哪些只能用于讨论，哪些必须进工程评审。

比如：

• 内部会议材料、临时分析、一次性活动页面，可以先允许小范围试用。
• 会读写客户数据、财务数据、生产系统数据的插件任务，必须走权限审批。
• 面向外部客户、会长期使用、会沉淀数据的 Sites 项目，必须有负责人、版本记录和下线方式。
• 涉及指标口径、合规判断、价格策略、合同条款的内容，必须有人复核来源。

这不是保守。越是让 Agent 进入日常工作，越需要把边界写清楚。

三件事现在就该补

第一，先做插件权限清单。

OpenAI Help Center 对插件的解释很清楚：插件本身不会凭空给用户新增数据权限，用户还必须在底层系统里拥有访问权限。问题是，很多公司内部权限并不干净。某些共享盘、CRM 字段、Slack 频道、数据仓库表，平时靠“大家差不多知道别乱看”维持秩序。一旦 Codex 能通过插件组合上下文，这些模糊边界就会变成真实风险。

一个实用做法是按插件列四个字段：可读系统、可写系统、敏感动作、确认机制。不要只看插件名字。一个“销售插件”可能同时接 CRM、邮件、会议记录和文档库；一个“数据分析插件”可能接数据仓库、BI 工具和报表文件。研发、数据、安全、业务负责人至少要知道它能碰哪里。

第二，给 Sites 制定“保存”和“部署”的区别。

Sites 文档里有一个很关键的提醒：保存版本和部署版本是两个阶段。保存版本适合审核，部署版本意味着上线。如果这个差异没有进入团队流程，业务侧会自然地把“生成一个页面”和“发布一个页面”混在一起。

建议团队先定一个简单规则：任何带真实客户数据、员工数据、财务数据、生产指标的 Sites，都必须先保存版本，再由负责人确认后部署。页面里如果有上传、表单、持久化数据，也要提前说明数据存在哪里、谁能访问、多久清理。

这听起来像流程，但它能避免很多低级事故。尤其是内部工具最容易被低估：大家觉得只是内部页面，结果链接一转发，访问范围比想象中大。

第三，把“标注式修改”接进 review 习惯。

annotations 的好处是返工快。缺点也是返工快。别人选中一个段落让 Codex 改，选中一个图表让 Codex 换标签，选中一个页面区域让 Codex 调整样式，这些修改看起来都不大，但它们可能改变事实、口径或交互路径。

研发团队可以要求 Codex 产物保留三个信息：改了哪里、为什么改、依据是什么。对于代码类任务，用 diff 和测试说话；对于报告、表格、幻灯片和 Sites，用来源链接、数据口径和版本说明说话。不要让“局部标注修改”变成绕开审核的捷径。

最容易踩的几个坑

第一个坑：以为装了插件就能用。

官方帮助文档列得很明白，插件可用性会受到套餐、工作区设置、功能开放、管理员启用的 app 影响。如果你看不到某个插件，或者插件提示 connector 需要 setup，这不一定是 Codex 坏了，可能是管理员还没启用对应 app，或者模板没有完成配置。

排查顺序可以很朴素：先确认工作区是否支持，再看插件是否可见，再看它依赖的 app 或 connector 是否启用，最后用一个低风险 prompt 测试。不要一上来就怀疑模型。

第二个坑：把业务系统权限和 Codex 权限混为一谈。

插件能调用某个系统，不代表每个用户都能看到系统里的所有内容。官方文档也强调，底层系统权限仍然要生效。实际项目里最该测的不是“插件能不能连上”，而是“不同角色看到的数据是不是正确”。销售、运营、财务、外包、管理员，至少要抽几个典型角色试一次。

第三个坑：把 Sites 当成普通草稿。

Sites 能快速把提示词或现有项目变成托管页面，这当然好用。但只要它拿到了生产 URL，就不能按草稿看。你应该提前想好：页面给谁看？是否需要登录？是否有持久化数据？是否用了真实数据？是否有下线入口？是否有人负责后续改动？

第四个坑：把“知识工作者增长”理解成开发者失业。

这类说法很抓眼球，但没什么操作价值。更现实的变化是，开发者的工作重心会从写每一个页面，转向定义哪些页面可以被快速生成，哪些必须进入工程体系。会写代码仍然有价值，只是价值越来越体现在架构、权限、质量、审查和复杂系统判断上。

一个更实用的 7 天适配路线

第一天，列出公司里最常被业务临时请求的 10 类小工具：报表、活动页、客户看板、项目进度页、数据分析表、复盘材料、审批说明、原型页面、FAQ、内部培训材料。把它们分成“可以让 Codex 先做初稿”和“必须研发介入”两类。

第二天，按插件维度盘点外部系统。重点看 CRM、数据仓库、文档库、邮件、日历、Slack/Teams、设计工具、BI 工具。不要追求一次做完，先把高风险系统标出来。

第三天，选一个低风险场景试 Sites，比如内部活动页面或项目复盘页。要求 Codex 先保存版本，团队评审后再决定要不要部署。

第四天，给标注式修改定一个记录格式：改动位置、修改原因、来源依据、审核人。格式可以很轻，但要留下痕迹。

第五天，设计两个反例测试。一个测试越权访问，一个测试错误口径。比如让没有财务权限的人请求财务数据，让 Codex 解释一个口径含混的指标。看系统和流程能不能拦住。

第六天，把成功案例写成内部模板。不是写一篇长文档，而是把好用的 prompt、权限要求、审核点整理出来，让下一个人照着做。

第七天，决定哪些场景可以放开，哪些继续收紧。Agent 工具最怕一开始全禁，也怕一开始全放。小范围试点、清楚记录、按风险放大，反而走得更稳。

这波更新的热点不在“Codex 又强了一点”。真正的变化是，Codex 正在从开发者工具变成工作流入口。插件负责接系统，Sites 负责把产物变成可交互页面，annotations 负责让返工变得更像点选和批注。

对开发者来说，这是一件有压力但也有机会的事。压力在于，很多原来必须排进研发队列的需求，会先绕过你做出第一版。机会在于，团队会更需要有人把这些第一版变成可靠系统：权限要清楚，数据要可信，部署要可回滚，版本要能追踪，质量要有人把关。

如果你现在要做一件事，我建议先别急着争论“AI 会不会替代开发者”。先去看看你团队里哪些临时页面、报表和内部工具已经可以被 Codex 做出第一版。然后把边界补上。

等业务侧真的把第一个 Sites 链接甩到群里，你会希望自己提前想过这些问题。

来源链接

• OpenAI：Codex for every role, tool, and workflow
  https://openai.com/index/codex-for-every-role-tool-workflow/
• OpenAI：Codex is becoming a productivity tool for everyone
  https://openai.com/index/codex-for-knowledge-work/
• OpenAI：Introducing Codex
  https://openai.com/index/introducing-codex/
• OpenAI Help Center：Plugins in Codex
  https://help.openai.com/en/articles/20001256
• OpenAI Developers：Sites - Codex
  https://developers.openai.com/codex/sites
• GitHub：openai/role-based-plugins
  https://github.com/openai/role-based-plugins
• OpenAI：Our response to the TanStack npm supply chain attack
  https://openai.com/index/our-response-to-the-tanstack-npm-supply-chain-attack/