面试官坏笑：“AI 自己都能检查代码了，要你何用？” 我骄傲：“俺能背锅！” 她大喜：“入职！组长就你了！”

大家好，我是程序员鱼皮。

最近 Claude 官方发了一篇博客，专门讲怎么让 Claude Code 自己检查自己写的代码，官方管这个叫 Verification Loop 验证循环。

简单来说，就是 AI 写完代码以后不急着交差，而是先自己跑一遍检查。有问题就继续改，改完再检查，形成一个循环，直到全部检查通过以后才交付给你。

原文指路：https://claude.com/blog/building-verification-loops-in-claude-code-with-skills

不过话说回来，现在 AI 写代码是真的快，可是每次它自信地跟我说「搞定了」，我还是得自己打开页面、一个功能一个功能试、切换到手机端再测、最后打开浏览器控制台看有没有报错。

代码是它写的，怎么最后验收还是我的活？

所以我倒要试试，Claude 官方的这套验证循环，到底能不能真让我少干点活。

什么是验证循环？

Claude Code 在开发过程中本来就会做一些基础检查，比如：

• 类型检查，确认变量类型有没有写错

• 代码规范检查，有没有少写分号之类的低级问题

• 自动化测试，跑一遍预设的测试用例

• 还有运行时报错，代码能不能稳定运行

这些检查都能给出明确的对错结果，AI 可以根据结果继续修改代码。

但是，这些基础检查覆盖不了所有最终效果。像手机端有没有布局错乱、按钮到底能不能点、页面有没有严重遮挡，这些问题光靠跑代码检查工具是发现不了的，最后还是得自己打开页面亲眼确认。

所以我平时用 AI 开发的流程一般是这样的：先让 AI 把代码写完、跑一些基础检查，然后我再实际操作一遍。发现问题以后告诉 AI 哪里不对，让它继续改。

但是换成 Verification Loop 以后，后面人工验收的部分也可以交给 AI 来干了。让 AI 自己验证、自己修改，全部通过以后再交付给我。

当然，光跟 AI 说一句「你自己检查一下」肯定不够。它得知道具体该检查什么，也得拿到一个能够判断「到底过没过」的明确结果。

在这方面，Claude 官方提到了好几种内置的验证方式：

• /verify技能，让 AI 自己构建项目、运行起来、然后观察改动有没有问题

• Toolchain，也就是利用项目里已有的工具链（比如代码检查工具），让 AI 直接读取工具返回的错误和警告来判断

• Code Review，一个自动审查代码改动的多 Agent 服务，可以在 PR（代码合并请求）上自动跑一遍审查

• GitHub Actions，在代码提交时自动触发检查流程

• Spec validation，按照项目里的需求规格文档来验证改动

• Rubrics，按照评分标准来打分，不及格就打回去重做

这些名字不用记住，核心思路都是一样的：给 AI 一个明确的检查结果，让它能判断这次到底是通过还是失败。程序能不能正常运行、测试有没有通过、代码提交有没有问题，都属于这种能够明确判断对错的结果。

甚至项目自己定的特殊规则，也可以变成验收条件。

那么你可能要问了：什么是项目自己定的特殊规则？

举个例子，假如数据库迁移要删掉一列数据，但是没有事先把数据备份保留下来，那这次修改就直接判定不通过。

这种规则是你的项目自己定的，通用的代码检查工具根本不知道这回事，但同样可以写进验证流程，让 AI 每次都按照这个标准来验。

用 Skill 把验证循环固定下来

如果你每次要重复的不只是一两条规则，而是一整套检查动作，那就可以把它们整理成 Skill 技能。

Skill 的本质就是一个 Markdown 文件，里面用自然语言写清楚检查步骤，放到项目的.claude/skills/目录下。以后再遇到类似的任务，AI 直接按照这套流程执行，不需要你每次重新教一遍。

官方推荐的上手路径是这样的：

1. 先从一项最常重复的人工检查开始，比如试试 Claude Code 里内置的/verify技能，输入这个命令以后，AI 就会自己构建项目、运行起来、然后检查改动有没有问题。

