Vibe coding 如何稳定长时运行不跑偏：我用三个模式，让AI一路跑到生产级

Vibe Coding 的爽是真的：一句话，五分钟，八百行能跑的代码。慌也是真的：代码摆在面前，你读不完，也看不出它哪里有问题。

过去半年，我把 AI 编程从「聊着写」升级成一条完整的工作流。核心就三个词：harness engineering、loop engineering，外加 Advisor 和 Delivery 两个监督机制。loop 里面还套着 TDD、SDD、VDD 三种开发方法论，最外面再套一圈自我进化的外环。

它们帮我解决三件事：让 AI 写的代码尽量是对的；让 AI 在几小时的长任务里不跑偏；让产出达到能上线的标准。现在从原型、开发、测试、部署，到 CI/CD、线上运维，是一条打通的链路。

一问题：AI 写的代码，得当它不可信

先说清楚为什么需要这套工作流。AI 编程和以前的编程，难的点完全不一样。

第一，它看起来完全没问题。

以前写软件，最贵的是写：一个想法变成能跑的代码，要几天几周。AI 来了，写几乎免费，难的地方换到了另一边——八百行代码摆在面前，你怎么知道它是对的？

最麻烦的是，AI 没有「不确定度」。人改不熟的模块，手是抖的，会多看两眼、多测一下。AI 说「我很确定」和「我在瞎猜」，句型和语气一模一样。它还会把话说得很满：「我已经测试过了」「全部通过」。人撒这种谎会犹豫，AI 生成这句话和生成任何一句话，代价一样。

第二，它零记忆。

项目里没写下来的东西，它全不知道。这个目录不能动、那个接口外面有人用、支付相关的改动必须多看一眼——这些原来只存在人脑子里。每开一个新会话，这些约定全部归零。它是个技术很强、但第二天就失忆的同事。

第三，错误会被时间放大。

所以问题的本质是：不是模型不够聪明，而是没有人给它搭环境、定规矩、设检查、管节奏。这就是三个模式各自的位置。

二第一个模式：Harness Engineering，给 AI 造一个靠谱的工作环境

有个等式在行业里流传：Agent = Model + Harness。模型负责想，壳负责让它想出来的东西落地时不翻车。

为什么壳这么重要？有个很直观的公开证据：同一个模型，换一个设计更好的运行环境跑，评测分数差一大截，能从排行榜中游冲进前五。业内有句话总结得好：好壳配普通模型，赢过强模型配差壳。你看到的模型能力，和模型实际能力的差距，很大一部分是壳的差距。所以别总等下一个模型版本，先把壳做好。

这套说法不是我编的。OpenAI 发过一篇讲 harness engineering 的文章，讲他们怎么用 Codex 在一个 agent-first 的环境里做工程：工程师不直接写代码，而是设计环境，把规矩全部写进仓库、让机器执行。Anthropic 发过一篇长任务 agent 的文章，专门研究怎么让 agent 连续跑几个小时不跑偏；advisor 策略（强模型监督弱模型执行）也出自他们的官方博客。我做的，是把这些公开方法论落成自己的日常。

心法一：出错先改配置，棘轮只进不退

没告诉它项目约定，就把约定写进规矩文档；它跑过一次破坏性命令，就加一道钩子拦住。每次踩坑都往环境里补一条，补过的坑永远消失——这叫 ratchet，棘轮，只进不退。

还要克制：只加你踩过的坑，别预先堆规矩。 规矩一多，每条就没分量。

心法二：壳做三件事

我把壳的工作归纳成三件。

第一件：做减法，让一大类错误根本写不出来。

类型检查、目录规范、模块边界、统一命令入口、禁止的命名——这些不检测错误，它们直接缩小能出错的范围。一条静态规则的价值经常超过十个测试：规则一次拦掉一整类错，测试一次只挡一个点。

第二件：给标准，一套不由 AI 自己说了算的检查。

