Bug Audit Prompt 工作流

20 分钟扫描代替 3 小时正式审查:让 AI 按类别(吞错、竞态、隐式 fallback、null 边界)找可疑点,带测试和优先级——不是泛泛的 review this code。

线上事故几乎都能回溯到”review 时看着没问题”的代码。这套工作流让 AI 当第二双眼睛,把人工 review 漏掉的可疑点找出来——吞掉的错误、竞态、隐式 fallback——在上线前一次性扫干净。目标受众是维护线上代码的开发者,要的是一个 20 分钟的扫描习惯,不是 3 小时的正式审查。

这篇讲什么

在出事故前,让 AI 找模块里”可能 bug”的位置——不是泛泛的 “review this code”,而是带类别、带测试、带优先级的一次性扫描。

这篇适合谁看

维护线上代码的开发者;准备上线功能的 on-call 工程师;被叫去给不熟悉模块的 PR 盖章的 tech lead。独立开发者也用得上——你就是自己的代码审查员,需要一个”合成 reviewer”。

什么时候适合用

  • 用户可见功能上线前
  • 准备删一段”看起来死掉了”的老代码前
  • 第一次动一个 legacy 模块前
  • 险些出事故后,检查同一片区域有没有兄弟 bug

开始前准备

  • 准备好模块文件、约定文档(或 CONTRIBUTING.md),再加一段”这模块线上怎么被用”的说明。
  • 用推理强的模型——代码审查比起草任务更吃推理深度。
  • 提前想好每条发现要怎么处理:开 ticket、立刻修、还是”只观察”。不想清楚的话清单写完就被忽略了。

具体步骤

  1. 把模块和约定文档喂给 AI,开场白这么写:“我在上线前审查这个模块。按类别列出可能 bug:错误处理、边界、竞态、输入校验、资源清理、隐式 fallback。”
  2. 每条都追问:“触发它的最小输入或场景是什么?写一个能抓住它的测试。”
  3. 让模型给每条发现打分:可能性 1-5、影响面 1-5。按乘积排序。
  4. Triage:前 1/4 在本次 PR 修;中段开 ticket;末段进”可能低风险”文档。
  5. 修完再扫一遍——有时候改一处会暴露旁边的新 bug。

Prompt 示例

你在审查这段 Node.js 模块,目标是上线前 production-ready。

约定:错误必须暴露给调用者,不能吞;
异步代码要处理取消;不允许全局状态。

对每个函数输出:
- 2-3 个可能 bug(每行一条)
- 触发它的最小输入或序列
- 严重程度:critical / high / medium / low
- 一个能失败的测试(vitest、async/await 风格)

跳过样式问题,专注正确性、竞态、资源泄漏。

第一次实操怎么跑

  1. 选一个你最近一个月写的 ~200 行模块——上下文还在你脑子里。
  2. 跑上面的 prompt。包括 triage 在内时间盒 30 分钟。
  3. 把每条标成”真 bug”、“锦上添花”、“误报”。一次至少找到 1 个真 bug;连续 3 次都是 0,说明 prompt 太泛。
  4. 把找出最多真 bug 的那版 prompt 存成团队模板。

完成后检查

  • 每条 critical 都要带一个模型写的可复现测试,不能只是”有点担心”。
  • 涉及用户数据、钱、auth 的 bug,不管打分多少都上提到最高。
  • 模型有没有引用根本不存在的函数 / 字段?有的话说明上下文不够,把原始文件而非转述重新喂一次。

怎么复用这套流程

  • 把好用的 prompt 存成 Cursor snippet 或 ChatGPT Custom GPT,命名 “bug-audit”。每次只换模块。
  • 每个走完这套流程的 PR 加 4 行总结:top finding、是否修、是否补测试、ticket 链接。
  • 维护一个 bug-audit-misses.md。真出事故时回头看审查有没有抓到——能告诉你 prompt 哪里要改。

建议的操作流程

模块 + 约定 → 分类 bug 列表 → 给 top 写测试 → triage 矩阵 → 修 + 开 ticket → 重扫。整套流程一次专注会话内能跑完。

容易踩的坑

  • 用 “review this code” 而不是 “find likely bugs”——拿到一堆样式建议,没有正确性问题。
  • 跳过写测试。没有失败测试的 finding 只是 vibe。
  • 让模型自己定严重程度且不质疑。1-5 评分不对劲就大声反驳。
  • 单文件审查,bug 却长在两个模块的接缝处。
  • 每条 flag 都修——真正吓人的那条被埋了。
  • 只审自己的代码。同事写的姐妹文件经常有同样的 bug pattern。

FAQ

  • 要不要把测试也喂进去?: 要。已有测试告诉模型哪些场景你已经覆盖,让它聚焦未覆盖部分。
  • 这能替代 code review 吗?: 不能。当作 review 前的一道扫描,让 reviewer 把时间花在设计上,不是猎杀 null-pointer。
  • 模型编造的 bug 怎么办?: 把每条当假设。它写的测试就是证据;测试在当前代码上能通过,就丢掉。
  • 能用在整个 codebase 吗?: 不太行。按 <500 行的模块跑。再大模型会丢跨切面问题,又狂报样式。

相关阅读

标签: #AI 编程 #教程