2. 觉得不够用的话再自己写。你可以把检查流程用自然语言描述出来，交给skill-creator插件帮你生成，它会理解你的工作流程然后自动生成对应的 Skill 文件。当然也可以自己手写一个 Markdown 文件，放到技能目录下就行。

3. 拿新任务跑一遍，看看哪里不好用就继续迭代。等单个检查稳定了，再尝试把多个检查串起来。

一个简单的 Skill 文件长这样：

# .claude/skills/verify-log-hygiene/SKILL.md
---
name: verify-log-hygiene
description: 检查错误日志是否包含请求 ID，并且不能泄露请求体内容。
---
读取当前代码改动中的错误处理路径。

 对于每一个错误路径上的日志调用，确认它包含了请求 ID，
并且没有把请求体、请求头、或用户提交的任何数据写进日志。

 逐条报告违规项（标注文件名:行号），然后修复它。

上面这个 Skill 的作用是检查日志规范。你可以看到，它就是一段 YAML 格式的头信息（名字和简介）加上几段自然语言写的检查指令，告诉 AI 该看什么、怎么判断、发现问题怎么处理。没有想象中那么复杂，本质上就是把你平时脑子里的检查流程用文字写下来。

像我平时检查前端页面，就会反复检查页面加载、核心交互、移动端适配、浏览器控制台这些东西，每次都是同样的流程。所以这次我干脆把它们写成了一个verify-frontendSkill，让 AI 自己对照着验收。

不过要注意，Verification Loop 是核心思路，Skill 只是实现它的一种方式。你也可以用 Hooks 钩子（在特定时机自动触发的脚本）来实现类似的效果，甚至可以用/goal命令定义一个目标条件，让 AI 自己循环直到条件满足为止。

实战验证 - 循环到底有没有用？

哔哔了一大堆，这玩意到底有没有用呢？

我决定设计一个对比实验来试试看。

同一个项目、同样的需求，第一轮正常让 AI 开发然后我人工验收，第二轮让 AI 开发完以后自己执行 Verification Loop 来验收。看看这套验证循环在实际开发中，到底能不能帮我省事。

本来我想直接在 Claude Code 里用 Claude 自家的模型来跑这个实验，但是我的 Claude 账号早就喜提封号了。。。

没办法，这次只能让 Claude Code 接 DeepSeek 模型给大家实测。具体怎么接入，大家可以看我之前发布的，这里就不展开讲了。

至于拿什么项目来测试，我选了最近挺火的竹知了~

我直接给了 AI 几张参考图，让它搓一只 3D 赛博风格的竹知了出来。

初始版本的页面只有竹知了主体、缓慢自转和一个标题。

竹知了初始版本

然后我给 AI 下了 5 条需求：

1. 鼠标拖动控制竹知了的旋转和朝向
2. 普通 / 狂暴模式切换
3. 狂暴粒子光效
4. 375px 移动端适配
5. 整体视觉完善

为了尽量公平，两轮实验都从同一个初始版本开始，用的是相同的 DeepSeek 模型和同一套工具环境，而且每轮都重新开一个全新的 Claude Code 会话。

同时为了保证公平，我在第一轮开始之前就把第二轮要用的 6 类验收检查全部定好了，避免我看完第一轮结果以后再临时往规则里塞东西。

左侧为正常开发，右侧为 verify-frontend Skill 第一轮、正常开发

这一轮我按平时开发的方式来，不告诉 AI 要额外测试，也不让它跑verify-frontendSkill。

5 分 33 秒后，Claude Code 宣布完成。5 项需求都有对应实现，而且 AI 自己还主动检查了一遍项目能不能正常构建。

来看看 AI 实现的效果。

我脑子里的「拖动竹知了」，其实是拿着棍子一甩，绳子受重力和惯性影响，下面的竹知了跟着晃，再配个「哇哇哇」的音效，美滋滋～

第一轮普通状态下竹知了

但是 AI 完全理解错了，它做出来的是鼠标按住模型以后，直接控制整个竹知了旋转。

我刚想吐槽，回头看了一眼自己写的需求。

行吧，这真不能怪 AI。

