Claude Code · 官方博客解读 · 2026-07-22图号 GP-VLOOP · 验证挂载

一道检查
该挂在哪

Claude 写完代码,已经会自己盯类型、lint、测试、运行时报错。剩下那些只能靠手动做的检查,才是该编码成验证闭环的部分。难点不在要不要写,而在写好之后它挂在哪:从一个人的习惯,长成整个团队的闸门。

来源claude.com/blog · Delba de Oliveira 主线四种挂载法 · 一条成熟度阶梯续自《Getting started with loops》审核引文与代码块逐字核对

1从分类到挂载 2内置的 loop 3写成 skill 4四种挂载法 5固定流程

GenAI Playbook · 官方博客忠实还原 · 引文保留英文原句

起点 · 定位

不是「有哪几类 loop」,是这道检查该挂在哪

这篇官方博客由 Claude Code 团队的 Delba de Oliveira 撰写,发布于 2026-07-22。它是《Getting started with loops》的续篇:那篇给 loop 下定义、分四类、配原语,回答「有哪几类 loop」;这一篇不重复分类,只往下追问:把一道检查交给 Claude 自己跑之后,它该挂在哪,又怎么从个人习惯变成整个团队的闸门。

原文对 verification loop(验证闭环)只有一句定义:

In Claude Code, a verification loop is an iterative process where Claude checks and attempts to fix the work.

也就是 Claude 写完后会反复检查并尝试修正,不达标就再来一轮,而不是把没验的结果直接交回给人。它已经会关注代码库里的确定性信号,也就是有明确对错、不依赖主观判断的结果:类型检查、linter、测试、运行时报错。真正需要继续编码的,是 Claude 看不到、只能由人每次手动去查的那部分。作者认为,这些反复出现的人工检查,正适合写成验证闭环。

图 1 · agentic loop:验证是循环里的一环,不是收尾动作

姊妹篇

loop 到底有哪几类、各用哪个原语(Turn-based / Goal-based / Time-based / Proactive)、以及 /goal、/loop、/schedule 怎么选,是另一篇的主题。本篇默认你已经越过「该建哪类 loop」这一步,只讲「一道检查落地时挂在哪」。想先看分类,读《官方给 loop 下了定义:四层分类与对应原语》。

起点 · 别重复造轮子

动手之前,先看 Claude 已经内置了哪些

在自定义 loop 之前,原文建议先了解 Claude 已经内置了哪些支持,避免重复建设。这类内置验证支持共有 6 项,从本机自查到托管评分逐层加重。

内置能力	它做什么	状态
`/verify`	构建、运行并观察应用中的改动	内置
Toolchain	捕捉你提供的工具(如 linter)返回的错误码和警告并据此处理;把确切的 build/test 命令写进 `CLAUDE.md`,Claude 就不必自己推断	内置
Code Review	托管的多 agent 服务,自动审查已启用仓库的 PR;可手动修复 finding 后 push,或在 finding 下评论 `@claude` 闭环	research preview
GitHub Actions	定义一个 job 用验证 skill 调 Claude,本地那套检查在每次 push/PR 时同样运行	内置
Spec validation	一个 skill,拿 repo 里的 markdown 规格逐条核对每处改动,找出违规并尝试修复	内置
Managed Agents rubrics	用一个独立的 grader(评分员)agent 按 rubric 验产出,未通过则自动退回重做	beta

rubric = 打分标准;grader agent = 独立的评分员 agent。这两项在 Claude Managed Agents 里。

落地 · 从习惯到 skill

每次都在做的小修正,就该写成 skill

作者给的判断标准很直接:每次 Claude 实现新功能后,如果人都在做同样的小修正,就该把这些步骤变成自己的验证 loop。第一步就是把每次都会做的事列出来。

新项目也适用同样的方法:用平实语言写出理想工作方式,the way you'd hand it to a new teammate on day one,也就是像新同事入职第一天那样把步骤交代清楚。如果暂时写不清检查规则,可以先让 Claude 给出一版最佳实践,再根据项目情况修改。通用做法与项目做法之间通常只有少数差异,而这些差异正是 skill 要准确捕捉的东西。

Pro tip · 检查不必是主观质量类的

"Reject any migration that drops a column without a backfill step":任何删除字段却没有 backfill(回填)步骤的 migration 都应被拒绝。这是一条确定性规则,通用 linter 抓不到,项目级 skill 却能检查。原文一句话收口:Anything you keep having to enforce by hand as a manual check qualifies for capture as a loop.(凡是需要反复用手工强制执行的检查,都值得固化成一个 loop。)

最常见的实现方式是写成 skill。最快的路径是装 skill-creator 插件,让 Claude 反过来访谈你的工作流,再帮你把 skill 写出来:

      skill-creator
/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.
    

也可以直接手写,把 markdown 文件放进 .claude/skills/。一个最简单的验证 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.
    

落地 · 核心

挂在哪:四种方式,一条成熟度阶梯

接下来要定的是这个验证 loop 怎么被触发。原文给了四种:standalone、embedded、chained、on every PR。它们不是并列的选项,而是一条从手动到自动、从个人习惯到团队基础设施的阶梯,每一级都有明确的「该升级了」的信号。

