2026 年 2 月，OpenAI 分享了一次颇为极端的工程实验。
一个小团队从空仓库开始，用 Codex 写下应用逻辑、测试、CI、文档、可观测性和内部工具。五个月后，仓库里约有一百万行代码，合并了约 1,500 个 PR。OpenAI 估计，这个产品只用了手工编码所需时间的十分之一。这是 OpenAI 的内部工程案例，不是一项受控实验。
如果只看这个案例，AI Coding 的结论似乎已经没有悬念：生产力发生了数量级变化。
可另一组数字没有这么整齐。
Cursor 公布的一项组织级研究发现，在 Agent 成为默认模式后，研究对象的 PR 合并率相对提高了 39%。但一篇独立的 MSR 2026 论文追踪开源项目后发现，Cursor 带来的显著速度增益主要集中在采用后的前两个月；代码产出增加的同时，研究样本中的代码复杂度也在上升。
再往前看，METR 在 2025 年做过一项随机实验。16 位资深开源开发者在熟悉的大型仓库中完成 246 个真实任务，使用的主要是当时由 Claude 3.5/3.7 Sonnet 驱动的 Cursor。允许使用 AI 时，他们平均多花了 19% 的时间。更有意思的是，实验结束后，他们依然认为 AI 让自己快了约 20%。
不过，这个结果也不能拿来判断今天的 Codex、Claude Code 和 Cursor。METR 已经明确将它标为过时结果，并在 2026 年调整了实验设计。
这些数字看起来互相冲突：十分之一的时间、39% 更多的 PR、短暂的速度增益，以及 19% 的减速。
问题不一定出在数字上。它们测量的，很可能不是同一件事。
从「辅助写代码」到「委派一项工作」
早期 AI 编程工具的基本单位是一条建议、一段补全或一次问答。开发者始终坐在驾驶位上，AI 帮他少敲一些字符，或者更快找到某个 API。
Codex、Claude Code 和 Cursor Agent 已经把交互单位变成了一项可以委派的工作。Agent 会读取仓库、修改多个文件、执行命令、运行测试、根据错误继续迭代，甚至提交 PR。一个人还可以同时启动几个任务，在它们运行时处理别的工作。
这不只是「补全变得更强」。它改变了生产函数。
过去，一小时工作大致对应一小时人的注意力。现在，一小时墙上时间里可能同时包含三个 Agent 的运行时间、十几分钟的人工指导，以及最后半小时的集中评审。单看任务从开始到结束用了多久，已经解释不了人的投入，也解释不了系统增加了多少产能。
更重要的是，Agent 会改变团队选择什么工作。
一个过去需要两天、因而一直排不上优先级的小工具，现在可能值得尝试。测试补齐、迁移脚本、内部仪表盘、一次性的客户预览，都可能因为实现成本下降而进入待办列表。与此同时，开发者也会把边界清晰的任务交给 Agent，把依赖隐性业务知识、需要复杂权衡的任务留给自己。
于是，「使用 AI 的任务」和「没有使用 AI 的任务」从一开始就不再可比。
METR 将这个问题拆成三种提升：完成旧任务有多快，完成采用 AI 后的新任务组合有多快，以及最终创造的价值增加了多少。三者不是同一个数字。新任务中可能包含过去根本不会做的工作，用旧的人类工时反推它们的“节省时间”，很容易得到惊人的提效倍数，却不一定得到同等比例的价值。
所以，Agent 时代最先失效的不是某个统计方法，而是我们对「生产力」这个词的偷懒用法。
Agent 首先扩大的是变更供给
把 Codex 的案例理解为「开发者写代码快了十倍」，会错过其中最有价值的部分。
OpenAI 的团队并不是给 Agent 一个普通仓库，然后等待奇迹发生。他们把仓库改造成了 Agent 可以理解和验证的工作环境：知识进入版本控制，架构规则可以被检查，测试和可观测性提供快速反馈，计划、产品判断、质量标准和可靠性要求都被尽可能写清楚。很多评审也逐渐由 Agent 处理。
这个案例真正展示的是：当执行能力变得便宜，工程团队需要投资新的生产资料，包括清晰的上下文、可执行的约束和足够短的反馈回路。
Claude Code 的使用数据从另一个角度支持了这一点。Anthropic 分析了约 40 万次 Claude Code 会话。在典型会话中，人更多决定「做什么」，Claude 更多决定「怎么做」。以严格的可验证成功标准衡量，任务专业度被评为新手的会话成功率约为 15%，中级及以上会话约为 28% 到 33%。
这不是 Claude Code 的因果提效实验，成功结果也来自分类器判断。但它揭示了一个重要方向：领域知识没有被 Agent 抹去。它正在从亲手实现，移动到任务选择、约束表达、方案判断和结果验收。
Agent 因此首先扩大的是「可尝试的软件变更供给」。一个工程师可以发起更多实现，探索更多方案，让更多过去不经济的工作成为可能。
可供给增加以后，下游会发生什么，取决于团队本来拥有怎样的系统。
如果需求含糊，Agent 会更快地产生错误方向的实现。如果测试缓慢且不稳定，更多并行任务只会争抢反馈。如果代码评审依赖少数资深工程师，生成速度越快，等待评审的队列越长。如果发布仍是低频、手工而高风险的活动，更多合并也不会自动变成更多客户价值。
AI 没有消灭瓶颈。它经常只是把瓶颈向右移动。
为什么 PR 变多，团队不一定更快
Cursor 公布的研究提供了一个很好的中间层信号：Agent 成为默认模式后，研究对象的 PR 合并率相对提高了 39%，PR 回滚率没有显著变化，缺陷修复类 PR 的比率略有下降。它说明 Agent 的确可能帮助组织吸收更多变更。
但「合并」仍然只位于价值链中间。
一个 PR 被合并，不代表它已经部署；部署了，不代表用户采用；用户看见了，也不代表问题得到解决。合并率可以增长，是因为团队完成了更多有价值的改进，也可能因为 PR 被拆得更小、实验变多，或者产生了更多随后需要返工的变更。
独立的 Cursor 项目研究让这种时间差更加明显。研究者使用差分中的差分方法分析了 806 个被识别为采用 Cursor 的开源仓库。采用后，新增代码行数平均增加约 28.6%，但提交数量没有显著变化；显著的速度增益主要出现在最初两个月。与此同时，代码复杂度上升。
这不能被概括成「Cursor 必然制造技术债」。研究对象是开源项目，采用识别并不完美，控制组也可能使用其他 AI 工具，而且模型迭代很快。它更适合提醒我们：采用第一个月的产出曲线，无法回答第六个月的维护成本。
Agent 生成代码的速度，以分钟计算。架构偏移、重复实现、脆弱测试和隐蔽缺陷的代价，可能几周后才出现。只在上游设置仪表盘，团队天然会高估收益、低估延迟发生的成本。
用四层证据链测量 AI Coding
如果一个团队想知道 Codex、Claude Code 或 Cursor 是否真正提升了生产力，可以把证据分成四层：Task、Flow、Delivery、Value。
它们不是四组可以随意挑选的 KPI，而是一条因果距离逐渐接近团队目标的证据链。
第一层：Task，任务有没有更省人的注意力
这一层适合回答：Agent 能不能更高效地完成某类边界清晰的任务？
除了任务完成率，还要分别记录人工活跃时间、Agent 运行时间和墙上时间；同时观察首次验收通过率、放弃率，以及任务经历了多少次重试。
这里最容易犯的错误，是只记录成功合并的 Agent 任务。被丢弃的分支、没有形成 PR 的尝试、反复重启的会话都消耗了资源。它们消失在仪表盘里以后，Agent 会显得比实际更稳定。
代码行数、Token 数、会话数和建议接受率可以解释使用行为，但不适合单独代表生产力。
第二层：Flow，工作有没有更顺畅地穿过团队
当一个人可以并行启动多个 Agent，个人任务速度已经不是主要约束。团队更应该看首次评审等待时间、PR 周期、返工轮次、变更批量和在制品数量。
一个很实用的信号是：Agent 产出增加以后，评审队列的年龄有没有同步增长？
如果合并数上升，但资深工程师每天花更多时间理解大批生成代码；如果 PR 等待更久、反复修改更多，那么自动化节省的实现时间已经转移成了评审负担。
这仍然可能是值得的。评审往往比亲手实现更容易扩展，也更适合由自动化测试、静态分析和第二个 Agent 分担。但团队应该把这笔成本记在同一张账上。
第三层：Delivery，更多变更有没有稳定地到达生产环境
DORA 当前使用五项软件交付指标：变更前置时间、部署频率、失败部署恢复时间、变更失败率和部署返工率。
对于 AI Coding 试点，这五项指标的价值在于把吞吐与不稳定性放在一起观察。
部署变快而故障率不升，才说明团队吸收了更多变更。部署频率上升，但紧急修复和回滚也明显增多，说明系统只是把速度换成了运营负担。反过来，如果代码生成大幅增加，变更前置时间却没有改善，真正的瓶颈很可能仍在评审、测试或发布流程中。
第四层：Value，新增产能有没有用在正确的问题上
这是最难测、也最不能省略的一层。
价值不必总是收入。它可以是用户完成关键任务的成功率，可以是一个功能的真实采用，可以是支持请求或故障负担下降，也可以是团队更快验证并否定了一个产品假设。
关键是，在试点开始前说清楚什么叫「有用的输出」。
如果一个月后，团队只知道 Agent 写了多少代码、完成了多少任务，却说不出这些任务为什么值得完成，那么它测到的是自动化规模，不是产品生产力。
三种常见的假繁荣
第一种是假繁荣来自并行。
工程师同时启动三个 Agent，墙上时间看起来缩短了，但他需要频繁切换上下文、重新解释任务，并在最后集中评审。如果只统计从任务创建到 PR 出现的时间，就会漏掉监督多个工作流占用的注意力。Agent 并行度应该与人工活跃时间分别记录。
第二种来自任务选择。
团队会自然地把适合 Agent 的任务交给 Agent。这是合理的生产决策，却让简单的 AI/非 AI 对比失去意义。AI 任务更快，可能来自工具，也可能因为它们原本就更清晰、更容易验证。比较时至少要按任务类型、复杂度、仓库熟悉度和质量要求分组。
第三种来自新增工作。
模型越强，开发者不只会更频繁使用它，也会尝试更复杂的工作。Cursor 对 500 家公司的研究观察到，在模型能力提升后的研究期内，每周消息量上升了 44%，高复杂度消息增加了 68%。这更像需求扩张，而不是固定工作量上的纯粹省时。
新增工作可以创造巨大价值。也可能只是因为代码便宜，团队开始生产更多没人使用的功能。区分两者，需要回到第四层。
怎样做一次不自欺的 30 天试点
不要一开始就问「全公司用了 AI 以后生产力提升了多少」。范围越大，工具差异、任务变化和组织噪声越容易淹没结论。
选择一个稳定团队、一个服务和一种重复出现的工作，例如小型 Bug 修复、测试补齐或边界明确的 API 变更。团队可以继续使用自己习惯的 Codex、Claude Code 或 Cursor；试点测量的是工作系统，不是安排一场脱离实际的工具擂台赛。
开始前，从历史记录中选取至少 20 个可比任务作为基线。给任务标注类型、复杂度、仓库熟悉度和验收标准。记录人工活跃时间、总历时、评审时间、返工和最终交付结果，同时增加两个过去容易消失的数据：被放弃的 Agent 尝试，以及并行运行的任务数。
前两周保持 PR 大小和质量门槛稳定。每个任务都要有测试或其他可执行的验收信号。每周两次复盘失败、重试和评审负担，不要只看合并量。
后两周再根据失败模式改造环境：补充仓库说明，缩短本地反馈，修复不稳定测试，把常见约束写进任务模板或自动检查。这样可以区分「买了工具就出现的效果」和「团队学会为 Agent 设计系统后的效果」。
30 天结束时，按照四个问题做决定：
- 可比任务是否消耗了更少的人工注意力，或者产生了更多可接受结果？
- 评审等待和返工是否吞掉了上游收益？
- 交付是否变快，同时没有显著增加失败和紧急返工？
- 新增产能是否服务于一个明确的客户、可靠性、学习或业务目标？
如果只有第一个问题得到肯定答案，可以把结果称为「任务自动化」。这已经是有价值的进步，但还不足以宣称组织生产力提高。
真正稀缺的东西正在改变
AI Coding 的讨论很容易落入两个阵营：一边展示几小时完成数周工作的案例，另一边强调幻觉、技术债和评审成本。
更接近现实的判断是，这两类现象会同时存在。
Codex、Claude Code 和 Cursor 正在快速降低实现成本，并让软件工作可以并行委派。很多过去不值得做、没有能力做的事情，现在确实变得可行。这不是虚假的提升。
但当实现不再稀缺，团队不会自动获得同等比例的产品速度。稀缺资源会转移到清晰的问题、可靠的上下文、可执行的反馈、架构判断、评审注意力，以及判断某项工作是否值得完成的产品能力上。
所以，AI Coding 生产力不应该用一个数字回答。
更好的问题是：Agent 带来的更多变更，有多少穿过了任务、流动、交付和价值这四层证据？又是在哪一层开始堆积？
找到那一层，才找到了团队下一步真正应该改造的地方。
参考资料
- OpenAI：Harness engineering with Codex
- Anthropic：Agentic coding and persistent returns to expertise
- Cursor：The productivity impact of coding agents
- Cursor：Better AI models enable more ambitious work
- He et al.：Speed at the Cost of Quality, MSR 2026
- METR：Early-2025 experienced open-source developer RCT
- METR：Task Substitution and Uplift
- DORA：Software delivery performance metrics
- Microsoft Research：The SPACE of Developer Productivity