AI 写代码怎么自动验收？验证闭环方法

这期讲了什么

• 方法出处：Claude Code 团队 Delba de Oliveira 的官方文章，2026 年 7 月 22 日发布，讲怎么用 Skill 搭 verification loop（验证闭环）
• agentic coding 本来就是一个环：提需求、收上下文、动手改、验证、不够再回头补——真正缺的往往不是会写，是把「验证」这一步做实
• AI 已能接住确定性信号：类型检查、代码规范检查、测试、运行时报错它有机会自己看见自己修；落回你手上的是代码库推断不出来的事——主流程通不通、迁移会不会丢数据、日志有没有带请求编号、界面合不合自家规范
• 写成 Skill 的核心要求：检查是能判真假的门禁（如「删列却没回填的迁移直接拒绝」），不是「代码质量高一点」这种模糊评价；Skill 最小形态是头信息加检查步骤，最好既判也修，修的范围要写死
• 四种挂载位置：独立调用、嵌进生产流程、串联、每个 PR 强制过同一套门；起步用六步法，先抓一条最烦的重复检查做成门禁，跑通了再嵌、再串、再上 PR；这不是无人值守，是把注意力腾给只能人拍板的判断

文字稿

先补上 agentic coding 缺的验证

你有没有过这种瞬间：AI 说「改好了」，你一点运行，红的。然后再改，再红，再改。最后你发现，真正耗时间的不是它写代码，是你在旁边当质检员。

更烦的是，这些质检动作你明明上周做过、昨天做过，今天换个功能还得再做一遍。不是你懒，是标准还装在你脑子里，没装进系统。

做 Claude 的那家公司 Anthropic，2026 年 7 月 22 号发过一篇官方文，作者是 Claude Code 团队的 Delba de Oliveira，题目很直白：怎么在 Claude Code 里，用 Skill 搭 verification loop。今天这期，我就按这篇文章，把这套方法讲成人话。你不一定用 Claude Code，也能把这套思路挪到自己的 AI 编程流程里。

先说他们怎么看一次 AI 编程会话。大多数 agentic coding，其实就在转同一个环：你提需求，它收上下文，动手改，验证结果；不够，再回去补上下文。注意，环上本来就有「验证」这一步。很多人用 AI 写代码，真正缺的不是会写，是把验证这一步做实。Verification，说白了，就是 AI 把活交到你面前之前，先检查自己干得怎么样。

那它现在会不会验？会一部分。文里写得很清楚：类型检查、代码规范检查、测试、运行时报错，这些确定性信号，它已经能接住不少。你终端里飘红、测试挂了、类型对不上，它都有机会自己看见、自己回头修。

可问题在于，代码库推断不出来的那些事，还是落回你手上。比如这个按钮点下去主流程通不通；这张表迁移会不会把线上数据弄丢；这行错误日志有没有带上请求编号，又有没有把用户隐私打进去；界面是不是还符合你们自己的设计规范。通用工具看不见的，就变成你的手动检查。你每次亲手做的这些检查，就是 verification loop 的原材料。

我给你打个比方。AI 像后厨一个手很快的新厨。你点一份菜，他炒完就端上来，端上来前他自己不尝，尝的人是你。咸了淡了，你喊一声，他再回锅。忙的时候你就变成专职试菜员。Verification loop 要干的事，就是让新厨端菜前自己尝一口；不对就自己调，对了再上桌。你不是消失了，你是不用再对每一口盐都亲自负责。

所以记住这句：verification loop，不是又一个黑话，是一个重复闭环——AI 检查自己的活，跑测试、跑检查器、跑你定的自定义规则，挂了就修，过了才往下走。在 Claude Code 里，这套环还可以打成 Skill，让每次会话自动按同一套标准验，而不是靠你记不记得跑。

