【卷卷观察】AI不会让你的流程变快 — 因为你搞错了瓶颈在哪

上周一个做技术管理的朋友跟我吐槽团队上了Cursor代码产出肉眼可见地快了但项目交付节奏一点没变。他甚至怀疑是不是自己管理能力不行。我说你管理能力没问题是你盯错了地方。一句话结论AI加速的是写代码但软件交付的瓶颈从来不是写代码。用TOC约束理论的话说你在非瓶颈环节上提速整体吞吐量不变。这不是什么新发现Goldratt在1984年就把这事说透了。只是每次有新技术出来大家都急着把老道理忘掉。当然AI也能用在需求分析、原型验证这些上游环节。但现实是绝大多数组织的AI投入集中在开发环节——让程序员用Copilot、Cursor写更多代码。这个前提没毛病。先看一个真实的交付流程一个典型的企业软件项目正常的Gantt图长这样数字因项目而异此处为示意项目时间线传统模式 需求阶段: 功能探索 |██████████| 10天 预算审批 |███| 3天 法务合规 |██████████| 10天 需求文档编写 |█████| 5天 开发阶段: 技术方案探索 |█████████████████████████| 25天 软件开发 |████████████████████████████████████████████████████████████████████████████████████████████████████| 70天 技术文档 |█████| 5天 部署阶段: 上线部署 |█████| 5天 观察期 |██████████| 10天总工期大约133天。一眼看过去软件开发占了大头——70天超过一半。所以理所当然的优化方向加速开发。要么加人要么上AI。陷阱在这里但Frederick Vanbrabant在那篇HN热帖481分345条评论里点出了一个被反复忽视的事实——软件开发慢不是因为打字慢。每个程序员都知道这事。你不可能通过打字更快来让项目更早交付。软件开发的本质是把业务问题翻译成机器能懂的指令。这个翻译过程需要什么需要你完全理解业务问题。用户完成销售后发一封邮件——听着简单吧实际问题一大堆邮件里放什么销售过程中出了岔子还发不发什么时候算完成——支付成功还是发货之后不同地区模板不一样怎么办这些问题AI答不了。只有业务方能回答。但业务方自己经常也没想清楚。所以开发慢的真正原因不是写代码慢是上游输入质量太差开发在等、在猜、在反复确认。上AI之后实际发生了什么大多数人对AI辅助开发的期望项目时间线理想中的AI模式 需求阶段: (同上) 28天 开发阶段: AI开发 |███| 3天 ← 从70天变3天 部署阶段: (同上) 15天 总工期约46天开发从70天变3天总工期从133天缩到46天醒醒。现实是这样的项目时间线实际AI模式 需求阶段: 功能探索 |██████████| 10天 预算审批 |███| 3天 法务合规 |██████████| 10天 需求文档编写 |████████████████████████████████████████████| 40天 ← 膨胀了8倍 开发阶段: AI开发人工修正 |████████████████████████████████████████████| 40天 ← 没快多少 部署阶段: 上线部署 |█████| 5天 观察期 |██████████| 10天需求文档从5天变40天因为你现在得写得更细。AI不像人类开发者能猜你大概想要什么——它需要精确到每一步的指令。文档写得粗了AI产出的代码就是一坨。你得反复改prompt反复检查输出反复修复它瞎编出来的接口调用。这些时间加起来省的都赔回去了。Vanbrabant原话说得好如果你给人类开发者同样详细的需求文档他们的效率也会飞起来。问题从来不是开发者太慢是需求太烂。TOC怎么看这件事约束理论Theory of Constraints是Goldratt在《目标》里提出的三句话概括任何系统至少有一个瓶颈总产出由瓶颈决定在非瓶颈环节提速不会增加总产出只会增加半成品库存要提升总产出必须找到瓶颈并优化它套到软件交付上瓶颈在哪需求定义和业务决策。开发在等需求、等决策、等确认。AI加速了什么开发环节——一个非瓶颈环节。结果呢代码写得快了但需求还是那个烂需求。代码堆在那里等确认变成新的库存。这跟工厂里某台机器产出飞快但下游工序跟不上一个道理。半成品堆满仓库成品产出一点没涨。TOC还有条黄金法则瓶颈环节应该获得可预测的、高质量的输入。翻译成人话就是——你要做的不是让开发更快而是让需求更清楚、让决策更果断、让评审更高效。这不是纸上谈兵之前带过一个支付风控项目8个人技术都不差。排期3个月实际做了5个月。复盘一看真正写代码只有5周。剩下时间花在了反复跟业务对需求他们自己没想清楚规则逻辑、等合规审批、联调等接口文档、上线前发现理解偏差返工。如果当时有人跟我说上AI能快一倍我大概会骂人。问题根本不在写代码的速度。后来我们做了一件事每个需求进开发前强制业务方填一份结构化模板包括所有边界条件和异常场景。刚开始业务方很抗拒我们哪能想那么细。结果开发周期从5周降到3周返工率掉了60%。项目总交付时间反而缩短了。这才是瓶颈优化该有的样子。那AI到底有什么用不是没用。我觉得最有价值的一个用法反而是在上游——原型验证快速出个demo让业务方看到做出来长什么样。很多时候需求说不清楚不是不想说是真没见过做出来的样子。一个可交互的原型比十页文档都管用。这反过来加速了需求澄清等于是在优化瓶颈本身。其他场景也不差重复性编码CRUD、boilerplate确实快了代码审查自动化减少了人工review时间从代码反向生成文档降低了维护成本。但这些都是局部优化。指望靠AI把整个交付速度翻倍你会失望的。Brooks在1975年就说了没有银弹。五十年过去了这句话还站着。给技术负责人的建议与其纠结要不要全面上AI编程不如做这几件事找到你的真实瓶颈。画一个最近3个项目的实际时间线看时间花在哪了。我赌一包辣条不是写代码。优化瓶颈的上游输入。需求质量、决策速度、评审效率——这些才是该投精力的地方。AI可以辅助比如帮需求模板查缺补漏但不能替代业务方的思考。用AI做验证工具不是替代工具。这个需求有没有遗漏的边界条件——这比让AI直接写代码有价值得多。重新定义快。不是代码产出快是从需求到上线的端到端快。盯着这个指标才能找到真正的提速空间。管理预期。老板问上了AI怎么没快多少你心里得有数。不是AI不行是瓶颈不在这。把这个道理讲清楚比盲目追求AI工具覆盖率重要得多。最后说几句很多团队上了AI工具之后确实感觉快了但多半是心理上的。代码产出多了commit多了PR多了。但看端到端的交付周期大概率没变。因为瓶颈在上游。你加速了一条非瓶颈流水线除了增加库存什么都不改变。下次再有人推销AI让开发效率提升10倍你就问一句我们的瓶颈在写代码吗答不上来那这10倍就跟你没关系。参考Frederick Vanbrabant I dont think AI will make your processes go faster / Goldratt《目标》/ Liker《丰田之道》/ Brooks《人月神话》