四个月从几乎不用到九成：Codex 是怎么自己长成唯一入口的？
财务、招聘、法务这些部门不写代码，本来也不必关心代码。可 2026 年 2 月到 6 月，它们在 OpenAI 内部的 Codex 使用率从接近 0% 涨到 90%，而且没有来自管理层的强制要求。桌面端负责人 Andrew Ambrosino 把这件事概括成一句话：过去几个月最大的主题，是一切都变成了编码代理；不管最后交付的代码是不是你写的，代理都在写你的产物。最能说明这是“用出来的需求”的细节出现在 2 月到 4 月——那时的 Codex 应用还会把代码显示在屏幕上，对非技术用户并不友好，非工程团队的采用率却已经接近 40%。他们拿它做研究、做演示文稿、做文档、做表格，因为这些东西最后都能被写成代码。
真正把曲线推上去的是长任务。Codex 加上了 /goal 设置：定一个目标，代理就一直做到完成为止。4 月到 5 月，使用率从 60% 跳到 90%。Ambrosino 观察到的变化是，人们开始在一个对话线程里待很久，甚至连续几天；长任务代理会自己派生出别的代理去处理其他事情，人需要同时盯着的界面反而变小了。
另外两个原因更像组织动作。生产力团队工程负责人 Akshay Nathan 说，过去是“能力溢出”——模型已经很强，产品没把能力放出来；现在变成了“认知缺口”——有人已经用 Codex 盯 Slack、更新 Airtable、做入职材料，更多人只用它干一件事，靠同事口口相传才发现别的用法。团队于是把各自的工作流做成插件分发出去；OpenAI 还把做幻灯片、做表格、写商业报告的领域专家招进 ChatGPT Work 的工程团队，因为模型在这些领域已经比开发者更懂，开发者没法把“品味”注进代理。
依赖深到什么程度？一次轻微宕机，同事在 Slack 里发的人工消息会和自动告警同时到达 Codex 与 Work 团队，有时还更早。两年前，这家公司里还没有 AI 代理，只有高级一点的自动补全。OpenAI 官方博客给出的口径更细：平均每位 OpenAI 员工超过 85% 的输出 token（模型处理文本的最小单位）由 Codex 产生，Codex 占公司每周输出 token 的 99.8%；相比 2025 年 8 月，非开发者的组织用户增长了 189 倍。
Codex 在 OpenAI 内部扩散的节点
- 2025 年 8 月 · 起点：工程师也主要在用 ChatGPT
OpenAI 官方博客称，那时平均每位员工用于 Codex 的 token 不到 10%。
- 2025 年 11 月 · Antigravity 以 VS Code 分支的形态出现
这让 Codex 团队一度怀疑是否也该跟着做 IDE，他们最终没有。
- 2025 年 12 月 · 纠结要不要发布桌面应用
团队担心它变成“失败的 iPad”，最后押注代理会让 IDE 变得不重要。
- 2026 年 1 月 · 用量激增，IDE 使用量开始下降
报道只给趋势，没有给降幅。
- 2026 年 2 月至 3 月 · Mac 版与 Windows 版 Codex 应用上线
非工程团队把工作流搬进 Codex，尽管界面还在满屏显示代码。
- 2026 年 4 月至 5 月 · /goal 上线，使用率从 60% 跳到 90%
报道把长任务能力列为关键推动力；人们开始把同一个线程用上好几天。
- 2026 年 7 月 · ChatGPT Work 发布
它由 Codex 的 harness（代理运行框架）驱动，非工程团队的工作流全面迁移过去。
节点按报道与 OpenAI 官方博客公开的时间整理；使用率是 OpenAI 自述口径，没有分母与外部审计。
- 2025 年 8 月 · 起点：工程师也主要在用 ChatGPT
- 2025 年 11 月 · Antigravity 以 VS Code 分支的形态出现
- 2025 年 12 月 · 纠结要不要发布桌面应用
- 2026 年 1 月 · 用量激增，IDE 使用量开始下降
- 2026 年 2 月至 3 月 · Mac 版与 Windows 版 Codex 应用上线
- 2026 年 4 月至 5 月 · /goal 上线，使用率从 60% 跳到 90%
- 2026 年 7 月 · ChatGPT Work 发布
如果代理能连着跑好几天，专门用来看代码的编辑器还有多大必要？
为什么 OpenAI 敢赌 IDE 会变得不重要？
这个赌注在 2025 年 12 月看起来并不划算。Ambrosino 回忆，团队当时不确定要不要发布 Codex 桌面应用：终端里已经有 Codex CLI（命令行工具），外面又有功能完备的大型 IDE（集成开发环境，写代码的图形界面工具），夹在中间的工具会不会变成“失败的 iPad”——很多人买了 iPad，最后要么用更便携的手机（相当于命令行），要么用功能更强的笔记本（相当于 IDE）。偏偏 2025 年 11 月 Google 又发布了 Antigravity 这个 VS Code 的分支，更让人怀疑是不是也该跟着做一个。他们最后按直觉下注：代理越强，IDE 就越不重要。
结果是，自 2026 年 1 月起，OpenAI 内部 IDE 的使用量持续下降——报道只给了趋势，没有给具体降幅。有点讽刺的是，Codex 应用自己正在变得更像 IDE：2026 年 6 月上线了在应用内直接编辑文件的功能。
真正变化的不是工具形态，而是数量。应用工程副总裁 Venkat Venkataramani 说，每位工程师的 PR（Pull Request，合并请求）数量在以曲棍球杆式的速度增长，构建—测试—部署流水线的每一段都在承受空前的负载。他给的说法是：某些系统的负载大约增长了 10 倍，而同样的增长在大多数公司要花两三年。他们的麻烦是连环的——刚为上一阶段补上容量，模型又解锁了新能力，瓶颈换个地方再冒出来。
负载涨到这个量级，原来的流程为什么接不住？
写代码变快以后，卡点挪到了哪里？
堵点有两处，一处是自己的，一处是别人的。
自家的堵点在容量。PR 数量暴涨，意味着版本控制要接住多得多的提交，CI/CD（持续集成与持续部署，代码自动跑测试并上线的流水线）要跟着扩容，生产发布流程要吸收高得多的变更频率。Venkat 的说法是，每个月醒来都是新一组扩容难题；他提的问题也变了——今天做代码审查和 PR 的方式越来越说不通，可观测性、上线方式都得重新想。他们现在的做法是把 CI/CD 重做一遍，并且用一个性能工具把可疑的 PR 送进 Synthetics A/B 框架（用合成流量做前后对照的实验框架），先评估这次改动对性能的影响。
别人的堵点在应用商店。原生 iOS 和 Android 的每一次更新都要过 Apple 和 Google 的人工审核，耗时几小时到几天。ChatGPT 工程负责人 Sulman Choudhry 曾在 Facebook 任职，他记得 2010 年代 Facebook 的突破是把 App Store 的发布节奏从每月一次压到双周、再压到每周，同时用实验和功能开关让代码提前上线、之后再远程打开功能。他觉得现在遇到的是同一个问题的下一版：代码生成快了太多，把代码送到原生移动端用户手里却没有变快。他那句话很直白——如果软件能在几分钟里写完，等几天甚至几周才能装到手机上，就开始显得荒谬。
2008 年 App Store 上线时的那些限制，到 2026 年还在原地。18 年过去，这件事没怎么变。
为了接住这些量，OpenAI 把整条流水线拆成了九道工序。
拆开这条 9 步流水线：人只在三个环节按下确认
“软件工厂”借用的是制造业的类比：机器人和人一起造车，最极端的形态是“暗厂”——里面没有人，连灯都不用开。在 OpenAI，这条产线已经在跑，并且完全围绕 Codex 搭起来。九道工序里，人真正按下确认的只有三处：定义目标、批准上线、决定故障缓解措施；剩下的环节由代理接手。工程师的角色也跟着变了，Venkat 说他们“更像产品经理，而不是传统的系统工程师”。
代理能接手的前提是上下文。OpenAI 已经把文档搬进源代码，代理还能读 Git 仓库与 GitHub、Slack、Notion、Databricks、Datadog、内部日志和内部 Codex 技能；新员工入职被引导“有问题先问 Codex”。
第五步的审查换成了多个代理。不是一个通用审查员，而是同时起若干个按领域配置的代理：数据、基础设施、云、安全各看各的，再按风险给变更分级。低风险变更可以走快速通道，某些代码区域甚至允许代理自动批准 PR；高风险变更叠加更多 AI 审查，或者强制人工复核。报道作者 Gergely Orosz 起初怀疑，一个被设定成“云基础设施专家”的代理，跟通用代理能有什么不同。解释是：所有代理都能读到 OpenAI 的代码和文档，专家配置的意义在于它只盯自己那块，把有限的上下文窗口用在刀刃上。
第六步的部署最能说明这条产线走到哪了。人批准上线之后，这次变更会被分配一个专属代理，任务可以概括成“陪护这次变更，直到它安全完整地进了生产”。它会去代码库里找到功能开关的位置，弄清这次改动做了什么，判断哪些信号代表成功、哪些代表失败，然后自己搭一块监控看板盯着。Orosz 说这一点是他之前没见过的——过去看板是人给服务建的，现在代理按“每次变更”的粒度自己建。
第九步的 Sevbot 是内部事故响应代理，同样基于 Codex。事故发生时它会被唤醒：收集上下文、给出可能的缓解手段、在 Slack 里回答工程师的问题，但它从不自己执行，要工程师下令才动。OpenAI 的长期目标是做出“每次变更的自主 SRE（Site Reliability Engineer，站点可靠性工程师）”，并在常规故障上让 Sevbot 自主处理、人上班后再复核。到报道发布时，oncall 值班还没有成为历史。
九道工序，六段可以看见的交接
人定义目标
工程师或产品经理写明问题与期望结果，判断、优先级和品味在这一步权重最高。
代理取上下文、写代码、修到 CI 变绿
文档已搬进源代码，代理可读 Git、Slack、Notion 与内部数据源；改完自己验证，开出 PR 后照看到各项检查通过。
多个领域代理并行审查
数据、基础设施、云、安全各起一个代理；变更按风险分级，低风险可自动批准，高风险叠加审查或强制人工复核。
代理陪护上线并自建看板
人批准后，变更配一个专属代理盯到进生产：找功能开关、判断成败信号、自己搭一块监控看板。
生产观察与性能回流
看板由代理按“每次变更”的粒度生成；Perf Factory 筛告警、去重、找出真正的延迟回退并提修复建议。
Sevbot 响应故障
它收集上下文、给出缓解手段、在 Slack 答疑，但从不自己执行，要工程师下令才动。
按报道描述的九道工序压缩成六段；人类按下确认的位置是定义目标、批准上线、决定缓解措施三处。
这套东西搬出 OpenAI 之前，有几个前提得先说清。
这套做法在什么条件下才成立？
第一，公开的数字都是自述口径。“四个月从 0% 到 90%”“4 月到 5 月从 60% 到 90%”“部分系统约 10 倍负载”，全部来自 OpenAI 内部人员的说法或 OpenAI 提供的图表；官方博客补充的 85%、99.8%、189 倍同样是自述。它们能说明这家公司内部发生了什么，不能推出照做的团队会有同样的曲线。
第二，内部版和对外版不是一回事。报道明确说，OpenAI 内部版 Codex 比对外版本先进得多，因为它几乎接进了公司所有系统——Slack、Notion、Databricks、Datadog 和内部日志。外部产品上能复现的是这套工作方式，不是这套接入。
第三，这条流水线依赖两个前提：文档被搬进了源代码，代理读得懂；评审、部署、值班本来就有分级流程，代理接上去才有位置站。缺了任何一个，九步里最先卡住的会是上下文和审批，而不是写代码这一段。报道没有披露的风险也集中在这里：Perf Factory 的准确率与误报率、Sevbot 的处理量与误判案例、低风险自动批准的错误率，都是空白。
写代码这一步被拿掉以后，开发者手里还剩什么？
把前几节拼起来看，OpenAI 的实践指向一个变化：软件工程的核心技能正在从实现能力移到目标定义和质量判断。这个判断有三个支点。
执行性的工作正在被系统性地自动化。写代码、跑测试、修 CI 失败、代码审查、部署、监控、性能优化、故障响应，这些原来占掉开发者大部分时间的事，在这条流水线里都有代理参与，而且不是在实验室里，是已经在生产环境跑着的流程。人的介入点则集中在需要判断力的环节：定义目标要知道什么问题值得解决、什么结果算好；批准上线要评估代理的输出可不可信、风险能不能接；决定故障缓解措施要在信息不全的时候做取舍。
“全栈”的含义也跟着变了。过去说全栈，是指前端、后端、数据库、运维每一层的实现都会写；现在代理能处理每一层的实现，你需要的是每一层的结果都能判断好坏——这是另一种能力，全链路判断力。
要落到自己身上，可以先用三个问题自查。目标能不能定义清楚？“做一个用户登录功能”不算，得说到“在不牺牲安全性的前提下，让新用户在 30 秒内完成首次登录、失败时有明确的错误引导”这个程度；如果提示词总在反复改，问题可能不在代理，而在目标。代理的输出能不能判断好坏？它写的代码看起来往往很合理，安全漏洞、性能问题、架构债却可能藏在里面，需要的是不逐行重写也能看出问题在哪的系统思维。知不知道该在什么时候介入？常规情况代理能处理，边界条件、系统交互、业务逻辑冲突这些异常仍然要人；值钱的不是什么都自己做，而是知道什么时候代理可以继续、什么时候必须停下来让人看一眼。
还有一个没有答案的问题：代理写的代码攒到一定规模，技术债会以什么形态出现。人写代码时，债来自时间压力、能力局限和需求变化；代理写代码时，债可能来自目标定义不精确造成的局部最优、代理彼此之间的风格不一致、为了通过测试而写出来的脆弱代码。怎么识别、怎么还，目前还没有成熟的方法论。
