「AI会让开发速度提升3倍」——大家都信了，都导入了。
但为什么交期还是在延误呢？
大家都这么以为
这个信念本身并没有错。GitHub的Copilot研究发现，开发者在编写HTTP服务器这样的孤立编码任务中平均快了55%。没有Copilot要花2小时41分钟的工作，缩短到了1小时11分钟。
看到这些，自然会得出结论：「把70天的软件项目用AI压缩到35天。」AI压缩了时间线中最长的那个阶段，对吧？
但数据指向了反方向
Google的DORA团队在2024年发布的数据很有意思。AI导入后个人生产力和满意度提升了，但软件交付稳定性和吞吐量在某些情况下反而下降了。个人变快了，但团队整体成果的可靠性下降了——这是个悖论。
这正是「约束理论（Theory of Constraints）」所解释的。核心原则很简单：任何系统的整体性能由最慢的那个环节决定。 加速瓶颈以外的环节，整体速度不会改变。
所以真正需要问的是：「你们项目里耗时最长的，真的是"编码"吗？」
误判瓶颈的后果
就算AI把编码时间压缩到接近零，如果需求澄清需要6周，项目就不可能在6周内完成。这就是约束理论的核心。
丰田早就知道的原则
有一个原则正好切中要害：「瓶颈必须接收可预测的、高质量的输入。」 这在埃利·高德拉特的《目标》和丰田生产系统中都反复强调。
举个例子。需求来了：「销售完成后给用户发邮件。」在写第一行代码之前，需要先确定：
- 邮件内容是什么？订单号？预计送达日期？
- 「完成」是什么意思？付款授权？库存扣减？发货开始？
- 失败了怎么处理？重试？通知某人？
- 邮件没发出去，订单还有效吗？
如果这些都不清楚，开发者和AI就只能靠猜，或者停下来问。编码速度提升55%有什么用，如果被卡在这个环节的话。
Martin Fowler的「Specification by Example」也是同样的道理：需求只有以具体例子（输入→预期输出）的形式表达时才算完整。对AI也一样——模糊的指令只会让AI迅速造出错误的东西。
| 仅导入AI | 需求澄清 + AI | |
|---|---|---|
| 输入质量 | 依然模糊 | 基于具体例子 |
| 编码速度 | 变快 | 变快 + 返工最少 |
| 交付稳定性 | 有风险 | 维持或提升 |
| 实际交期 | 不变或延误 | 可以缩短 |
从哪里开始？
- 找到真正的瓶颈
诚实地记录近期项目各阶段的耗时，以及为什么花了这么长时间。需求变更？返工？等待审批？那里才是真正的瓶颈。 - 在写代码之前定义「完成」
为每个功能编写具体例子：「用户A完成付款→以B格式发送订单确认邮件。」这个具体程度，才是对AI和开发者都有效的高质量输入。 - 把不确定性前移到编码之前
如果「这怎么处理？」在编码过程中才出现，就已经太晚了。和PM/PO花1小时沟通，能防止2天的返工。 - 然后再引入AI
需求达到具体例子级别之后，再把实现交给AI。只有输入清晰，AI的提速才有意义。 - 用正确的指标衡量
不要问「快了吗？」，要问「返工减少了吗？」、「需求变更减少了吗？」DORA的部署频率、前置时间和变更失败率是好的基准。
想深入了解？
I don't think AI will make your processes go faster 这篇文章的种子来源——Frederick Vanbrabant的原文。具体的甘特图示例和约束理论的实际应用。 frederickvanbrabant.com
2024 DORA Accelerate State of DevOps Report Google DevOps研究团队的年度报告，用数据分析AI对开发团队的影响。 dora.dev
Theory of Constraints — Wikipedia 埃利·高德拉特约束理论概述。瓶颈管理和五步聚焦法的基础。 wikipedia.org
SpecificationByExample — Martin Fowler 以具体例子定义需求的方法论。解释了为什么抽象需求会失败。 martinfowler.com
Research: Quantifying GitHub Copilot's Impact on Developer Productivity GitHub官方研究。55%速度提升的实际实验条件和局限性。 github.blog
