没有意图的自动化，只是更快的混乱

我用 AI 做“氛围式编程”已经有一段时间了。用 AI 做功能，发布那些我一个人以前不会尝试的东西，看多模型流水线处理过去要花我几天的问题。这件事确实让人兴奋。

但做着做着，我注意到一个不舒服的事实。那个本来帮我更快发布的流水线，反而开始拖我后腿。不是因为它不工作；它工作得还行。问题是，我自动化了一个自己都没把终点说清楚的流程。没有意图的自动化，只是更快的混乱。

我把自己的 Dev Buddy 插件流水线迭代了三版，才弄清楚真正重要的是什么。过程大概是这样。

复杂的成功

第一版，v0.2.x，是我自己手搓的 Ralph 流水线。如果你不熟，Ralph Wiggum 技巧 的核心是每次迭代都用新上下文：规格写在磁盘上，AI 每次重新读取，然后循环直到正确。这样可以避免幻觉一路累积，也能减少上下文漂移。

我从零做了整套东西。自定义编排，手调阶段，把所有部分粘起来的胶水代码。说实话，它确实能跑。功能会从另一端出来。多 AI 方法，也就是不同模型互相检查，会抓到单模型抓不到的问题。

但它像一台鲁布·戈德堡机器。看起来很厉害，维护起来很累。每次想改东西，我都要穿过好几层自定义逻辑。我为它自豪，但也害怕碰它。那个本该节省时间的流水线，在吃掉我的周末。

当你花在维护流程上的时间，比真正构建功能还多，这就是坏信号。

反噬的简化

所以我做了任何理性的人都会做的事：简化。0.3.x 去掉复杂度，让系统更轻、更直接。

然后我什么都看不见了。

流水线会运行，但我不知道里面发生了什么。我启动一个流程，然后只能等。它在工作吗？卡住了吗？三步前是不是已经静默失败？不知道。简化把复杂度扔掉了，也把可见性一起扔掉了。

我一小时后回来，发现流水线要么已经走到完全错误的方向，要么在一个本该立即标记的问题上空转。进度不可见，失败不可见。我像是在盲飞。

这时一位同事提到了反压。

这个概念来自系统工程：当下游系统跟不上时，它会向上游施加压力，而不是静默丢数据或崩溃。设计良好的流水线会这样处理过载：系统告诉你出了问题，而不是假装一切正常。

我开始想：如果我的 AI 流水线也这样呢？如果它在出错时不是假装没事继续跑，而是把压力推回上游？把失败暴露出来，带着新上下文重试，或者停下来让我介入，而不是顺滑地错下去？

突破点

把反压和 Ralph 循环结合后，事情变了。第一次，流水线不再对明显不好的工作照单全收。

现在每个阶段都有关卡。机械反压，也就是测试、类型检查和静态检查，会在每次构建后运行。但编排器不相信 AI 自己汇报的结果。它会独立运行检查。失败时，流水线带着失败上下文回到下一次尝试。上下文是新的，视角也是新的，但它记得刚刚哪里出了错。

我会在不同阶段配置不同 AI 模型，比如探索、需求、代码审查，这样一个模型家族的盲点不会在整个流水线里叠加。如果你想看完整架构，这里有流程图。

结果是：以前要反复来回几天的复杂项目，现在几小时内就能完成。我启动它，在早期检查点做方向确认（探索、需求、拆解都会暂停让我批准），然后让它自己跑构建、审查、UAT。

但我必须诚实：它仍然高度依赖两件事，模型能力和计划细节。弱模型或含糊计划，会让流水线无限循环，烧掉 token 但没有进展。工具会放大你给它的东西，无论是好方向还是坏方向。

先知道自己要什么

这是我做了这么久 AI 辅助编程后学到的最重要一件事。

开始前你必须知道自己要什么。不是大概知道，也不是“做着做着再看”。你需要一个真实、具体的终点。

我通常会在任何实现开始前，在计划文件上花几个小时。而且不只是写一次，是反复迭代。启动流程，发现计划漏洞，停下来，改进，再重启。有时要走三四轮，计划才足够扎实，让流水线干净地跑完。

这听起来很慢，像是在违背 AI 辅助开发的初衷。但这些规划时间会省下几天返工。计划清楚时，流水线会很顺。计划含糊时，流水线会产出看起来很自信的垃圾。

我反复掉进的坑是范围蔓延。一开始计划很清楚、很聚焦。然后我想到还能加一件事，再想到另一件。计划越长越大，最后变成一个我光看就累的庞然大物。实现清单横跨整个屏幕，东西还没开始做，我已经疲惫了。

这种疲惫我经历过太多次。每一次根因都一样：我让范围超出了最初想要的东西。我不再知道什么叫完成。

那时我意识到，我需要一种机械方式强制 “完成”。不是感觉，不是我会忽略的检查清单，而是真正的关卡。

UAT 关卡

这个想法来自一个简单问题：如果有一个技能能替我做所有测试会怎样？

不是单元测试。那些我已经有了。单元测试检查单个部件，但不检查整个功能是否按用户预期流动。我见过太多情况：每个单元测试都过了，但实际功能仍然坏。零件没问题，但整个流程跑不通。

所以我做了另一种东西。我把关心的场景列出来，包括正常场景和异常场景，放在一个文件夹里。一个技能遍历这些场景，自动跑用户验收测试。不是“函数返回值对不对”，而是“这个功能是否真的按我描述的方式工作”。

然后我把 UAT 步骤加进 Ralph 循环，作为门控条件。UAT 不通过，流水线就不能把工作标记为完成。如果一个场景失败，它会识别受影响的单元，把它们送回构建和代码审查，然后重新跑 UAT。直到全部通过。如果在迭代上限内做不到，它会升级给我，而不是假装成功。

到目前为止，这很有效。UAT 关卡抓到了单元测试抓不到的问题：集成问题、流程问题、只有测试真实用户体验时才会暴露的边界情况。因为它是自动化的，我也不需要记得手工测每件事。流水线不会允许我发布一个和我说的目标不匹配的东西。

UAT 场景本质上就是机器可读版的“我想要什么”。这个关卡拒绝让流水线在没完成时假装完成。

我会对一年前的自己说什么

工具没有你以为的那么重要。反压、Ralph 循环、多 AI 审查、围绕流水线搭起来的所有脚手架，都有用。但真正改变结果的，是在开始自动化前先弄清楚我想要什么。

范围纪律永远胜过工具复杂度。一个定义清楚的目标加上简单流水线，会胜过一个含糊目标加上最复杂的编排。我是迭代三版后用笨办法学到的。

如果你对技术细节感兴趣，Dev Buddy 插件 是开源的。也有一篇 分步教程 可以帮你自己搭起来。但架构不是这篇文章的重点。

重点更简单：如果你不知道 “完成” 长什么样，再多流水线工程都救不了你。我花了三版才学会这件事。