如果你以为写代码速度是问题——你 有更大的问题
典型场景：VP的兴奋
周二早上。你的VP工程副总裁站在幻灯片前，兴奋得像2017年刚发现加密货币的人。他刚参加完一个大会或厂商晚宴，三杯黑皮诺加一个demo，现在他有消息了：
"我们要给每个团队部署AI编码助手。早期的数字显示代码产出增加了40%。这将改变我们的效率！"
房间里的反应很有意思：一半人点头，另一半突然对笔记本电脑产生浓厚兴趣。你的staff工程师脸上写着那个表情——他在计算是说点什么还是更新LinkedIn。
Goldratt会说点什么
1984年，Eli Goldratt写了《The Goal》，一本关于制造业的小说，却对软件行业出奇地适用。这也是你读过的最有用的一本商业书（虽然是小说）。
核心概念是约束理论：
这是大多数人都懂的部分。下面是他们不懂的、应该让他们害怕的部分：
恐怖秀：當你"3x代码产出"时实际发生了什么
你的开发者产出PR的速度比以往任何时候都快。好极了。精彩极了。拿彩带。现在这些PR进入审查队列，而你的审查者没有增加三倍。没有人增加三倍的审查者。
所以PR堆积。一天。两天。一周。作者已经context-switch到下一个AI辅助的功能，等到审查意见来临时，他几乎不记得第一个是做什么的了。
"你能解释这个函数是做什么的吗？"他们问道，盯着八天前写的代码——在开发者记忆里，那大概是侏罗纪时期。
- 审查开始被 rubber-stamp（匆匆批准）——因为要审查的实在太多了
- CI需要45分钟，在 flaky test 上失败，重跑，第二次通过
- 部署pipeline需要某人的手动批准（他在开关于会议的会议）
- 功能在staging待三天，因为没有人紧迫地拥有"把它部署到生产"的步骤
同时，开发者已经又发出了两个PR。队列增长。WIP暴涨。每个人都有六件事在同时进行，却没有任何一件事真正完成。Cycle time（真正衡量你向用户交付价值的速度）变得更糟。
你建了一座工厂，擅长生产堆积在地板上腐烂的库存。有人会因此被晋升。
还有一个更让人失眠的点
很多这些AI生成的代码？没有人完全理解它。写它的人并没有真的写它。他们prompt了它，浏览了一下，可能运行了一次。当它在生产中出问题（凌晨2点，在内衣里调试生产的故障），值班的人没写它，prompt它的人也无法解释它。
那真正的瓶颈在哪里？
如果写代码不是问题（几乎从来不是），那应该看哪里？走价值流。跟随一个功能从"有人有想法"到"用户从中获得价值"。我保证瓶颈会跳出来向你招手——它可能还会对你竖中指，因为你一直忽视它。
1. 你不知道要构建什么
这是没有人想谈的，因为很尴尬。你的PM已经两个月没有和真实用户聊过了。你的需求是一张Jira ticket，三句话加一个Figma链接——设计是某个从未用过产品的人批准的。
你的工程师每天做五十个关于行为、边缘情况和错误处理的小决定——没有人指定，因为没有人想过它们。
他们在猜。
我曾看到一个团队花六周构建一个功能，基础是销售在Slack上转发的一条消息，重述了一个潜在客户在电话里可能说过的话。六周。潜在客户甚至没买。那个功能被11个人使用，其中9个是内部QA。
这不是交付问题。这是"我们他妈的到底在做什么"的问题。
2. 代码之后的一切都是".done"的一半
在代码之后：审查、CI、staging、手动批准、部署文档、监控、on-call轮换、调试 production 问题的能力——所有这些都没有被三倍加速。它们是瓶颈。
3. 没有人理解你构建的系统
当AI写代码而人不理解时：
- on-call的人无法调试它
- 新人无法维护它
- 事故响应变慢
那该怎么办？
1. 先修复瓶颈，不是代码速度
如果你不知道要构建什么——先修复那个。如果你有堆积如山的PR——先修复那个。不要优化不是瓶颈的东西。
2. 测量正确的指标
代码产出 != 交付的价值。测量cycle time、交付频率、恢复时间（MTTR）。这些才是真正衡量软件交付速度的指标。
3. 把AI当作"autocomplete on steroids"，不是"junior developer"
AI可以帮助你更快地完成你 already know how to do 的事情。但它不能帮你知道你应该做什么。
4. 投资于理解，不是产出
当你的代码库有AI生成的部分，确保：
- 有自动化的scaffolding检查质量
- 有文档解释架构决策
- 有人真的能维护它
结论
AI coding assistant是一个强大的工具——但就像所有强大的工具一样，用在错误的地方会很危险。
如果你认为你的问题是"写代码不够快"——你可能有一个更大的问题：你不知道你在构建什么，或者你的交付流程有瓶颈。
先修复那些。
评分：★★★★★ 必读 - 罕见的深度分析
更新日期：2026-04-06