浏览 AI 知识库
怎样让 AI 做代码审查：先找 Bug、回归和缺测试
让 AI 做代码审查时，先要求它找会改变行为的 Bug、回归风险和缺失测试。命名与格式可以最后看，不能让它们淹没权限或数据问题。
按实际操作顺序推进
每完成一段就检查当前输出，确认结果符合预期后再继续。
审查列了十条风格建议，却漏掉退款接口的权限漏洞
代码审查结果列了变量命名、空行和注释风格，却没发现退款接口缺少权限校验。漂亮的建议不等于有效审查。
- 发现指向具体文件与行为
- 严重度与影响相称
- 缺失测试和回归风险已覆盖
动手前，把材料和不能改的部分定下来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | PR 修改退款路由、服务和测试；需求要求仅财务角色可退款，且重复请求不能重复退款。 |
| 不能越过的边界 | 先找正确性、安全、回归和缺测试；每条发现给文件位置、触发条件和影响；不把纯偏好当 Bug。 |
| 要交付的结果 | 按严重度排序的审查清单 |
AI 代码审查提示词，从“理解变更意图”开始做
理解变更意图
读取 issue、PR 说明、规则和 diff，确认旧行为、目标行为和范围外，不从单个文件猜全局。
沿关键路径检查
追输入、权限、状态、错误、数据写入和外部副作用，关注边界和失败路径。
验证兼容与迁移
检查接口、配置、数据库、缓存、客户端和回滚是否同步，寻找单点改动引发的不一致。
检查测试是否有效
测试应能在旧错误下失败，覆盖高风险分支；只增加覆盖率但无断言不算。
按严重度写发现
先给位置和结论，再给触发、影响与修复方向；不确定项标问题，不宣称已证实。
一条高优先级发现必须带触发条件和影响
| 位置 | 触发 | 影响 | 验证/建议 |
|---|---|---|---|
| api/orders.ts:87 | tenant_id 为空时查询全表 | 跨租户数据暴露 | 补租户必填测试并在查询前拒绝 |
| worker.ts:41 | 重试无幂等键 | 重复发送通知 | 模拟超时重试，增加唯一键 |
| 无发现 | 关键流程只有 happy path | 回归风险未覆盖 | 补失败和权限分支 |
文件和行号为示例；真实审查必须指向当前 diff。
让 AI 做代码审查时，先找 Bug、回归和缺测试
适合提供真实diff和上下文文件后使用，不让AI只评价命名和格式。
可复制使用
让 AI 做代码审查时，先找 Bug、回归和缺测试
请只审查我这次提供的代码 diff，优先找会导致错误行为、数据损坏、安全边界破坏或兼容回归的问题。 任务目标/不允许改变的行为【】；完整 diff【】；必要调用方与相关测试【】；已运行命令及原始输出【】。 每个发现都要给严重度、文件和行、具体触发条件、实际影响及最小修复方向。没有可复现证据的担忧放入“待核查”，不要包装成缺陷。最后单列漏测风险。不要评论纯风格偏好，不扩展到 diff 之外的重构。
使用范围：适合提供真实diff和上下文文件后使用，不让AI只评价命名和格式。不要把个人风格偏好写成Bug，不扩大到无关重构。
完成后的按严重度排序的审查清单
审查首先报告 P1：路由只验证登录未验证财务角色；P1：幂等键未落库；P2：测试只覆盖管理员成功。每条含复现路径和建议测试，样式问题不占主要结论。
为什么“发现很多潜在问题，作者无法判断优先级”还不能交付
发现很多潜在问题，作者无法判断优先级
- 原因
- 没有区分可触发缺陷与猜测
- 怎么改
- 按严重度、发生条件和证据排序，无法证实的内容写成问题而非结论