文里也列了他们已经有的一些验证路径：一个叫 verify 的 Skill，会去构建、运行、观察你的应用改动；把精确的构建和测试命令写进项目说明文件，别让模型自己猜该敲哪条命令；面向拉取请求的代码审查预览能力；用 GitHub Actions 在每次提交时跑同一套检查；对照仓库里的说明文档做规格校验；以及托管智能体里用评分表打分的试验能力。有的还标着预览或者测试阶段，你先当能力地图看，不必一次全上。

名字可以先混个脸熟，重点不是背菜单，是看懂一件事：验证这件事，正在从「人的记忆」变成「系统的默认动作」。

把反复做的手动检查写成 Skill

什么时候该自己写一条验证环？文里给的信号很实在：如果 AI 每做一个新功能，你都在做同一类小修正，那就该写了。你已经不是在「偶尔帮忙看看」，你是在当一条没有写进程序的流水线。新项目也一样——你得先用大白话写清，这个项目到底怎样才算表现正常，像交给新同事第一天的手册，而不是只在你脑子里。

写法不神秘。第一步，把你每次都在干的检查，一条条记下来。别一上来就写框架，先写人话。比如说：改完前端，我一定要开页面点一遍主流程；动到数据库迁移，我一定要看有没有把列直接删掉却不做数据回填；打错误日志时，我一定要看有没有请求编号，且绝不能把用户原文打进日志。你看，这些都不是「感觉代码优雅不优雅」，是能判真假的门禁。

文里有个特别好的提醒：检查不必是模糊的质量评价。它举了个例子——任何「删掉一列却没有回填步骤」的数据库迁移，直接拒绝。通用代码检查器未必抓得住这种项目规矩，但你的项目专属规则抓得住。凡是你反复用手强制执行的，都有资格收成 loop。换句话说，别只写「请保证代码质量高一点」；要写「什么情况算过，什么情况必须打回」。

说不清怎么验？可以先让 AI 按行业常见做法列一版，你再改。真正值钱的，往往不是教科书那几条，而是你跟通用最佳实践不一样的那几条差异：你们服务必须带请求编号、你们前端改完一定要过某条用户路径、你们迁移绝不许静默丢数据——这些差异，才是你团队的味道，也才是最该写进 Skill 的东西。

怎么做成 Skill？文里给了两条路。一条快：装他们的 skill-creator，让它采访你，比如你说「给我做一个从头到尾验收前端改动的 Skill，先问我工作流」。另一条稳：自己在项目的 skills 目录里丢一个 markdown 文件。最小形态就两块：头信息写名字、什么时候该用、允许动哪些工具；正文写清楚检查步骤、失败怎么报、怎么修。

官方文给了个日志卫生的小例子，我转成大白话。Skill 上场后，先读当前改动里的错误处理路径；每一处错误日志，确认带了请求编号，并且没有把请求体、请求头、用户塞进来的内容打进去；找到违规就报文件和行号，然后直接改：缺编号就补，多出来的敏感内容就剥掉。你看，它不是在「评价代码好不好看」，是在执行一条你本来每次都要吼的规矩。

这里有个很容易忽略的点：好的验证 Skill，最好既能判，也能修。只报「这里不对」还是半成品；报完接着改到过线，闭环才算关上。当然，修的范围你得写死，别让它借机重构半个仓库。

到这里，Skill 的本质也清楚了。它不是又一篇提示词范文，是把你的验收动作，冻成可重复执行的流程。写一次，后面每次会话都能套。你从「我得记得验」，变成「系统默认会验」。

检查挂在哪：独立、嵌进、串联还是 PR

光会写还不够，还得会挂。文里把验证检查的挂法，分成四档。挂错位置，要么太吵，要么形同虚设。我还用后厨比方讲。

第一档，独立调用。菜已经炒完了，你想起来再让人总检一次。适合那些不是每次都要做、但很多流程用得上的横切检查：提交前的安全扫描、提拉取请求前的无障碍检查、全仓库许可证头检查。好处是灵活，想用才用；坏处是，每次还得你记得喊一声。文里说得很准：如果你发现自己每次改完都在跑它，说明这套手续已经够资格升级了——该嵌进去，或者串起来。