检查有强弱之分。最弱的只看「崩没崩」，往上看类型、看已知答案、看变化规律，最强的把完整要求写成机器可判的规格。AI 任务接之前，先想好怎么检查；想不出来，就先建一个。检查的强度，比检查的数量更能解释质量差异。

全绿有五种来路：真绿、检查被跳过、缺配置自动跳过、断言是空的、检查的对象早就没了。后面四种最后都会绿。假绿比没检查更危险——人不在场时，AI 会一直把系统往假绿的方向推：测试跑不过，就把断言改松；报错烦人，就包一层吞掉。错误消失了，问题还在。

对策很简单：定期故意写一段违规代码，看门禁拦不拦。拦不住，这道门禁等于没有。

心法三：文档当地图，不写手册

规矩文档控制在百行以内，只教 AI「下一步看哪里」，知识本体放 docs 目录。上下文是稀缺资源，AI 读不到的东西，对它就等于不存在。

只管不变量：分层、依赖方向、横切入口写死，具体怎么实现不管。规矩能写进 linter 和结构测试就写进去，报错文案里直接带修复指引——一次编码，处处生效。

这套东西落在仓库里，就是三支柱

缺一个都会漂移：命令接了没规矩，AI 不知道该听谁；规矩立了不验证，慢慢就没人当回事。

心法四：跟项目腐化打持久战

前三件心法管「搭起来」，这一件管「别烂掉」。

软件是会腐化的：每次修改只照顾眼前，单看每一步都合理，一百步之后没人看得懂。AI 把腐化加速了好几倍——它一天加的补丁、建的 `_v1`/`_v2` 文件、复制的代码块，比人一个月都多。它还有个坏习惯：照仓库里已有的模式写，哪怕是歪的、次优的。 一个歪模式被复制十遍，仓库就成沼泽。

对策分三层。

第一层，漂移扫描。 把人的品味编码进仓库，后台任务定期扫偏差、自动开修复请求。技术债小笔持续还，不攒巨债。

第二层，篱笆自测。 从来没红过的检查，说明不了任何事。每加一道门禁，配一条故意触犯它的例子，看它拦不拦。拦不住的门禁等于没有。

第三层，Goodhart 防线。 你盯着哪个数字，哪个数字就会开始撒谎。在 agent 系统里这是对抗型的：AI 会主动钻数字和目标之间的缝，追覆盖率追出一堆没有断言的测试。规矩只有一条：被检查者自己产出来的证明，不算证据。 这也是为什么后面讲的 Delivery 和 Advisor，检查者全部是独立第三方。

三第二个模式：Loop Engineering，让壳自己转起来

Prompt 和 loop 的区别：prompt 是孤立指令，模型答一句就停，等你下一句；loop 是递归目标，你定下目的，系统一直转，转到达成。

这个词在 2026 年才被广泛讨论，谱系很清楚：2023 年讲 prompt engineering（一次提问怎么说清），之后讲 context engineering（带什么上下文），2025 年底讲 harness engineering（壳怎么设计），2026 年讲 loop engineering（让壳自己转）。

骨架：计划、执行、检查、再计划

四个环，转起来就是长任务。

计划。 目标、范围、完成判据，开工前写死。完成标准必须是可检查的——「测试全过」，而不是「看起来写完了」。

执行。 按清单逐件做，每做一件留一个提交，把清单上的条目逐条勾掉。知识沉淀成可复用的技能文件，每一轮不用从零推导整个项目。

检查。 这是最容易被糊弄的一环：自己开发完了自己检查，永远都是好的。所以必须派独立的检查者来审——另一个不看执行过程的 AI，只看证据。循环里最贵的就是这一步，它决定你敢不敢走开。

再计划。 检查出问题，两种处理：更新原任务的说明，或者往清单里追加新任务。然后继续转。

换班制：长任务靠磁盘上的笔记

几小时的任务，上下文会满、会话会断。解决办法借鉴 Ralph loop 的思路：第一轮先只写清单——启动脚本、进度日志、特性清单，每条先标「未完成」；之后每一轮做一件、提交一次、勾掉一条。

