🏠 总目录 📚 资料库Claude Code 实践

Building Verification Loops in Claude Code with Skills（用 skills 在 Claude Code 中构建验证循环）

📄 来自 Claude 官方博客
原文标题
Building Verification Loops in Claude Code with Skills（用 skills 在 Claude Code 中构建验证循环）
原文链接
https://claude.com/blog/building-verification-loops-in-claude-code-with-skills
作者
Delba de Oliveira（Claude Code 团队）
发布日期
2026-07-22
⚠️ 本页是原文的中文结构化整理笔记（保留架构、数据、案例、结论），并非逐字翻译。具体参数与功能名更新很快，落地前请点击上方链接核对原文。

⏱ 12 分钟 ｜ 🔁 把「怎么验收」也打包进去

🎯 一句话

Skill 不只装「怎么做」，更该装「怎么确认做对了」。⭐ 把验证步骤写进 Skill，Agent 就能自己跑完「做→验→改」的闭环，而不需要人在中间盯着。

📑 本页目录

把重复的手动检查步骤编码成可复用的 skill，就能变成自动化的验证循环——让 Claude 自我纠错、自主迭代，开发者得以专注于更高层的工作。

验证循环如何工作

Agent 开发工作流有三个阶段：收集上下文 → 采取行动 → 验证结果。除了类型检查、测试这些确定性信号，团队还可以创建 Claude 自动运行的自定义检查。

内置验证机制（/verify skill、GitHub Actions 集成、Code Review 工具）之外，团队可以针对自己的需求设计自定义验证循环。

配置示例

独立的验证 skill（日志规范检查）：

# .claude/skills/verify-log-hygiene/SKILL.md
---
name: verify-log-hygiene
description: "检查错误日志包含 request ID 且绝不……"
allowed-tools: [Read, Edit, Grep]
---
读取当前 diff 中的错误处理路径。
对错误路径上的每个日志调用，确认它包含 request ID
且没有传入请求体……

链式调用多个验证：

# .claude/skills/safe-refactor/SKILL.md
先对当前 diff 运行 /simplify。
/simplify 完成后，调用 /verify-no-public-api-changes。

四种部署方式

方式 说明 适用
独立（Standalone） 手动调用 横切性检查——安全扫描、许可证核验
嵌入（Embedded） 作为某个工作流的一部分自动执行 单一工作流内的检查（如脚手架 skill 末尾追加 eslint 验证）
链式（Chained） 一个 skill 完成后调用下一个 端到端验证
PR 级（PR-wide） 基础设施层面应用到团队所有 PR 全员强制的检查

最佳实践

  1. 从观察开始： 找出你经常手动做的检查，然后用平实的英语把流程写下来——就像讲给新同事听
  2. 用 skill-creator： 借助 skill-creator 插件引导式开发，而非手写 markdown
  3. 部署方式匹配范围： 检查适用于一个工作流（嵌入）、多个工作流（链式）、还是所有变更（PR 级）
  4. 捕捉确定性规则： 项目专属的检查（如「拒绝没有回填就删列的迁移」）非常适合做成验证循环，即使通用 linter 抓不到
  5. 先测试再扩大： 确认嵌入式检查确实在 skill 输出中触发了，再去部署链式或 PR 级验证
  6. 平衡自动化与灵活性： 步骤真正独立时不要强行链式——链式会增加 token 消耗、降低开发者的控制力

结论

通过 skills 把验证系统化，团队能减少手工投入、提升一致性。从独立检查 → 嵌入流程 → 链式工作流 → 团队基础设施的演进路径，代表了走向自动化、自纠错开发流程的进化。这让 Claude 能自己闭合反馈环，开发者则专注于 skill 无法捕捉的创造性判断工作。

✅ 检查点

  1. 为什么 Skill 里应该包含验证步骤？
  2. 一个好的验证步骤应该满足什么条件？
  3. 这种「自带验证的 Skill」适合什么场景？
👀 答案
  1. 因为没有验证的 Skill 只能保证「按流程做了」，不能保证「做对了」。把验证写进去之后，Agent 能自己发现失败并重试，闭环从「人来检查」变成「机器来检查」，才可能无人值守。
  2. ⭐ 必须是客观的、可自动执行的、返回明确成败信号的。比如跑测试、执行 lint、比对输出格式、检查文件是否生成。⚠️ 「让模型自己看一眼对不对」不算验证——那还是模型的自我评价（和循环工程那一章同一个道理）。
  3. 重复性高、验收标准明确、失败可回滚的场景：代码迁移、格式转换、批量重构、按规范生成文件。⭐ 判据是：你能不能写出一段代码来判断这次做得对不对——能写出来，就能做成自带验证的 Skill。

🛑 可以停在这里

⚡ 走神救援
⭐Skill 不只装「怎么做」，更该装「怎么确认做对了」——没有验证的 Skill 只能保证「按流程做了」不能保证「做对了」；写进验证后 Agent 能自己发现失败并重试，闭环从「人来检查」变成「机器来检查」，才可能无人值守。⭐好的验证步骤必须客观、可自动执行、返回明确成败信号（跑测试/执行 lint/比对格式/检查文件是否生成）；⚠️「让模型自己看一眼对不对」不算验证——那还是自我评价。适合场景：重复性高、验收标准明确、失败可回滚（代码迁移、格式转换、批量重构）；⭐判据是「你能不能写出一段代码判断这次做得对不对」。