把整个仓库丢给模型，不如把 Diff 与意图讲清。面向 Diff 的审查提示词，逼模型回答：正确性、安全、兼容、测试与回滚，而不是争论缩进。

适用场景

拉取请求预审、热修二次核查、新人改动的风险扫描。最终合并仍由人负责。

流程

  1. 准备：PR 描述、Diff、相关测试结果摘要
  2. 要求模型按严重级别列问题
  3. 人确认真伪，过滤口味建议
  4. 对真实问题补测试或改代码
  5. 必要时第二轮只审争议文件

提示词模板

【角色】资深审查者，只基于提供的 Diff 与说明，不假设未给出的文件正确。
【变更意图】：
【Diff】：
【已有测试/验证】：
请输出：
1. 阻断级问题（正确性/安全/数据损坏）
2. 应修问题（边界、兼容、可观测性）
3. 测试缺口
4. 可忽略的风格项（单独一栏，默认不阻塞）
每条含：位置、原因、建议复现或验证方式。
禁止编造 Diff 中不存在的函数行为。

延伸阅读

系统化清单见AI 代码审查指南；安全向提示注入演练见提示注入演练。

技巧与坑

  • 大 Diff 按目录拆开审，避免模型「摘要式放过」
  • 生成代码与审查用不同提示，减少自我偏好
  • 密钥与生产数据不要贴进提示

小结

Diff 审查提示词的核心是风险分级与可验证性。让 AI 当探灯，人当判官。

安全与秘书类问题

优先让模型找：注入点、权限扩大、密钥泄漏、不安全反序列化、明显竞态。风格与命名争议单独一栏，默认不阻塞合并。

与 CI 的分工

静态检查与单测交给 CI；模型审「意图与风险叙事」。两者都绿仍可能有逻辑洞，所以关键路径要人读。

审查输出如何进 PR

把阻断级问题贴回 PR 评论，附复现步骤；风格项可折叠。若模型误报，标记 false positive 并改进提示词中的项目约定（例如你们允许的日志库）。长期可将高频误报写成「忽略规则」段落，减少噪声。

对数据库迁移、权限中间件、支付相关 Diff，提高人工必读比例，模型意见仅作辅助。审查提示词里可声明你们的语言与框架版本，减少过时建议。若 Diff 由 AI 生成，审查者应特别盯「看起来完整但缺错误处理」的路径。把常见项目陷阱写成提示词附录，审查质量会更稳。

相关阅读