AI编程提速的幻觉：编码只占交付时间15%

AI 编程工具正在以惊人的速度普及，但一个被多数团队忽视的事实是：写代码从来不是软件交付的真正瓶颈。如果编码只占交付周期的 15%，那么把编码速度翻倍，对整体交付的提升不过 7.5%。

编码，一个没人测量的瓶颈

一位工程负责人在过去半年里反复向工程经理们提出同一个问题：你们的交付时间里，有多少花在编写新代码上？ 答案集中在 10% 到 20% 之间，有时更低。

剩下的时间去了哪里？理解不断变化的需求、与改了主意的利益相关者对齐、调试生产环境的线上缺陷、协调三个节奏不同的团队敲定一个集成日期、阅读别人写的代码库。GitHub 的开发者体验研究佐证了这一点——开发者花在等待构建和测试上的时间，与写新代码的时间相当，而这还没算上会议、代码评审和安全工作。

DORA 发布的《AI 辅助软件开发的 ROI》报告从财务角度得出了相同结论：回报来自工具周边的组织系统，而非工具本身；简单任务上能获得 35-40% 的增益，复杂遗留代码上则只有 10% 甚至更少。增益恰恰在真正的工作所在之处缩水。

然而大多数 AI 编程基准测试测量的正是代码生成——孤立的绿地任务、干净的问题陈述、明确的成功标准、没有人类介入。真实交付中等待你的，是自相矛盾的 Jira 工单，和某个下游服务团队没打招呼就部署了破坏性变更。没有哪个基准能捕捉这些。

DORA 是 DevOps Research and Assessment 的缩写，最初由 Nicole Forsgren、Jez Humble 和 Gene Kim 等人创立，2018 年被 Google 收购后成为 Google Cloud 旗下研究项目。它以年度《加速状态报告》（State of DevOps Report）闻名，通过数万份从业者问卷建立了软件交付绩效的量化基准，提出部署频率、变更前置时间、变更失败率、恢复时间四项核心指标。DORA 的研究方法把工程实践与组织绩效直接关联，因此常被工程负责人当作判断工具投资是否值得的参照系。本文引用的《AI 辅助软件开发的 ROI》报告即延续这一传统，从财务和流程两端评估 AI 工具的边际收益。

一个被误读的"AI 生产力胜利"

某团队曾宣布他们的"首个 AI 生产力胜利"：一个二十多名开发者日常使用的共享服务，构建时间缩短了 50% 以上。幻灯片看起来很漂亮，但深挖之后，故事比标题有趣得多。

一位资深工程师追踪了容器化测试基础设施中的执行路径，发现 PostgreSQL 的 JIT 编译特性——对大型生产数据库有益——给小型 JUnit 测试数据库带来了灾难性开销。关掉它之后，SQL 执行时间从 62 分钟降到 6 分钟。

AI 帮他们在知道要找什么之后更快地定位了配置。但知道该问哪个问题，需要的是理解各层如何交互的人，一个被类似问题烧过、对哪里该戳一下有直觉的人。这才是基准测试无法衡量的工作，也正是真正带来胜利的工作。

需求与对齐：交付真正发生的地方

有整个冲刺周期里，最有影响力的工程活动是一场 40 分钟的产品负责人对话。它阻止了团队建造错误的东西。没有写任何代码，冲刺速度指标纹丝不动，但那场对话节省了数天甚至数周的白费功夫。

大多数项目最难的部分从来不是实现。最难的是让五个优先级各异的利益相关者就"完成"的定义达成一致，是沟通权衡——解释快速交付某个功能可能以牺牲他们更看重的东西为代价。AI 编程工具在回答"如何实现 X"上强得惊人，但它无法帮你判断 X 是不是该做的事。这个问题活在组织政治、业务战略、监管约束构成的人类语境里——都塞不进提示窗口。

Andrew Diamond 在《AI 时代的软件工程》中指出：AI 无法知道它刚生成的代码是否违反了你产品所受的法律约束，也无法知道它是否与另一个团队下季度计划发布的功能冲突。这些知识活在人的制度记忆里，是决策时存在却从未被写下来的累积语境。

一个始料未及的发现是：AI 编程助手节省下来的时间，并没有被重新投入到更好的需求分析或更深的思考中，而是花在了审查生成的代码、修正遗漏重要上下文的建议、以及在工具之间来回切换上。建造错误东西的成本从未降低，我们只是更快地做到了它。

生产调试：上下文问题的极致体现

问任何资深工程师最紧张的工作时间花在哪里，答案不会是"写新功能"，而是"弄清楚昨天还能跑的东西今天为什么不跑了"。

