# 没有意图的自动化，只是更快的混乱 **Summary:** 三套失败的流水线架构，一次关于反压的教训，以及最终让多 AI 氛围编程跑起来的 UAT 门。本文复盘什么坏了、什么留下来，以及为什么知道自己想要什么比工具本身更重要。 - Canonical: https://markhuang.ai/zh/blog/automation-without-intention-is-just-faster-chaos - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-04-03 - Section: AI 与 LLM - Tags: 氛围编程, 多 AI, 反压, Dev Buddy, AI 编码, 经验 - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![一条全速运行的装配线，产出的不是整齐产品，而是一堆混乱缠绕的零件](https://cdn.markhuang.ai/blog/automation-without-intention-is-just-faster-chaos/hero.zh-CN.webp) *没有意图的自动化，只是更快的混乱* 用 AI vibe coding 有一阵子了。一个人以前不敢碰的功能，现在让 AI 帮着写出来就上线了；以前要花好几天的问题，现在丢给 multi-model pipeline 一会儿就啃完了。说实话，这种感觉确实上头。 但做着做着我发现一个很拧巴的事：那条帮我加速发布的 pipeline，反而成了拖慢我的瓶颈。不是因为它跑不起来——它跑得挺好的。问题出在我自动化了一个连终点都没想清楚的流程。没有意图的自动化，说白了就是更快地制造混乱。 我的 [Dev Buddy](https://github.com/Z-M-Huang/vcp/tree/main/plugins/dev-buddy) 插件迭代了三个版本，我才搞明白到底什么才是重要的。说说这个过程。 ## 能跑，但累 第一版 v0.2.x，是我自己手搓的一套 Ralph pipeline。不太熟的话，[Ralph Wiggum 技巧](https://ghuntley.com/ralph/)的核心思路就一句话：每轮迭代都用全新 context。规格写死在磁盘上，AI 每次都从头读，然后循环跑到对为止。幻觉不会越滚越大，context drift 也不存在。 整套东西从零搭的。自定义编排器，手动调的阶段划分，一堆胶水代码把各个部分粘起来。说实话，它确实能跑通。功能能从流水线那头出来。[多 AI 互相 review](/blog/the-multi-ai-thesis) 这套打法，不同模型交叉检查，能揪出单模型根本发现不了的问题。 但它就像一台鲁布·戈德堡机械——看着挺炫，维护起来要命。每次想改点什么都得扒开好几层自定义逻辑。我为它挺骄傲的，但同时也怕碰它。一个本该省时间的 pipeline，在吃掉我的周末。 花在维护流程上的时间比写功能还多，这就已经亮红灯了。 ## 越简化越瞎 然后我做了个所有正常人都会做的决定：砍。0.3.x 大刀阔斧砍复杂度，让系统更轻、更直接。 ![开发者盯着充满雾气的监视器，看不见背后运行的流水线](https://cdn.markhuang.ai/blog/automation-without-intention-is-just-faster-chaos/lost-visibility.webp) *简化之后丢失的可见性* 然后我什么都看不到了。 Pipeline 还在跑，但里面在干嘛我完全不知道。启动一个任务之后就只能干等。在跑吗？卡住了吗？三步前是不是就已经悄悄挂了？全都不知道。简化把复杂度砍掉了，可见性也跟着一起没了。 一个小时后回来看，pipeline 要么跑到了一个完全离谱的方向上，要么在一个本该第一时间报出来的问题上死循环。进度看不到，失败也看不到。纯纯盲飞。 就这时候，一个同事跟我聊到了 backpressure。 这个概念来自系统工程：下游系统处理不过来的时候，不是默默丢数据或者直接崩，而是向上游施加压力。设计得好的 pipeline 就该这样处理过载——系统主动告诉你出问题了，而不是假装一切正常。 我就想：我的 AI pipeline 能不能也这样？出错的时候不是闷头继续跑，而是把压力推回来——把失败暴露出来，带着新 context 重试，或者干脆停下来让我介入，而不是一路丝滑地错下去？ ## 转折点 把 backpressure 和 Ralph loop 结合起来之后，事情真的不一样了。Pipeline 第一次学会了对明显有问题的产出说"不行"。 现在每个阶段都有 gate。机械层面的 backpressure——测试、类型检查、lint——每次 build 之后都会跑。但编排器不信 AI 自己报的结果，它会独立跑一遍检查。挂了的话，pipeline 会把失败的 context 带进下一轮尝试。Context 是新的，视角是新的，但刚才哪里栽了它也记着。 不同阶段我会配不同的 AI 模型——探索、需求、code review 各用不同的，这样一个模型家族的盲区不会在整条 pipeline 里层层放大。想看完整架构的话，[这里有流程图](https://github.com/Z-M-Huang/vcp/blob/main/plugins/dev-buddy/README.md#the-solution-ralph-loop-architecture)。 效果怎么样呢？以前要来回折腾好几天的复杂项目，现在几个小时就能跑完。我启动 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 全绿，但功能实际上是坏的——零件没问题，流程跑不通。 ![左边是混乱无控制的数据流，右边是平静且经过关卡验证的流程](https://cdn.markhuang.ai/blog/automation-without-intention-is-just-faster-chaos/uat-gate.zh-CN.webp) *UAT 关卡把"完成"变成可验证状态* 所以我换了个思路。我把在意的场景——正向的、反向的——全列在一个文件夹里，然后写一个 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 插件](https://github.com/Z-M-Huang/vcp/tree/main/plugins/dev-buddy)是开源的。还有一篇[分步教程](/blog/dev-buddy-multi-ai-pipelines-with-claude-code)可以帮你搭起来。但架构不是这篇文章的重点。 重点比那简单多了：如果你不知道"完成"长什么样，再多 pipeline 工程也救不了你。我花了三个版本才学会这件事。