🧠 代码速度不是瓶颈：AI加速让情况更糟
💡 核心洞察：AI加速代码产出但瓶颈在后：review、CI、部署、手动审批。结果：代码产出↑，实际交付↓。"你创造了更多的库存来腐烂在地板上"
问题的本质：Theory of Constraints
Eli Goldratt在1984年的《The Goal》中提出：每个系统只有一个约束（bottleneck）。整个系统的吞吐量由这个瓶颈决定。
关键洞察：优化非瓶颈步骤会让系统更糟糕。
如果A站生产更快，但B站（瓶颈）处理速度不变，你只是在上游创造了更多未完成的库存。库存上升，lead time上升，B站的人现在淹死在等待中。
AI时代的灾难：3x代码输出 = 3x问题
当VP宣布"AI让代码产出提升40%"时，没有人在乎：
- Reviewers没有翻倍 —— PR堆积，一天、两天、一周
- CI没有翻倍 —— 45分钟测试失败，重跑，又失败
- 部署审批没有翻倍 —— 手动审批环节永远卡着
- on-call没有增加 —— 凌晨2点崩溃没人懂
真正的瓶颈在哪里？
1. 你不知道要做什么
PM两个月没跟用户聊天，需求是Jira上三句话+Figma链接。工程师每天做50个微决策guess behavior、edge cases、error handling。
"六周做一个功能，基于sales在Slack上 paraphrased 的 prospect 的话。Prospect甚至没买。功能11个人用，9个是内部QA。"
加速写代码 = 更快地构建错误的东西。
2. Code Review
Reviewer没有翻倍，PR开始rubber-stamp。没人真的读代码就approve。代码带着bug进入生产。
3. 部署
CI 45分钟、flaky test、手动审批、staging躺三天因为没人 owning "get it to production"。
4. 跨团队协调
没人想当那个解释cycle time的人，dashboard只显示productivity up 40%。
AI让情况更糟
- 更多incident surface —— AI生成的代码没人完全理解
- 更少能理解系统的人 —— "写"代码的人prompted it没真的写，on-call的人不懂
- 更多代码，更少理解 —— 这不是 productivity gain，这是 time bomb with nicer dashboard
教训
- Velocity是伪 KPI，board看不懂cycle time
- 先找到真正的瓶颈，再优化
- AI是工具，不是解决方案本身
- 理解问题 > 写代码速度