在 Claude Code 中使用 Skills 构建验证循环¶
如何将你的手动检查转化为 skills,让 Claude 自行关闭反馈回路。
作者:Delba de Oliveira,Claude Code 团队成员
日期:2026 年 7 月 22 日 | 阅读时间:5 分钟
引言¶
大多数 Agent 编码会话遵循一个循环:你提出变更请求,Claude 收集上下文、执行操作、验证结果,如果需要就回到收集上下文阶段重新来过。
验证是 agent 在响应之前检查自己工作的方式。Claude 已经通过观察你代码库中的确定性信号来做一些验证工作,包括类型检查器、linter、测试和运行时错误。Claude 无法推断的部分,就变成了你手动检查功能时需要执行的步骤。
然而,这些手动步骤可以转化为验证循环。在 Claude Code 中,验证循环是一个迭代过程,Claude 在其中检查并尝试修复工作。
Agent 循环:1. 收集上下文 → 2. 执行操作 → 3. 验证结果
本文涵盖最常见的验证循环类型,展示我们在 Anthropic 内部使用的方式,然后说明如何将你已经在做的手动检查编码为 skills,这样 Claude 就能自行关闭反馈回路,而你可以去忙别的事。
刚接触 agent 循环?从循环入门开始。
什么是验证循环?¶
验证循环是 AI agent 检查自己工作的重复周期——运行测试、linter 或自定义检查——在继续之前修复失败的部分。
在 Claude Code 中,验证循环可以被打包为 skills,这样每个会话都自动应用相同的检查,而不是依赖人来记住它们。
内置验证循环¶
在设计自定义验证循环之前,了解 Claude 对多种验证循环的内置支持会很有帮助。
| 功能/方式 | 说明 |
|---|---|
/verify skill |
构建、运行并观察你的应用中的变更 |
| 工具链(Toolchain) | Claude 会捕获并处理你提供的任何工具(如 linter)的错误代码和警告。好的做法是在 CLAUDE.md 中列出你确切的构建和测试命令,这样 Claude 就不必去推断 |
| Code Review(研究预览) | 一个托管的多 agent 服务,对你启用的仓库中的 PR 运行自动审查。你可以手动修复发现的问题并 push,或者通过在发现的问题上评论 @claude 来关闭循环(如果你已经设置了 GitHub Actions) |
| GitHub Actions | 定义一个调用 Claude 和验证 skill 的 job,你在本地运行的相同检查会在每次 push 或 PR 时触发 |
| Spec 验证 | 一个 skill,帮助对照仓库中的 markdown 规格说明验证每个变更,并尝试修复违规 |
| Claude Managed Agents 中的 Rubrics(beta) | 一个托管的 agent 服务,允许你使用单独的评分 agent 对照评分标准验证结果。失败会自动循环回去返工 |
编写验证循环¶
当你发现每次 Claude 为你实现新功能时都在做同样的小修正,就是时候把这些步骤转化为自定义验证循环了。
当你有一个现有项目,发现每次 Claude 为你实现新功能时都在做同样的小修正,就是时候把这些步骤转化为自定义验证循环了。第一步是写下你每次都在做的所有事情。
如果你正在开始一个新项目,需要弄清楚项目应该如何表现也是一样的。用简明的英文写下最佳实践版本,就像你在第一天交给新队友那样。
如果你难以清晰表达验证检查本身,先问 Claude 最佳实践是什么,然后在此基础上编辑。你的版本可能在几个具体点上有所不同,而这些差异正是你想要捕获的。
提示:检查不一定是定性的才能放在这里。"拒绝任何没有回填步骤就删除列的迁移"是一个确定性规则,通用 linter 不会捕获它,但项目特定的 linter 会。任何你一直需要作为手动检查来执行的事情都可以被捕获为循环。
将其变为 Skill¶
将重复步骤编码为验证循环最常见的方式是将其写为 skill,创建 skill 最快的方式是安装 skill-creator 插件让 Claude 采访你。
示例:
/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.
你也可以手写 skill,只需在项目中的 .claude/skills/ 目录下放一个 markdown 文件。最简单的验证 skill 就是几行 frontmatter 加上正文:
# .claude/skills/verify-log-hygiene/SKILL.md
---
name: verify-log-hygiene
description: Check that error logs include the request ID and never
include the request body. Use when the diff touches error handling
or logging.
allowed-tools: [Read, Edit, Grep]
---
Read the error-handling paths in the current diff.
For each log call on an error path, confirm it includes the request ID
and does not pass the request body, headers, or any user-supplied payload.
Report each violation with file:line, then fix it: add the request ID
where it's missing and strip the payload from the log call.
完整的 schema 和背后的设计理念在我们的构建 skills 完整指南中。
匹配检查的运行位置¶
下一步要确定验证循环如何触发:独立式、嵌入式、链式,还是绑定到 PR。
独立式(Standalone)¶
你在产出物存在之后刻意调用它——适用于不需要每次都触发的跨领域检查。
你在产出物存在之后刻意调用。独立式 skill 适合不是每次都适用的跨领域检查:提交前的安全扫描、PR 前的可访问性审计、跨仓库的许可证头验证。任何你想在多个工作流中可用但不想在每次代码变更时都触发的东西。
代价是每次调用仍然是你需要记住执行的一个步骤。当你在每次变更后都在运行它时,就是你已经超越了独立式的信号。此时,这个流程已经赢得了一个永久位置:将其嵌入或链接。
嵌入式(Embedded)¶
作为产出 skill 的一部分自动触发——检查属于一个特定工作流,无需你主动请求就会运行。
作为产出 skill 的一部分自动触发。检查属于一个特定工作流,而工作流现在不需要你请求就会运行它。
最简单的版本是在产出 skill 正文末尾追加一行:
# .claude/skills/scaffold-component/SKILL.md
---
name: scaffold-component
description: Scaffold a new React component under src/components/, including
the component file, its co-located test, and an index export. Use when the
user asks to create a new component.
allowed-tools: [Read, Write, Edit, Bash, Glob]
---
# Scaffold a new React component
Given a component name (PascalCase), create the following under `src/components/<Name>/`:
1. `<Name>.tsx`: function component with a typed props interface and a default export.
2. `<Name>.test.tsx`: React Testing Library test that renders the component and asserts
it mounts without throwing.
3. `index.ts`: re-export the default and any named exports.
Follow the patterns in `src/components/Button/` as the reference. Match the import alias
style (`@/components/...`) used throughout the codebase.
# code continues...
After creating the component file, run eslint on it and
address any errors before reporting completion.
通过在新任务上调用 skill 来验证嵌入是否生效,确认新步骤作为输出的一部分运行。如果没有,skill 的描述或前面的指令没有将追加的检查拉入。
嵌入式只适用于你可以编辑的 skills:你自己写的,或者安装在项目级别且 SKILL.md 文件在你控制下的。内置 skills 和插件管理的 skills(那种更新时会被覆盖的)不适合这种模式;对那些,请使用链式。
对于跨工作流的检查请跳过嵌入式;那些需要独立式,这样你可以从任何上下文调用它们。
链式(Chained)¶
一个 skill 在结束时调用另一个,多个经过验证的交接端到端运行。
一个 skill 在结束时调用另一个,多个经过验证的交接端到端运行。
Anthropic 的 Claude Code 团队成员在日常工作中使用这种模式:/code-review 寻找 bug,/simplify 清理 diff,/verify skill 确认端到端行为,如果变更触及了 UI,自定义的 /design skill 会对照 DESIGN.md 文件中的指南进行检查。
链式也是你为无法修改的 skill 添加验证的方式:构建一个自定义包装 skill,先调用原始 skill,然后调用你的验证 skill:
# .claude/skills/safe-refactor/SKILL.md
Run /simplify on the current diff first.
When /simplify finishes, invoke /verify-no-public-api-changes.
原本是一个习惯("我总是在 /simplify 之后运行 /verify")变成了一个契约("/simplify 完成时总是运行 /verify")。链条自行运行整个开发周期。你只在某些事情升级回你这里时才介入。
当步骤足够独立以至于你有时想单独运行其中一个时可以跳过链式;链式用灵活性换取了自动化。链式验证循环会增加 token 消耗,所以最好在广泛部署之前测试这些循环。
每个 PR 触发¶
一旦链条对你自己的变更可靠了,同样的流程可以在每个 PR 上运行——队友的变更通过和你相同的门禁。
一旦链条对你自己的变更可靠了,同样的流程可以在每个 PR 上运行。队友的变更通过和你相同的门禁,无论他们是否记得调用链条。基础设施与你已经写的链条是同类的东西,只是更进一步:相同的 skills、相同的评分标准、相同的标准,不依赖于作者的自律来应用。
这就是验证从个人基础设施变成团队基础设施的地方。你为了每周省两分钟写下的检查,现在在每个变更上为每个人每周省两分钟。在链条还在变动时暂缓 PR 级别的门禁;每次调整都会变成团队可见的事件。
总结:验证循环的创建流程¶
不管你在自动化什么或在什么环境中,验证循环的创建过程是一致的。
一旦你掌握了流程,就可以扩展你的循环工程。无论你在自动化什么或在什么环境中,验证循环创建过程是一致的:
- 挑选你本周最常做的那个手动后续检查
- 先试用内置的
/verifyskill,看看它是否对你的流程有帮助 - 用简明的英文写下这个流程,就像你在第一天交给新队友那样
- 交给 skill-creator,或者自己在
.claude/skills/中放入 markdown 文件 - 在新任务上调用它,确认检查作为输出的一部分运行,如果需要就迭代
- 尝试 skill 链式组合,创建端到端的验证流程
你能编码让 Claude 遵循的越多,Claude 的响应在第一次尝试时就越接近你想要的。你不再需要摆弄的那些修正,现在释放了你的注意力去做只有你能做的独特工作——那些没有任何 skill 能替你写下的东西。
开始在 Claude Code 中使用验证循环吧。查看 agentic 编码介绍了解更多关于 agent 循环的基础知识,或参阅在大型代码库中使用 Claude Code 的最佳实践了解团队级基础设施的搭建。