我只写了「鼠标拖动控制竹知了的旋转和朝向」，根本没写绳子、重力、惯性这些东西。

AI 宣布完成以后，我还是老老实实自己验了一遍，功能基本都能用，不过狂暴模式的效果跟我想象中还是有点差距。虽然旋转确实变快了，但粒子和光效变化并不明显，只看图片的话，跟前面那个没啥区别。

第一轮狂暴模式下的竹知了

另外我还发现，浏览器控制台里躺着两条黄色警告。简单来说就是 3D 渲染库 Three.js 提示有两处旧的用法已经不推荐了，不过目前还能正常运行，所以不影响这次验收。

总结一下这轮测试。AI 花了 5 分 33 秒写完代码，我又花了大概 2 分钟手动验了一遍。点交互、切换模式、测 375px、最后还得打开浏览器控制台看报错。

第二轮、验收也交给 AI

第二轮我把代码回退到了竹知了最初的样子，也就是只有主体模型和缓慢自转的那个版本，确保两轮测试的起点完全一样。

前面那 5 条功能需求一字不改，只额外增加了一句话：

开发完成后必须执行 verify-frontend Skill，全部通过后才能宣布完成。

这次 AI 不光要写代码，还得把我平时会做的那些验收工作自己跑完。

还记得前面提到，我在实验开始前就定好的那 6 类检查吗？

• 项目能不能正常构建

• 页面能不能正常打开

• 核心交互有没有生效

• 375px 手机端有没有问题

• 浏览器控制台有没有报错

• 页面有没有明显错位、遮挡或者裁切

为了让 AI 真正能操作页面，这次我给它配了两个工具。

1. Playwright 是一个浏览器自动化测试框架，相当于 AI 的「手」，能帮它打开网页、拖动模型、点击按钮这些真实操作。

2. Vision 视觉能力相当于 AI 的「眼睛」，让它能够截图并看懂页面长什么样，检查有没有明显的错位、遮挡或者裁切。可以用 GitHub 上开源的 多模态视觉识别 Skill

AI 写完代码之后，会自动执行验收流程。

中间还出了个小插曲，Playwright 一开始因为依赖没装好所以没跑起来。不过这点小问题根本不需要人工处理，AI 自己排查出了原因、修好了依赖、然后继续往下验收。

最终，按照实验前定好的规则，6 类检查全部通过了。

这一轮任务总耗时 9 分 48 秒。而且从效果上来看，第二轮狂暴模式的粒子效果，比第一轮确实炫酷多了。

第二轮狂暴模式下的竹知了

AI 在最终的验收报告里还记录了一条构建警告，提示打包后的文件体积超过 500 KB，还是挺细心的~

不过和第一轮验收一样，打开浏览器控制台，我发现那两条警告信息还在。

这也提醒了我，如果真要把验收交给 AI，光告诉它该验什么还不够。AI 具体用什么方式去检查（比如是看截图还是读控制台日志）、检查到异常以后怎么分类记录、最后怎么在报告里完整汇报出来，这些同样得在 Skill 里写清楚。中间任何一环有疏漏，都可能出现有问题却没有报告的盲区。

两轮实验的对比结果

按照实验前定好的规则，两轮都通过了验收，也都没有发现影响功能的业务 Bug。

真正发生变化的，是验收这件事由谁来做。

第一轮 AI 写完以后，我自己点、自己看、自己测。

第二轮在 AI 宣布完成之前，我完全没有插手验收过程，它自己把整套流程跑完了。

代价就是，第二轮总耗时多了 4 分多钟。但这段时间不需要我守在旁边一个个手动点击屏幕，我可以去喝杯水、摸摸鱼、做一组提肛，回来直接看结果。这才是我觉得 Verification Loop 真正有价值的地方。

当然，「通过验收」和「效果完全符合预期」还是两回事。就像第一轮的狂暴模式，功能确实做出来了，但到底够不够狂暴、视觉效果满不满意，还是得人工来判断。

所以我觉得，真正适合先交给 AI 验收的，是那些能够明确判断对错、而且每次都要重复做的事情。比如项目能不能构建、核心交互有没有生效、手机端有没有适配问题、浏览器控制台有没有报错。