接班的 AI 不用回忆，读清单就知道还剩哪几条。AI 换班，上一班的上下文不在新会话里，靠磁盘上的笔记继续。

三件保险：预算、刹车、人

预算。 轮数、时间、token 都有上限，超了就停。停要带名字停——「预算耗尽」不是完成的理由。

刹车。 长任务有五种典型失败：反复试同一个修法停不下来；干到一半就报完成；上下文被历史塞满、推理质量下降；自评永远「看起来不错」，转了十圈质量不涨；目标被埋在上下文里，慢慢偏到别的任务。五种失败落到三件事上：评价要独立、状态要落盘、停止条件要可查。

人。 自动化不是把人从流程里移除。人做三件事：决定做什么，验证产出，保留必须人工判断的关口——安全、支付、数据删除、对外接口、数据库迁移，列出来，必须人来批。你的审查带宽决定能并行跑几个任务，而不是工具决定。

Loop 里的开发方法论：TDD、SDD、VDD

loop 的「检查」这一环，靠什么撑住？我按强度排了三种开发方法论。

TDD，测试驱动开发。 先写测试，再写实现。测试从红变绿，绿是挣来的，不是说来的。它是最基础的防假绿装置：AI 没法再说「我测试过了」，因为测试写在代码之前，而且不由它说了算。

SDD，规格驱动开发。 先写 spec，再写代码。spec 是合同：输入是什么、输出是什么、边界在哪里。AI 按 spec 逐条实现，检查也按 spec 逐条核对。loop 里「计划」这一环写出来的执行计划，本质就是 spec——它必须产出一个能当场演示的行为，而不是「改到符合定义」。

三者的关系一句话：TDD 管「代码写没写对」，SDD 管「代码是不是按约定写的」，VDD 管「检查本身可不可信」。 一层比一层硬，loop 的检查环才有底气。

外环：自我进化

前面讲的 loop，都是 AI 转着干活。还有一层外环：让 loop 自己越转越好。这就是自我进化。

进化的对象可以是任何可评估的产物：一段 prompt、一个技能文件、一段代码、一份配置，甚至 harness 本身。需要三样东西：产物（被改进的东西）、oracle（判好坏的标准：一组标准答案用例，或一条打印分数的命令）、执行方法（怎么从产物得到结果）。

loop 的形态一句话：变异、评估、过门、保留或回滚。 每轮只改一处（原子变异）；改之前先写一个可证伪的预测——哪几条用例会从红变绿、哪几条不受影响；改完拿预测对结果。预测写完就锁死，事后补预测等于作弊。

几个关键设计。

oracle 是唯一真源，且不许改 oracle。 改标准答案让检查通过，等于改考题迁就答案。

用例切三份。 开发集每轮用；留出集只在最后一道门用，提方案的一方永远看不到；回归集保护已经通过的用例。这防的是「刷题」：练习题做得好不算数，期末考试好才算。

门是确定性的。 保留还是回滚，由规则算出来，不由 AI 自评。更狠的一招是预算对齐的对照组：给基线同样的预算跑一遍，把「产物真的变好了」和「只是搜得更久了」分开。没有总预算上限的进化是耍流氓——「一直迭代到变好」这句话，靠堆钱就能满足。

定时删除。 每隔几轮必须做一次删除型变异。只加文字的 loop 迟早臃肿，攒下的废话指令会抵消它带来的收益。全绿的时候也别闲着，转向简化：更短更干净的产物，比更长的强。

这层外环还能进化它自己——管 loop 的方法论本身也是产物，也能放进进化 loop 里跑。loop 管 loop，harness 就不再是一次搭好、永久使用，而是一个活的系统。

四两个监督机制：Advisor 和 Delivery

Loop 转起来之后，还差两个具体的把关角色。一个管「干得对不对」，一个管「干完没有」。

Advisor：一步一盯的私教

模式是「小模型执行，大模型监督」。执行用便宜快的模型，每一步做完，一个更强的模型立刻在旁边看这一步有没有问题，发现偏离当场纠正。

