夜雨聆风当你以为 AI 能把 70 天的开发缩短到 3 天的时候，你可能忽略了流程中最关键的一环——它从来不在"开发"这一步。
引言
我有一个感觉：市面上几乎每一家公司，至少有一部分精力都花在了流程优化上——尤其是在市场下行的时候。而如今，这件事又加上了 AI 的维度，以及随之而来的不切实际的期望。
为了充分准备这个话题，我决定重读这个领域的两本经典著作：《丰田模式》（The Toyota Way）和《目标》（The Goal）。这两本书我在大学时就读过，但重读之后我意识到：很多流程优化工作过于简单化，而且经常搞错了该关注的重点。
视觉化的瓶颈
让我说明我的意思。
项目时间线
需求阶段
功能探索 ██████████ 10天
预算评估 ███ 3天
法务审批 ██████████ 10天
文档编写 █████ 5天
开发阶段
技术探索 █████████████████████████ 25天
软件开发 ████████████████████████████████████████████████████████████████████████████████ 70天
文档编写 █████ 5天
部署阶段
部署上线 █████ 5天
稳定期支持 ██████████ 10天注：这只是一个用于说明的甘特图。通常你会看 BPMN（业务流程建模），但用甘特图更容易说明问题。
如果你看这张甘特图，你会立刻发现哪个环节耗时最多：软件开发，70 天。
如果你的任务是提高项目的整体吞吐量，软件开发自然是你首先关注的地方。这没有错。
但问题在于，我看到的大多数人的做法是：往这个问题上堆人，或者直接假设 AI 会让它快很多倍。
而大多数人不做的事情是：搞清楚为什么这一步花了这么长时间。更重要的是：耗时长并不自动意味着问题的根源就在这里。
在上游解决问题
我们现在说的是软件开发，但这个道理适用于所有你觉得"太慢了"的流程。
每个软件开发者都知道：你不能只靠"打字更快"来让项目变快。如果是那样的话，我们都该去上打字课了。
软件开发的核心是：把一个业务问题翻译成一个计算机可以理解并自动解决的方案。 最好还能安全、可扩展。
要做到这一点，你需要对问题有全面的了解。要么通过功能或范围文档（如果你走瀑布流），要么通过与领域专家的持续迭代（如果你走敏捷路线）。
而这往往正是拖慢软件开发的部分：试图搞清楚一个模糊的、只有一个标题的功能需求，到底是什么意思。
"销售完成后给用户发邮件"——这句话是什么意思？
好，我们能发邮件。但邮件里应该写什么？如果销售流程出了问题，我们还需要发错误邮件吗？什么时候算"销售完成"？
这些看似简单的问题，往往需要来回沟通好几次才能搞清楚。而这几十次来回沟通的时间，全部算在了"开发"头上。
"把 AI 丢上去就行了"
关于自动化软件开发（AI 生成代码），我一直在听到的一个论点是：你可以直接跳过开发环节，软件开发者就变成了项目经理。
围绕软件开发展开的 AI 讨论，恰恰完美地说明了这个问题。
很多人期望 AI 开发的结果是这样的：
项目时间线（AI 梦想版）
需求阶段
功能探索 ██████████ 10天
预算评估 ███ 3天
法务审批 ██████████ 10天
文档编写 ████ 4天
开发阶段
AI 开发 ███ 3天
部署阶段
部署上线 █████ 5天
稳定期支持 ██████████ 10天但这不是事情的真实运行方式。在这里，我们面临着和之前完全一样的上游问题。
是的，AI 可以快速生成代码（至于这是否是好事情，还可以再讨论），但这并不意味着它生成的是正确的代码。
在人类开发者和 AI 开发者的对比中，人们总是忽略了"手把手引导"AI 完成工作所花费的时间。
真实情况更像这样：
项目时间线（AI 现实版）
需求阶段
功能探索 ██████████ 10天
预算评估 ███ 3天
法务审批 ██████████ 10天
文档编写 ████████████████████████████████████████ 40天
↑ 需要把每个功能和 bug 修复细化到极致
开发阶段
AI 开发 ████████████████████████████████████████ 40天
↑ 与文档编写并行进行，持续迭代
部署阶段
部署上线 █████ 5天
稳定期支持 ██████████ 10天也许这种方式确实比旧的工作模式快一些。但我认为这是一个不公平的比较。因为这样工作需要对领域专家和产品专家更深程度的参与——这意味着要把每一个功能、每一个 bug 修复都细化到最微小的细节。
而这恰恰是软件开发者从入行第一天起就想要的事情：给我一份关于问题和预期结果的详细说明书。
如果你给人类开发者同等详细程度和规模的功能/范围文档，你会发现他们的生产力也会直线飙升。
真正加快流程的方法
如果你想加快流程，你需要确保执行工作的人拥有完成这项工作所需的一切手段。
这意味着：
如果你的法务审批流程很慢，你应该看看启动法务审批需要什么。如果他们需要追着五个人要一份不完整的文件，那你往法务部门加再多律师也加快不了这个流程。
《目标》这本书中最重要的教训之一就是："瓶颈应该接收可预测的、高质量的输入。"
我认为这应该是流程自动化的第一站。
写在最后
这篇文章的核心观点其实可以浓缩为一句话：
AI 不会让你的流程变快。但如果你的流程本来就跑对了，AI 会让它跑得更快。
大多数公司的问题不在开发环节太慢，而在上游输入太差。模糊的需求、不完整的文档、缺乏领域专家的深度参与——这些才是真正的瓶颈。
AI 代码生成再快，也无法弥补需求定义中的模糊。
AI 自动部署再智能，也无法解决法务审批中的流程混乱。
AI 生成文档再高效，也无法替代产品专家对业务逻辑的深度理解。
把 AI 丢到一个本身就运转不良的流程上，就像给一辆没油的车装上更好的轮胎——看起来升级了，但实际上还是走不动。
真正值得做的，是先把流程理顺。确保每个环节都能接收到清晰、完整、高质量的输入。然后，再让 AI 来加速。
顺序不能搞反。
📌 原文作者：Frederick Van Brabant
📌 原文来源：frederickvanbrabant.com/blog/2026-05-15-i-dont-think-ai-will-make-your-processes-go-faster/
📌 推荐阅读：《丰田模式》(The Toyota Way)、《目标》(The Goal)
