翻译自：https://frederickvanbrabant.com/blog/2026-05-15-i-dont-think-ai-will-make-your-processes-go-faster/

我有一种感觉：几乎每家组织都在或多或少地关注流程优化，尤其是在市场低迷时期更是如此。如今这个话题又多了一个人工智能的维度，以及随之而来的种种不切实际的期望。

为了充分准备这个话题，我重读了两本经典著作：《丰田之路》和《目标》。我在大学期间读过这两本书，但重读之后让我意识到，很多流程优化练习本质上过于简单化，而且往往误解了真正应该关注的地方。

以一个甘特图为例：如果你的任务是提高项目吞吐量，软件开发无疑占据了图表中最长的时间段——这会是你的第一站，而且这是正确的。然而问题是：我看到的人们通常的处理方式要么是往这个问题上堆人，要么是简单假设 AI 会让事情变得快很多。人们通常不会做的是去看为什么这件事需要这么长时间，更重要的一点是：长时间并不自动意味着问题就出在那里。

软件开发的核心瓶颈往往不在于编码本身的速度。每一个软件开发者都知道，你不可能仅仅通过打字速度变快来让项目进展更快。如果真是那样的话，我们都应该去上打字课了。软件开发本质上是将一个问题转化为计算机能够理解和自动解决的方案，而且最好是以一种安全且可扩展的方式。要做到这一点，你需要对问题有完整的理解——要么通过特性文档或范围文档（如果你更偏向瀑布式开发），要么通过与领域专家的持续迭代（如果是更敏捷的方式）。

问题通常就出在这里：试图理解一个模糊的、只有标题的功能请求实际上意味着什么。比如"销售完成后向用户发送邮件"是什么意思？好的，我们可以发送一封邮件，但邮件里应该写什么？如果销售流程中出了问题，我们是否仍然发送错误邮件？什么时候算销售完成？

很多人认为 AI 开发的结果应该看起来像甘特图中那样——直接跳过开发阶段，软件开发者变成项目经理。但那不是真实情况。我们面临的恰恰是同样的上游问题。AI 可以快速生成代码（至于这是否是好事，还存在争议），但这并不意味着它生成的是正确的代码。在人与 AI 开发的比较中，人们总是忽略了 AI 做事所需的手把手指导。实际上这个过程更像是这样的：需要领域和产品专家的深度参与，把每个功能缺陷都细化到最微小的细节之后才能交付给 AI。

这种工作方式要求我们对每一个功能和缺陷修复都给出极尽详细的说明，而软件开发者从职业诞生之初就在呼吁获得这样的详细问题描述和预期结果的说明。如果你给人类开发者同样多的功能或范围文档，你也会看到生产力飙升。

《目标》中有一个重要经验："瓶颈应该收到可预测的、高质量的输入。"我认为这应该是流程自动化的第一站。《丰田之路》是一本很棒的书，我强烈推荐它。《目标》读起来稍微不那么愉快，我会选择漫画版《人月神话》——另一本经典。