为什么现在才用得起？因为执行模型最近追上来了，又便宜又快，监督的钱花得值。官方数据：中等模型执行加强模型监督，比中等模型单独跑分数高，单任务成本反而低一成左右；用最强的模型当顾问，能拿到它单独跑九成多的分数，成本约六成。

这里有个关键设计选择。监督可以做成一个工具，等执行者主动求助；也可以做成一个钩子，每一步结束强制触发一次审查。前者像线下培训班，学生不举手老师就不管，弱模型常常闷头做完都不求助；后者像一对一私教，每一步都有人盯着。我选了后者，并且做了分级：小问题提醒，大问题警告，严重偏离才要求立即改正。顾问默认静默，不乱插手。

还有个经验：让合适的模型干合适的事。有的模型想得深、上下文窗口短，让它长时间执行容易挖到一半满盘皆输；但它判断快、想得深，当监督正合适。一个长执行、一个快指正，短板互补。

Delivery：收工前的一道判决链

执行者说「我做完了」，这话不算数。Delivery 在每轮结束时跑一条判定链，四段固定顺序：

两个细节值得抄走。

证据分两种：声明和记录。 执行者的汇报是「声明」，工具真实跑出来的结果是「记录」。评审只信记录，声明只是关于记录的说法。工作区的快照对比也是如此：你说你改了，diff 说没变，那就是没变。

评审是干净房间。 只读权限，不能写文件、不能碰项目环境，防止评审自己被项目带偏，也防止它顺手把活干了。

Advisor 管过程，Delivery 管结果，两个合起来，任务才能真正自己跑完。

五合起来看：一条生产级的交付链路

三个模式各管一段，拼起来是一条完整的链路：

原型阶段，vibe coding 照旧，快就完了。从开发开始，规矩接管：新仓库先装基座——地图文档、统一命令、门禁三件套，一键就绪。

开发不再是一句句对话，而是先出执行计划。计划是一等产物，每份计划必须产出一个能当场演示的行为，不是「改到符合定义」就算完。计划把执行者当新手写：假设它对这个仓库一无所知。

测试和部署靠的是同一条判定链：声明不算数，记录才算数。门禁全过、工作区真有变化，Delivery 才放行「完成」这个裁决。

贯穿全程的原则只有一条：别信汇报，去验证。 这句话适用于每个环节。

六效果：变便宜的只有算力，注意力没有

用了这套工作流之后，几个变化很实在。

长任务敢放手了。 以前一个任务超过半小时就得盯着，现在几小时的任务可以放心去干别的，回来先看裁决和证据，再看产出。

全绿变得可信了。 每一道门禁都亲手用违规代码测过，绿灯亮了就是真的亮了。心里那块「这绿是不是假的」的石头，被机制搬走了。

质量从靠手感变成靠机制。 踩过的坑变成棘轮，人的品味写进仓库，技术债小笔持续还，不攒巨债。

交付是生产级的。 从原型到线上，一条命令的链路，中间每一环都有独立的把关。上线的东西不再需要「第二天人工复查一遍」。

工作流自己会涨。 外环跑起来之后，prompt、技能文件、harness 都在被数据推着改进，保留还是回滚有账可查。我不再是靠感觉调工作流，而是靠门和对照组。

但有两件事要说清楚。

第一，人没有变闲，是换了位置。 以前逐行读代码，现在审的是这套装置本身：这套检查够得着这个改动吗？哪些检查从来没红过（要么没用，要么坏了）？绿灯到底证明了什么，没证明什么？哪些判断必须留给人？

第二，机器只能保证「做对了」，保证不了「做的是对的」。 所有门禁全绿、比对一字不差，然后交付了一个用户根本不需要的东西——壳对这种事一个字都说不出来。设计合不合理、需求成不成立、这个方向值不值得做，永远是你的活。AI 时代这更危险了：错东西造得更快更多，而且每一件都全绿。

写在最后

如果只记住四句话：

Vibe Coding 的下半场，拼的不是谁的模型新，是谁的环境硬。

术语对照

来源