1. 为什么提交前总在补验证写代码最怕的不是写不出来而是写完觉得没问题提交后 CI 红了一片。构建挂了、类型报错、lint 警告堆成山、测试覆盖率不达标这些问题如果等到 PR 阶段才暴露返工成本会翻好几倍。我见过太多团队把验证动作全压在 CI 上本地开发时只跑一个npm run dev看页面能打开就算完事结果每次合并都像开盲盒。Claude Code 里的 verification-loop 技能本质上是把「提交前该做的事」固化成一个可重复执行的循环。它覆盖构建验证、类型检查、代码检查、测试套件、安全扫描、差异审查六个阶段每个阶段都有明确的通过标准和失败处理策略。你不需要记住每次要跑哪些命令只要触发这个技能它会按顺序走完整个验证流程最后给你一份结构化的验证报告。这个技能适合谁适合所有在本地做功能开发、需要频繁提交代码的工程师。尤其是 TypeScript 项目、Python 项目或者任何有构建步骤和测试套件的工程。如果你经常遇到「本地能跑、CI 挂掉」的情况或者团队里有人总忘记跑 lint 就提交那这套配置值得花二十分钟落地。接下来我会给出可复制的 settings.json 骨架、TaoToken 统一 Key 的接入方式以及一条命令验证循环是否生效。整个过程不需要你改项目源码只动 Claude Code 的配置。2. TaoToken 前置统一 Key 与 API 通道verification-loop 本身是 Claude Code 的技能配置但它执行验证命令时如果涉及调用模型能力比如让 Claude 分析类型错误、生成修复建议就需要一个稳定的 API 通道。TaoToken 在这里的角色是统一入口你不需要在多个模型供应商之间切换 Key也不用担心某个通道突然限流导致验证中断。TaoToken 的官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数直接用于配置。你需要先拿到一个 API Key。进入控制台创建 Key 的路径是https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。创建后复制 Key后面配置里会用到。如果你还没决定用哪个模型可以先在模型对话页面测试一下通道是否通畅https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。输入一句简单的话看是否能正常返回。这一步能排除 Key 无效或网络配置错误的问题。对于长期做编码和 Agent 任务的团队Coding Plan 页面有更详细的套餐说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。不过 verification-loop 的日常使用对额度消耗不大按量付费的 Key 就够用。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有不同语言和工具的配置示例。API Keys 管理页面是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 可以随时查看和轮换 Key。注意不要把 Key 硬编码在项目源码里。verification-loop 的安全扫描阶段会检查sk-开头的字符串和api_key关键字硬编码会导致安全扫描失败。正确做法是放在环境变量或 Claude Code 的本地配置中。3. 可复制配置settings.json 骨架与技能挂载Claude Code 的配置通常放在项目根目录的.claude/settings.json或者用户级的~/.claude/settings.json。verification-loop 技能需要两部分配置一是技能本身的定义二是 API 通道的环境变量。先看技能定义。在.claude/skills/目录下创建verification-loop.md内容如下--- name: verification-loop description: 提交前全面验证构建、类型检查、lint、测试、安全扫描、差异审查 trigger: - after_feature_complete - before_pr - after_refactor - quality_gate --- # Verification Loop 按顺序执行以下阶段任一阶段失败则停止并报告。 ## 阶段1构建验证 bash npm run build 21 | tail -20失败则停止修复后重新触发。阶段2类型检查npx tsc --noEmit 21 | head -30报告所有类型错误关键错误必须修复。阶段3代码检查npm run lint 21 | head -30记录警告数量重要警告需修复。阶段4测试套件npm run test -- --coverage 21 | tail -50覆盖率目标 80%低于目标需补充测试。阶段5安全扫描grep -rn sk- --include*.ts --include*.js . 2/dev/null | head -10 grep -rn api_key --include*.ts --include*.js . 2/dev/null | head -10 grep -rn console.log --include*.ts --include*.tsx src/ 2/dev/null | head -10发现密钥泄露立即修复。阶段6差异审查git diff --stat git diff HEAD~1 --name-only审查每个变更文件确认无意外变更。输出格式VERIFICATION REPORT Build: [PASS/FAIL] Types: [PASS/FAIL] (X errors) Lint: [PASS/FAIL] (X warnings) Tests: [PASS/FAIL] (X/Y passed, Z% coverage) Security:[PASS/FAIL] (X issues) Diff: [X files changed] Overall: [READY/NOT READY] for PR然后在 .claude/settings.json 中挂载技能并配置 API 通道 json { skills: { verification-loop: { enabled: true, path: .claude/skills/verification-loop.md } }, env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的TaoToken Key }, hooks: { PostToolUse: [ { matcher: Write|Edit, command: echo 代码已修改建议运行 /verify 触发验证循环 } ] } }如果你用的是 Claude Code 的 Anthropic 兼容模式环境变量名可能是ANTHROPIC_AUTH_TOKEN或ANTHROPIC_API_KEY具体看接入文档的说明。ClaudeCodeAnthropic 的配置页面在 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude-code-anthropicutm_campaignrewrite 里面有完整的参数对照表。提示settings.json 里的env字段会覆盖系统环境变量。如果你已经在 shell 里 export 了 Key这里可以省略避免重复配置导致冲突。配置完成后重启 Claude Code 会话技能就会生效。你可以用/skills命令查看已加载的技能列表确认 verification-loop 在列。4. 验证请求一条命令确认循环生效配置写好了怎么确认它真的在工作最直接的方式是触发一次验证循环看它是否按阶段输出报告。在 Claude Code 会话中输入/verify如果技能挂载成功你会看到它依次执行构建、类型检查、lint、测试、安全扫描、差异审查最后输出一份 VERIFICATION REPORT。每个阶段的结果会实时显示失败的阶段会标红并给出错误摘要。如果你想更精确地测试某个阶段可以单独触发。比如只跑类型检查/verify --stage types或者跳过测试阶段本地快速验证时有用/verify --skip tests实测下来一个中等规模的 TypeScript 项目完整跑完六个阶段大约需要 30 到 90 秒取决于测试套件的执行时间。如果构建和类型检查都通过但测试覆盖率不达标报告里会明确写出当前覆盖率和目标值的差距。验证循环生效的另一个标志是 PostToolUse hook。当你用 Claude Code 修改了文件后hook 会输出提示「代码已修改建议运行 /verify 触发验证循环」。这个提示不会自动执行验证只是提醒你该跑了。如果你希望自动触发可以把 hook 的 command 改成直接调用验证脚本但我不建议这么做——自动跑验证会拖慢编辑节奏手动触发更可控。注意/verify命令是技能定义的触发词不是 Claude Code 的内置命令。如果你的会话里输入后没有反应检查技能文件是否放在了正确的路径以及 settings.json 里的skills字段是否拼写正确。5. 本篇常见错排查配置 verification-loop 时最容易踩的坑集中在路径、权限和命令兼容性上。下面列出几个我遇到过的典型问题。技能不生效输入 /verify 无反应。首先检查.claude/skills/verification-loop.md是否存在文件名是否完全匹配。然后看 settings.json 里的path字段是否指向了正确位置。如果用的是用户级配置路径要写绝对路径比如/Users/yourname/.claude/skills/verification-loop.md。项目级配置可以用相对路径但相对于项目根目录。构建阶段报错「command not found」。这是因为 Claude Code 执行命令时的 shell 环境和你终端里的不一样。npm或pnpm可能不在 PATH 里。解决办法是在技能文件里用绝对路径或者先在 settings.json 的env里补充 PATH。更简单的做法是确保项目根目录有package.json并且你用的包管理器在系统 PATH 中可用。类型检查通过但 CI 仍然报类型错误。检查tsconfig.json的include和exclude配置。npx tsc --noEmit只会检查 tsconfig 覆盖的文件。如果 CI 用了不同的 tsconfig 或者额外的类型检查步骤本地验证循环需要同步配置。可以在技能文件里加一条npx tsc --noEmit -p tsconfig.ci.json来对齐。安全扫描误报。grep -rn api_key会匹配到变量名、注释、文档字符串里的api_key不一定是真的密钥泄露。如果误报太多可以把 grep 模式改得更精确比如grep -rn api_key\s*\s*[\]sk-。或者把安全扫描阶段改成可选的只在 PR 前跑。测试覆盖率不达标但不知道缺哪些文件。npm run test -- --coverage的输出里通常有每个文件的覆盖率明细。如果输出被tail -50截断了可以临时改成tail -100或者把完整输出写到文件里再查看。Jest 项目可以加--coverageReporterstext让报告更紧凑。差异审查阶段显示的文件数不对。git diff HEAD~1 --name-only比较的是最近一次提交和上一次提交的差异。如果你还没提交这个命令不会显示工作区的变更。应该用git diff --name-only查看未暂存的变更或者git diff --cached --name-only查看已暂存的变更。技能文件里可以同时保留这两条命令。API 调用超时或返回 401。检查 TaoToken 的 Key 是否有效以及ANTHROPIC_BASE_URL是否配置为https://taotoken.net/api。如果 Key 没问题但仍然 401可能是环境变量名不对。Claude Code 不同版本对环境变量的读取优先级不同建议在 settings.json 的env里显式设置而不是依赖 shell export。排障时如果涉及 API 通道问题可以到 API Keys 页面重新生成一个 Key 测试https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。接入文档里也有常见错误码的说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。6. 把验证循环固化进日常流程verification-loop 的价值不在于它跑了多少命令而在于它把「提交前该做什么」变成了一个不需要思考的固定动作。你不需要每次手动敲六条命令也不需要记住覆盖率目标是多少。触发一次报告出来该修的修该过的过。对于团队协作我建议把技能文件提交到项目仓库的.claude/skills/目录下这样每个成员拉取代码后都能用同一套验证标准。settings.json 里的 API Key 不要提交用环境变量或者本地覆盖的方式配置。可以在 README 里写一句「运行 /verify 后再提交」比写十页规范文档都管用。如果你还在用「本地跑一下 dev server 就提交」的流程不妨花二十分钟把 verification-loop 配起来。第一次跑可能会暴露一堆历史遗留的类型错误和 lint 警告但修完之后CI 的红灯会少很多。长期来看这二十分钟的投入回报率很高。最后提醒一点验证循环是辅助工具不是替代品。它帮你发现构建失败、类型错误、测试不通过这些机械性问题但代码逻辑是否正确、边界情况是否覆盖仍然需要你自己判断。差异审查阶段就是留给人工确认的别跳过。
【IT研发实用Skill】verification-loop 技能：Claude Code 构建验证与类型检查配置实战
1. 为什么提交前总在补验证写代码最怕的不是写不出来而是写完觉得没问题提交后 CI 红了一片。构建挂了、类型报错、lint 警告堆成山、测试覆盖率不达标这些问题如果等到 PR 阶段才暴露返工成本会翻好几倍。我见过太多团队把验证动作全压在 CI 上本地开发时只跑一个npm run dev看页面能打开就算完事结果每次合并都像开盲盒。Claude Code 里的 verification-loop 技能本质上是把「提交前该做的事」固化成一个可重复执行的循环。它覆盖构建验证、类型检查、代码检查、测试套件、安全扫描、差异审查六个阶段每个阶段都有明确的通过标准和失败处理策略。你不需要记住每次要跑哪些命令只要触发这个技能它会按顺序走完整个验证流程最后给你一份结构化的验证报告。这个技能适合谁适合所有在本地做功能开发、需要频繁提交代码的工程师。尤其是 TypeScript 项目、Python 项目或者任何有构建步骤和测试套件的工程。如果你经常遇到「本地能跑、CI 挂掉」的情况或者团队里有人总忘记跑 lint 就提交那这套配置值得花二十分钟落地。接下来我会给出可复制的 settings.json 骨架、TaoToken 统一 Key 的接入方式以及一条命令验证循环是否生效。整个过程不需要你改项目源码只动 Claude Code 的配置。2. TaoToken 前置统一 Key 与 API 通道verification-loop 本身是 Claude Code 的技能配置但它执行验证命令时如果涉及调用模型能力比如让 Claude 分析类型错误、生成修复建议就需要一个稳定的 API 通道。TaoToken 在这里的角色是统一入口你不需要在多个模型供应商之间切换 Key也不用担心某个通道突然限流导致验证中断。TaoToken 的官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数直接用于配置。你需要先拿到一个 API Key。进入控制台创建 Key 的路径是https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。创建后复制 Key后面配置里会用到。如果你还没决定用哪个模型可以先在模型对话页面测试一下通道是否通畅https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。输入一句简单的话看是否能正常返回。这一步能排除 Key 无效或网络配置错误的问题。对于长期做编码和 Agent 任务的团队Coding Plan 页面有更详细的套餐说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。不过 verification-loop 的日常使用对额度消耗不大按量付费的 Key 就够用。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有不同语言和工具的配置示例。API Keys 管理页面是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 可以随时查看和轮换 Key。注意不要把 Key 硬编码在项目源码里。verification-loop 的安全扫描阶段会检查sk-开头的字符串和api_key关键字硬编码会导致安全扫描失败。正确做法是放在环境变量或 Claude Code 的本地配置中。3. 可复制配置settings.json 骨架与技能挂载Claude Code 的配置通常放在项目根目录的.claude/settings.json或者用户级的~/.claude/settings.json。verification-loop 技能需要两部分配置一是技能本身的定义二是 API 通道的环境变量。先看技能定义。在.claude/skills/目录下创建verification-loop.md内容如下--- name: verification-loop description: 提交前全面验证构建、类型检查、lint、测试、安全扫描、差异审查 trigger: - after_feature_complete - before_pr - after_refactor - quality_gate --- # Verification Loop 按顺序执行以下阶段任一阶段失败则停止并报告。 ## 阶段1构建验证 bash npm run build 21 | tail -20失败则停止修复后重新触发。阶段2类型检查npx tsc --noEmit 21 | head -30报告所有类型错误关键错误必须修复。阶段3代码检查npm run lint 21 | head -30记录警告数量重要警告需修复。阶段4测试套件npm run test -- --coverage 21 | tail -50覆盖率目标 80%低于目标需补充测试。阶段5安全扫描grep -rn sk- --include*.ts --include*.js . 2/dev/null | head -10 grep -rn api_key --include*.ts --include*.js . 2/dev/null | head -10 grep -rn console.log --include*.ts --include*.tsx src/ 2/dev/null | head -10发现密钥泄露立即修复。阶段6差异审查git diff --stat git diff HEAD~1 --name-only审查每个变更文件确认无意外变更。输出格式VERIFICATION REPORT Build: [PASS/FAIL] Types: [PASS/FAIL] (X errors) Lint: [PASS/FAIL] (X warnings) Tests: [PASS/FAIL] (X/Y passed, Z% coverage) Security:[PASS/FAIL] (X issues) Diff: [X files changed] Overall: [READY/NOT READY] for PR然后在 .claude/settings.json 中挂载技能并配置 API 通道 json { skills: { verification-loop: { enabled: true, path: .claude/skills/verification-loop.md } }, env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的TaoToken Key }, hooks: { PostToolUse: [ { matcher: Write|Edit, command: echo 代码已修改建议运行 /verify 触发验证循环 } ] } }如果你用的是 Claude Code 的 Anthropic 兼容模式环境变量名可能是ANTHROPIC_AUTH_TOKEN或ANTHROPIC_API_KEY具体看接入文档的说明。ClaudeCodeAnthropic 的配置页面在 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude-code-anthropicutm_campaignrewrite 里面有完整的参数对照表。提示settings.json 里的env字段会覆盖系统环境变量。如果你已经在 shell 里 export 了 Key这里可以省略避免重复配置导致冲突。配置完成后重启 Claude Code 会话技能就会生效。你可以用/skills命令查看已加载的技能列表确认 verification-loop 在列。4. 验证请求一条命令确认循环生效配置写好了怎么确认它真的在工作最直接的方式是触发一次验证循环看它是否按阶段输出报告。在 Claude Code 会话中输入/verify如果技能挂载成功你会看到它依次执行构建、类型检查、lint、测试、安全扫描、差异审查最后输出一份 VERIFICATION REPORT。每个阶段的结果会实时显示失败的阶段会标红并给出错误摘要。如果你想更精确地测试某个阶段可以单独触发。比如只跑类型检查/verify --stage types或者跳过测试阶段本地快速验证时有用/verify --skip tests实测下来一个中等规模的 TypeScript 项目完整跑完六个阶段大约需要 30 到 90 秒取决于测试套件的执行时间。如果构建和类型检查都通过但测试覆盖率不达标报告里会明确写出当前覆盖率和目标值的差距。验证循环生效的另一个标志是 PostToolUse hook。当你用 Claude Code 修改了文件后hook 会输出提示「代码已修改建议运行 /verify 触发验证循环」。这个提示不会自动执行验证只是提醒你该跑了。如果你希望自动触发可以把 hook 的 command 改成直接调用验证脚本但我不建议这么做——自动跑验证会拖慢编辑节奏手动触发更可控。注意/verify命令是技能定义的触发词不是 Claude Code 的内置命令。如果你的会话里输入后没有反应检查技能文件是否放在了正确的路径以及 settings.json 里的skills字段是否拼写正确。5. 本篇常见错排查配置 verification-loop 时最容易踩的坑集中在路径、权限和命令兼容性上。下面列出几个我遇到过的典型问题。技能不生效输入 /verify 无反应。首先检查.claude/skills/verification-loop.md是否存在文件名是否完全匹配。然后看 settings.json 里的path字段是否指向了正确位置。如果用的是用户级配置路径要写绝对路径比如/Users/yourname/.claude/skills/verification-loop.md。项目级配置可以用相对路径但相对于项目根目录。构建阶段报错「command not found」。这是因为 Claude Code 执行命令时的 shell 环境和你终端里的不一样。npm或pnpm可能不在 PATH 里。解决办法是在技能文件里用绝对路径或者先在 settings.json 的env里补充 PATH。更简单的做法是确保项目根目录有package.json并且你用的包管理器在系统 PATH 中可用。类型检查通过但 CI 仍然报类型错误。检查tsconfig.json的include和exclude配置。npx tsc --noEmit只会检查 tsconfig 覆盖的文件。如果 CI 用了不同的 tsconfig 或者额外的类型检查步骤本地验证循环需要同步配置。可以在技能文件里加一条npx tsc --noEmit -p tsconfig.ci.json来对齐。安全扫描误报。grep -rn api_key会匹配到变量名、注释、文档字符串里的api_key不一定是真的密钥泄露。如果误报太多可以把 grep 模式改得更精确比如grep -rn api_key\s*\s*[\]sk-。或者把安全扫描阶段改成可选的只在 PR 前跑。测试覆盖率不达标但不知道缺哪些文件。npm run test -- --coverage的输出里通常有每个文件的覆盖率明细。如果输出被tail -50截断了可以临时改成tail -100或者把完整输出写到文件里再查看。Jest 项目可以加--coverageReporterstext让报告更紧凑。差异审查阶段显示的文件数不对。git diff HEAD~1 --name-only比较的是最近一次提交和上一次提交的差异。如果你还没提交这个命令不会显示工作区的变更。应该用git diff --name-only查看未暂存的变更或者git diff --cached --name-only查看已暂存的变更。技能文件里可以同时保留这两条命令。API 调用超时或返回 401。检查 TaoToken 的 Key 是否有效以及ANTHROPIC_BASE_URL是否配置为https://taotoken.net/api。如果 Key 没问题但仍然 401可能是环境变量名不对。Claude Code 不同版本对环境变量的读取优先级不同建议在 settings.json 的env里显式设置而不是依赖 shell export。排障时如果涉及 API 通道问题可以到 API Keys 页面重新生成一个 Key 测试https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。接入文档里也有常见错误码的说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。6. 把验证循环固化进日常流程verification-loop 的价值不在于它跑了多少命令而在于它把「提交前该做什么」变成了一个不需要思考的固定动作。你不需要每次手动敲六条命令也不需要记住覆盖率目标是多少。触发一次报告出来该修的修该过的过。对于团队协作我建议把技能文件提交到项目仓库的.claude/skills/目录下这样每个成员拉取代码后都能用同一套验证标准。settings.json 里的 API Key 不要提交用环境变量或者本地覆盖的方式配置。可以在 README 里写一句「运行 /verify 后再提交」比写十页规范文档都管用。如果你还在用「本地跑一下 dev server 就提交」的流程不妨花二十分钟把 verification-loop 配起来。第一次跑可能会暴露一堆历史遗留的类型错误和 lint 警告但修完之后CI 的红灯会少很多。长期来看这二十分钟的投入回报率很高。最后提醒一点验证循环是辅助工具不是替代品。它帮你发现构建失败、类型错误、测试不通过这些机械性问题但代码逻辑是否正确、边界情况是否覆盖仍然需要你自己判断。差异审查阶段就是留给人工确认的别跳过。
