夜雨聆风摘要：每一代"银弹"都承诺软件开发效率翻倍，每一代都打偏了同一个靶心。80 年代的 CASE 工具如此，00 年代的外包潮如此，今天的 AI 编程依然如此。为什么？因为瓶颈从来不在"写代码"这一层。
银弹承诺书：你听过这个故事吗？
"AI 开发从期望的 3 天膨胀到现实的 40 天。"——这是最近一篇热文揭示的现实。听起来耳熟吗？
1986 年，Fred Brooks 写下软件工程史上最著名的一篇论文《没有银弹》——"银弹"指传说中能一枪杀死狼人的银质子弹，Brooks 借它比喻那种"一项技术就让生产力翻倍"的灵丹妙药。他的判断是：软件工程最难的部分是搞清楚到底要做什么，任何工具都很难从根本上消除这个困难。
此后近四十年，每一代人都声称自己找到了那颗银弹，每一代都打偏了。
最后一行来自 Frederick Vanbrabant 最近的一篇文章。他用甘特图（项目进度时间线）展示了一个典型项目的期望与现实：范围界定、法务审批、文档撰写之后才是软件开发。AI 的承诺是开发只需 3 天。
但现实是什么？AI 写代码确实快，但你需要把每一行代码背后的需求、边界条件、异常处理全部写清楚，它才能写对。 这意味着文档阶段从 5 天膨胀到 40 天，AI 开发本身也需要持续的"手把手指导"，又是 40 天。也许总时间比原来短一些，但远远不是"3 天"的承诺。
Vanbrabant 引用了《目标》一书中的一句话：瓶颈应该获得可预测的、高质量的输入。 这才是加速流程的第一步：关键在于确保瓶颈之前的一切都准备到位，而非给瓶颈加力。
问题在于，这恰好是四十年来每一颗银弹都打偏的地方。
第一层：写代码从来不是瓶颈
软件开发到底慢在哪里？
Vanbrabant 说得很直白：软件开发是"把问题翻译成机器能理解的方案"，翻译速度取决于你对问题理解多深，不取决于你打字多快。 如果打字速度决定开发效率，所有程序员早就去报打字班了。
一个开发者收到这样的需求："销售完成后给用户发邮件。" 看起来简单，但追问下去全是黑洞：邮件里放什么内容？销售过程中出了异常还发不发？什么叫"交易完成"——付款成功？发货确认？还是客户签收？开发者真正花时间的地方，就是回答这些需求文档里没有写、产品经理也没想清楚的问题。
Hacker News 上一位开发者 phyzix5761 回忆自己的经历：拿到过字面意思只有"把数据给用户"的需求——什么数据？从哪来？什么格式？他花在追问这些问题上的时间，远多于写代码本身。
这恰好是 Brooks 在 1986 年就预言过的。在《没有银弹》的"自动编程"章节里，他写道：自动编程的收益取决于需求规格的精确度，而需求规格的精确度恰恰是软件工程中最难的部分。Brooks 当年的话，简直就是给今天写的。
更近的历史回响是 00 年代的外包潮。把代码丢给半个地球外的团队，看起来开发成本减半了。但需求写不清楚，交付回来的东西"看起来对但用不了"。Hacker News 上有人直接类比："你们忘了外包是怎么翻车的吗？不问问题的承包商交付的代码，跟不问问题的 LLM 生成的代码，是同一种灾难。"
AI 加速了代码生成。但代码生成往往不是那堵墙。真正的墙在于搞清楚要生成什么。
第二层：机构臃肿抵消速度优势
第一层的问题还只是个体开发者的事，第二层已经是组织层面的大规模失灵了。
Vanbrabant 举了一个例子：法务审批慢，不是因为没有足够的律师，而是因为律师要追着五个人补全文件。流程慢的根因在瓶颈上游的输入质量，瓶颈本身只是表象。 给法务部门加律师，跟给开发团队加 AI，犯的是同一个错误。
Hacker News 上的讨论把这一点拓展开了。一位叫 echelon 的用户说了一句最锋利的话：AI 让小团队闪电般快，它可能是终极颠覆工具。 另一位 michaelbuckbee 接上：组织越大，开发者真正花在写代码上的时间占比越小，AI 的直接收益就越少。
同一个工具，独立开发者用起来势如破竹，大企业用起来原地踏步。差的是什么？
我用"AI 吸收率"来描述这个差异：一个组织能把 AI 的速度优势保留多少到最终交付物上。吸收率取决于三件事：
官僚层有多厚：多少人在审批而非创造？每一层审批都是速度损耗 反馈链路有多长：从用户痛点分析到代码改完，经过几层传话？传话越多，信号衰减越严重 决策权和信息权是否错位：做决定的人不理解问题，理解问题的人做不了决定
Conway's Law 说，系统架构反映组织沟通架构。反过来也成立：组织沟通架构不变，AI 生成的代码往往会更忠实地复制组织的混乱。 你用 AI 十倍速写出了代码，但这些代码要经过三个委员会审批、两个部门协调、一轮法务合规检查——AI 省下的时间，被组织摩擦吃干抹净。
《人月神话》里的规模化悖论也在回响：加人让项目更慢，因为协调成本指数增长。AI 让代码生成更快，但审查和协调的瓶颈没变。Hacker News 上 tgv 的观察最直观：同事 vibe coding（凭感觉让 AI 写代码，不细审就提交）产出一大堆代码提交（commit），团队根本看不过来。"LLM 不是团队玩家。"
AI 速度再快，经过官僚海绵一过滤，出来的还是原来的节奏。海绵不除，加速还能剩多少？
第三层：验证悖论——生成越快，验证越慢
前两层说清楚了"为什么 AI 加速不了流程"，第三层更反直觉：AI 加速不仅没帮你省时间，还可能让你花更多时间。
你可能觉得：AI 帮我生成了代码，我省下了写代码的时间。但 AI 生成的代码越多，你要验证的代码也越多，而验证的认知负荷远大于生成。
这就是验证悖论：生成速度从 10 行/小时跳到 1000 行/小时，但你的验证速度还是 50 行/小时。 瓶颈从生成端转移到了验证端，而且两者的速度差距在持续扩大。
三个战场看得最清楚：
代码战场：审查 AI 生成的代码比写代码更累。Hacker News 上 vips7L 抱怨："80k 行的生成项目砸我手上，它不用框架自带的组件和 ORM（对象关系映射，数据库操作的标准化工具），完全是个维护噩梦。"另一位 tombert 做分布式系统的补充：AI 擅长出原型，但并发和分布式场景下代码质量"平庸甚至糟糕"，大量需要重写。
需求战场：PM 用 LLM 扩写需求文档，看起来详尽专业，实际上全是大模型的"合理猜测"。Hacker News 上 stefan_ 的观察最精准："至少以前一眼能看出需求是废话，现在废话被包装得像真的了。" 验证一份看起来完美的需求，比从零写一份粗糙但真实的需求，认知负荷更高。
事实战场：LLM 不问问题。niek_pas 指出了一个关键差异：人类团队收到模糊需求至少会追问"你说的数据是哪个？"，LLM 直接回答"好的，做完了"——做完了，但做的是它猜你想让它做的。这种"过度自信的沉默"比"追问的噪音"更危险，因为沉默不会触发你的警觉。AI 不追问，你就不警觉——这才是最危险的。
软件工程有一条古老的常识：审查代码比写代码更难。但 AI 把这条常识推到了极端。以前审查的是同事的代码，至少有共同上下文；现在审查的是 AI 闭着眼吐出来的代码，你甚至不知道它是怎么得出这个结果的。验证悖论或许是 AI 生产力承诺最难突破的天花板：只要验证速度不跟生成速度同步提升，生成加速往往产生更多"看起来完成但其实没有"的半成品。
你的组织在第几层打转？
三层瓶颈，每一层都有不同的症状。用这张表快速诊断：
大多数组织在第一层和第二层之间反复横跳：抱怨 AI 不够聪明，又抱怨组织不够敏捷。但真正的天花板可能在第三层——验证悖论不解决，前两层修好了，会不会只是把更多 AI 生成的代码倒进更窄的验证漏斗？
Brooks 在 1986 年的判断依然有参考价值：没有银弹。但 AI 或许不需要是银弹——它是一面镜子，照出你组织真正的瓶颈。技术局限只是表象。
你的组织卡在哪一层？评论区说说你见过的"官僚海绵"或"验证黑洞"，我们一起拆。
参考资料
Frederick Vanbrabant：I Don't Think AI Will Make Your Processes Go Faster，2026-05-15 Fred Brooks：No Silver Bullet — Essence and Accidents of Software Engineering，1986 Hacker News 讨论：I Don't Think AI Will Make Your Processes Go Faster，2026-05 Frederick Brooks：The Mythical Man-Month，1975 Melvin Conway：How Do Committees Invent?（Conway's Law），1968 Eliyahu Goldratt：The Goal，1984
