Prove It

这是什么？适合谁？

Prove It 是一个开源的对抗性验证 Agent Skill，适用于 Claude Code、OpenAI Codex、Cursor 及其他 AI 编程 Agent。GitHub 15 Stars（Apache-2.0），但完成度与设计成熟度远超其 star 数：六语言 README、12 个可复现基准用例、零运行时依赖。

它针对的是 AI 编程的核心风险：

Tests passed.  Build exited 0.  Healthcheck returned 200.  No ERROR lines found.

然后 Agent 说 done。但通过的信号不等于通过的结果。Prove It 强制你的编码 Agent 在被允许相信自己的结论之前，先主动寻找自己错了的证据。

口号即方法论：Don’t try to prove it works. Try to prove it doesn’t.（别试图证明它行，试图证明它不行。）

它挑战什么（README 的场景表）：

基准设计（benchmark 目录，12 个可复现用例）：典型如「一个通过的测试制造了虚假自信；Prove It 发现断言被弱化并返回 FAILED」—用可复现的失败模式证明 Skill 的价值，而不是口头宣称。

适合人群：

• 重度依赖 AI 编程的工程师：PR 合并前的最后一道闸
• AI Agent 代码审查的团队：把「对抗性验证」制度化
• 测试工程师：让 Agent 主动找「测试通过但需求坏了」的洞
• 任何被「Agent 说修好了其实没有」坑过的人

不适合：希望 Agent 更快交付的场景（对抗性验证必然增加一轮流程）；纯绿field 一次性脚本。

使用前提：一个 AI 编码 Agent（Claude Code/Codex/Cursor 等）；零依赖（无 runtime dependencies）。

准备工作

1. 运行环境：任一支持 Agent Skill 标准的编码 Agent（Claude Code / Codex / Cursor）。
2. 获取：npx skills add <repo> 或按仓库说明复制到 skills 目录。
3. 成本：免费开源（Apache-2.0）；对抗性验证会多消耗一轮 Agent tokens（值得）。
4. 时间预算：安装 2 分钟；每次「done」声明前的验证回合约 1-3 分钟。

3 步快速上手

第 1 步：安装

npx skills add Pablo-aps/prove-it
# 或 git clone 后复制到 ~/.claude/skills/

第 2 步：正常让 Agent 干活

照常修 bug、写测试、提 PR。不需要改变工作方式。

第 3 步：在「done」处触发验证

Agent 报告完成时，Skill 介入（或你显式说「prove it」）：

你说修好了。Prove it.

Agent 将被要求：构造原始 bug 的复现场景、检查测试断言是否被弱化、寻找反例（什么输入仍会失败）、验证信号与结果的一致性。

预期结果：要么确认（附新的反证尝试记录），要么返回 FAILED 并指出具体漏洞（如「断言从 toEqual(expected) 被改成了 toBeTruthy()」）。成功判定：每条「done」都附带一次失败尝试的证据链。

常见踩坑

踩坑 1：把 Prove It 当成测试框架

• 现象：问「它能跑我的测试套件吗」。
• 原因：误解定位—它不是跑测试的工具，是检验「测试通过≠需求正确」的元层 Skill。
• 解决：测试照常用 Jest/Vitest/pytest；Prove It 审的是断言质量与验证逻辑。

踩坑 2：每次小改动都全量对抗验证

• 现象：改个文案也要 prove it，节奏被拖垮。
• 原因：把验证回合用在了低风险变更上。
• 解决：按风险分级—bug 修复、测试改动、PR 审查必过；纯样式/文案改动跳过。

踩坑 3：Agent 表演式验证

• 现象：验证回合秒过，全是「已检查，无问题」。
• 原因：弱模型对复杂指令敷衍执行。
• 解决：要求验证产出具体证据（复现步骤/反例输入/断言 diff），空泛确认视为未验证；12 个基准用例可用来校验 Agent 的执行力。

踩坑 4：只在最后一步验证

