用 Claude Code 内置的 /code-review、/simplify、/verify、/design 四个 Skill 搭建验证层，让 AI 写完代码先自查再交付。
用 Claude Code 内置的 /code-review、/simplify、/verify、/design 四个 Skill 搭建验证层，让 AI 写完代码先自查再交付。
Claude Code 团队 2026-07-22 公开了内部每天都在用的「验证循环」实践：让 Claude 写完代码不直接交差，而是自己先跑四道检查。本文聚焦验证这一层——4 个内置自查 Skill、如何写一个自己的验证 Skill、以及 4 档自动化等级。如果你已经熟悉 agentic loops 的通用模式（循环、反馈、工具调用），这篇是叠在你既有循环之上的「验证层」。
官方原文：
官方定义：一个 Claude 检查并尝试修复自己工作的迭代过程。
传统 agentic loop 的闭环是「收集上下文 → 执行动作 → 人工检查」，最后一步卡在人身上。验证循环把它改成：
收集上下文 → 执行动作 → 自动验证 → 修复 → 再验证检查和修复被塞回循环里，AI 从「会写代码」进化到「会检查自己写的代码」。
两类检查需要区分：
Claude Code 团队每天在用的四道工序：
/code-review：专审代码改动，把潜在 bug 揪出来，给一份 review 意见，相当于一个不知疲倦的审稿人。/simplify：清理本次改动的 diff，把绕来绕去的复杂实现删掉，让结构变简单。不加功能，只做减法、压低维护成本。/verify：做端到端验证，真跑一遍，确认功能是真的完成，而非「看起来完成了」。在 CLAUDE.md 里写清构建/测试命令，它就照着执行。/design：只在动了 UI 时上场，对着仓库里的 DESIGN.md，逐条核对视觉实现有没有跑偏。四道跑完，才算交付。这 4 个 Skill 等于在 Claude Code 通用地基（内置 /verify、PR 多智能体审查、GitHub Actions 自动触发）之上又加了一道工序。
把你每次都要手动做的那一步写下来，就像给第一天入职的新同事交代注意事项。
如果你连这步检查该怎么描述都卡壳，先让 Claude 给一版通用最佳实践，再在上面改。你的版本跟通用做法不一样的那几点，恰恰是最该记下来的。
检查不能停留在「感觉对不对」这种模糊判断。
💡 提示：典型项目专属红线——「任何删掉数据库字段、却没配套数据迁移步骤的改动，一律打回」。这是通用 linter 永远抓不到、却是你项目专属的「土规矩」。凡是你一直靠手动死盯才守得住的红线，都值得写成一个循环。
两种方式选一种：
skill-creator，让它反过来采访你几句后自动生成。.claude/skills/ 目录扔一个 Markdown 文件。最简单的验证 Skill 就是几行说明加一段正文。
在新任务上调一次，确认这步检查真的跟着执行了。
💡 避坑：碰到改不动的 Skill（内置的、插件托管的），写一个外壳 Skill，让它先调原来的、再调你的验证，照样把检查嵌进去。
从松到紧四档：
| 档位 | 说明 |
|---|---|
| Standalone | 你自己想起来，手动调一下。 |
| Embedded | 嵌进某个任务流程，跟着一起跑。 |
| Chained | 多个验证 Skill 串成一条链，一个接一个自动跑完。 |
| On every PR | 最狠的一档，每次提交代码都自动过一遍。 |
官方把中间这层跃迁叫「从习惯到契约」：本来是「我每次都记得在 /simplify 后面补跑一次 /verify」的个人习惯，串成链后变成「/simplify 跑完自动调 /verify」的固定契约。
⚠️ 重要：链式验证会实打实地烧 token。别一上来就把所有检查都设成 PR gate、每次提交必卡。正确姿势是先看它稳不稳，再一步步往上加。
四档全开是终点，不是起点。建议的最小验证链：
/code-review → /verify → /simplify把这条链挂到 Chained 档跑一周，观察 token 消耗和 bug 拦截率，再决定要不要拉到 On-every-PR。
