本页目录7
- 验证循环 = 收集上下文 → 执行操作 → 验证结果 的重复周期，失败就自动修复再继续。
- Claude Code 已内置多种验证手段：/verify、toolchain 错误捕获、Code Review（研究预览）、GitHub Actions、spec 校验、Claude Managed Agents 的 rubrics（测试版）。
- 当你发现自己每次都在做同样的「小修正」，就该把这些步骤写成 plain English 的 skill，存到 .claude/skills/ 下的 SKILL.md。
- 可用 /skill-creator 交互式生成，也可手写 markdown,frontmatter 里配置 name、description、allowed-tools。
- 验证循环可以 standalone 独立调用、embedded 内嵌到生成型 skill 末尾、chained 链式串联多个 skill，或作为 PR 级别的团队基础设施。
- Anthropic 内部工程师会把 /code-review、/simplify、/verify、自定义 /design 等 skill 串成端到端流程。
本文是对 Anthropic 官方文章「Building verification loops in Claude Code with skills」的中文要点摘要，完整内容以原文为准：https://claude.com/blog/building-verification-loops-in-claude-code-with-skills
什么是验证循环
文章把「验证循环」定义为：AI 代理反复检查自己工作的一个周期——运行测试、linter 或自定义检查，发现问题就先修复再继续。这个周期可以拆成三步：
- 收集上下文（gathering context）
- 采取行动（taking action）
- 验证结果（verifying results）
核心思路是，与其每次都靠人工在 Claude 完成任务后挑毛病、提修改意见，不如把这些「挑毛病」的标准写成一个可复用的 skill，让 Claude 自己跑。
Claude Code 已内置的验证方式
在动手写自定义 skill 之前，文章先列出了 Claude Code 已经具备的验证能力：
- /verify skill：构建应用、实际运行，观察变化是否符合预期
- Toolchain：自动捕获并处理 linter 等工具产生的错误码和警告
- Code Review（研究预览版）：自动化的 PR 审查服务
- GitHub Actions：在每次 push 或提 PR 时触发验证流程
- Spec validation：针对一份 markdown 规范文档校验改动是否合规
- Claude Managed Agents 的 Rubrics（测试版）：用单独的评分代理来打分验证结果
如果这些内置能力已经覆盖了你的需求，不必重复造轮子。
什么时候该写自己的验证循环
文章给出的判断标准很直接：当你发现自己每次 Claude 实现新功能后都在做同样的小修正时，就该把这些步骤沉淀成一个专属的验证循环了。
具体做法：
- 记录下那些反复出现的修正动作
- 用 plain English（自然语言）把「最佳实践」版本写下来
- 定性规则也可以写进去，比如「拒绝任何删除列却没有 backfill 步骤的迁移」
如何创建 Skill
最快方式——用 /skill-creator 交互式生成，让它反过来采访你的工作流程：
/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.
手工创建——在 .claude/skills/<skill-name>/SKILL.md 里写 markdown，配置 frontmatter（name、description、allowed-tools），正文用自然语言描述检查逻辑。文章给出的示例是一个检查日志规范的 skill：确认错误路径上的日志都带 request ID、且不包含请求体/用户负载，发现违规就报告 file:line 并自动修复。
验证循环的四种落地模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
| Standalone（独立） | 手动调用，不绑定特定工作流 | pre-commit 安全扫描、pre-PR 无障碍审查 |
| Embedded（内嵌） | 在生成型 skill 末尾追加一行，自动触发 | 例如 scaffold-component 之后自动跑 eslint 并修复 |
| Chained（链式） | 一个 skill 结束时自动调用下一个 skill | /code-review → /simplify → /verify → /design 串成流水线 |
| On every PR（PR 级别） | 同一套流程应用到所有 PR | 从个人工具升级为团队基础设施 |
Chained 模式还可以通过写一个 wrapper skill 来「扩展」那些你没有权限直接修改的 skill。文章提醒，链式编排虽然能打通完整开发周期，但也会增加 token 消耗、降低灵活性，需要权衡。
Anthropic 内部的实践
文章提到，Claude Code 团队自己在日常开发中就是这么用的：用 /code-review 找 bug,/simplify 清理 diff，内置的 /verify skill 确认端到端行为是否正常，再配合团队自定义的 /design skill 检查 UI 是否符合规范。
建议的上手步骤
- 挑一个本周你手动重复次数最多的「事后检查」动作
- 先看内置的 /verify 等能力能不能直接满足
- 用 plain English 把这个检查流程写清楚
- 用 /skill-creator 或手写
SKILL.md落地 - 在新任务上实际调用，确认检查真的会被触发
- 尝试把多个 skill 链起来，搭建端到端流程
文章的结论是：能沉淀给 Claude 的检查越多，Claude 第一次尝试就命中目标的概率就越高——原本花在反复修正上的注意力，会被释放出来，用于那些没有任何 skill 能替你完成的、真正需要人来做的工作。