至于动画是不是太快、页面够不够好看、竹知了到底有没有小时候甩起来那个味儿，这些涉及主观审美和产品感觉的事情，最后还是得人来拍板。

在 AI 时代，审美和判断力才是人类最稀缺的能力。

验证循环还能怎么玩？

我这次只是在 AI 开发完成以后，单独跑了一遍验收。但 Verification Loop 并不只能放在最后一步。

等这套验收方式拿真实任务跑过几次、确定比较可靠以后，还可以把它嵌进日常开发流程，甚至跟其他检查串起来形成一条流水线。

Claude 官方把这些用法总结成了 4 种运行方式：

1）Standalone 独立执行

需要的时候手动触发一次，比如提交代码前临时跑个安全扫描。

2）Embedded 嵌入到其他 Skill 里

把验证步骤直接写进生产 Skill 的末尾。比如你有一个自动创建 React 组件的 Skill，就可以在最后加一行「创建完成后跑一遍 eslint 检查」，这样每次用这个 Skill 的时候都会自动验证。

3）Chained 链式串联

多个 Skill 首尾相连，一个跑完自动触发下一个。

Anthropic 自己的 Claude Code 团队日常就是这么用的。先用/code-review命令找 Bug，再用/simplify命令精简代码，然后用/verify命令确认功能正常，如果改动涉及 UI 的话，最后还会用一个自定义的/designSkill 比对设计规范。

这四步跑完，就是一整套全自动的代码质量保障流程，开发者只有在某一步出了问题、需要人工介入时才会收到通知。

4）On every PR 每次提交代码时自动执行

等链式流程在你自己的开发中跑稳以后，就可以把它挂到 GitHub Actions上。这是 GitHub 提供的自动化流水线服务。

这样一来，团队里任何人提交代码合并请求，都会自动触发同一套验证检查，不需要靠每个人自觉去手动执行，代码质量有了统一的底线保障。

顺带一提，Claude Code 的创造者 Boris Cherny 在今年 6 月说过一句话：我已经不再手动给 AI 写提示词了，我现在的工作是设计循环，让循环去指挥 AI 该做什么。

这个理念在开发者社区里被叫做 Loop Engineering 循环工程，核心思想就是人类从「逐条指挥 AI」转变为「设计一套系统让 AI 自己运转」，而 Verification Loop 就是其中最关键的一环。

看到这里，你应该感受到了 Verification Loop 的作用。

如果你要用 AI 做完整的大项目，我建议你除了给 AI 需求清单之外，再给 AI 一张验收清单。

像那些每次都要重复做的检查，能让 AI 先跑一遍，就没必要再从头手动验一遍了。

得益于这套方法，最近我用 AI 轻轻松松搞了不少完整的作品，并且已经推广给不少人用了~

比如下面这个游戏记录工具：

如果你也有一套写完代码后每次都会重复的检查流程，可以试着整理成 Skill。懒得从零写的话，可以用官方的skill-creator插件，它会像面试一样问你平时的工作流程，然后帮你自动生成。

话说回来，AI 能自己检查代码了，那还要程序员干嘛？

答案很简单：背锅（bushi）

AI 验收通过不代表万事 OK，它只能覆盖那些能明确判断对错的部分。真要上线出了问题，需求是谁定的、验收标准是谁写的、最终拍板上线的是谁，这些责任 AI 可背不了。

AI 是很好的执行者和检查员，但它不是决策者，更不是责任人。

所以别觉得什么「一人公司」就很轻松。你只是没看到人类背后被 AI 反复折磨、对着屏幕狂骂的样子罢了。

一个能做判断、敢扛责任的人，加上一个不知疲倦、执行力拉满的 AI，这才是当前最靠谱的组合。

OK 就分享到这里。如果你对 AI 编程感兴趣，欢迎阅读我免费开源的 ，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。

鱼皮的 AI 编程教程

我是鱼皮，持续分享 AI 编程干货，觉得有用的话记得点赞收藏和关注。

你用 AI 写代码时，最烦的事情是什么？评论区聊聊~