最近用 Claude Code、Codex、Cursor 这类工具写代码，我越来越明显地感觉到一件事：AI 写代码是真的快，但 review 并没有变轻松。
现在很多人的 AI 编码流程大概是这样：先和 AI 讨论需求、拆实现方案，然后让 Codex、Claude Code、Cursor 或 Copilot 直接改本地代码。AI 改完后，如果项目能跑、页面看起来没问题，很多人就准备提交了。问题恰恰出在这里。
以前 review 代码，主要看逻辑对不对、命名清不清楚、有没有明显 bug。现在 AI 一次能改很多文件，而且改得很自然，很多风险不是“代码完全不能跑”，而是混在 diff 里，看起来没那么刺眼。
比如：代码能跑，但测试被删了；功能能过，但权限判断被弱化了；CI 还能跑，但 GitHub Actions 权限被放大了；配置文件看起来正常，但 secret 被写进了代码；甚至 AGENTS.md、CLAUDE.md、Cursor rules 这类文件被改了，后续 AI 的行为规则也跟着变了。
这些问题不一定马上炸，但很适合藏进一次普通提交里。所以我做了一个很小的工具：PatchBrake。
项目地址：https://github.com/RyanCoreAI/patchbrake
Demo 在线体验：https://raw.githubusercontent.com/RyanCoreAI/patchbrake/main/assets/demo.gif
1. PatchBrake 是什么？
PatchBrake 的定位很窄：AI 改完代码后，在提交前扫描这次 diff，看看有没有明显危险信号。
它不是 AI Reviewer，也不调用 LLM。它不会上传你的代码，不会接 SaaS，不会做 Web Dashboard，也不会替你判断业务逻辑。它做的事情更像是提交前的一脚刹车：在代码进入 commit 之前，先把一些高风险 diff 提醒出来。
我反而是故意把它做得很“笨”：只看 diff、只跑本地规则、只报能解释清楚的风险。 因为很多 AI 编码带来的问题，并不需要另一个 AI 来推理，它们本来就是很直接的信号。
比如 staged diff 里出现：
+ permissions: write-all或者测试被删掉：
- test("rejects anonymous users", () => {
- expect(() => requireAdmin(null)).toThrow("Unauthorized");
- });再或者配置里出现：
+ OPENAI_API_KEY="sk-..."这些不是复杂安全研究问题，而是提交前就应该被提醒的问题。
2. 怎么安装和使用？
先说前提：需要已经安装 Node.js 20+。
npx 本身是 npm 附带的工具。也就是说，如果你的电脑里没有 Node.js / npm，通常也就没有 npx，这时直接运行下面的命令会失败：
npx patchbrake scan --staged所以第一次使用前，可以先在终端里检查一下：
node --version
npm --version
npx --version如果这三个命令不存在，先安装 Node.js 20+。安装完成后，一般会自带 node、npm 和 npx。
环境没问题后，就不需要手动安装 PatchBrake 了，直接用 npx 运行：
npx patchbrake scan --staged如果你想全局安装，也可以：
npm install -g patchbrake
patchbrake scan --staged实际使用流程很简单。AI 改完代码后，先把准备检查的改动放进 staged 区域：
git add <changed-files>如果你确认这次所有改动都属于同一个任务，也可以：
git add .然后运行：
npx patchbrake scan --staged这里的 staged 不是让你必须立刻提交。它只是告诉 PatchBrake：请检查我准备提交的这批改动。
如果你用的是 Codex 桌面版，也一样。PatchBrake 不关心代码是 Codex 桌面版改的、Claude Code 改的，还是 Cursor 改的。只要最后文件落在本地 Git 仓库里，就可以在项目目录打开终端，先 git add，再运行：
npx patchbrake scan --staged如果扫出 error，就先修掉，再重新扫描；没有明显风险后，再正常提交。
3. 实际效果
我做了一个测试 diff：新增一个疑似 OpenAI API key、删除一个测试文件、把 GitHub Actions 权限改成 write-all。PatchBrake 扫出来是这样：
这个输出里可以看到三类风险：
- secret-leak：新增了疑似 API key，并且输出里已经脱敏
- deleted-tests：测试文件被删除
- workflow-permissions：GitHub Actions 权限被放大到
write-all
这就是我想要的效果：它不需要理解整个业务，只要能在提交前把这些明显风险拦一下，就已经很有价值。
4. 为什么只扫 diff？
因为 AI 编码真正容易出问题的地方，经常不是“整个仓库历史上有没有漏洞”，而是：这一次 AI 到底改了什么。
你让 AI 重构认证模块，它可能顺手删掉一个断言；你让 AI 改 release workflow，它可能把权限放大；你让 AI 补配置，它可能把 token 写进文件；你让 AI 整理项目规则，它可能改掉 agent 的约束。
这些变化如果进了主分支，后面再查就麻烦了。所以 PatchBrake 的位置很靠前：在 commit 前，多做一次本地 diff 质检。
5. 现在能检查什么？
目前 PatchBrake 主要覆盖这些风险：
- secret-leak：新增 API key、token、private key、
.env风险 - deleted-tests：测试文件、测试用例或断言被删除
- workflow-permissions：GitHub Actions 权限被放大
- migration-risk：危险 migration，比如
DROP、TRUNCATE、无WHERE的DELETE - prompt-config-drift：AGENTS.md、CLAUDE.md、
.cursor/rules、prompt 配置变化 - beta 规则：auth guard 删除、危险 npm script、危险 shell 命令、依赖风险等
它不追求覆盖所有漏洞。我更在意的是，先抓住 AI 改代码时最容易被忽略、但提交前最值得停一下的那几类问题。
6. 它和 Gitleaks / Semgrep / CodeQL 是什么关系？
PatchBrake 不是用来替代这些工具的。
Gitleaks、TruffleHog 更专注 secret scanning；Semgrep、CodeQL 更接近静态分析和 SAST；zizmor 对 GitHub Actions 安全检查更深入。PatchBrake 的目标更小：把 AI 生成代码中常见的 diff 风险，用一个本地 CLI 在提交前统一拦一下。
它更像是 AI coding workflow 前面的一道轻量 safety gate，而不是完整安全平台。
7. 现在还很早
PatchBrake 还是早期版本。我最想要的反馈不是泛泛夸奖，而是这三类：
- false positive：它误报了什么？
- real bad diff：你真的遇到过哪些 AI 生成的危险 diff？
- rule request：你希望它多检查什么？
如果你经常用 Codex、Claude Code、Cursor 或 Copilot 改代码，可以拿自己的项目跑一次：
npx patchbrake scan --staged如果它帮你拦下过一次低级但严重的 diff 风险，欢迎给个 star，或者直接提 issue，把你的 bad diff case 留下来。
