前言
文章来源：Andrew Murphy
原文标题：If You Thought the Speed of Writing Code Was Your Problem You Have Bigger Problems
本文为博主翻译，若有理解偏差欢迎指正。
周二早上，你们 VP of Engineering 站在投影前，兴奋得像刚在 2017 年买到第一枚加密货币。TA 刚从某个大会（或者厂商晚宴）回来，三杯黑皮诺下肚，看完一场 Demo，然后带回了“好消息”：
“我们要给所有团队上线 AI 编码助手。早期数据显示，代码产出提升 40%。这会彻底改变我们的研发速度。”
会议室里就会出现那种经典场面：一半人在点头，另一半人突然对自己的笔记本屏幕产生了浓厚兴趣。资深工程师脸上写着“要不要现在说真话，还是回去更新 LinkedIn”。
但没有人问最关键的问题：
你说的速度，是朝着什么目标在加速？
因为你们刚刚做了一件事：在整个交付系统里，挑中了本来就不慢的一环，然后把它继续加速。你们给“非瓶颈”砸了钱。
而系统论告诉我们，这不仅不会帮到你，甚至会让情况更糟。
Goldratt 会想跟你聊聊
1984 年，Eli Goldratt 写了《The Goal》。这是一本讲制造业的小说，却对软件交付异常适用。
核心思想是约束理论（Theory of Constraints）：
- 每个系统只有一个真正约束（瓶颈）；
- 整体吞吐量由这个瓶颈决定；
- 在瓶颈解决前，优化别的环节意义不大。
很多人理解到这里就停了。真正可怕的是下一句：
当你优化的不是瓶颈时，你得到的不是“更快系统”，而是“更坏系统”。
很直观：A 工位更快了，但瓶颈 B 速度不变，于是 A 和 B 之间堆起半成品；库存上升，交付周期变长，B 工位被淹没，优先级更混乱，质量也会下降。
你并没有提速，你只是制造了一场交通堵塞，并把它叫做“生产力”。
恐怖现场：当你“3 倍代码产出”后会发生什么
开发者 PR 提交更快了，听起来很好。但评审人数没变，没人去扩容 reviewer。
于是 PR 堆在队列里：一天、两天、一周。作者已经上下文切换去写下一个 AI 加持功能，回头再看第一个 PR 时，连自己都快不认识了。为了赶队列，评审开始“橡皮图章式”通过；CI 跑 45 分钟，偶发失败，重跑通过；发布还需要人工审批，而审批人正在开“关于会议的会议”；功能在 staging 再躺三天，因为没人真正对“尽快上线”负责。
同时，开发者已经又提了两个 PR。队列越来越长，在制品（WIP）爆炸，人人手里都有 6 件“进行中”，但“真正完成”的反而更少。真正衡量价值交付速度的 cycle time 不降反升。
你会得到一个很荒诞的局面：
- 代码更多；
- 软件交付更少；
- 仪表盘显示“生产力 +40%”。
你们建成了一个世界级工厂：特别擅长生产会堆在地上腐烂的库存。
更糟的是，很多 AI 生成代码没有被任何人真正理解。提示词的人不一定真正“写过”它；值班排障的人也不一定懂它。于是系统可出故障面积变大，而能推理系统的人变少。
更多代码，更少理解。这不是生产力提升，这是定时炸弹。
那真正的瓶颈在哪？
沿着价值流走一遍：从“有人提出想法”到“用户真正获得价值”。瓶颈会自己跳出来。
1. 你根本不清楚该做什么
PM 两个月没访谈真实用户；需求是三句 Jira + 一个 Figma；工程师每天要替产品做几十个没人定义的细节决策。大家在猜。
结果是：你可能用 6 周做了一个功能，最后只有 11 个人用，其中 9 个还是内部 QA。
这不是“交付慢”，而是“我们到底在干嘛”。
在这种环境里加速写代码，只会更快把错误功能做完。
瓶颈是“理解问题”，不是“敲键盘速度”。
2. 代码“写完”之后的所有环节
在多数组织里，写代码可能只占 20%，其余 80% 都在排队。
评审、CI、staging、QA、安全审查、产品验收、发布窗口、灰度……代码在各个环节之间静止等待。很多功能代码半天写完，却两个月后才到生产。
你看见过“紧急修复”9 天才上线，就知道瓶颈根本不在编码。
想提速，先看“等待时间”，而不是“编码时间”。
3. 发布信任的恶性循环
测试不稳定、可观测性混乱、灰度流程没人信，团队越来越怕发布。越怕越攒大包，包越大风险越高，风险越高就更怕。
这时再提高代码产出，只会把“恐惧文化”喂得更肥：更多代码、同样恐惧、更大批次、更低发布频率。
4. 上线了，但到底有没有效果？没人知道
功能发布后，没有像样分析、没有用户回访、没人复盘“问题是否被解决”。于是下一个需求继续猜。
你只是更快地重复“做了—发了—耸肩”的循环。
5. 你的日历才是承重墙
有时瓶颈不是技术，而是协作：
- 等一个决策会议；
- 三个团队一个月没对齐 API；
- 某架构师成了所有设计的单点审批；
- 季度规划流程太重，紧急事项也要排队。
这都是组织问题、人问题、协调问题。
写代码更快，对这些问题的作用是 0。
应该做什么（不性感但有效）
- 画出价值流：把一个功能从想法到上线的每一步写下来，也写下步骤之间“等了多久”。
- 衡量 cycle time，不是产出量：别再盯代码行数、PR 数、故事点；看从提交到用户拿到价值要多久。
- 消灭等待态：评审慢就改评审机制；发布卡人工审批就自动化或降低摩擦；决策依赖会议就拆小决策。
- 少开工，多完工：限制 WIP，3 个真正完成比 10 个进行中更有价值。
- 听一线团队的：开发者早就知道瓶颈在哪，只是通常没人认真听。
结语
如果真的想加速交付，正确的管理台词不该是“代码产出提升 40%”，而应是：
“我们做了价值流分析，发现功能平均在流程间等待 9 天。接下来我们要把这个时间砍半。”
写代码速度从来不是大多数团队的核心问题。真正的优势不属于“写得最快”的团队，而属于能持续做到这三件事的团队：
- 搞清楚该做什么；
- 把它做出来；
- 快速、稳定地送到用户手里。
修瓶颈。瓶颈不在键盘。