「AI 会让一切流程加速」——这是过去两年企业管理者最常挂在嘴边的假设。但 Frederick van Brabant 在重读了《丰田之道》和《目标》两本经典后，给出了一个冷静的反驳：AI 并不是流程加速的万能药，真正决定速度的瓶颈，往往不在你盯着的地方。
甘特图的视觉陷阱
文章用一个典型的甘特图切入：范围探索 → 预算评估 → 法律审查 → 开发探索 → 软件开发（70天）→ 部署。任何经理看到这个图，都会指着最长的「软件开发」阶段说：「加速它。」然后呢？加人、加 AI、砸资源——但这一切都忽略了更本质的问题。
「时间长≠问题的根源在那里。」作者借《目标》一书的核心洞见指出，软件开发之所以耗时长，往往不是因为代码写得慢，而是因为上游的需求定义模糊不清。当你收到一个仅写着一句话的功能需求——「用户购买完成后发邮件」——开发者需要花大量时间猜测邮件内容、异常处理逻辑、以及「购买完成」的精确定义。
AI的真正影响：加速执行，不解需求
作者并不否认 AI 在编码阶段的效率提升，但强调了一个关键区分：AI 擅长的是执行层面的加速，而流程瓶颈出在需求定义和信息对齐。你可以用 AI 更快地生成代码，但如果需求本身是模糊的，生成再快也只是更快地制造返工。这正解释了为什么许多企业的「AI 提效」实验结果低于预期。
Toyota Kata：从瓶颈而非速度入手
文章回到了精益生产的经典方法论：与其在瓶颈环节堆资源，不如先问「为什么」这个环节会成为瓶颈。上游的交付物质量、跨团队的沟通效率、业务方对技术可行性的理解——这些「软」环节才是真正的约束。AI 可以给一些环节加速，但不能消除这些结构性摩擦。
社区讨论：两极化的共鸣与质疑
这篇 471 分的帖子引发 335 条评论。高票评论者 @kj4211cash 表示「110% 同意」——大型组织里的技术工作确实被这些上游需求问题反复拖累。但 @ddosmax556 提出了有力反驳：AI 的影响绝不仅限于开发阶段，它在构思、法律审查、文档生成、部署等各个环节都可以发挥作用。最有洞见的评论来自 @siliconc0w：「非平凡的软件开发中，编码占比远不到 50%，而且往往是最简单的部分，通常是给初级工程师做的。」他认为真正的挑战在于跨系统协调和利益相关方对齐——而这些恰恰是 AI 目前最难介入的领域。
📎 原文：frederickvanbrabant.com｜💬 HN讨论：Hacker News (471分 / 335评论)