原文：https://indieseek.co/zh/blogs/claude-code-verify-code-review-explicit-workflow/
Claude Code v2.1.215 之后的验证门禁：显式运行 /verify 与 /code-review
快速结论
Claude Code v2.1.215 于 2026 年 7 月 19 日发布。这个版本不再由 Claude 自行调用 /verify 和 /code-review skill。命令仍然存在，但任务看起来已经完成时，不能再预期 Claude 会自动进入这两段流程。
如果原工作流把它们当作质量门禁，应把隐含假设改成显式结束流程：
完成实现
-> 运行确定性检查
-> /verify
-> /code-review <target>
-> 修复发现并重跑检查
-> 人工决定是否合并
这不代表 Claude Code 在所有场景中都不再运行测试。官方 release note 的范围更窄：变化仅针对两个具名 skill 的自主调用。Prompt、hook、脚本与 CI 仍可能执行其他检查。
适合谁
这份指南适合交互式使用 Claude Code，并曾假定 completion prompt、CLAUDE.md 规则或 agent 自己的判断会自动触发验证与代码评审的开发者。
它也适合构建无人值守 coding-agent 任务的团队。Slash command 可以提供额外证据，但真正可强制执行的门禁仍应是确定性命令与 CI。需要规划指令文件职责时，可参考 AGENTS.md、CLAUDE.md 与 Copilot instructions 指南；面对不可信仓库时，应先建立 coding agent sandbox 边界，再运行任何项目命令。
7 月 19 日发生了什么变化
Anthropic 的 v2.1.215 release 只有一项聚焦的行为调整：Claude 不再自行运行 /verify 和 /code-review，需要用户显式调用所需命令。
这与 Claude Code 文档中的 skill 模型一致。普通 skill 默认既可以由用户调用，也可以由 Claude 选择；设置 disable-model-invocation: true 后则只能由用户调用。这个版本相当于给两个内置工作流增加了人工触发边界，其他 skill 仍可能被自动选择。
真正的风险不是命令消失，而是旧流程可能已经到达“完成”状态，却没有执行作者以为会隐式发生的 review 阶段。
分开三类门禁
| 门禁 | 最佳证据 | 主要发现 | 是否应阻止完成 |
|---|---|---|---|
| 确定性检查 | Exit code 与测试报告 | Build、lint、type、unit、integration 或产品断言 | 是 |
| Claude Code skill | /verify 与 /code-review 输出 |
漏掉的验证、可疑 diff 行为、复用与正确性问题 | 工作流要求时应阻止 |
| 人工评审 | 已审 diff、风险决定与 approval | 产品意图、可接受取舍与部署判断 | 重要改动应阻止 |
三者不能相互替代。/code-review 没有发现问题，不等于应用可以构建；测试全绿不等于改动解决了目标问题；没有检查记录的人工 approval，也会让回归更难追踪。
建立显式结束流程
1. 实现前写清确定性命令
在任务或仓库指令中列出最小相关命令：
Required checks
- npm test -- --runInBand
- npm run lint
- npm run build
- changed route 的一条 smoke test
不要只写“验证改动”。这种表达没有定义证据形态。应写清命令、环境和至少一条行为级断言。
2. 把 /verify 作为独立步骤
完成实现与确定性检查后，显式运行：
/verify
公开的 v2.1.215 note 提到了这个命令，但没有承诺稳定的参数协议。除非当前安装版本明确展示了可用参数，否则使用裸命令，并记录它实际执行了什么。如果 /verify 只是总结已有证据，它不能替代缺失的测试输出。
3. 给 /code-review 明确范围
Claude Code Review 文档说明，本地命令默认检查当前 branch 相对 upstream 多出的 commits，以及 working tree 中未提交的改动；也可以传入文件、PR 编号、branch 或 ref range。
准备合并到 main 时，应把比较范围直接写出来：
/code-review main...my-feature
只有确实需要把结果发到 Pull Request 时才使用 /code-review --comment。只有审阅过发现并确认不会破坏无关 working-tree 改动时，才使用 --fix。
4. 修复后重跑确定性门禁
Review 驱动的修改会让更早的测试结果失效。处理发现后，应重新运行相关 build 与 tests，并记录最终 commit 和结果，不能复用最后一次代码变更之前的绿色结果。
本地 Review 不等于托管 PR Review
本地 /code-review 在 Claude Code session 内运行。Anthropic 的 GitHub 托管 Code Review 是另一项服务，具有 PR 创建、每次 push 或手动 @claude review 等 repository 级触发方式。v2.1.215 release note 没有宣布这些托管触发器发生变化。
按场景选择：
- 交互式本地任务：交付前运行确定性检查、
/verify与本地/code-review。 - 无人值守 agent 任务：在模型之外强制执行脚本与 CI，把 skill 输出作为附加证据。
- GitHub Pull Request：保留 required CI 与人工 approval，可按需增加托管 Code Review 作为第二轮检查。
- 很小的文档改动：执行格式、链接与构建检查；只有 diff 确实需要时才运行 code review。
使用紧凑证据块
在任务交付或 Pull Request 中保留：
Verification evidence
- Claude Code version:
- Final commit:
- Deterministic commands and exit codes:
- Product smoke test:
- /verify result:
- /code-review scope and result:
- Findings fixed:
- Remaining risk / human decision:
这样，跳过 skill 会成为显性状态，不再依赖不可见的模型选择；无人值守任务即使发生日志压缩或 session 恢复，也仍有可审计记录。
常见错误
- 认为“finish and verify”仍会让 Claude 自动调用两个 skill。
- 在
CLAUDE.md中要求模型自己选择/verify，却把它当成可强制执行的 hook。 - 混淆本地
/code-review与 GitHub 托管 Code Review。 - Review 前跑过 tests，但处理 review 发现后没有重跑。
- 用 AI review 替代 required CI 或人工 approval。
- 发布含 token、环境变量或私有仓库 URL 的原始日志。
FAQ
/verify 和 /code-review 被删除了吗？
没有。Release 明确说的是 Claude 不再自行运行它们，并要求用户按需显式调用。
Claude Code 还会运行测试吗？
它仍可能执行 prompt 或 instructions 明确要求的命令。已确认变化只涉及两个具名 skill 的自动调用，因此应检查真实命令日志，不要扩大解读 release note。
CLAUDE.md 能强制执行这两个 skill 吗？
应把仓库指令视为行为指导，而不是强制机制。硬门禁应在交互式 session 中显式调用命令，或在 CI 中执行确定性脚本。
/code-review 能替代人工评审吗？
不能。它用于发现问题和整理证据；产品意图、风险接受、secret 暴露与合并授权仍需要确定性策略和人工判断。
来源
- Claude Code GitHub release
v2.1.215：https://github.com/anthropics/claude-code/releases/tag/v2.1.215 - Claude Code Docs：Extend Claude with skills：https://code.claude.com/docs/en/skills
- Claude Code Docs：Code Review：https://code.claude.com/docs/en/code-review
- Claude Code repository：Code Review plugin：https://github.com/anthropics/claude-code/blob/main/plugins/code-review/README.md