生产调试要求跨越服务边界理解系统交互，阅读不完整的日志——"不完整"不是指还没建索引，而是根本没人觉得这些信息值得记录。然后你需要制度知识：这个服务上周四部署过，而那个团队悄悄改了重试策略却没更新运维手册。祝你在提示词里找到这些。

AI 工具在特定调试任务上确实有用——日志模式匹配、提出假设、解释陌生代码。但困难的部分是知道该去哪里看，这需要模型不具备的跨系统上下文。加快代码生成，对凌晨两点追踪一个超时、穿过四个服务和消息队列、试图弄清当天十七个变更中哪个引入了微妙顺序依赖的工程师，毫无帮助。

跨团队依赖：沉默的杀手

从没见过哪个项目因为打字慢而延期，但见过几十个项目因为依赖另一个团队而延期。等待 API 契约最终确定——它被重新排了优先级却没人告诉你；共享库更新被一个冲刺接一个冲刺地推迟；平台团队要你提工单才能分配环境，而审批人休假到下周；安全评审积压；某个决策因为需要一位周四之前都在连续会议中的人的意见而卡住。

约束理论同样适用于软件交付：改善非瓶颈环节不会提升系统吞吐量。如果编码占交付周期的 15%，跨团队协调占 40%，把编码速度翻倍只能省下 7.5%，让协调效率提升 25% 则能省下 10%。数学并不复杂，只是我们不愿意直视它，因为协调问题混乱、涉及政治、没有能在幻灯片上演示的干净解法。

Harness 委托的一项覆盖 700 名从业者和管理者的调查强调了同一点：94% 的工程负责人表示，技术债、验证时间、开发者倦怠等关键因素完全不在他们的生产力指标里。我们在测量容易测量的东西，然后把它称为全貌。

约束理论（Theory of Constraints）由以色列物理学家 Eliyahu M. Goldratt 在 1984 年的《目标》一书中提出，最初用于制造业，后被引入项目管理与软件交付。其核心主张是：任何系统都存在一个制约整体产出的瓶颈环节，在非瓶颈上加速不仅无法提升系统吞吐量，反而可能制造更多在制品和等待队列。Goldratt 给出的改进顺序是识别约束、挖掘约束潜力、让其他环节服从约束节奏，再考虑提升约束本身。把这一逻辑套到软件交付上，如果编码只占周期的 15%，那么围绕编码做优化就像在一条狭窄隧道之外拓宽高速入口，车流最终还是会堵在同一处。

约束转移到了评审环节

一个值得认真对待的反驳是：AI 代理不再只是打字了——它们能跑测试套件、追踪失败的测试、开 PR。但请看队列在哪里形成。代理产出的一切仍然落在必须决定是否信任它的人类面前，而这正是当下团队卡住的地方：审查和验证已经变成了曾经构建时间所扮演的约束角色。

有研究者在从头重新思考代码评审模型，工程负责人也在用同样的措辞描述这一困境——一个在人类写代码时行之有效的评审模型，正在机器人产出的体量下崩溃。DORA 将这一机制描述为 J 曲线：先下降再上升，而下降来自验证开销而非学习工具。把 15% 的环节自动化得更彻底，只会把更多体量推入它身后的队列。

J 曲线是描述技术或流程变革初期收益的经典模型：引入新工具后，短期绩效先下降，随后回升并最终超越原有水平。DORA 用它解释 AI 辅助开发对交付的影响——下降并非因为团队不熟悉工具，而是因为 AI 大幅提升了代码产出量，涌入评审、测试和验证环节的待处理工作骤增，而这些环节的容量并未同步扩张。理解这一机制对工程负责人至关重要：如果只盯着编码环节的局部指标，就会误把曲线谷底当作工具失败，或者误把后续回升完全归功于工具本身，从而错过真正需要投资的验证能力建设。

该测量什么

如果你是一位在周一早晨读到这篇文章的工程负责人，不要测量代码从 PR 到合并花了多长时间，测量一个想法变成客户能用上的东西花了多长时间。大多数组织已经有这些数据了，它们埋在 Jira 工单、Slack 对话和日历邀请里。

当你发现六周过去了而写代码只花了三天，瓶颈就一目了然了。你不需要另一个工具来找到它，只需要看整个旅程，而不是其中一小段。

问题的关键不是 AI 是否有用——它有用，我每天都在用。真正的问题是：我们的投资分布是否匹配我们的约束分布。从我在自己实践中的观察来看，它并不匹配。