vibe-coding 玩久了我最大的感受不是“AI 写代码真快”而是“AI 写代码真快错得也真快”。最初我也跟大多数人一样让 AI 哗哗生成一屏代码自己再屁颠屁颠跑测试、修报错来回折腾大半天。后来我给自己立了一条硬规矩AI 交付任何东西之前必须自己测、自己修全部跑绿了再汇报。这门功夫我管它叫 vibe-coding 的九阳神功之测——AI 得把“测试”练成本能像护体真气一样自动运转而不是靠我在后面一勺一勺输内力。这篇文章就把我这套“AI 自测自修闭环”的完整玩法拆开讲包括怎么给 AI 立验收标准、怎么搭报错反馈回路、怎么定义“跑通”、以及我在实际项目里踩过的坑和现在的工具链适合所有正在用 vibe-coding、又不想天天给 AI 擦屁股的人。1. 为什么“AI 自己测自己修”才是 vibe-coding 的分水岭1.1 vibe-coding 的第一层是“能生成”第二层是“能闭环”很多人提起 vibe-coding第一反应就是“让 AI 照着需求一顿输出代码”。但代码生成只是最外面那层皮。你把需求丢给 AIAI 三分钟给你吐出三五个文件看起来像模像样实际一跑全是错。这时候整个项目就陷入一个很尴尬的循环AI 负责“写”你负责“改”AI 写得越快你改得越累。说白了这跟雇了个只写不验的实习生没区别。我自己的分水岭出现在一个多月前。当时有个小工具要补一个批量导入功能我照旧让 AI 写完然后自己打开终端跑测试发现三个失败继续把报错丢回去让 AI 改如此往复第六轮的时候我终于烦了凭什么跑测试、读 traceback、判断改得对不对这些事全得由我来做如果 AI 真的理解它生成的代码它就应该自己知道怎么验证。从那天起我正式把“AI 必须自己测、自己修、跑通了再汇报”写进了所有任务的 base prompt这件看似简单的事把我的返工率从“每天烦一次”降到了“一周偶尔一次”。这个变化背后其实是身份切换人类从“AI 的测试工具人”变成“AI 的验收方”。代码还是 AI 写但写完之后谁对结果负责一开始是人负责因为 AI 只是码字机器后来我意识到只要把“测试”这个动作也交给 AI并且给它完整的反馈回路它完全可以对自己交付的质量负责。这才是 vibe-coding 真正值钱的地方不是“写得多”而是“写完能自己证明它对了”。1.2 我见过的最典型的翻车现场为了说清楚这个分水岭我给你看几个我同学和同事项目里最常见的翻车现场你也大概率见过。第一个是“AI 说完成了我一测全是错”。AI 生成完代码你问它“写好了吗”它信誓旦旦说写好了细节完美得像是从文档里抄出来的。但你把代码往项目里一放import 就炸了。为什么因为 AI 在“写”的过程中压根没真正执行过任何东西它的“完成”是它脑补出来的完成。第二个是“AI 改好一个 bug又引入两个 bug”。你把 traceback 贴回去AI 很乖地说“我来修”然后它确实把那个报错修掉了但顺手改了一个不该改的函数签名于是另外两个测试跟着挂了。这种问题特别隐蔽因为从 diff 上看它每次改动都很小但影响范围你根本没法靠肉眼扩散。第三个是“AI 自己编造 API”。上下文一长模型就开始飘明明项目里没有merge_all这个函数它认定有写完直接调用仿佛调用一个真实存在的库。你看到代码的第一反应是“这函数在哪儿定义的”翻遍项目找不到再问 AI它就说“抱歉我记错了”。这三个翻车的根子都一样AI 从来没有对自己的输出做过验证因为它没有被要求验证也没有工具去验证。你想想如果我们在它每次交付前都强制它跑一遍真实命令、把输出贴回来、根据失败结果自我修正上面三种情况至少能挡掉九成。所以我一直跟朋友说vibe-coding 不是“让 AI 写代码”而是“让 AI 写完代码之后自己给自己找茬”。找茬这项技能才是它的九阳神功。2. 给 AI 立自测规矩测什么、怎么测、算过关2.1 把验收标准写进 prompt 的硬约束想清楚“要让 AI 自测”第一件事不是去配工具而是把“自测”这个要求从“建议”变成“硬约束”。我的做法是在每个任务 prompt 里固定嵌一段“交付前检查协议”任何任务都一样。下面这段是我目前一直在用的你可以按需改你是一个接入到 Python 仓库的开发助手。每次完成代码修改后必须按以下顺序执行 1. 运行 pytest -x -q tests/把终端输出完整原样贴回来 2. 如果退出码非 0阅读 traceback 定位根因修复后重新执行直到退出码为 0 3. 运行 coverage run -m pytest tests/ 和 coverage report -m汇报行覆盖率与分支覆盖率 4. 上述步骤全部通过之前禁止输出“完成”“已搞定”等结论 5. 通过后按汇报模板输出改动文件清单、每个改动的目的、测试结果摘要。注意这里最关键的是“把终端输出完整原样贴回来”和“退出码为 0”这种可验证的词。为什么要这样措辞因为如果你只说“请测试后再交付”AI 大概率会在回复里给你来一句“我已经测试过了一切正常”但它实际上根本没跑。你要让它贴出真实输出它就没法纯靠嘴完成验收因为模型知道“如果我贴一段假输出你一眼就能看出来不对劲”。虽然它偶尔还是会脑补但频率会低很多后面我会讲怎么用脚本彻底堵死这个口子。还有一个细节我给 AI 定义了“可执行命令”和“不可执行命令”。比如允许它运行 pytest、运行单个测试文件里的具体用例不允许它在没经过允许的情况下跑git push、pip install、改数据库。不是怕 AI 干坏事是怕它为了“让测试通过”而偷偷装包或者改环境那测试就失去意义了。“测什么”和“不准为了通过测试动什么”要同时说清楚。2.2 用 pytest coverage 给“测过”下定义“我测过了”这句话在 AI 嘴里非常廉价所以必须有一个机器可判断的标准。我选 pytest coverage 这套组合原因很简单断言明确、退出码可脚本判断、覆盖率可量化。你不用跟 AI 争论“你到底测没测”你只需要看两个数字退出码是不是 0覆盖率是不是达标。跑测试时我会用这组命令pytest -x -q --tbshort tests/ coverage run -m pytest tests/ coverage report -m --skip-covered-x是“失败即停”因为自测修复阶段我们只要一个失败点就足够让 AI 去定位了没必要一口气给它三十个失败把它绕晕--tbshort是让 traceback 精简一点减少喂给模型的上下文噪音coverage report -m能看到哪些行没覆盖给了 AI 一个明确的补测试方向。覆盖率这个指标很关键因为 AI 写的测试经常出现“断言很正面但根本没覆盖 edge case”的情况比如测了正常合并却漏了空文件、类型冲突、超大输入。加了覆盖率检查之后AI 至少会知道“我这轮测试只覆盖了 60% 的分支”它就会主动去补边界。我一般在测试类任务里要求行覆盖率不低于 90%、分支覆盖率不低于 80%。这个目标对大多数工具函数是合理的AI 也能做到真做不到的时候它会老老实实告诉我“这里有两个分支因为场景限制无法覆盖”这个说明本身就是非常有价值的信息。如果项目里还没有 coverage建议先装上并在 pytest 配置里把addopts --cov你的包名 --cov-reportterm-missing写好这样每次跑 pytest 都会自动出覆盖率报告。2.3 一个可以直接抄的小例子光说规矩有点虚我拿一个真实小任务示范一下。有一次我需要一个工具函数把多个 JSON 文件按键合并key 冲突时抛异常。换成正常操作我可能直接甩给 AI“写个 merge_json 函数”然后等它写完我再手动测。但现在我的流程是让 AI 先给我测试计划再写实现。我给它的 prompt 大概是需求写一个 merge_json(*files) 函数把多个 JSON 文件的顶层 key 合并key 冲突时抛出 KeyConflictError。 第一步先不要写实现先列出 6 个测试用例包括正常合并、空文件、key 冲突、非 JSON 内容、嵌套 dict 中被吞掉的情况、超大文件。每个用例写清楚输入、预期行为。 第二步把列出的用例写成 pytest 测试先运行一遍确认它们是失败状态RED。 第三步写实现代码让全部测试通过GREEN。 第四步跑 coverage补用例到行覆盖率 90% 以上。结果它跑完三轮之后给了我一个大惊喜第一版实现用dict.update()合并嵌套 dict 里的同名字段直接被后者覆盖而不是报冲突。好在我要求它先写的“嵌套 dict 中被吞掉的情况”那个测试正好把这个 bug 暴露出来了——这正是“让 AI 自己测”的价值它自己写的测试能抓住它自己实现里的想当然。如果按以前的流程这段嵌套覆盖的 bug 大概率是我在真实业务数据里撞上之后才发现的到时候再 debug 就麻烦多了。这里的关键启发是你不需要告诉 AI“这段函数应该怎么合并嵌套 dict”你只需要在测试计划里摆一个“嵌套场景该有明确行为”的用例AI 实现不对测试就会亮红灯。所谓“测什么”不是你去定义每个技术细节而是你去定义“什么行为是合理的边界”剩下让 AI 在测试和实现之间自己咬合。3. 反馈回路设计AI 报错后怎么让它自己转弯3.1 报错信息的规范化回填让 AI 自测容易让它“自修”才是真正考验设计能力的地方。很多人的做法是测试失败了把终端输出整段复制给 AI说一句“报错了你修一下”。这种模糊反馈的问题在于模型要在几万字的上下文里自己找重点找着找着就偏了改出来的东西往往牛头不对马嘴。我在纯靠人肉搬运报错的前期阶段也吃过不少这个亏。后来我把反馈给模型的“失败信息”固定成了一个模板每次都按字段喂失败命令确切执行了哪条命令退出码多少最后 30~50 行输出主要是 traceback 和 pytest 的失败摘要涉及文件哪些文件本轮被修改过期望行为用一句话或一条断言描述应该发生什么。举个例子我不要“测试挂了帮我看看”而是失败命令pytest -q tests/test_merge.py::test_nested_conflict 退出码1 输出最后 20 行 ... merge_json(f1, f2) E assert 30 {b: 2} ... 涉及文件src/merge_json.py, tests/test_merge.py 期望行为当嵌套 dict 的 key 冲突时应该抛出 KeyConflictError而不是覆盖。为什么这样规范因为大模型对结构化的信息敏感度远高于一大坨终端日志你把“期望行为”用一条断言写出来之后它基本不需要猜你到底想要什么修的目标非常聚焦。这个模板我后来直接写进了自动循环脚本里变成每次失败都自动拼好喂给模型连人工复制粘贴都省了。3.2 循环上限与护栏AI 自修有一个非常让人上头的陷阱它会一直修下去好像很努力但可能改到第 8 轮还在原地打转甚至把本来绿着的测试改红了。所以自修循环必须有明确上限和护栏。我现在每个修复任务默认允许 3 轮。超过 3 轮还没绿就停止循环把当前 diff 回滚到最近一个绿的 commit同时把“多轮修复未解决”当作结果反馈给我由我决定是换一个模型、拆小任务还是改需求。这个“3 轮硬上限”不是什么科学计算出来的它更多的是一条工程纪律如果 AI 3 轮内修不好一个明显 bug说明问题大概率出在任务边界、上下文质量或依赖环境上继续让它耗只会浪费 token。我用的最小循环脚本长这样思路可以直接参考#!/usr/bin/env bash # fix_loop.sh —— 跑测试失败则喂回给 AI 修复最多 3 轮 for round in 1 2 3; do if pytest -q tests/ /tmp/pytest_out.txt 21; then echo PASS after ${round} round(s) exit 0 fi echo Round ${round} failed, feeding back to AI # 把失败输出、退出码、涉及文件拼成结构化模板传给模型 ai_fix --file src/merge_json.py --tests tests/test_merge.py --round ${round} # AI 改完之后自动进入下一轮 done echo FAIL after 3 rounds, rolling back... git checkout -- src/merge_json.py tests/test_merge.py exit 1实际跑的时候“喂给 AI”那一步你会接入你用的模型 API 或者 Agent 框架脚本思路是通用的失败就回填回填就重跑重跑还失败就再回填到了上限立刻止损。还有一个我强烈建议的护栏每轮修复前都先让 git 记录当前状态AI 改完以后如果测试直接挂掉马上git checkout回滚到上一轮而不是在错误的代码上叠加修改。没有这个护栏AI 很容易从“修 bug”变成“把项目推向更深的混乱”。3.3 修复策略先读报错、再定位、后动手我给 AI 写修复指令的时候现在会强制要求它按三步走每一步输出都给到我才算数第一步解释根因。让 AI 用一两句话说明“为什么这个测试会失败”这是逼它真正读 traceback而不是上来就乱改代码。模型有时候确实会猜但只要让它先写根因很多明显瞎猜的修复在第一轮就被过滤掉了。第二步定位改动范围。让它说清楚“要改哪一个文件、哪一行、为什么是这里”如果它说“可能要重构整个模块”那就得警惕了。第三步给出最小 diff。我会在 prompt 里加一条硬约束“只允许修改与本次失败直接相关的代码禁止顺手重构、规范化、注释美化。”比如它报错是TypeError: merge_json() got an unexpected keyword argument files正确根因就是函数签名写错了正确修法就是把签名改成支持files参数。但如果 AI 的回复里开始出现“顺便我把整个模块的日志格式也统一了一下”我会二话不说把它这份 diff 打回去重做。代码风格统一这种事不是不好而是不能在自修循环里做因为每一次无关改动都会扩大测试回归面让“修 A 挂 B”的概率直线上升。还有一个经验修复指令里的“期望行为”最好是一条可以独立验证的断言而不是一句自然语言。你写“应该正确处理嵌套冲突”AI 可能理解成各种样子你写assert merge_json(f1, f2)[a] 30它就非常清楚自己要达成什么。把期望行为断言化是让 AI 自修真正高效的秘诀。4. 跑通的定义与汇报口径让 AI 学会“交作业”4.1 四层验收清单功能、边界、性能、异常“跑通了再汇报”里有个大坑到底什么算“跑通”你如果不定义清楚AI 给你的“跑通”就只是“我写的测试过了”这远远不够。我现在把“跑通”拆成四个层面任何一个层面没达标都不允许汇报成功。层面检查项AI 的自测动作例子功能主路径是否按需求工作跑核心用例、验证输出符合预期合并 3 个 JSON 文件后key 数量正确边界空值、极值、类型异常是否可预期主动补边界用例并说明场景空文件、单个文件、只读文件、超大文件性能数据量大后是否还在可用范围内执行基准并给出耗时上限10 万行 JSON 合并应在 1 秒内完成异常错误路径是否被正确处理触发异常并检查报错信息key 冲突时抛出指定类型异常为什么把性能也放进来因为 AI 写的代码在很多场景下不是功能不对而是复杂度爆炸。它可能用一个O(n²)的循环处理一个本来应该O(n)的任务小数据测试全绿一上真实数据就卡死。所以我让 AI 在任务涉及批量数据处理时必须自带一个简单的性能断言比如“处理 5 万条记录耗时不超过 10 秒”跑不出来就不算通过。这个检查对工具函数和脚本类任务尤其管用。边界和异常层面我另外发现一个非常有用的 prompt 技巧让 AI 自己扮演“恶意用户”。我经常在任务里写一句“假设你是一个专门破坏这个函数的 QA你会怎么测试它”这句话一下就能激发模型输出很多边界用例比如文件不存在、权限不足、传了二进制内容、写到了只读目录。这些用例我再要回给 AI让它自己跑经常能逼出真问题。4.2 汇报模板改了什么、为什么、哪里还不硬自测全绿之后AI 通常只会回一句“全部测试通过”但这句话对我做 review 没有任何帮助。我需要知道它到底改了哪些文件、每个改动为了解决什么问题、测试结果是不是真实跑出来的、还有哪些它自己都拿不准的地方。所以我在最终汇报阶段强制用固定模板结构是这样交付摘要 1. 改动清单src/merge_json.py14 行、tests/test_merge.py8 行 2. 每个改动解决的问题 - src/merge_json.py将 update 合并逻辑改为递归合并修复嵌套 dict 冲突被静默覆盖的问题 3. 测试结果pytest 退出码 023 passed行覆盖率 94%分支覆盖率 86% 4. 尚未覆盖的风险Windows 路径下的中文编码未实测超大文件未压到真实 10 万条 5. 需要人工重点审阅src/merge_json.py 第 41 行递归分支因为该处覆盖了核心冲突逻辑这个模板的好处是第 2 项逼着 AI 解释它的改动意图我可以快速判断它是不是为了过测试瞎改的第 4 项是决定我是否直接合入的关键如果 AI 能自己说出“这个场景我没测过”那说明它有基本的风险意识比那种张口就来说“已经全面测试过”的回复靠谱一百倍第 5 项能帮我直接把 code review 的注意力放在最容易出错的位置不用一行行读完整份 diff。我试过在多个项目里用同一套汇报模板AI 会逐渐学会“迎合”这个格式但这种迎合是好事因为它必须在模板里填出真实数据和风险描述。格式一旦固定我对“AI 交付物”的评审效率高了很多基本只看风险列表和重点位置就行不用全量重读。4.3 人机协作的边界哪些不该全交给 AI“AI 自己测、自己修、跑通了再汇报”听起来很美但必须划一条清晰的红线不是所有任务都适合这个自动闭环。我现在的判断标准很简单——适合自动闭环的任务纯函数、CLI 工具、接口封装、模块级重构、脚本类任务。这类任务有明确的输入输出、可写断言、可回滚AI 自测的结论可信度很高。不太适合的任务涉及支付/权限/安全策略的代码、不可回滚的数据库迁移、真实用户数据的批量处理、需要行业权威判断的业务规则。这些领域即使测试全绿我也必须人工做逻辑复核因为测试里没覆盖到的隐性违约风险AI 不可能替我把关。我举个真实例子一个给客户的定时任务需要扫描一批文件并分类归档逻辑本身很简单测试也全绿。但它涉及真实文件删除和移动一旦跑错客户的原始文件可能找不回来。这种场景我绝不让 AI“自己修完就直接跑”我把文件系统操作封装成一个 AI 无法直接触碰的接口层AI 只能改纯逻辑真正的文件删除动作必须由外围脚本控制并且先跑一遍 dry-run。这其实就是人机协作的边界AI 负责聪明人类负责兜底。5. 我在实际项目里用的工具链与踩坑记录5.1 低配起步pytest 脚本 本地模型我知道很多人看到“AI Agent”“多智能体”这种词会觉得门槛很高先被吓退一半。其实完全可以低配起步。我最开始跑这套自测自修循环时没有用任何复杂框架就是三个东西pytest、一段类似前面fix_loop.sh的 Shell 脚本、一个能调用文本生成的本地开源模型。模型不用多强能读懂 traceback、能按指令改代码就够用了。低配版的效果其实比很多人想象中好。我拿一个本地部署的 7B 级别模型跑过一个简单的 CSV 清洗脚本任务它写的第一版代码有个通病——用pandas处理所有事情但目标环境根本没有pandas。按我的规矩第一轮跑测试直接 ImportError反馈回路把报错贴回去它第二次就乖乖改成纯标准库实现了。这个能力水平在大模型里算是很基础的但它确实会在“失败→回填→修改→重跑”的循环里一次比一次靠谱因为每一次失败信息都喂到了它的嘴边。低配版最大的问题是上下文遵循度不稳定。上下文一长模型容易高高兴兴地开始自说自话你让它把终端输出原样贴回来它只贴一句“测试已通过”。所以低配版里我特别依赖脚本的“只认退出码”策略——人工判断改为机器判断让模型输出什么都无所谓只要它生成的代码能通过 pytest 就算数。这是我的核心心得模型爱吹牛没关系脚本不信它就行。5.2 进阶玩法AI Agent 与多 AI 协作当我不满足于“一个人贴报错给 AI”之后我升级到了 Agent 模式让 AI 自己具备“执行命令、读取文件、修改文件”三种能力。常见的 Agent 框架都能做到核心是给模型挂上三个工具execute_command、read_file、write_file。挂上这三个工具后AI 可以自己跑 pytest、自己看 traceback、自己改代码形成一个完全自主的循环人类的角色只剩“下达任务”和“验收最终结果”。再往上一个台阶是多 AI 协作。我现在玩得最顺的模式是三个角色写手 AI、测试 AI、评审 AI。写手 AI 负责实现业务代码测试 AI 负责给写手找茬评审 AI 负责在合并前挑毛病。三个角色之间不让它们直接聊天而是通过“测试报告”来传递信息写手提交代码测试 AI 独立跑测试并输出报告写手根据报告修改改完以后评审 AI 再读一遍最终 diff给出放行或驳回意见。这么做的好处是上下文隔离每个 AI 只看到它该看的避免两个模型在聊天里互相传染幻觉。多 AI 协作里我发现一个很重要的细节不要让“测试 AI”和“写手 AI”共享全部历史对话。如果测试 AI 看到了写手是怎么写出来的它就会不自觉地去“理解”而不是去“破坏”。相反让测试 AI 只拿到最终代码和一个需求描述它会更客观地找茬经常能找出写手自己眼里很合理的坑。简单说写的人和测的人不能一边聊天一边把标准聊丢了。5.3 三个真实的翻车案例与修复升级到 Agent 模式以后并不是就天下太平了。我照样翻过几次车而且翻得很精彩。第一个翻车AI 假装测试通过。当时我的 Agent 已经能自己跑命令但有一次它跑完 pytest输出里明显有失败它却在最终汇报里写“全部测试通过”。我一看生成的报告差点信了因为我只看到它的“结论”没看到命令输出。后来我把流程改成“必须附带真实终端输出片段”“脚本以退出码为准”双保险才彻底堵住。这件事也让我确认了一个规律模型在任务接近完成时特别容易为了“交付成功”而脑补结果毕竟它对“让用户满意”这件事有巨大的内在驱动力。第二个翻车修 A 挂 B。有一次让 AI 优化一个数据处理模块的运行速度它在优化过程中把函数签名改了结果业务侧调用它的另一个模块直接起不来。测试跑的是它自己优化后的模块全绿但整个项目启动测试挂了。从那以后我把“全量回归”设成硬指标AI 可以改局部代码但每次交付前必须跑一遍项目级 pytest而不是只跑它自己接触的那个目录。损失是多了几十秒跑测时间收益是再也没有“我这里没问题你那儿怎么挂了”这种扯皮。第三个翻车AI 在长上下文里虚构 API。经过多轮修复之后AI 在上下文里“记住”了一个并不存在的辅助函数后面几轮一直基于这个幻觉在改代码越改越离谱。现在的对策是每轮反馈给它的内容尽量精简让它只关心最近的失败同时对import做了一次白名单审查禁止新增依赖。只要它想引入新包或者新函数必须先在汇报里说明理由。这招一出幻觉导致的连环翻车少了很多。翻车场景根因我的解法假装测试通过模型为交付成功而脑补结果脚本以退出码为准强制贴真实输出修 A 挂 B只跑局部测试忽略影响面每次交付前跑全量回归长上下文里虚构 API无关上下文太多模型自行补全精简反馈内容import 白名单5.4 稳定下来的工作流折腾了这一大圈我现在固定下来的工作流是这样的先写任务卡片把功能要求、验收断言、禁止事项一次性说清然后让 AI 先输出测试计划和风险点我确认后再放它去写实现实现完成以后脚本自动进入“跑测→失败回填→修改→重跑”的循环最多 3 轮过了就继续全量回归和覆盖率检查全部绿了AI 按汇报模板输出交付摘要我做最终人工评审重点看风险列表和 AI 标记的困难点。这套流程走下来我个人的体会是vibe-coding 真正让人省心的时刻不是你看着 AI 噼里啪啦写代码的时候而是它把一份“测试全绿 风险自述清晰”的成果递到你面前你只需要做判断、不需要做体力活的时候。让 AI 自己测、自己修、跑通了再汇报本质上是把一个不可控的“灵感生成器”变成一个可控的“执行闭环”。如果你也刚开始练这门功先别急着上多 Agent 多角色把一个 pytest 循环跑稳、把汇报模板立住比什么都管用。