1. 为什么你的 Claude Code 总是“写完还要你擦屁股”

先说一个我踩过的坑。上个月重构一个订单模块，让 Claude Code 帮我改OrderService.ts，它三下五除二写完，我一看代码结构挺漂亮，直接提交。结果 CI 挂了——类型报错、两个单测失败、还有个 ESLint 的no-unused-vars。回头翻对话记录，它其实“知道”自己改了哪些文件，但它不知道这些改动有没有破坏别的东西。这就是典型的“人驱动”流程：AI 生成代码，你手动跑 lint，发现错误，再告诉 AI 修复，AI 改完你再跑测试……你成了质量检查员，来回沟通三四轮，精力全耗在传话上。

Claude Code 的 Auto-Verification（自动验证）要解决的就是这件事。简单说，它让 AI 在每次修改代码后，自己运行 Lint、类型检查、单元测试，根据报错结果自我修正，直到所有检查通过才向你报告“任务完成”。你从“质量检查员”变成“验收员”，只看最终结果。这套机制适合所有需要代码质量保障的场景——尤其是你已经在用 Claude Code 做日常开发、但每次都要手动跑验证命令的人。核心检索词就三个：Claude Code、Auto-Verification、验证闭环。搞懂这三个，你就能把“写了再改”变成“写完即好”。

自动验证的价值链其实很直白：代码生成 → Lint 检查 → 类型检查 → 单元测试 → 全部通过。中间任何一环失败，AI 自己读报错、自己改、自己重跑。它和传统流程最大的区别在于反馈延迟——你手动跑一次测试可能要等几分钟才发现问题，而 AI 在同一个会话里秒级感知、立即修正。遗漏风险也低得多，因为每次修改都会完整执行你配置的验证流水线，不会像人一样“这次忘了跑 typecheck”。

但这里有个前提：你得把验证流水线配对。配错了，要么 AI 陷入无限重试，要么验证命令本身把代码改得面目全非。下面我从最小配置开始，一步步把可复制的 settings 片段、hooks、pass@k 模式讲清楚，最后用一个完整的“验证失败 → 修复 → 重跑”闭环演示收尾。

2. TaoToken 前置：把模型通道和验证环境准备好

在配 Auto-Verification 之前，得先保证 Claude Code 能稳定调用模型。我实测下来，用 TaoToken 做模型通道比较省心，它的 API 兼容 Anthropic 格式，Claude Code 直接改 Base URL 就能接。官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api ，注意 API 地址后面不加 UTM 参数。

具体操作分三步。第一步，去控制台创建一个 API Key，地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，创建完复制那串sk-开头的 Key。第二步，如果你用 Claude Code CLI，在项目根目录的.claude/settings.json里配置环境变量，或者直接在 shell 里 export。我习惯写在 settings 里，团队协作时不会漏。第三步，确认模型 ID，Claude Code 默认走claude-sonnet-4-5这类 ID，TaoToken 的模型列表在文档里能查到，地址是 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。

这里要提醒一句：Auto-Verification 会频繁触发模型调用（每次验证失败都要 AI 分析报错、生成修复），所以通道稳定性比平时更重要。如果 Key 额度不够或者通道抖动，验证循环跑到一半断了，AI 会卡在“等待响应”状态。我建议先在模型对话页面 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 发一条测试消息，确认通道通了再往下配。

另外，如果你打算长期用 Claude Code 做编码和 Agent 任务，可以看下 Coding Plan，地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite ，它针对高频编码场景做了额度优化，比按量计费更适合 Auto-Verification 这种“多轮验证”的用法。API Keys 管理页在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ，方便你随时轮换 Key。

环境准备好之后，验证一下 Claude Code 能不能正常对话。在终端跑claude进入交互模式，输入“列出当前目录的文件”，如果它能正常返回，说明通道没问题。这一步别跳过，我见过有人直接配 Auto-Verification，结果验证失败时 AI 根本没连上模型，报错信息全是超时，排查了半天才发现是 Key 没生效。

3. 可复制配置：settings.json 与 hooks 完整片段

现在进入正题。Claude Code 的 Auto-Verification 配置主要写在.claude/settings.json里。最小化启动只要两行：

{ "effort": "xhigh", "autoVerify": true }

effort: "xhigh"是让模型用最强推理档位，保证修复质量；autoVerify: true是开启自动验证。这两行下去，Claude Code 会按优先级自动检测你项目里的验证工具：先读package.json的 scripts，找lint、typecheck、test；找不到就读配置文件，比如eslint、prettier --check、tsc --noEmit；再找不到就用你自定义的verification.commands。

但自动检测有个问题：它可能跑全量测试，慢得让你怀疑人生。所以实际项目里我建议直接写自定义流水线。下面是我在一个 TypeScript + Vitest 项目里用的完整配置，你可以直接复制改路径：

