我不认为AI会让你的流程变得更快

# 我不认为AI会让你的流程更快 来源：https://frederickvanbrabant.com/blog/2026-05-15-i-dont-think-ai-will-make-your-processes-go-faster/ 我感觉现在每一个组织机构，至少在一定程度上，都在关注流程优化——这通常发生在市场不景气的时候。如今，AI又为整个事情增添了一个角度，以及随之而来的不切实际的期望。 为了充分做好准备，我决定重读这个领域的两个绝对经典著作：《丰田之道》（https://en.wikipedia.org/wiki/The_Toyota_Way）和《目标》（https://en.wikipedia.org/wiki/The_Goal_%28novel%29）¹（https://frederickvanbrabant.com/blog/2026-05-15-i-dont-think-ai-will-make-your-processes-go-faster/#fn:1）。我在大学期间读过这两本书，但重读让我意识到，很多这样的流程优化练习本质上过于简单化，而且常常误解了应该关注的重点。 ## 看得见的瓶颈 让我来说明我的意思。 ``` gantt title 项目时间线 dateFormat YYYY-MM-DD section 范围界定 功能探索 :s1, 2024-01-01, 10d 预算范围界定 :s2, after s1, 3d 法律 :s3, after s1, 10d 文档编写 :s4, after s3, 5d section 开发 探索 :d1, after s4, 25d 软件开发 :d2, after d1, 70d 文档 :d3, after d2, 5d section 部署 部署 :dp1, after d2, 5d 超期运维 :dp2, after dp1, 10d ``` *这是一个用于演示的甘特图，通常你会看 BPMN。用甘特图更容易说明问题。* 如果你看一下这个甘特图，你会立刻看到什么占据的时间最长：软件开发。如果你的任务是提高项目吞吐量，那就会是你的第一站。这样想是对的。 然而，问题在于我通常看到人们是如何处理它的：要么往问题上投入更多人手²（https://frederickvanbrabant.com/blog/2026-05-15-i-dont-think-ai-will-make-your-processes-go-faster/#fn:2），要么就是假设AI会让它快得多。 人们通常不去看**为什么**这会花这么长时间，更重要的是：持续时间长并不自动意味着问题就出在那里。 ## 从上游解决问题 我们现在在谈论软件开发，但这适用于所有比你期望的要花费更长时间的过程。 每个软件开发人员都知道，你不能仅仅通过打字更快来让项目加速。如果那样的话，我们都去上打字课了。 软件开发是把一个问题转化为一个计算机能够理解并自动解决的方案。最好是安全且可扩展的方式。 要做到这一点，你需要对问题有全面的了解。要么是在功能或范围文档中（如果你更倾向于瀑布式），要么是与领域专家持续迭代（更敏捷的方式）。 这通常是拖慢软件开发的部分。试图弄清楚一个模糊的、只有标题的功能请求到底是什么意思。 “用户完成销售后发送邮件”是什么意思？好的，我们可以发送邮件，但邮件里应该有什么？如果销售过程中出现了问题，我们是否还要发送错误邮件？销售何时算作完成？ ## 直接用AI搞定 关于软件开发自动化（AI生成代码），我反复听到的一个论点是，你可以直接跳过开发部分，软件开发人员变成项目经理。围绕AI开发软件开发的讨论实际上完美地说明了这个问题。 很多人期望AI开发的结果看起来像这样： ``` gantt title 项目时间线 dateFormat YYYY-MM-DD section 范围界定 功能探索 :s1, 2024-01-01, 10d 预算范围界定 :s2, after s1, 3d 法律 :s3, after s1, 10d 文档编写 :s4, after s3, 5d section 开发 AI开发 :d1, after s4, 3d section 部署 部署 :dp1, after d1, 5d 超期运维 :dp2, after dp1, 10d ``` 但事实并非如此。在这里我们面临着和之前完全相同的上游问题。 是的，AI可以快速生成代码（这是好是坏还有争议），但这并不意味着它生成的是正确的代码。 在人类与AI开发的比较中，他们总是忽略AI做好事情所需要的“手把手指导”。实际情况更像是这样： ``` gantt title 项目时间线 dateFormat YYYY-MM-DD section 范围界定 功能探索 :s1, 2024-01-01, 10d 预算范围界定 :s2, after s1, 3d 法律 :s3, after s1, 10d 文档编写 :s4, after s3, 40d section 开发 AI开发 :d1, after s3, 40d section 部署 部署 :dp1, after d1, 5d 超期运维 :dp2, after dp1, 10d ``` 也许这种设置比旧的工作方式更快。但我也认为这是一种不公平的比较。以这种方式工作需要领域和产品专家更深入的参与。这种参与意味着要把每一个功能和错误修复都写到最细微的细节。 这正是软件开发人员从一开始就渴望的东西：收到问题的详细大纲以及最终结果应该是什么样子。 如果你给人类开发人员同样数量的功能/范围文档，你会发现他们的生产力也会飙升。 ## 真正加速流程 如果你想加速流程，你需要确保那些需要做工作的人拥有做工作的所有手段。 这意味着，如果法律审批流程速度慢，你要看看启动法律审批流程需要什么。如果他们需要追着五个人要不完整的文档，你不会通过增加部门里的律师数量来加速这个流程。 《目标》中的一个重要教训是：“瓶颈应该接收可预测的、高质量的输入。” 我认为这应该是流程自动化的第一站。