第二档，嵌进生产流程。比如你有一个「脚手架生成新组件」的 Skill，生成完组件文件后，自动跑一遍代码规范检查，错误修完才允许汇报完成。检查不再是事后补课，是这道菜出锅的固定步骤。注意边界：只有你能改的 Skill 才适合这么嵌，会随插件更新被覆盖的、内置改不了的，别硬改，改用下一档串联。嵌进去之后，记得拿一个全新任务验一次，确认这步真的跑进了结果里，而不是写在文档里吃灰。

第三档，串联。一个 Skill 干完，自动叫下一个。Claude Code 团队自己日常就这么干：先代码审查找问题，再做精简清理改动，再跑验证确认端到端行为；如果动到了界面，再拿设计规范检一遍。也可以做个包装 Skill：先精简，再验证「有没有改坏对外接口」。习惯一旦写成合同，整条开发环就能自己转，你只在它搞不定、需要升级给你时才进场。

串联的代价也要说清。串得越长，消耗越大；如果有的步骤你有时想单独跑，就别全焊死。文里的建议很务实：先小范围试，再铺开。别第一天就串成一条谁都不敢动的巨型流水线。

第四档，每个拉取请求都过同一套门。你自己的链稳了，就让同事的改动也过同一套标准，不管他记不记得手动调用。验证从个人基建，升级成团队基建。文里特意泼了冷水：链还在变的时候，先别急着全队强制，你每次改规则，都会变成全团队可见的事件。先自己跑顺，再变成门口的闸机。

好，方法有了，怎么开始？官方文给了六步，我压缩成人话。第一，挑本周你最常做的那项手动善后。第二，先试他们内置的 verify，看能挡住多少。第三，用大白话把流程写下来，像交给新同事。第四，做成 Skill。第五，拿一个新任务真跑一遍，确认检查出现在结果里，不够就改。第六，再试技能串联，把单点检查收成端到端的验证流。

最后泼两盆必要的冷水。第一，这不是「写了 Skill 就无人值守、人可以撤了」。文里的目标很清楚：减少你反复手工拧的那些修正，把注意力腾出来，做 Skill 写不下来的判断——比如要不要做这个功能、风险能不能上、接口该不该对用户承诺。第二，也别一上来就追求大而全。先抓一条你这周最烦的重复检查，做成门禁；跑通了，再嵌、再串、再上拉取请求。

你甚至可以今天就做最小闭环：只选一条规矩，比如「错误日志必须带请求编号」，先让 AI 每次改完都自查这一条，过了再扩展。小，但真，比空挂十个大而全的检查有用。

所以记住这一句就够了：AI 编程真正拉开差距的，往往不是它会不会写，而是你有没有把验收标准，写成它跑不掉的闭环。你能交代清楚的越多，它第一次交出来就越接近你要的；你不再需要亲手收拾的小错越多，你才越有时间处理那些真正只能由人拍板的事。

常见问题

验证闭环是什么？

验证闭环（verification loop）就是让 AI 把活交到你面前之前先检查自己干得怎么样：跑测试、跑检查器、跑你定的自定义规则，挂了就自己修，过了才往下走。方法来自 Claude Code 团队 2026 年 7 月的官方文章，这套环还可以打成 Skill，让每次会话自动按同一套标准验收。

怎么把手动检查写成 Skill？

先把每次都在做的检查用大白话一条条写下来——写「什么情况算过、什么情况必须打回」，而不是「保证代码质量」。然后在项目 skills 目录放一个 markdown 文件：头信息写名字、什么时候该用、允许动哪些工具；正文写检查步骤、失败怎么报、怎么修。也可以装官方的 skill-creator 让它采访你生成。

Skill 应该挂在哪里生效？

文里把挂法分四档：独立调用（想用才用，适合横切检查）、嵌进生产流程（如生成组件后自动跑规范检查，只适合你能改的 Skill）、串联（一个 Skill 干完自动叫下一个）、每个拉取请求强制过同一套门（从个人基建升级成团队基建）。建议先小范围试，链还在变的时候别急着全队强制。