{ "effort": "xhigh", "autoVerify": true, "verification": { "commands": [ "prettier --check 'src/**/*.{ts,tsx}'", "tsc --noEmit", "eslint 'src/**/*.{ts,tsx}' --cache --cache-location .eslintcache", "vitest --run --changed" ], "maxRetries": 3, "failFast": true, "parallel": false, "mode": "pass@3" }, "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "echo '文件已修改，触发自动验证流水线'" } ] } ] } }

逐字段说清楚。commands是按顺序执行的验证命令数组，顺序很关键，后面单独讲。maxRetries: 3是每个命令失败后最多重试 3 次，超过就向你报告。failFast: true是遇到第一个失败就停，省时间；如果你想让所有检查都跑完再统一修，设成false。parallel: false是顺序执行，避免多个验证命令抢资源——我试过开并行，结果 eslint 和 vitest 同时读写.eslintcache，报了一堆莫名其妙的错。mode: "pass@3"是验证模式，表示 3 次尝试中至少 1 次成功就算通过，适合探索性任务；生产代码建议用pass^3，要求 3 次全部成功。

hooks里的PostToolUse是 Claude Code 的钩子机制，matcher: "Edit|Write"表示每次 AI 编辑或写入文件后触发。这里我只放了个 echo 提示，实际你可以挂更复杂的脚本，比如记录验证日志、发通知。注意 hooks 的 command 是在 shell 里跑的，路径要用绝对路径或者确保工作目录正确。

如果你用 Cline MCP 或者 Codex 的auth.json做多工具协同，记得三件套要写全：Base URL、Key、Model ID。比如 Cline 的 MCP 配置里，Base URL 填https://taotoken.net/api，Key 填你的sk-串，Model ID 填claude-sonnet-4-5。少一个都会导致验证循环里模型调用失败，报401或者local proxy failed。

还有一个坑：eslint命令绝对不要加--fix。原因后面第 5 节详细讲，这里先记住——验证命令只负责“检查”，不负责“修改”。让 AI 读报错、自己改代码，它才能学会你的项目规范；用--fix静默改文件，等于每次重试的“被验证对象”都不一样，验证结果不可复现。

4. 验证请求与成功结果：一次完整的 pass@k 闭环演示

配置写好了，怎么确认它真的在工作？我拿一个真实场景演示：给UserService加一个updateEmail方法，故意留两个错误，看 AI 怎么自己修。

先在终端进入 Claude Code 交互模式，输入任务：

帮我在 src/services/UserService.ts 中增加一个 updateEmail 方法， 要求：接收 userId 和 email，email 必须符合邮箱格式，否则抛出错误。

AI 生成代码后，Auto-Verification 自动触发。你会看到类似这样的输出：

自动验证中... prettier --check 通过 tsc --noEmit 失败 src/services/UserService.ts:45:10 类型 'string | null' 不能赋值给类型 'string' [AI 分析]：email 参数允许 null，但 updateEmail 方法期望 string [AI 修复]：添加 null 检查，如果 email 为 null 则抛出错误 重新运行 tsc --noEmit... 通过 eslint 通过 vitest --run --changed 失败 UserService.test.ts: 1/3 失败 FAIL: updateEmail should reject invalid email Expected: "Invalid email format" Received: "Email is required" [AI 分析]：验证逻辑中参数检查顺序不对，先检查了空值再检查格式 [AI 修正]：先验证格式，再检查是否为空 重新运行 vitest --run --changed... 通过（3/3） 所有验证通过！任务完成。

这个闭环里，AI 经历了两次失败、两次自我修复。第一次是类型错误，它加了 null 检查；第二次是测试断言不匹配，它调整了参数校验顺序。整个过程你没介入，只在最后看到“所有验证通过”。

这里pass@3的含义是：3 次尝试中至少 1 次成功。上面这个例子第一次尝试就通过了（虽然中间有修复，但都在同一次验证循环内），所以算 pass。如果第一次尝试失败、第二次成功，也算 pass@3 通过。pass^3则要求连续 3 次验证全部成功，任何一次失败都要重新来——适合生产代码，因为偶发性失败（flaky test）在pass^3下会被暴露出来，逼着你去修。

验证成功后，你可以让 AI 输出一份验证报告。在交互模式里说“把刚才的验证过程整理成 markdown”，它会生成包含每轮命令、报错、修复动作的表格。这份报告可以直接贴到 PR 描述里，reviewer 一看就知道代码经过了哪些检查。

如果你想在 CI 里跑同样的流程，用 Headless 模式：

claude -p "Refactor user service" \ --allowedTools 'Read,Edit,Write,Bash(npm run typecheck),Bash(npm run test)' \ --output-format json \ --max-turns 10

--allowedTools里要显式允许Bash(npm run typecheck)和Bash(npm run test)，否则 AI 没法执行验证命令。--max-turns 10是限制最多 10 轮对话，防止验证循环跑飞。环境变量里配好ANTHROPIC_API_KEY，如果你用 TaoToken，把 Base URL 也 export 进去。

5. 本篇常见错排查：401、local proxy failed、reading choices

配 Auto-Verification 最容易卡在几个报错上，我按出现频率排一下。

401 Unauthorized。这个最常见，九成是 Key 没生效。检查三处：.claude/settings.json里的env字段有没有写对 Key；shell 里有没有覆盖成旧 Key；TaoToken 控制台里这个 Key 是不是被禁用或额度耗尽。我遇到过 settings 里写了 Key，但 shell 的.zshrc里有个旧的ANTHROPIC_API_KEY把它覆盖了，排查了半天。解决办法是在 settings 里显式写"env": { "ANTHROPIC_API_KEY": "sk-你的Key" }，优先级高于 shell。

local proxy failed。这个报错通常出现在你用了本地代理工具的情况下。Claude Code 会读HTTP_PROXY/HTTPS_PROXY环境变量，如果代理没启动或者端口不对，就报这个。检查echo $HTTPS_PROXY，如果指向一个没开的端口，unset 掉再试。另外，TaoToken 的 API 地址是https://taotoken.net/api，确认你的 Base URL 没写错，别多写或少写/api。

reading choices 报错。这个一般出现在模型返回格式异常时，比如通道返回了非 JSON 内容，Claude Code 解析失败。先确认模型 ID 写对了，claude-sonnet-4-5别写成claude-3-5-sonnet。然后去模型对话页面发一条消息，看返回是否正常。如果对话正常但 Claude Code 报这个错，检查settings.json里有没有多余的model字段覆盖了默认值。

OAuth 相关报错。如果你之前用 Anthropic 官方账号登录过，Claude Code 可能缓存了 OAuth token，和 API Key 冲突。删掉~/.claude/下的缓存文件，重新用 Key 认证。具体路径看你的系统，macOS 是~/.claude/，Linux 也是，Windows 在%USERPROFILE%\.claude\。

验证命令顺序不当导致的超时。有人把npm run test放在tsc --noEmit前面，结果测试跑了 5 分钟才失败，AI 再修类型错误，又跑 5 分钟。正确顺序是：类型检查 → Lint → 单元测试 → 集成测试，从快到慢、从浅到深。类型检查通常 5-15 秒，Lint 3-10 秒，单元测试 30 秒到几分钟。把快的放前面，能在几秒内拦截的问题绝不等到几分钟后。

flaky test 导致 pass^k 永远失败。如果你用pass^3，但项目里有个偶发性失败的测试，AI 会一直重试到maxRetries耗尽，然后报告失败。解决办法：先用pass@3完成任务，同时让 AI 标记这个 flaky test，单独开一个任务修它。别在验证循环里硬刚 flaky test，那是另一个问题。

maxRetries 设置太小。简单修改设 2，常规开发设 3，重构设 5，探索性任务设 5-10。设太小，AI 还没来得及自我修正就放弃了；设太大，遇到死循环会浪费额度。我一般设 3，观察几次验证循环的轮数，再调整。

6. 把 Auto-Verification 接进你的日常编码流

配好之后，怎么让它真正融入工作流？我的做法是分三层。

第一层，日常小修改用pass@3+failFast: true。改个工具函数、加个字段，AI 跑完类型检查和 Lint 就够，测试只跑变更相关的（vitest --run --changed）。这样验证循环通常 10-30 秒结束，不打断心流。

第二层，核心模块修改切pass^3+failFast: false。认证、支付、数据完整性相关的代码，要求所有检查全部跑完、连续 3 次通过。这时候验证会慢一些，但值得。我通常把这类任务放在单独的分支上跑，跑完再合并。

第三层，CI/CD 里用 Headless 模式做质量门禁。在 GitHub Actions 里加一个 job，跑claude -p带--allowedTools限制，验证不通过就 fail。这样即使本地忘了跑验证，CI 也会兜底。

和 Plan 模式的协同也值得说一句。Plan 模式出方案时不触发验证，你审核确认后再切到执行模式，这时候autoVerify: true生效，AI 逐步执行、每步自动验证。整个流程是：Plan 出方案 → 你确认 → 执行 + 自动验证 → 全部通过 → 任务完成。比一上来就让 AI 写代码、写完再验证要稳得多。

最后提醒一个细节：Auto-Verification 会频繁调用模型，额度消耗比普通对话快。如果你用 TaoToken，建议开 Coding Plan 或者定期看 API Keys 页面的用量。我实测下来，一个中等复杂度的重构任务，验证循环可能触发 5-10 次模型调用，每次调用都消耗 token。心里有数，就不会月底看到账单吓一跳。

这套流程跑顺之后，你基本可以做到“提交前不用手动跑验证”——AI 已经帮你跑完了。剩下的精力，留给真正需要人判断的事：架构设计、业务逻辑、边界条件。