发布日期： 2026年7月22日

分类： Claude Code

来源： https://claude.com/blog/building-verification-loops-in-claude-code-with-skills

---

大多数Agentic Coding 会话都会经历同一个循环：你提出一项改动，Claude 收集上下文、执行操作、验证结果；如有必要，再回到前面补充上下文。

验证是 Agent 在回复前检查自身工作的方式。Claude 已能通过代码库中的确定性信号完成部分验证，例如类型检查器、linter、测试和运行时错误。Claude 无法自行推断的部分，就会变成你需要手动检查功能的步骤。

但这些手动步骤可以被改造成验证闭环。在 Claude Code 中，验证闭环是一种迭代过程：Claude 检查工作结果，并尝试修复发现的问题。

Agent 循环：1. 收集上下文；2. 执行操作；3. 验证结果。

本文会介绍最常见的验证闭环，以及 Anthropic 内部正在使用的方式；随后说明如何把你本来会手工做的检查编码成 Skills。这样 Claude 可以自行闭合反馈回路，而它迭代时，你可以转去处理其他工作。

什么是验证闭环？

验证闭环是一个重复循环：AI Agent 运行测试、linter 或自定义检查来检验自己的工作，在继续之前修复失败项。在 Claude Code 中，可以把这种闭环封装成 Skill，让每次会话都自动应用同一套检查，而不必依赖某个人记得执行它。

内置验证闭环

在设计自定义验证闭环之前，先了解 Claude 已内置支持的验证方式会很有帮助。常见功能和做法包括：

• /verify Skill：构建、运行并观察应用中的改动。
• 工具链：Claude 会尽力捕获并处理你提供的各类工具所返回的错误码和警告，例如 linter。建议把准确的构建和测试命令写入 CLAUDE.md，避免 Claude 自行猜测。
• Code Review（research preview）：一项托管式多 Agent 服务，可在你启用的仓库中自动审查 PR。你可以手动修复发现项并推送；也可以在发现项下评论 @claude，让它继续完成闭环（前提是下文所述 GitHub Actions 已设置完成）。
• GitHub Actions：定义一个调用 Claude 和验证 Skill 的 job，让你本地运行的同一套检查在每次 push 或 PR 时执行。
• 规范验证：一种 Skill，用于把每项改动与仓库中的 Markdown 规范逐一对照，并尝试修复违规项。
• Claude Managed Agents（beta）中的 Rubrics：一项托管式 Agent 服务，使用独立的 grader agent 按 rubric 验证结果；失败后会自动回到返工环节。

编写验证闭环

如果在既有项目里，每次 Claude 帮你实现新功能后，你都会重复做同一类小修正，就该把这些步骤转化成自定义验证闭环。第一步，是把自己每次都会做的检查完整写下来。

新项目也是如此。如果你还在梳理项目应当如何表现，就用自然语言写一版最佳实践，写法应当像你在第一天交给新同事的工作说明。

如果难以准确说明检查本身，先让 Claude 提供一版最佳实践，再据此编辑即可。你的实际版本很可能只在少数具体细节上不同，而那些不同之处正是应被捕捉进闭环的内容。

实用提示： 这里的检查不一定是主观判断。例如，“拒绝任何未包含回填步骤却删除列的迁移”，就是通用 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 及其设计理念，请参阅《Claude Skills 构建完整指南》。

让检查方式匹配其运行位置

接下来需要决定的是：验证闭环如何触发。它可以独立运行、嵌入生产 Skill、串联多个 Skill，或绑定到 PR。

独立运行

在产物已经生成后，刻意手动调用。独立 Skill 适合并非每次都适用的跨领域检查，例如提交前安全扫描、提 PR 前的无障碍审计，或对整个仓库检查 license header。它们应该能在很多工作流中使用，但不必在每次代码改动时自动触发。

代价是每次调用仍要靠你自己记得。当你发现每次改动后都在运行它，就说明不应再把它当作独立步骤了：这项流程已经值得成为固定组成部分，应当嵌入或串联。

嵌入运行

嵌入式检查会作为产出 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 的描述或更早的指令没有把追加检查带入执行上下文。

嵌入式方式只适用于你能编辑的 Skill：例如自己写的 Skill，或安装在项目级、SKILL.md 由你控制的 Skill。内置 Skill 和由插件管理的 Skill（更新时可能被覆盖）不适合这种模式；此时应采用串联方式。

跨多个工作流的检查也不应嵌入，应保持为独立 Skill，以便从任何上下文调用。

串联运行

一个 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 上运行。无论队友是否记得调用这条链，他们的改动都会通过与你相同的门槛。这与已经写好的串联基础设施本质相同，只是再向前一步：使用相同的 Skills、相同的 Rubrics、相同的标准，而不依赖作者是否足够自觉。

此时，验证不再是个人基础设施，而成为团队基础设施。你为了每周省两分钟而写下的检查，现在会为团队中每个人、每一次改动都节省时间。不过，在串联仍频繁变化时，先不要设置覆盖全部 PR 的门禁，因为每次调整都会变成团队可见的事件。

无论要自动化什么、运行在哪种环境中，创建验证闭环的过程都一致：

1. 选出本周最常做的一项手动后续检查。
2. 先试用内置的 /verify Skill，看看它是否有助于你的流程。
3. 用自然语言写下这套过程，写法如同第一天交给新同事的说明。
4. 交给 skill-creator，或自行把 Markdown 文件放入 .claude/skills/。
5. 在新任务上调用它，确认检查会随输出执行；必要时继续迭代。
6. 尝试串联 Skills，形成端到端验证流程。

能编码给 Claude 遵循的内容越多，Claude 第一次回复就越可能接近你的预期。你不再需要反复调整的那些事项，会把注意力释放出来，投入到任何 Skill 都无法替你写下的、只属于你的工作中。

开始在 Claude Code 中使用验证闭环。

本文由 Claude Code 团队成员 Delba de Oliveira 撰写。