编程从来都不是瓶颈
AI 已经席卷了软件开发。我们两个人的工作，一边是为软件工程师打造产品，一边是为数以百万计的普通用户打造消费级产品，所以我们也算是利益相关方。我们当然希望 AI 提升生产力的故事是真的——更多产出、更紧的时间线、更快乐也更高产的工程师。谁会不希望呢？
但当我们去看那些实际的研究，再去对照真实世界里正在发生的事，我们却没法让二者达成一致。或者说，我们能，但前提是我们愿意承认：“productive（有生产力）”这个词的意思，和最近这波主流叙事所认为的并不一样。
1、最让人不舒服的结论先说
2025 年初，一家研究机构 METR 用开源开发者做了一场对照实验。他们发现（与业界当时的预期相反）：使用 AI 工具的工程师，比不用的同行多花了 19% 的时间，置信区间为 +2% 到 +39%。这种变慢在统计上是稳健的。那还是行业里一个不一样的时期——Claude 还没发布它的 Opus 模型，业界还在摸索 AI 能做什么、不能做什么。但真正引人注目的，倒不是变慢本身，而是工程师们相信自己大约快了 20%，而数据却显示并非如此，由此揭示出了认知与现实的巨大鸿沟。
在把其余证据一股脑堆上去之前，请先为这个发现停留片刻，因为它会改变你阅读其余一切的方式。
METR 从 2025 年 8 月起尝试了一项后续研究，而那项研究后来的遭遇，或许比最初的结果更发人深省。2026 年 2 月，他们发了一篇帖子，解释为什么放弃了原有的实验设计。问题在于：太多开发者拒绝参与，除非他们能在所有任务里都用 AI。剩下 30% 到 50% 的参与者报告说，会选择性地回避提交那些他们不想在没有 AI 的情况下去做的任务。样本因此系统性地偏向于“最不可能展现出 AI 价值”的开发者与任务之外的人群。
2025 年末那项研究的数据，显示出趋势上的改善。在最初那批回归的开发者子集中，估计效应转为速度提升 18%（置信区间：-38% 到 +9%）。在新招募的开发者中，速度提升 4%（-15% 到 +9%）。但 METR 指出，这些数字可能只是下限，因为很多人是自我选择退出（self-selected out）的。他们的结论：自 2025 年初以来，AI 工具确实变得更有用了，但如今的选择效应（selection effects）已经严重到，让受控测量近乎不可能——那些对 AI 最狂热、最热情的开发者，已经不肯在没有 AI 的情况下工作了，于是再也无法充当对照组。这不是 METR 方法论的失败，而是一个关于我们身处何地、又将去向何方的信号。
2、另外三个数据点
在 2025 年末到 2026 年初这段时间，又有几项研究相继出炉。
Anthropic 在 2025 年末调查了自己内部的 132 名工程师，做了 53 场访谈，并分析了 200,000 条 Claude Code 转录记录。员工自报的生产力提升达 50%。随着工程组织和 Claude 的使用量增长，他们声称每位工程师每天的拉取请求（pull request）数量上升了 67%。Anthropic 的工程师在每日工作中有 60% 用到了 Claude，而且 Claude 自主完成的任务也越来越多。
CircleCI 分析了横跨数千个团队的 2800 万次 CI 工作流。工作流吞吐量上升了 59%，但中位数团队的主分支（main branch）吞吐量却下降了 7%。构建成功率跌到了 70.8%，是五年来的低点。存在的代码比以往任何时候都多，但真正抵达生产环境的却更少，CI 正在变成一个 chokepoint（瓶颈点）。
哈佛商学院的研究者研究了 78 名借助 AI 完成其专业领域之外任务的员工。AI 在头脑风暴环节对所有人帮助一样好，但在执行环节，技能远离该领域的员工，表现比领域专家差了 13%。AI 在规划阶段看似弥合的差距，在执行阶段又重新出现了。
METR 在 2026 年 5 月对 349 名技术工作者的调查——这是在实验设计崩溃之后进行的——发现人们自报的 AI 工具生产力增益为 1.4 倍到 2 倍。但 METR 自己的研究团队成员（也就是在 2025 年对“认知偏差”最心中有数的一群人）在这个调查中，报出的增益却是所有子群体里最低的。
3、这在实践中是什么样子
下面这个场景，对某些读者来说会很眼熟：工程师的活动指标表面上看很漂亮。拉取请求在增加、代码提交在上涨、速率点（velocity points）以团队多年来未曾达到的节奏被关闭。领导层很高兴，工程师也觉得自己更有生产力。然后，某个人——很可能是产品经理——问：为什么六周前就标记为“进行中”的路线图事项，到现在还“在进行中”？
大家同时意识到同一件事：功能的时间线其实根本没变。真正发生的，是 AI 大幅降低了开始工作的成本，但达到“可上线”的打磨仍然是个难题。初稿函数、样板代码、脚手架、以及为陌生代码写解释，这些全都显著便宜了。但真正卡住交付的，从来都不是这些任务。卡住交付的是产品决策、设计评审、QA、合规、基础设施、发布流程。当你把编程加速，你最终只是把更多“在制品”塞进了同样那几个下游瓶颈里。CircleCI 那份基于 2800 万次工作流的数据，某种程度上就是这种状况在规模上的写照：特性分支里活动爆棚，主分支的吞吐量却持平甚至下滑。
这不仅仅是聚合数据里的模式。正如 Anthropic 负责 Claude Code 的工程总监 Fiona Fung 在 2026 年 6 月的一场演讲中所言，写代码、写测试、做重构，已经很少再拖她团队的后腿，但瓶颈并没有消失，只是换成了验证、代码评审和安全。她特别点名了 CI——随着团队生成更多代码，构建系统和 CI 流水线会难以跟上。那可是全球最被 AI 加速的工程组织之一，却撞上了和 CircleCI 数据所描述的同一堵约束墙。天花板不再是代码编写速度了；事实上，它从来都不是。
Anthropic 有一个发现：AI 辅助完成的工作中，有 27% 若没有 AI 根本就不会发生——这一点其实是把双刃剑。其中一部分确实有价值，比如为真正决策提供信息的原型探索、那些真正被写出来的文档。但另一部分，是没人排过优先级、说到底就是不够重要的工作。现在，因为构建它变得几乎免费，它却在消耗评审周期和 CI 资源；而评审、测试、维护它，则一点也不免费。
4、能力—信心之间的鸿沟
HBS 的研究指出了一个具体的机制：AI 弥合了新手与专家之间的信心鸿沟。它让每个人都能平等地拿到方案、解释和初稿。但它并没有弥合能力鸿沟。当一个后端工程师用 AI 辅助去做一个前端功能时，他产出的东西看起来是对的。问题藏在底下——在他本不知道该质疑的那些决策里，在他本不知道该测试的那些边界情况里。
早先 METR 的结果表明，这甚至延伸到了在自己专业领域内工作的资深从业者身上。AI 并没有让他们变得无能；它实际上是让他们感觉比产出所支撑的更有能力。而正如 METR 后续研究的崩塌所展示的：一旦开发者把 AI 深度整合进工作流，他们就失去了“脱离 AI 作为参照点”去工作的能力——研究者称之为自动化偏差（automation bias）。
这正是该让工程领导者警惕的部分。你看不见的东西，你修不了。如果你团队里每个工程师都真诚地相信自己多产了 50%，而你的交付日期却纹丝未动，那这就是一个没人认为存在的问题。
5、什么能让 AI 原生的开发持续下去
让代码评审更严格，而不是更快。 AI 生成的代码很容易通过表面检查——格式干净、约定一致、没有 linter 报错等等——而这恰恰就是它危险的地方。问题往往藏在审阅者扫一眼 diff 看不出来的那种地方。
我把这叫做“合理怀疑评审”（reasonable doubt review）。做法是：从怀疑而非信任出发，问自己“有什么地方可能是错的、而我从 diff 里看不出来？”具体来说：模型做了哪些在输出里看不见的假设？它在哪些边界情况下会静默失败？它又在哪里耦合到了作者可能根本没想到过的东西？
这更慢。而这正是重点。它也不是无限可扩展的，所以才需要和“不需要判断力的自动化”配对使用，把人类注意力集中在真正需要判断的地方。
Claude Code 团队的做法是个好例子：让 AI 作为第一道关口去处理风格、lint、抓 bug 和生成测试，但把涉及安全的代码、信任边界、以及任何触碰法律风险的部分，直接交给领域专家。这种分工不是“AI 评审小的、低风险的改动，人类评审大的、高风险的改动”，而是“AI 负责表层正确性，人类掌握有后果的判断”。这是个有意义的区别。很多团队在做的是前者，却以为自己是在做后者。
让你的 CI 去适配新的失败模式。 CircleCI 的构建成功率在吞吐量暴涨的同时跌到五年最低，说明大多数团队还没更新自己的流水线，去捕捉 AI 生成代码究竟是怎么坏的。AI 生成的代码，坏法和人类生成的不一样。它更可能是“局部正确但架构上不一致”，能通过单元测试却挂掉集成测试，守着函数签名却违背了那些函数被围绕建立的假设。集成测试、契约测试、以及能在流水线里强制约束你系统架构的“架构适配函数（architecture fitness functions）”，会比 linter 或类型检查器抓住更多这类问题。如果 AI 生成的代码违背了你的模式，那么构建系统就应该在审阅者打开 diff 之前把它拦下来。这能同时解决你未来的评审问题和基础设施问题。
在特性开关（feature flag）后面发布，并 aggressively 地监控。 接受这个事实：你不可能在部署前抓住所有问题。与其把赌注全压在“合并前质量”上——而证据表明它比感觉起来更难评估——不如先部署给 1% 的用户，盯着仪表盘，一旦出问题就快速回滚。这种做法也会倒逼你在可观测性（observability）上的投入，而无论 AI 与否，这笔投入本身都能回本。
为 AI 辅助的代码要求人类编写的测试（直到 AI 能自信地生成确定性测试为止）。 尤其是针对边界情况和边界条件的、人类手写的测试。写测试这件事本身的纪律，会逼着开发者去想清楚行为，而不是照单全收地接受输出。如果一个工程师写不出测试，那他很可能还没理解这段代码到足以交付的程度。这是个有用的信号，而不是一种失败状态。
保护那种刻意的、知识共享的时间。 Anthropic 的研究发现，随着 Claude 取代了工程师之间原本会有的那些交谈，导师制正在悄然被侵蚀。这是数据里长期的隐患。架构决策记录（ADR）、轮值的系统走查、以及资深与资浅工程师一起攻克问题的结对环节，在“问 AI”旁边显得很低效，但它们正是团队建立起共享理解的方式——也正是那种能防止“同样的错误每六个月就用更好排版的代码被重写一遍”的理解。
6、测量问题
那么，这是否意味着我们该停止使用 AI？不。去用 AI，并且在它明显有助于繁琐任务、原型开发、探索性工作——任何你能快速验证的东西——的地方大用特用。在边界清晰、可独立验证的工作上，那些增益是真实存在的。
但如果你试图衡量 AI 是否真的在帮你的团队交付，那么 PR 数量和自报的速率，是错误的仪表。我们评估的那四项研究合在一起表明：这些不仅仅是测量问题，它们是一个警告信号——我们平时赖以判断“某样东西到底有没有用”的反馈循环，已经发生了显著变化。
那个更难的问题——所有研究都提了出来、却都没能真正回答的——是：真正的测量到底会告诉你什么。从功能构想到交付的周期时间，或者“合并的代码在不回滚的情况下抵达生产”的速率，可能是更好的指标。或者一个 sprint 结束时计划范围与实际范围的差距。或者更抽象一点：与 AI 投入（工具、基础设施、运营支出）相关联的公司营收增长。
这些指标没有一个是容易落地的。你该问团队的，不是“我们感觉多有效率？”，而是“我们需要知道些什么、才能去测量？”
原文链接: Coding Was Never a Bottleneck
汇智网翻译整理，转载请标明出处