挂载方式	触发	适合	升级信号 / 边界
standalone 独立手动	产物已存在后刻意手动调用	不必每次都跑的横切检查(安全扫描 / 无障碍审计 / license header)	开始每次改动后都在跑它 → 应嵌入或链式
embedded 嵌入生产者	作为生产 skill 的一部分自动触发	只属于某一个工作流的检查	仅适用于可修改的 skill;不可修改的改用 chain
chained 链式	一个 skill 结束时调下一个	多个验证交接串成端到端	各步足够独立时不必链;会增加 token,宜先测
on every PR 团队闸门	链路稳定后挂到每个 PR	不依赖作者自觉的团队级标准	链路仍在调整时不宜上;每次调整全团队可见

Standalone · 独立手动触发

在产物已经存在之后刻意手动调用。它适合那些不必每次都跑的横切检查:提交前的安全扫描、开 PR 前的无障碍审计、整个 repo 的 license header 校验。这类检查可以用在许多工作流里,但不必在每次代码改动后触发。代价是每次调用都得有人记得去做。升级信号很明确:

The signal that you've outgrown standalone is when you're running it after every change.

当它已经跟在每次改动后面运行,就该给这道流程一个固定位置:嵌进去,或者链起来。

Embedded · 嵌进生产者 skill

作为「生产那个产物的 skill」的一部分自动触发。这道检查只属于某一个特定工作流,而这个工作流现在无需额外指令就会自己跑它。最简单的形态是往生产者 skill 正文末尾追加一行。下面这个 scaffold-component 的例子,末尾加了「创建完组件文件后,先跑 eslint、修完错误再报完成」:

      .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//`:

1. `.tsx`: function component with a typed props interface and a default export.
2. `.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 的 description 或前面的指令没把追加的检查纳入流程。边界在于,embedded 只适用于可修改的 skill(自己编写的,或项目级、SKILL.md 在你手里的);内置 skill 和由插件管理、更新时会被覆盖的 skill 不适用,这类要改用 chain。跨多个工作流的检查也更适合保留为 standalone,以便在任何 context 中单独调用。

Chained · 链式:把习惯写成契约

一个 skill 在自己结束时调下一个,几个「验过的交接」串起来端到端跑。Anthropic Claude Code 团队日常就用这种模式,下面是一条真实链路:

图 2 · Anthropic CC 团队日常链路:/code-review → /simplify → /verify →(碰 UI 时)/design

原文这句可直接引用:/code-review hunts for bugs, /simplify cleans up the diff, a /verify skill confirms end-to-end behavior, and a custom /design skill checks against guidelines in a DESIGN.md file if the change touched UI. 其中 DESIGN.md 是团队存放设计规范的 markdown 文件。

链式也是给无法修改的 skill 加验证的办法:建一个 wrapper(包装)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.
    

这一步的关键,是把个人习惯写成了流程契约:

What started as a habit ("I always run /verify after /simplify") becomes a contract ("/simplify always runs /verify when it finishes").

链路能自行跑完整个开发循环,只有某个环节把问题抛回来时,才需要人工介入。代价是灵活性下降,也会增加 token 消耗;各步足够独立、有时需要单跑其中一个时,就不必强行串联。广泛部署前最好先测一测实际开销。

On every PR · 从个人基建变成团队基建

链路在自己的改动上稳定之后,同一套流程可以挂到每个 PR 上。队友的改动过的是同一道闸,无论作者是否记得触发;同样的 skill、同样的 rubric、同样的标准,不再依赖个人自觉。作者用一句话概括这一跃迁:

This is where verification stops being personal infrastructure and becomes team infrastructure.

这道检查最初只是帮你自己每周省两分钟,如今在每次改动上为团队里每个人省下同样的两分钟。边界在于:链路仍在频繁调整时,不宜过早升级为 PR 级闸门,因为每次调整都会变成一个全团队可见的事件。

收口 · 固定流程

无论自动化什么,创建流程是同一套

流程稳了就能扩展你的 loop engineering。原文给的这套验证 loop 创建流程是固定的,不管你自动化的是什么、在什么环境:

挑最频繁的那个手动动作

挑出你这周做得最频繁的那个手动收尾动作。

先试内置 /verify

先试试内置的 /verify skill,看它对你的流程有没有帮助。

用平实语言写下来

用平实的语言把这道流程写下来,像入职第一天交给新同事那样。

交给 skill-creator 或自己写

把它交给 skill-creator,或者自己把 markdown 文件放进 .claude/skills/。

在新任务上验证

在一个新任务上调用它,确认这道检查作为输出的一部分执行了,需要时再迭代。

试着链起来

试着做 skill 链式串联,搭出一条端到端的验证流。

能交给 Claude 遵循的规则越多,它第一次给出的结果就越可能接近你想要的样子。那些原本要你反复手动修正的细节交给 skill 之后,注意力就腾了出来,可以留给那些写不进任何 skill、只能由你自己完成的工作。

一道检查该挂在哪