线上事故几乎都能回溯到”review 时看着没问题”的代码：一个被吞掉的错误、一个只在高负载下才触发的竞态、一个悄悄返回过期数据的 fallback。这套工作流让推理模型当第二双眼睛，在模块上线前把这些点找出来。它是”review this code”的精准、追问驱动版——给维护线上代码的开发者，要的是一个 20 分钟的扫描习惯，不是 3 小时的正式审查。
一句话总结
- 别说”review this code”，要说”按类别找可能的 bug，每条配一个失败测试”。带类别的 prompt 出正确性问题；开放式 prompt 出样式建议。
- 按 ~500 行以下的模块跑，上下文里放真实文件（不是转述）和你的约定文档。
- 让模型给每条打分：可能性（1-5）、影响面（1-5），按乘积 triage。前 1/4 在本次 PR 修。
- 用强推理模型——Claude Opus 4.7 或 GPT-5.5（Thinking），不是快速起草模型。审查吃推理深度。
- 没有可复现失败测试的 finding 是 vibe，不是 bug。把测试当成工作的最小单位。
为什么”review this code”效果差
开放式 review prompt 优化的是把 diff 看一遍，于是模型把注意力均匀铺开，挑那些最省事就能注意到的东西：命名、格式、缺注释。bug 审查把这个逻辑反过来。你先把失败类别点出来——错误处理、边界、竞态、输入校验、资源清理、隐式 fallback——逼模型去推理运行时可能出什么错，而不是纸面上哪里看着别扭。
这一点很关键，因为做了 agent 化重构的专业 AI 审查工具就是这么干的。Cursor 的 Bugbot 在 2025 年底从固定多 pass 流水线重写成了一个 agent：它在 diff 上动态推理，自己决定哪里要深挖；到 2026 年 6 月还加了 Default / High / Custom 三档 effort，让你在高风险 PR 上让它多想一会儿（见 Cursor 文档）。下面这个手写 prompt 借的就是这个姿势：先分类，再在热区深挖。
这篇适合谁看
维护线上代码的开发者；准备上线功能的 on-call 工程师；被叫去给不熟悉模块的 PR 盖章的 tech lead。独立开发者也用得上——你就是自己的代码审查员，需要一个凌晨两点也不会累的”合成 reviewer”。
什么时候适合用
- 用户可见功能上线前，尤其是碰钱、auth、用户数据的。
- 准备删一段”看起来死掉了”、久到没人记得为什么存在的老代码前。
- 第一次动一个 legacy 模块前。
- 险些出事故后，检查同一片区域有没有兄弟 bug——同一个作者常常重复犯同样的错。
开始前准备
- 准备好模块文件、约定文档（或
CONTRIBUTING.md），再加一行”这模块线上怎么被用”的说明（请求路径、定时任务、队列消费者）。 - 选一个推理强的模型。截至 2026 年 6 月，Claude Opus 4.7（SWE-bench Verified 87.6%，更难的 SWE-bench Pro 64.3%）和 Thinking 模式下的 GPT-5.5 是两个能稳定推理运行时行为、而不是只匹配表面问题的模型。快速 / Instant 模型只会扫一眼。取舍可看 ChatGPT vs Claude vs Gemini 对比。
- 提前想好每条发现怎么处理：开 ticket、立刻修、还是”只观察”。不想清楚的话，清单生成完就被忽略了。
具体步骤
- 把模块和约定文档喂给模型，开场白这么写：“我在上线前审查这个模块。按类别列出可能 bug：错误处理、边界、竞态、输入校验、资源清理、隐式 fallback。只用我给你的代码。”
- 每条都追问：“触发它的最小输入或序列是什么？写一个能抓住它的测试。”
- 让模型给每条打分：可能性（1-5）、影响面（1-5）。按可能性 × 影响面排序。
- Triage：前 1/4 在本次 PR 修；中段开 ticket；末段进”可能低风险”文档。
- 在改过的文件上再扫一遍。修一个 bug 常常会暴露旁边的兄弟 bug，模型也会在新的控制流上重新推理。
Prompt
你在审查这段 Node.js 模块，目标是上线前 production-ready。
约定：错误必须暴露给调用者，不能吞；
异步代码要处理取消；不允许全局状态。
对每个函数输出：
- 2-3 个可能 bug（每行一条）
- 触发它的最小输入或序列
- 严重程度：critical / high / medium / low
- 一个能失败的测试（vitest、async/await 风格）
规则：
- 只用我给你的代码，不要假设辅助函数存在。
- 引用任何函数或字段，它必须出现在上面的源码里。
- 跳过样式问题，专注正确性、竞态、资源泄漏。“只用我给你的代码”这行比看上去重要。开放式审查正是推理模型最容易幻觉的地方——它会编出一个根本不存在的 validateInput() 辅助函数，然后”在里面找出一个 bug”。把模型钉死在你提供的源码上，能狠狠砍掉这个失败模式。
自己写 prompt，还是用专业工具？
手写 prompt 审查免费、能跑在那些不方便贴进第三方服务的代码上，还能按你的领域调类别列表。专业 PR 审查工具则每次 push 自动跑，能在团队层面铺开。深审一个高风险模块用 prompt 工作流；上面再叠一个工具做全量覆盖。一份独立准确率数据（2026 年 6 月）有助于校准预期：
| 工具 / 做法 | 独立准确率信号 | 成本（2026 年 6 月） | 适合 |
|---|---|---|---|
| 手写 prompt（Opus 4.7 / GPT-5.5） | 看 prompt 和上下文；你的测试是把关人 | 你现有的 Plus/Pro/Max 套餐 | 深审一个高风险模块 |
| Cursor Bugbot | 约 70%+ 的 flag 在 merge 前被处理；Autofix 提的改动 35%+ 被直接合 | 按用量计费，约 $1.00-$1.50 / 次 | Cursor 团队里每个 PR 自动审 |
| DeepSource | OpenSSF CVE Benchmark F1 84.51%（实测最高）；确定性 pass 误报 <5% | 按仓库付费 | 想要低噪声安全覆盖的团队 |
| Greptile | F1 约 82%；抓得多但误报也多 | 按席位付费 | 宁可有噪声也要抓全的审查 |
| CodeRabbit | OpenSSF CVE Benchmark 准确率 59.39% / F1 36.19% | 免费档 + 付费席位 | 轻量的行内 PR 评论 |
准确率数据来自 OpenSSF CVE Benchmark——目前唯一一个用来横向比这些工具的公开、独立数据集（200+ 个真实 CVE）。对 prompt 工作流的启示是：连最好的专业工具都会漏真 bug、又会过度 flag，所以你审查里的每条 finding 都必须带一个失败测试作为证据。
第一次实操怎么跑
- 选一个你最近一个月写的 ~200 行模块——上下文还在你脑子里。
- 跑上面的 prompt。包括 triage 在内时间盒 30 分钟。
- 把每条标成”真 bug”、“锦上添花”、“误报”。一次至少找到 1 个真 bug；连续 3 次都是 0，说明 prompt 太泛——把类别列表收紧到你的技术栈。
- 把找出最多真 bug 的那版 prompt 存成团队模板。
完成后检查
- 每条 critical 都要带一个模型写的可复现测试，不能只是”有点担心”。测试在当前代码上能通过，说明这条是误报，丢掉。
- 涉及用户数据、钱、auth 的 bug，不管打分多少都上提到最高。
- 模型有没有引用根本不存在的函数 / 字段？有的话说明上下文不够，把原始文件而非转述重新喂一次，并在 prompt 里保留”只用我给你的代码”这条规则。
怎么复用这套流程
- 把好用的 prompt 存成 Cursor snippet 或 ChatGPT Custom GPT，命名 “bug-audit”。每次只换模块。
- 每个走完这套流程的 PR 加 4 行总结：top finding、是否修、是否补测试、ticket 链接。
- 维护一个
bug-audit-misses.md。真出事故时回头看审查有没有抓到——漏掉的那些告诉你 prompt 哪个类别要加强。
容易踩的坑
- 用 “review this code” 而不是 “按类别找可能的 bug”——拿到一堆样式建议，没有正确性问题。
- 跳过写测试。没有失败测试的 finding 只是 vibe。
- 让模型自己定严重程度且不质疑。1-5 评分不对劲就大声反驳；你有它没有的上下文。
- 单文件审查，bug 却长在两个模块的接缝处。接口 bug 要把两个文件都喂进去。
- 每条 flag 都修——真正吓人的那条被埋在杂活底下。
- 只审自己的代码。同事写的姐妹文件经常有同样的 bug pattern，这也是出事后做一遍清扫值得的原因。
FAQ
- 要不要把已有测试也喂进去？：要。已有测试告诉模型哪些场景你已经覆盖，让它聚焦未覆盖部分，而不是重报已处理的。
- 这能替代 code review 吗？：不能。当作 review 前的一道扫描，让 reviewer 把时间花在设计和取舍上，不是猎杀 null-pointer。连最好的专业工具在 OpenSSF CVE Benchmark 上也就 82-85% F1 封顶，最终的判断还得人来做。
- 模型编造的 bug 怎么办？：把每条当假设。它写的测试就是证据；测试在当前代码上能通过，就丢掉。保留”只用我给你的代码”这条规则来砍掉幻觉出来的辅助函数。
- 该用哪个模型？：截至 2026 年 6 月，审查本身用 Claude Opus 4.7 或 Thinking 模式的 GPT-5.5。两者都推理运行时行为，而不是扫表面样式；快速 / Instant 模型会漏掉最要命的竞态和隐式 fallback。
- 能用在整个 codebase 吗？：不太行。按 ~500 行以下的模块跑。再大模型会丢跨切面问题，又狂报样式。要全仓覆盖，上面叠一个专业 PR 工具。