引用：I don’t think AI will make your processes go faster
这篇文章的核心判断很直接：AI 也许能让某些执行环节变快，但它不会自动让整个流程变快。真正拖慢流程的，往往不是“写代码太慢”这种可见环节，而是上游输入质量太差，问题没有被定义清楚。
我认同这篇文章，而且我觉得它戳中了很多 AI 乐观叙事里最偷懒的一块：把“执行速度”误当成“流程速度”。现在一提到 AI 辅助开发，很多讨论会立刻滑向一个很爽的想象，需求来了，模型写代码，工程师从键盘工变成项目经理，原来几周的开发被压缩成几天。听起来很未来，问题是，这套想象经常假装上游世界已经干净、清楚、结构化。现实当然不是这样。
作者用甘特图举了一个很典型的例子。项目里看起来最耗时的是软件开发，于是大家很自然地盯上开发环节，想加人，想自动化，想让 AI 把代码生成得更快。但长耗时不等于问题根源就在这里。开发慢，很多时候不是因为开发者打字慢，而是因为需求本身像一张没有填完的表：发什么邮件，什么时候算交易完成，异常时要不要通知，谁负责审批，边界条件怎么处理。这些都不清楚，代码写得越快，只是越快把模糊变成 bug。
这也是我最喜欢原文的一句判断：如果给 AI 足够详细的需求说明，它当然可能产出得很快；可同样的说明给人类开发者，效率也会大幅提升。换句话说，很多所谓“AI 让流程变快”的案例，其实隐含了一个不公平前提：为了让 AI 工作，人们终于愿意把需求写清楚、把边界补齐、把验收标准讲明白。那到底是 AI 的功劳，还是上游输入终于像个人样了？这个问题不问清楚，后面的效率神话就很容易变成幻术。
这里不是说 AI 没价值。恰恰相反，AI 在执行层的价值很明显，尤其是把明确规格转成代码、生成测试、补样板、迁移重复结构、检查明显缺陷时，它确实能减少大量机械劳动。但它不擅长替组织承担那些本来就没人愿意承担的责任：谁来定义目标，谁来取舍范围，谁来确认异常路径，谁来为最终用户负责。你可以把这些问题丢给模型，让它先猜一版，但猜测不是决策。模型给出的默认方案越流畅，团队越容易忘记那只是默认方案，不是已经被业务承认的现实。
这篇文章把问题拉回流程管理，我觉得很必要。流程优化不是看哪一段最长就砍哪一段，而是看瓶颈收到的输入是不是稳定、完整、可处理。作者引用《目标》里的思想，瓶颈应该收到 “predictable, high-quality inputs”，也就是可预期、高质量的输入。这个标准放到 AI 时代更重要。因为 AI 会降低试错成本，也会降低乱试的心理门槛。以前一个含糊需求没人敢立刻开干，现在模型一分钟能生成一堆东西，于是团队会产生一种“先做出来看看”的错觉。看似快，后面全是返工、解释和补债。
我尤其警惕“开发者变成项目经理”这种说法。它听起来像角色升级，实际经常只是把产品定义、系统设计、质量控制、风险判断全塞给同一个人，再让 AI 负责制造更多待审核产物。真正困难的不是让模型写出一段能跑的代码，而是知道这段代码是不是应该存在，是否符合场景，未来会不会把系统带偏。这个判断如果没有被流程承接，只靠最后一个人在 code review 里硬扛，那不是效率提升，是把不确定性集中到更晚的位置爆炸。
所以我的结论会比原文再刻薄一点：AI 不会拯救烂流程，它只会让烂流程更快暴露。一个团队如果原本就能写清楚需求、拆清楚边界、给出稳定输入，那 AI 会是很好的放大器；一个团队如果长期靠口头默契、临时拍板和模糊标题推进，AI 只会把这些模糊批量翻译成看似完成的半成品。速度不是没有了，只是从“慢慢做对”变成“快速做错再慢慢修”。
这篇值得读，尤其适合那些正在把 AI 当流程加速器的人。我的一句话理由是：别先问 AI 能不能把开发压到三天，先问你的需求能不能让任何一个清醒的人在三天后验收。