写代码这件事，AI 已经能替人完成不少工作。可一段代码到底写得对不对，很多时候验收压力还在人工这一端。
Anthropic 近期把这一步也放进了 Claude 的执行循环里。按照 Claude Code 团队公开的做法，Claude 在写完代码后不会直接交付，而是先自行跑完 4 道检查：/code-review、/simplify、/verify，以及在界面发生改动时追加的 /design。4 道流程全部完成后，才算交付结果。
7 月 22 日，Claude Code 团队公开了这套内部使用的“验证循环”。按文章描述，Claude 写完代码后，会先自己找错、修改，再把结果交还给用户。对应的变化不只是“会写代码”，而是开始具备“检查自己写的代码”的能力。
Anthropic所说的“验证循环”是什么
Anthropic 将这套机制命名为 verification loop，也就是验证循环。官方给出的定义很直接：这是一个 Claude 检查并尝试修复自己工作的迭代过程。
它改变的是智能体完成任务的闭环结构。原先的路径更接近“收集上下文→执行动作→人工检查”，最后一道检查长期压在人身上。现在，这条链路被拉长成“收集上下文→执行动作→自动验证→修复→再验证”，检查与修复被重新塞回流程内部。
按照官方展示的智能体循环示意图，提示进入后，Claude 会先收集上下文，再执行动作，随后验证结果；如果验证不通过，就返回重跑，通过后才输出结果。
其中有一部分检查，Claude 本来就能处理。比如代码仓库里的确定性信号，包括 type checker、linter、运行测试以及运行时报错，这些内容它能读取，也能顺手修正。
难点在另一类问题上：界面改动是否正确、用户流程是否顺畅、这次修改有没有埋下不容易察觉的风险。这类检查过去往往要靠人一遍遍盯着做，重复次数可能是几十次甚至上百次。
Anthropic 的做法，是把这些原本需要人工反复执行的检查逐条写清楚，再封装为 Skill，让 Claude 在每次任务中自动执行。
瓶颈从写代码转向验证与审查
文中提到，过去几十年软件工程里的很多流程——写需求、做规划、层层评审以及大量会议——背后的一个基本前提是写代码速度慢，工程师时间昂贵。
而当 AI 让代码生成变得更快、更便宜，这个前提开始变化。Claude Code 团队的判断是，瓶颈并没有消失，只是从“写代码”转移到了验证、代码评审和安全等环节。
代码生成速度加快后，新的问题变成：这些代码到底对不对、谁来维护、人工是否还能跟上审查节奏。面对这个新瓶颈，Claude Code 团队先把方法用在自己内部。
Claude Code团队内部每天使用的4个Skill
Claude Code 团队披露，内部每天都在使用 4 个自查 Skill。
/code-review：先找潜在 bug，再给 review 意见
/code-review 用来专门审查代码改动，目标是揪出潜在 bug，并给出一份 review 意见。按文中的说法，这相当于给模型自己配了一个不会疲倦的审稿人。
/simplify：清掉冗余实现，压低维护成本
/simplify 负责清理本次改动的 diff，把绕远路的复杂实现删掉，让结构更简单。它不增加功能，而是通过删减冗余、简化实现，把后续维护成本往下压。
文章特别强调了这一点的重要性。多数工具更容易一路往上堆功能，能主动做减法的工具更少见。
/verify：做端到端验证，不看“像不像完成”
/verify 负责端到端验证，也就是把功能真正跑一遍，确认任务确实已经完成，而不是只在表面上看起来完成。
/design：只有动到 UI 时才触发
/design 只在界面发生改动时启用。它会对照仓库里的 DESIGN.md，逐条检查视觉实现是否偏离设计要求。
这 4 个 Skill 不是凭空出现的。Claude Code 底层已经提供了一层验证支持，包括：
- 内置的 /verify，可以把应用跑起来并观察变化；
- 如果用户在 CLAUDE.md 里写清构建和测试命令，Claude 会按说明执行；
- 面向 PR 的多智能体 Code Review；
- 能够在每次提交时自动触发的 GitHub Actions。
Claude Code 团队日常使用的那 4 个 Skill，就是在这层通用基础上，再叠加的一道内部工序。
Anthropic如何建议用户编写自己的验证Skill
Anthropic 给出的做法不复杂：把每次都需要手动执行的检查步骤，用最直白的话写下来，就像在给第一天入职的新同事交代注意事项。
如果一开始连这一步该怎么描述都没有头绪，可以先让 Claude 生成一版通用最佳实践，再在此基础上修改。文章指出，用户自己的版本往往会在某几个点上和通用做法不同，而正是这些不同之处，最值得被记录下来。
检查也不一定只能是“感觉对不对”这种模糊判断。文中举例说，任何删除数据库字段、却没有配套数据迁移步骤的改动，都应该一律打回。这样的规则，通用 linter 很难捕捉，但对具体项目来说却是明确的“土规矩”。
凡是长期依赖人工死盯才能守住的红线，都值得被写成一个循环。
写完之后，可以把它交给 skill-creator 来反向提问，也可以直接把一个 Markdown 文件放进 .claude/skills/ 目录。
最简单的验证 Skill，只需要几行说明加一段正文。随后在一个新任务上调试一次，确认这一步检查确实会跟着执行；如果不合适，再继续修改。
如果遇到某些不能直接改动的 Skill，比如内置 Skill 或插件托管的 Skill，Anthropic 也给出了解法：可以再写一个外层 Skill，让它先调用原有 Skill，再调用用户自己的验证步骤。通过这种包装方式，也能把检查嵌入流程。
验证触发方式分4档：从习惯到契约
当检查被封装为 Skill 后，下一个问题是触发时机。Anthropic 给出了 4 档自动化程度，从松到紧依次是：
- Standalone：想到时手动调用；
- Embedded：嵌进某个任务流程，执行任务时一并运行；
- Chained：多个验证 Skill 串成链条，按顺序自动跑完；
- On every PR：每次提交代码时都自动检查一遍。
官方把中间这一步跃迁概括为“从习惯到契约”。原本是“每次都记得在 /simplify 后再补跑一次 /verify”这样的个人习惯；当它们被串成链后，就变成“/simplify 结束后，自动调用 /verify”的固定约束。
整条链可以自己完成开发循环，只在需要人工拍板时再返回给人。
不过，Anthropic 也专门提醒，链式验证会实打实消耗 token。因此，不建议一开始就把所有检查都设成 PR gate，也就是每次提交都必须过关，比较稳妥的方式是先看流程是否稳定，再逐步提高自动化等级。
4个Skill背后，AI编程竞争点正在变化
文章认为，这 4 个 Skill 反映出 AI 编程的竞争正在从“生成”转向“验证”。
文中提到，Claude Code 之父在 6 月 9 日发推表示，在强大模型能够长时间自主运行的阶段，自我验证是让模型运行更久、结果更贴近用户预期的关键。这样一来，用户不必一直守在一旁频繁盯着 Claude，也可以把更多任务交出去。
按这个逻辑，验证机制越扎实，智能体就越能被放开运行，人工也越容易从频繁复查中抽身。
文章还专门纠正了一个常见误解：Skill 不是一段 Markdown 提示词。它是一个能力模块，里面可以包含指令、文件结构、脚本、工具调用、配置，以及整套工作流程。换句话说，它是在把团队的检查步骤、设计规范和踩过的坑，沉淀成一个可反复调用的能力包，Claude 在需要时再去使用。
更关键的一点在于，Skill 正在从 Claude Code 的单一功能，逐步变成跨厂商的开放标准。按文中梳理，GitHub Copilot、Cursor、OpenAI Codex 和 Gemini CLI 都已经采用同一套格式。
这意味着，团队沉淀下来的 Skill 不会被锁死在单一工具里。团队经验、规范和检查流程，可以继续作为一项能力反复调用。
这也带出文中的一个现实判断：即便使用的是同一个 Claude，不同团队的效率也可能差出几倍，差距不一定来自模型本身，而在工作流上——是否把检查写成 Skill，是否搭起验证循环，是否让智能体自己把反馈闭环跑通。
文章将智能体能力概括为一道加法题：模型、工具、验证机制、工作流程。模型这一项正在趋同，真正拉开差距的，是后面 3 项，而这些都掌握在用户手里。
Anthropic展示的是流程优化，不是独立交付
文末也明确指出，这篇博客展示的是 AI 辅助开发的流程优化，并不等于“AI 已经能独立写软件”。它依然离不开工程师，也无法脱离人工完成生产级交付。
换句话说，这不是在说明智能体会取代工程师，而是在说明方向已经更清楚：过去人们一直在教 AI 怎么写代码，现在开始教它验证自己写得到底对不对。
对于长期使用 AI 写代码的人来说，等到“下班前还得手动复查一遍”这件事能够放心交给 AI 时，AI 才算真正开始承担更多执行工作。
参考资料
- https://claude.com/blog/building-verification-loops-in-claude-code-with-skills
- https://claude.com/blog/getting-started-with-loops?utm_source=chatgpt.com
本文来自微信公众号“新智元”，作者：ASI 启示录。