• 现象：写完 500 行才 prove it，失败时回溯成本大。
• 原因：把它当成出厂检查而非过程纪律。
• 解决：在「断言型节点」触发（写完测试、修完 bug、提交 PR 前），粒度越小反证越便宜。

踩坑 5：忽略「验证期望 vs 验证结果」的区分

• 现象：CI 绿了就放心，直到用户报障。
• 原因：日志/CI 检查容易变成「找符合期望的信号」而非「找不符合结果的证据」。
• 解决：读 CI/日志场景下，让 Agent 先列出「如果坏了会看到什么」，再去找这些坏信号。

踩坑 6：基准用例只看不用

• 现象：benchmark 目录存在感为零。
• 原因：不知道它是拿来校准的。
• 解决：换新 Agent/新模型时先跑几个基准用例，确认它真的会执行对抗性验证（而不是秒过）。

初级用法

1. bug 修复验证：Agent 说修复完成时，「prove it—原始 bug 的复现场景构造出来了吗」。
2. 测试弱化审查：PR 里含测试改动时，让 Prove It 比对断言强度（严格断言是否被放松）。
3. 日志结论复核：Agent 从日志得出「服务正常」结论后，要求列出「异常时的日志长相」并反查。

高级玩法

1. PR 门禁流水线：CI 中对每个 AI 生成 PR 自动附加 Prove It 审查步骤，产出反证报告供人审。
2. 断言强度 diff：让 Agent 对测试改动做「断言语义 diff」（哪一行从强断言变弱断言），弱化即标红。
3. 对抗性测试生成：与 TDD 结合—先让 Agent 写「证明代码有 bug」的测试，写不出来才算实现完成。
4. 基准即验收：把 12 个基准用例作为 Agent 雇佣/升级的验收测试，不通过的模型不用于生产代码。

小技巧

1. 「prove it」比「确认一下」有效：显式触发词让 Skill 的对抗流程完整走起来。
2. 要求证据格式：验证输出固定为「复现场景/反例尝试/断言检查」三段，防止表演式验证。
3. FAILED 是好消息：验证返回 FAILED 说明闸门起效了—比上线后被用户发现便宜一个量级。
4. 与代码审查 Skill 分工：审查 Skill 看「代码好不好」，Prove It 看「结论真不真」，两者互补。
5. 零依赖是部署福音：无 runtime dependencies，任何环境可装，不存在版本地狱。

常见问题 FAQ

Q1: 和让 Agent「再检查一遍代码」有什么区别？

A: 「再检查」是让 Agent 找自己做得对的证据（确认偏误的温床）；Prove It 结构性反转—只准找自己错的证据。找不出来才有资格说 done。这个方向反转是两者的本质区别。

Q2: 会拖慢开发吗？

A: 会增加每个「done」前的一轮验证回合（1-3 分钟）。但对 AI 编程而言，一个漏网 bug 的回溯成本（复现-定位-再修-再验）远高于此。按风险分级使用（见踩坑 2）可控制开销。

Q3: 15 stars 是不是太小众不可靠？

A: 判断依据：六语言 README、12 个可复现基准用例、零依赖设计、agentskills.io 开放标准徽章—工程成熟度远超典型早期项目。风险是社区小（贡献者少），适合先在低风险场景试运行。

Q4: 支持哪些 Agent？

A: README 明确 Claude Code、OpenAI Codex、Cursor 及其他 AI 编程 Agent；采用 Agent Skill 开放标准（agentskills.io），任何支持该标准的 harness 均可。

Q5: 12 个基准用例怎么用？

A: 两种用法：阅读它们理解「虚假自信」的典型模式（断言弱化/信号≠结果等）；或在接入新 Agent 时跑一遍，验证该 Agent 真的会执行对抗性验证流程。

参考链接

• GitHub 仓库
• 基准用例 benchmark/
• Agent Skill 开放标准

本文基于公开资料整理（GitHub 仓库 README，数据核验日期 2026-08-25），AI 辅助生成。