staged-verify
Claude Code AI Coding 开源
这是什么
一个 skill，把”帮我验证一下这段代码”这句含糊的话，变成四道有明确通过标准、且不通过就不许推进的质量门：
Phase 1 Phase 2 Phase 3 Phase 4干净 review → 冒烟+单测+覆盖率+效率 → 边界双轨(白盒+黑盒)+并发/故障 → 真实环境覆盖+效率对照每阶段产出报告、停下等确认才进入下一阶段，状态落盘支持断点续跑。
为什么做它
让 agent 直接”验证一下刚写的代码”，通常得到的是”跑了下测试，看起来没问题”。三个结构性缺陷：作者自查（刚写完的会话上下文里全是自我辩护）、只能测到已经写出来的东西（从代码出发推导用例，测不出”本该写但没写”的逻辑）、没有门（一次性对话，也无法断点续跑）。
核心设计
- 零污染 review：Phase 1 在看不到本次会话历史的全新上下文里做，只给 diff 和维度，严禁给实现思路。
- 白盒黑盒双轨求差集：白盒轨读代码推导用例，黑盒轨给一个看不到实现的子代理只喂契约让它独立推导——只在黑盒轨出现的用例，就是”代码可能漏实现”的高危项。这类缺陷白盒轨在原理上发现不了。
- 左移：那份契约清单，写代码之后生成是检查表，写之前生成就是施工图纸。同一条轨道，写前防 bug、写后兜 bug。
设计说明
完整的设计取舍写在这篇文章里：给 AI 的验证流水线：四道门与一次求差集
我的判断与适用边界
我不会要求所有改动都完整执行四个阶段。纯文案、简单配置和低风险局部修改，验证成本不应高于改动本身；涉及并发、持久化、安全边界、跨服务协议或真实部署行为时，分阶段门禁才有明显收益。
Phase 4 必须依赖真实环境和可观察结果。环境不可用时可以明确跳过，但不能把“未执行”写成“已经通过”。这套流程也不能证明需求本身正确：如果输入契约遗漏了关键边界，黑盒轨与白盒轨可能同时遗漏。因此，验证流水线负责检查实现与契约是否一致，需求评审仍然是独立环节。
怎么用
Claude Code 复制进 skill 目录即可：
git clone https://github.com/yaofuhong0311/staged-verify.gitcp -r staged-verify/skill ~/.claude/skills/staged-verify四个 Markdown 文件，没有可执行代码、没有依赖。对刚写完的代码说”对这次改动做一轮完整验证”即可触发。