AI Engineering
AI 代码审查实践：如何让模型帮你发现真实问题
把 AI 用在代码审查中，重点不是让它泛泛点评，而是围绕变更意图、风险边界、测试证据和上线影响发现真实问题。
AI 很适合做第一轮代码审查，但前提是审查任务被设计好。直接把 diff 扔给模型，让它“帮我 review 一下”，通常会得到格式化建议、命名建议和一些看似正确但价值不高的提醒。真正有用的 AI Review，要让模型围绕变更意图、风险边界和验收证据工作。
核心判断
好的 AI Review 不是评论更多，而是更早发现真实风险：行为回归、权限绕过、边界条件、数据兼容、安全泄露、测试缺口和部署风险。
审查链路
AI 应该介入三处：提交前自查、PR 初审、合并前复核。提交前适合发现低级错误；PR 初审适合补充审查视角；合并前复核适合确认测试、风险和发布说明是否齐全。
给模型什么输入
不要只给 diff。更好的输入结构是：
请按代码审查方式检查这个变更。
变更目标：
- [这次改动想解决什么问题]
风险边界：
- 不能破坏的公开 API / URL / 数据格式
- 不能修改的权限、计费、审计、配置逻辑
检查材料：
- git diff
- 相关文件
- 测试结果
- 构建结果
输出要求：
- 只列真实风险，不要泛泛建议
- 按严重程度排序
- 每条问题给文件位置、原因、影响和建议修复
- 如果没有发现问题，说明剩余风险和缺失测试审查维度
| 维度 | 重点问题 |
|---|---|
| 行为 | 是否改变了已有用户可见行为、路由、接口、默认值。 |
| 数据 | 是否影响持久化格式、迁移、空值、兼容性。 |
| 权限 | 是否绕过 ACL、租户隔离、角色校验、对象级权限。 |
| 安全 | 是否暴露密钥、日志敏感信息、SSRF、注入、XSS。 |
| 并发 | 是否有竞态、重复提交、幂等性、锁和重试问题。 |
| 性能 | 是否引入 N+1 查询、无界循环、过大上下文、缓存击穿。 |
| 测试 | 是否覆盖成功路径、失败路径、边界条件和回归场景。 |
Prompt：提交前自查
你是严格的代码审查者。请检查当前 diff，只关注可能导致真实线上问题的点。
优先级：
1. 行为回归
2. 安全和权限
3. 数据兼容
4. 错误处理和边界条件
5. 测试缺口
请不要输出风格建议，除非风格问题会导致 bug。这个 Prompt 适合开发者在本地提交前使用。它能减少无意义反馈，把模型注意力收束到风险上。
Prompt：PR 初审
请像资深 reviewer 一样审查这个 PR。
上下文：
- PR 目标：...
- 相关业务约束：...
- 已运行检查：...
请输出：
1. 必须修复的问题
2. 建议修复的问题
3. 需要作者确认的问题
4. 缺失的测试
5. 如果可以合并，请说明剩余风险
限制：
- 不要重复描述代码做了什么
- 不要提出无关重构
- 每条发现必须能映射到具体代码或测试缺口PR 初审的价值不是代替人工 approve，而是帮助 reviewer 更快定位需要重点看的地方。
Findings 格式
要求模型使用固定格式，能显著提高可用性：
[Severity] 文件:行号
问题：...
影响：...
建议：...
需要测试：...例如：
[High] src/auth/checkAccess.ts:42
问题：只校验了用户是否登录，没有校验 document.tenantId 是否等于 currentTenantId。
影响：多租户场景下可能读取到其他租户文档。
建议：在返回前加入租户校验，并补充跨租户访问测试。
需要测试：tenant A 用户访问 tenant B 文档应返回 403。让 AI 少说废话
AI Review 常见问题是啰嗦、重复、过度建议。可以用三个约束控制：
人和 AI 的分工
| 角色 | 负责内容 |
|---|---|
| AI | 快速扫 diff、列风险、找边界条件、建议测试。 |
| 作者 | 解释变更意图、补测试、修复问题、说明取舍。 |
| Reviewer | 判断风险是否真实、决定是否阻塞合并。 |
| CI | 用类型检查、测试、构建和安全扫描提供客观证据。 |
不要让 AI 决定“能不能合并”。它可以提供审查候选项，但最终判断必须由熟悉业务边界的人做。
合并前门禁
确认 PR 描述包含目标、范围、测试和风险。
让 AI 对最终 diff 做一次风险复核。
人工检查 AI 标出的高风险点。
确认 CI、类型检查、构建和关键测试通过。
如果涉及数据、权限、计费、发布配置，必须有人工二次确认。
实用结论
AI 代码审查的正确定位是“风险放大镜”，不是“自动盖章器”。把输入上下文、风险分类、输出格式和门禁流程固定下来，它能稳定帮助团队发现真实问题；如果只是让它泛泛 review，通常只会制造更多噪音。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。