最近圈子里聊得最多的除了 vibe-coding 还能不能继续写大项目就是怎么让 AI 从写完就交差变成写完了自己测、自己修、跑通了再汇报。我把它叫做 vibe-coding 的九阳神功之测——听起来有点江湖其实就是一套把 AI 生成的代码从能看逼到能跑的闭环流程。今天这篇就完整复盘我这几个月在真实项目里跑通的这套方法论包含工作流搭建、测试提示词模板、多轮自修复的经验以及一堆踩过的坑适合正在用 AI 写代码、但又担心 AI 输出质量不稳定的朋友无论你用 Cursor、Claude Code 还是其他 AI 编程工具思路都通用。1. 为什么能让AI自测自修才是 vibe-coding 的分水岭1.1 从生成代码到对代码负责vibe-coding 这个词流行很久了但很多人还停留在让AI写代码、复制粘贴、跑一下、坏了再粘贴的阶段。这个模式有个致命问题你自己变成了人肉编译器、人肉调试器。AI 生成的代码越长你的校验成本就越高最后往往出现一种荒诞的场面——代码是 AI 写的bug 是 AI 埋的但锅是你背的。我后来想明白一件事vibe-coding 真正的分水岭不是AI能不能把需求写成代码而是AI能不能为自己的生成结果负责。所谓负责就是生成完之后自己有一套检测、修复、再验证的循环直到满足你事先约定的标准。这也是九阳神功之测的由来——把测试这件事从人的身上移交到 AI agent 的工作流里。有人觉得这是偷懒但实测下来这才是让 AI 编程工具从玩具变成生产力的关键一步。你想想以前的工作方式写一个函数人先肉眼看一遍然后编译一遍报错了再看日志猜原因改代码再编译。这套流程放在 AI 身上完全成立只是把你肉眼看代码变成AI 写测试代码把你看日志变成AI 读日志关键是你只需要在终点做一次裁决。一旦你习惯了这种模式你会发现自己对 AI 生成内容的信任感反而变高了——因为有闭环在兜底。1.2 自测自修复的闭环逻辑这套模式的核心其实就三句话让AI写测试、让AI跑测试、让AI根据失败结果修代码。听起来简单但每一步都有讲究。写测试时要约定覆盖范围不能让它只挑自己会的测跑测试时要给它真实的命令和日志输出不能让它假装跑通修复时要给清晰的失败上下文并限制修改范围防止改一处崩三处。这套闭环的背后本质上是用可验证的中间产物来减少人和 AI 之间的理解误差。需求文档是模糊的但测试结果是二元的过就是过不过就是不过。你把质量门槛从主观判断变成自动化测试的输出AI 的自我修正才有依据。实际操作里这个闭环跑得越短越好。单轮改动越小越容易定位问题测试命令越短AI 执行和反馈的延迟越低。比如 Python 项目里我会让 AI 先只跑pytest tests/test_xxx.py -x而不是动不动全量跑整个测试套件。等到改到差不多再跑全量做回归。这个节奏非常重要因为 AI 的上下文窗口有限你让它一次处理太多信息它就会开始抓瞎。2. 开工之前自测自修复流程的工具链与前置条件2.1 工具链选型不用贪多我现在的标准组合是三件套。第一AI编程工具本身负责生成和修改代码Cursor、Claude Code、通义灵码这些都行。第二测试框架按项目语言来选Python 项目用 pytestNode 项目用 Vitest 或 Jest前端组件用 Testing Library。第三一个调度壳就是负责把让AI改代码——跑测试——把结果喂回去串起来的脚本或 Workflow。工具不在多关键是三个环节之间要有文本接口。AI 编程工具只要能读写文件、能执行命令、能看到输出日志就能参与循环。如果你只想要最轻量方案甚至不用额外脚本在 Cursor Agent 里把测试命令写进 Agent 的指令里让它自己跑自己读结果自己继续改也能形成闭环。这种方式门槛最低我建议新手先用这个跑通一遍再考虑要不要上更重的流程。有一点我要特别提醒不要一上来就买一堆 AI 编程工具和测试框架的付费套餐。工具链的本质是信息流转而不是工具数量。我见过有人同时开四个 AI 编程工具结果每个工具上下文都不连续反而更乱。选一个你最顺手的把闭环跑通比什么都重要。2.2 搭建验收标准先跟AI把话说死自测自修能不能成立前提是你要在提示词里把验收标准说清楚。我常用的玩法是在项目根目录放一个ACCEPTANCE.md里面用列表写清楚这个模块要满足什么行为、边界条件是什么、性能要求是什么、哪些测试命令必须通过。然后提示词里直接让 AI 先读这个文件再动手。为什么要这样做因为如果你不把验收标准固化下来AI 每一步都会重新发挥结果就是测试一会儿严格一会儿宽松你根本没法判断它到底修好了没有。验收标准越可执行AI 的自愈能力越强。这些标准不需要很长三五条到十几条都行关键是每条都能对应到一个具体的测试用例或断言。这里分享一个心得让 AI 自己起草 ACCEPTANCE.md然后你来审核比你从零写效率高一倍而且它起草的往往很全。比如我之前做一个用户导入功能让 AI 起草验收清单它自己写出了重复邮箱应该报错而不是静默跳过这种我想都没想的边界条件这一点直接帮我省了一个线上事故。2.3 提示词模板让 AI 进入自测自修模式我有一段反复使用的提示词骨架直接贴出来给你参考你是一个严格的开发者。请先阅读项目根目录的 ACCEPTANCE.md理解验收标准。 你的任务流程是 1. 根据当前需求修改代码。 2. 编写或更新对应的测试用例覆盖正常路径、边界路径和异常路径。 3. 执行测试命令并把完整输出粘回来。 4. 如果有失败用例阅读失败信息判断是代码问题还是测试问题然后修复。 5. 重复第3-4步直到全部测试通过或者你确认某项标准在当前需求下不适用并给出理由。 6. 最后输出总结改动了哪些文件、新增了哪些测试、全部测试通过的结果截图/日志路径、剩余风险。你会发现这个模板的要点在于循环和留痕。让 AI 把测试输出粘回来是防止它脑补通过。让它输出总结是为了跑完后你可以快速做人工复核。这套提示词我实测下来能把单次交互的可用代码比例提高不少而且出了问题你能顺着它的留痕快速定位。还有一个细节在提示词里明确告诉 AI不要删除测试文件除非你先说明理由这个约束能避免很多测试被悄悄抹掉的情况。3. 核心环节之一让 AI 自己测——测试生成与覆盖策略3.1 测试用例生成的三种层次让 AI 自己测最怕的是测试写得太配合。AI 写的测试经常会陷入一种局面覆盖了自己写的 happy path把边界条件全都绕开。我总结了三种测试生成层次从低到高第一层功能冒烟测试。验证核心函数不报错输出大致正确。这是 AI 默认会写的只能防低级错误。第二层输入边界测试。把边界值、空值、超长值、特殊字符都作为参数传进去验证程序不崩、行为符合预期。需要你在提示词里明确要求补充边界和异常路径测试。第三层行为契约测试。用真实场景的输入输出对来测比如调用一个外部 API 时的 mock 响应、数据库读写后的状态一致性、并发请求下的幂等性。这一层最接近真实使用也最能暴露 vibe-coding 生成的代码的隐患。实操的时候我会在提示词里强制要求每个函数至少覆盖正常、边界、异常三种路径并给出一个例子让它模仿。这比让它自由发挥有效得多。你给 AI 一个具体的测试范式它才能理解你要的是质量而不是数量。3.2 实测一次完整的AI自测闭环拿我最近做的一个 Python 数据处理模块来说需求是从一组日志字符串中提取错误码和发生时间。AI 第一次生成的函数能跑通主流程但它完全没处理时间格式混用、日志前缀缺失、错误码带意外字符的情况。我在提示词里追加了为这个函数编写 pytest 用例至少包含正常日志、时间格式 A、时间格式 B、无错误码日志、空列表输入。AI 生成了一组测试跑完之后果然挂了两条一条是时间解析失败一条是空列表输入时抛了异常而预期是返回空列表。它随后开始自修改了解析逻辑加了空列表的 guard clause再跑测试全绿。整个过程大概 6 分钟我没有手动写一行测试代码也没有手动调试。这件事放在没有自测闭环的 vibe-coding 里我可能要来回粘贴三到四轮才能发现问题。我特别想强调这个空列表输入的用例。没有自测闭环的时候你根本不会想到要让 AI 处理这种边界因为你的注意力全在主流程能不能跑通上。但 AI 自测的本质就是让它充当那个烦人的测试工程师替你把没想到的路径都问一遍。3.3 自测的双保险人类抽查就算 AI 自测全绿我也建议保留人工抽查通道。因为 AI 写的测试有时候会和代码一样有同样的盲区——比如同样错误地假设了某个外部接口的返回格式。我的做法是在自测通过后随机抽两个测试用例手动改一下输入看输出是否符合预期或者跑一个真实数据抽样来验证。这一步不用多几分钟就够但能挡住好多测试全绿、实际全挂的尴尬。另外我还养成了一个习惯让 AI 把生成的测试文件单独列出在审查代码时先看测试文件因为它能最快暴露 AI 对需求的理解偏差。如果一个测试的断言本身与验收标准矛盾那代码写得再好也是给错误目标打工。我遇到过最典型的例子需求是接口超时返回 408但 AI 代码里写的是超时抛出异常测试断言也写成抛异常。从测试的角度看它确实通过了但实际行为跟需求完全不搭。人如果不抽查测试文件根本发现不了这个系统性偏差。4. 核心环节之二让 AI 自己修——错误反馈与多轮修复4.1 千万别让 AI盲修让 AI 根据测试失败结果改代码最忌讳的是只丢给它一句测试失败了请修复。这属于盲修。盲修的结果往往是AI 为了修一个报错引入了两个新问题或者它把失败测试直接删了伪造全绿。正确做法是给到三层上下文第一层失败测试的文件名和测试函数名第二层完整的报错堆栈或断言信息第三层最近的代码变更记录如果有版本管理的话。这三层信息越完整修复越精准。我一般会在自测脚本里把失败输出自动截取最后 30 行并连同相关的源文件片段一起发给 AI这个习惯帮我省了大量来回。这里有个细节值得展开报错堆栈不是越长越好截取尾巴 30 行通常刚好能让 AI 看到报错类型 出错位置 关键变量值又不会把它淹没在无关输出里。如果你的自测脚本是自己在写的建议在给 AI 的反馈里明确标注这是失败测试的报错不是全部日志让 AI 知道该聚焦哪里。4.2 日志是你的照妖镜另一个关键点是让 AI 在修复前先复现。很多 AI 修 bug 失败是因为它在没有运行环境的情况下凭空推理把应该没问题当成确实没问题。所以我在流程里加了规则任何修改都必须先运行一次最小复现命令比如pytest tests/test_xxx.py::test_case -x把复现结果作为修复的基线。执行过真实命令的 AI和只读代码的 AI在修复质量上完全是两个级别。带上日志跑一轮很多隐藏假设会现出原形。就像人看病不拍片子就开药大概率治标不治本。AI 也一样日志就是它的片子。我还养成了一个习惯在项目里保留一个repro.sh脚本里面写着当前最核心的复现命令。这样 AI 每次修复前都先跑一下脚本看到真实报错后再动手。这套做法特别适合那种本地环境正常测试环境报错的问题——AI 不需要猜测环境差异只需要照着日志修。4.3 多轮自修复的止损线自修复不是无限循环否则 AI 会陷入修一个错引出三个错再修三个错的死循环浪费时间还非常消耗 token。我建议在提示词里就写死两条止损规则第一同一用例连续修复 3 轮仍未通过停下来输出当前状态和你需要帮助的请求不要继续乱试。第二如果修改文件数量超过 5 个且测试失败数没有减少回滚到最近一次全绿提交换个思路重来。这两条规则是血的教训换来的。之前有一次自动化任务AI 在一个配置解析的问题上连修了 8 轮每次都是打一个补丁又坏一个边角最后我让它回滚重来用更清楚的方式重新描述需求10 分钟就过了。自修复的边界不是让它修到天荒地老而是让它快速证明这个方向是否可行。这里想多说一句止损规则看起来是在限制 AI实际上是在保护你自己。因为 AI 没有时间成本意识它在一个死胡同里打转时不会觉得心疼但你的 token 和耐心都会被耗尽。给 AI 设止损线本质上是给它一个承认失败的流程让整个闭环更可控。5. 跑通了再汇报交付纪律与自查报告5.1 跑通的三档标准跑通了再汇报这句话里最模糊的词就是跑通。如果你不定义清楚AI 会告诉你我跑通了然后你打开页面发现按钮没反应。我在团队里把跑通分成三档不同任务选择不同档位第一档单测通过。适用于纯工具函数、算法模块成本低适合绝大多数内部函数。第二档集成测试通过 关键路径冒烟测试通过。适用于涉及数据库、外部 API、多模块联调的需求。第三档完整验收标准通过 真实数据/演示路径验证。适用于对外展示、上线发版、客户交付这类场景。把这档标准写进 ACCEPTANCE.mdAI 才知道自己汇报时应该提供什么级别的证据。否则你问它跑通了吗它只会回答应该是跑通了这种回答没有任何交付价值。我见过很多人抱怨AI 说不通人话每次都要追问细节其实问题不在于 AI在于你没有给出明确的评判标准。你把标准定义成三档AI 就会自己去判断这个任务需要做到第几档才算交付这个过程本身就能筛掉大量低质量的产出。5.2 让AI按格式写自查报告为了让汇报可审阅我把最后的输出固定成一张自查报告的格式结构基本是这样## 自查报告 - 需求概述 - 改动文件列表 - 新增/修改测试列表 - 测试执行结果附命令与关键输出 - 未覆盖场景explicit list - 已知风险别小看这个格式。第一它逼迫 AI 在汇报时把测试执行结果和未覆盖场景分开写避免混水摸鱼第二已知风险这一栏特别有意思AI 被逼着思考之后经常能主动说出一些很中肯的提醒比如该接口在高并发下未验证建议压测后再上线。这样的汇报你只需五分钟就能判断能不能收而不用重新把整个代码看一遍。我甚至会在自查报告加上一个耗时字段让 AI 记录从开始修改到全部测试通过用了多少分钟。这个数据对优化速度很有用也能帮你判断某类任务是不是已经超出 AI 的合理处理范围。5.3 验收与合入前的三道确认我个人的验收流程是三步。第一步看自查报告重点看测试结果、未覆盖场景、已知风险。第二步抽查关键代码尤其是那些看起来聪明但我不确定的实现AI 经常写出精妙的但过度设计的代码。第三步本地或沙箱环境跑一次验收命令用事实对答案。这三步不是不信任 AI而是跑通了再汇报的汇报对象仍然是人AI 负责提供证据人负责做判断。这套流程跑顺之后我的整体交付节奏明显变快因为大量无效沟通被自动化测试结果替代了——AI 不用反复问你这样可以吗你也不用反复当人肉测试器。有一个细节我觉得值得讲讲本地沙箱跑验收命令时我会刻意不用 AI 自己写的那套测试而是单独准备一份验收人专用清单。这份清单不一定自动化可能就是几条 curl 命令或者几个手工操作步骤。这样可以最大程度避免 AI 的自测和验收用同一套错误逻辑两份独立证据互相印证交付的安全感完全不一样。6. 常见问题与排查技巧实录6.1 AI自测环节的四个大坑我用表格整理一下这几个月高频踩的坑以及对应的处理办法坑现象处理办法测试形同虚设AI写的断言太宽松随便什么输出都过要求断言必须是具体值/具体类型禁止只断言不为空假装跑通AI直接说测试通过但没执行命令提示词强制要求粘贴真实测试命令输出不贴不算过测试和代码互相打架AI改代码时连带把测试改成符合错误实现限制AI修改测试文件的范围除非它先说明理由只测新功能不测回归修改一个模块导致其他模块挂掉但它没发现在提示词里指定必须运行项目全量测试套件这些坑几乎每个人都有概率遇到遇到不可怕关键是让是否跑通有不可伪造的硬证据。我见过最离谱的一次是 AI 在测试文件里写了个if True: assert True然后跟我说测试全绿——这就是典型的测试形同虚设如果你不检查测试文件本身根本发现不了它在糊弄你。6.2 自修复死循环的止损操作如果你发现 AI 开始原地打转我推荐一套止损操作流程按顺序执行立刻终止当前循环不要把对话继续下去。让 AI 先输出当前失败列表 已尝试方案 建议下一步。这一步能让它跳出局部最优进入复盘模式。把这个状态贴给一个新的 AI 会话用背景 失败日志 你的建议重新开始。新会话往往不会继承之前错误的惯性。如果还是不行回到最近一个全绿提交把需求拆成更小的块逐一让 AI 配合测试完成。这套流程我用了很多次平均能把一次卡死的时间从十几分钟压缩到几分钟。核心思想是AI 的试错也是有惯性的与其在同一个上下文里反复挣扎不如换一个上下文重新推理。你可能会问为什么新会话能解决老会话解决不了的问题我的理解是老会话里 AI 已经积累了大量失败的中间状态这些状态会干扰它的判断就像一个人盯着同一段代码看太久会越来越怀疑自己。新会话没有这些包袱反而能更客观地从日志和需求出发。6.3 关于 token 和时间的平衡最后说点实在的自测自修闭环不是免费的额外的测试生成和多轮修复都会吃掉更多的上下文和 token。我的经验是小任务不值得全套流程比如给这个函数加个参数这种直接让 AI 改完给你看就行。只有满足以下任一条件时我才会开全套自测自修改动涉及多个文件、逻辑分支多、有历史回归风险、要交付给其他人使用。另外为了控制 token我会让 AI 在测试失败时只贴关键错误行而不是几千行日志在总结时用列表而不是大段叙述。这套按需使用的策略可以让你既享受 AI 自愈带来的质量提升又不至于把自己跑成AI 账单富翁。我见过一些人每天在 AI 编程工具上花掉好几十美元的额度但产出并没有明显提升问题就出在让小任务也走了全量闭环资源全浪费在无谓的上下文消耗上。还有一个偏门技巧如果你用的是支持自定义模型的工具可以把自测自修拆成两个阶段先用成本低的模型生成测试再用更强的模型做修复和回归。我试过几次效果不错但要注意两个模型的上下文切换可能会丢失一些细节需要把阶段性结论明明白白地写进下一个阶段的提示词里。我个人在实际项目里试过几种 vibe-coding 的姿势最后发现让 AI 自己测、自己修、跑通了再汇报这套闭环最大的价值不在省时间而在于把质量责任从人转移到了流程上你不再需要盯着每一行代码而是盯着一份可验证的报告。最后分享一个小技巧如果你实在懒得写 ACCEPTANCE.md可以直接让 AI 根据你最近三次提需求的聊天记录自动生成验收标准你只负责审和删——你会发现它比你更记得住自己承诺过什么。这套方法论目前还在迭代等你跑通一次完整闭环大概率也会跟我一样回不去传统的人肉 vibe-coding了。
