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

用 AI vibe coding 有一阵子了。一个人以前不敢碰的功能，现在让 AI 帮着写出来就上线了；以前要花好几天的问题，现在丢给 multi-model pipeline 一会儿就啃完了。说实话，这种感觉确实上头。

但做着做着我发现一个很拧巴的事：那条帮我加速发布的 pipeline，反而成了拖慢我的瓶颈。不是因为它跑不起来——它跑得挺好的。问题出在我自动化了一个连终点都没想清楚的流程。没有意图的自动化，说白了就是更快地制造混乱。

我的 Dev Buddy 插件迭代了三个版本，我才搞明白到底什么才是重要的。说说这个过程。

能跑，但累

第一版 v0.2.x，是我自己手搓的一套 Ralph pipeline。不太熟的话，Ralph Wiggum 技巧的核心思路就一句话：每轮迭代都用全新 context。规格写死在磁盘上，AI 每次都从头读，然后循环跑到对为止。幻觉不会越滚越大，context drift 也不存在。

整套东西从零搭的。自定义编排器，手动调的阶段划分，一堆胶水代码把各个部分粘起来。说实话，它确实能跑通。功能能从流水线那头出来。多 AI 互相 review 这套打法，不同模型交叉检查，能揪出单模型根本发现不了的问题。

但它就像一台鲁布·戈德堡机械——看着挺炫，维护起来要命。每次想改点什么都得扒开好几层自定义逻辑。我为它挺骄傲的，但同时也怕碰它。一个本该省时间的 pipeline，在吃掉我的周末。

花在维护流程上的时间比写功能还多，这就已经亮红灯了。

越简化越瞎

然后我做了个所有正常人都会做的决定：砍。0.3.x 大刀阔斧砍复杂度，让系统更轻、更直接。

然后我什么都看不到了。

Pipeline 还在跑，但里面在干嘛我完全不知道。启动一个任务之后就只能干等。在跑吗？卡住了吗？三步前是不是就已经悄悄挂了？全都不知道。简化把复杂度砍掉了，可见性也跟着一起没了。

一个小时后回来看，pipeline 要么跑到了一个完全离谱的方向上，要么在一个本该第一时间报出来的问题上死循环。进度看不到，失败也看不到。纯纯盲飞。

就这时候，一个同事跟我聊到了 backpressure。

这个概念来自系统工程：下游系统处理不过来的时候，不是默默丢数据或者直接崩，而是向上游施加压力。设计得好的 pipeline 就该这样处理过载——系统主动告诉你出问题了，而不是假装一切正常。

我就想：我的 AI pipeline 能不能也这样？出错的时候不是闷头继续跑，而是把压力推回来——把失败暴露出来，带着新 context 重试，或者干脆停下来让我介入，而不是一路丝滑地错下去？

转折点

把 backpressure 和 Ralph loop 结合起来之后，事情真的不一样了。Pipeline 第一次学会了对明显有问题的产出说"不行"。

现在每个阶段都有 gate。机械层面的 backpressure——测试、类型检查、lint——每次 build 之后都会跑。但编排器不信 AI 自己报的结果，它会独立跑一遍检查。挂了的话，pipeline 会把失败的 context 带进下一轮尝试。Context 是新的，视角是新的，但刚才哪里栽了它也记着。

不同阶段我会配不同的 AI 模型——探索、需求、code review 各用不同的，这样一个模型家族的盲区不会在整条 pipeline 里层层放大。想看完整架构的话，这里有流程图。

效果怎么样呢？以前要来回折腾好几天的复杂项目，现在几个小时就能跑完。我启动 pipeline，在前几个 checkpoint 把方向调好——探索、需求、拆解每一步都会暂停等我确认——然后让它自己跑 build、review、UAT。

但得说实话：这套东西到现在还是高度依赖两样——模型能力和计划的细致程度。模型弱了或者计划写得含糊，pipeline 就会无限循环，token 哗哗烧但就是没进展。工具放大的是你给它的东西，方向对也好方向错也好。

先想清楚你要什么

做了这么久 AI 辅助开发，这是我觉得最重要的一件事。

动手之前你必须知道自己要什么。不是大概知道，不是"边做边看"，是得有一个实实在在的终点。

我一般会在动手写代码之前，花好几个小时磨 plan 文件。而且不是写一遍就完事——我会反复迭代。启动流程，发现 plan 里的漏洞，停下来改，再重启。有时候这个循环要走三四轮，plan 才足够扎实，pipeline 才能一口气跑完。

听着很慢对吧？感觉跟 AI 辅助开发的初衷对着干。但花在 plan 上的这几个小时，能省下后面好几天的返工。Plan 清楚的时候，pipeline 跑得飞起；plan 含糊的时候，pipeline 只会产出一堆看起来很自信的垃圾。

我一直踩的坑是 scope creep。一开始 plan 又清楚又聚焦，然后想着"要不再加个这个"，然后又想到一个。Plan 越写越长，最后变成一个光看着就累的庞然大物。实现清单横跨整个屏幕，还没开始干就已经累了。

这种疲惫感经历过太多次了。每次根因都一样：我让范围膨胀出了最初想要的东西，不再清楚"完成"到底长什么样。

到这时候我才意识到，我需要一种机械化的方式来强制定义"完成"。不是靠感觉，不是靠那种我会直接忽略的 checklist，而是一个真正的 gate。

UAT 关卡

想法来自一个很简单的问题：如果有个 skill 能帮我把所有测试都跑了呢？

不是 unit test，那个我早就有了。Unit test 检查的是单个模块对不对，但它检查不了整个功能在用户手里是不是真能跑通。这种场景我见太多了：unit test 全绿，但功能实际上是坏的——零件没问题，流程跑不通。

所以我换了个思路。我把在意的场景——正向的、反向的——全列在一个文件夹里，然后写一个 skill 去遍历这些场景，自动跑 UAT。不是"函数返回值对不对"那种，而是"这个功能是不是真的按我描述的方式在跑"。

然后我把 UAT 这一步加进 Ralph loop 里当硬性 gate。UAT 不过，pipeline 就不算完成。某个场景挂了，它会定位受影响的模块，打回去重新 build 和 code review，然后再跑一遍 UAT。循环到全部通过为止。如果在迭代上限内搞不定，它会升级给我，而不是装作成功了。

目前来看效果不错。UAT gate 能抓住 unit test 抓不到的东西——集成问题、流程问题、只有真正模拟用户操作才会暴露的 edge case。而且因为是自动化的，我也不用手测每一样东西。Pipeline 不会让我发布一个跟预期不符的东西。

UAT 场景说白了就是"我想要什么"的机器可读版本。这个 gate 拒绝让 pipeline 在没做完的时候假装做完了。

如果能跟一年前的自己说句话

工具没你想的那么重要。Backpressure、Ralph loop、多 AI review、围绕 pipeline 搭的所有脚手架——都有用，当然有用。但真正改变结果的，是在开始自动化之前先把"我要什么"想清楚。

范围纪律永远比工具花哨管用。一个定义清楚的目标加一条简单的 pipeline，会赢过一个模糊目标加上最复杂的编排。这件事我是迭代了三个版本之后用笨办法学会的。

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

重点比那简单多了：如果你不知道"完成"长什么样，再多 pipeline 工程也救不了你。我花了三个版本才学会这件事。