ProofPR：AI 让写 PR 变快，但 review 没变便宜

AI 让写 Pull Request 变快了，但没有让 review 变便宜。很多 PR 最大的问题不是代码一定错，而是没有复现、没有测试、没有截图，也没解释为什么要改权限。ProofPR 先检查这些“应该随改动一起出现的证据”，再把 PR 交给人看。

ProofPR 在 GitHub Action 中生成的审查报告

先说清楚：ProofPR 不是 AI code reviewer，运行时也不调用大模型。它不猜代码是不是 AI 写的，不理解你的业务逻辑，更不会替维护者判断实现是否正确。它做的是一套可解释、可重复的初筛。

一个 PR 是怎样被处理的

在本地 CLI 中，ProofPR 从 Git 读取 unified diff；在 GitHub Action 中，它会读取 PR diff、标题、正文和仓库里的 .proofpr.yml。之后的数据链是这样的：

ProofPR 将本地或 GitHub 的 PR 输入经过确定性证据规则转换为可解释审查结果

规则会关注改动规模、敏感路径、测试缺失、描述过薄、疑似 secret、依赖版本与 lockfile、GitHub Actions 权限、pull_request_target、不可信 checkout 和 MCP 凭据等信号。最后给出四种 gate：ready、review-carefully、needs-evidence 或 block-merge。

这不是在说 block-merge 的 PR 一定有漏洞，而是在提醒维护者：现有证据不足，或者风险已经高到不该直接合并。

Evidence Contract 比“一套规则管所有仓库”更实用

不同目录需要的证据不一样。改 UI 时，截图很有用；改 workflow 时，更应该说明权限为什么增加；改可复现 bug 时，验证步骤比一张绿勾更重要。

ProofPR 的 Evidence Contract 可以按路径声明要求，例如：

1
2
3
4
5
6
evidence:
  contracts:
    - id: ui-screenshot
      paths: ["src/ui/**"]
      requires: ["screenshot", "verification"]
      severity: medium

这样维护者检查的不是“正文够不够长”，而是这类改动有没有带上真正有用的材料。规则命中后也能看到具体原因，不需要猜评分从哪里来。

为什么故意不用 LLM

这里不用模型不是因为 AI 没价值，而是 PR gate 更看重稳定和可追溯：

不需要 API Key，也不会把 diff 发送给第三方模型服务；
相同输入得到相同结果，方便复现 benchmark；
每条发现都能回到具体规则和证据；适用时还会标出文件与新增行；
维护者可以在配置里明确调整阈值，而不是修改提示词碰运气。

ProofPR 也不会查询完整漏洞数据库。依赖漏洞仍然更适合交给 OSV、Dependabot 等专用工具；它关注的是“这个依赖改动有没有说清楚、有没有锁定、生命周期和来源是否可疑”。

代码是怎么拆的

项目使用 pnpm monorepo。@proof-pr/core 负责 TypeScript 规则引擎、配置校验和报告模型；CLI 用 Commander 读取本地 Git；GitHub Action 使用 GitHub Actions Toolkit 获取 PR 上下文并发布结果。Zod、YAML 和 Picomatch 负责配置与路径匹配，Vitest 与 benchmark 用来锁定规则行为。

当前仓库的 benchmark 覆盖 22 个固定案例。这个数字本身不代表工具已经“识别所有风险”，它的价值是：新增或修改规则时，能立刻知道旧案例有没有被破坏。

ProofPR 也是我围绕“先补审查证据”这个问题自行设计的项目，不是某个 reviewer 仓库的换皮。开发和测试过程中，我会借助 AI 做规则梳理、重构和文档辅助；但发布后的扫描器不调用模型，阈值、评分和输出都留在可查看、可复现的代码里。

它适不适合你的仓库

如果仓库经常接收外部贡献，或者团队已经觉得 PR review 被重复检查拖慢，它会比较有用。若只是一个人写、一个人合并的小项目，维护这套 gate 可能反而比手动看两眼更重。工具存在的意义不是给每个 PR 多加一盏红灯，而是把有限的 review 时间留给真正需要人判断的部分。

GitHub 仓库：linsk-labs/proof-pr
项目总览：404_@林达 Projects