2026年6月26日/ AI Application Notes

AI Code Review 怎么做：让模型审风险，不审感觉

AI Code Review 的价值不是替人点 approve，而是作为第二视角找 bug、回归风险、边界遗漏、安全问题和测试缺口。

AI-assisted DevCode ReviewWorkflowAgentEngineering Practice

AI 写代码越来越快之后，Code Review 反而更重要。

不是因为 AI 写的代码一定差，而是它很擅长生成一段“看起来完整”的实现：命名合理、格式整齐、类型通过、页面能跑。真正的风险通常藏在另一层：边界条件、权限判断、错误处理、回归影响、测试缺口，以及和项目既有模式不一致的地方。

所以我更愿意把 AI Code Review 当成第二视角：

不是让模型说“这段代码不错”
而是让模型尽量证明“这段代码哪里可能坏”

模型不负责点 approve。它负责帮人发现盲点，最后是否接受风险，仍然要人判断。

先定义 AI Review 的职责

AI Review 最适合做风险扫描，而不是做最终裁决。

它可以帮忙看：

  • 这次改动是否真的符合任务目标。
  • 是否引入回归风险。
  • 是否漏掉空值、异常输入、重复提交、超时等边界。
  • 是否绕过权限、安全校验或数据一致性约束。
  • 是否缺少关键测试。
  • 是否复制已有逻辑、绕开项目既有封装。
  • 是否为了修一个问题，引入更复杂的问题。

它不适合决定：

  • 这个需求值不值得做。
  • 某个技术债是否现在必须还。
  • 团队是否接受某个工程取舍。
  • 高风险逻辑是否可以免验证合并。

也就是说，AI Review 的定位应该是“找风险”，不是“盖章”。

输入要比 prompt 更重要

把 diff 丢给模型，然后问“帮我 review 一下”，通常会得到一堆泛泛建议。

更好的输入是：

任务目标：
验收标准：
本次 diff：
相关项目规则：
已运行的验证命令：
没有运行的验证：
已知不能碰的文件或逻辑：

如果是修 bug，再补：

复现步骤：
预期行为：
实际行为：
这次修复的思路：

如果是重构，再补：

重构前后行为是否应该一致：
哪些公共接口不能变：
哪些测试可以证明行为没变：

Review 不是让模型猜上下文。上下文给得越清楚，它越可能指出具体问题，而不是输出“建议增加错误处理”这种空气建议。

输出要像 code review，不像读后感

我不喜欢让 AI Review 输出长篇总结。更实用的格式是 findings first：

只列发现的问题。
按严重程度排序。
每条必须包含：
- 级别
- 位置
- 风险
- 原因
- 建议验证方式

不要泛泛评价风格。
不要重复总结 diff。
如果没有发现高风险问题，请明确说明，并列出剩余风险。

严重级别可以简单分三档：

级别 含义
P0 / Blocker 可能导致安全、数据、权限、生产事故，必须修
P1 / High 可能导致明显 bug、回归或用户可见问题，建议合并前修
P2 / Medium 可维护性、测试缺口、边界不足，视情况处理

低价值的风格建议可以少写。AI 很容易在命名、注释、微小格式上啰嗦，反而淹没真正风险。

审查重点

任务目标

先看这次改动是不是解决了原问题。

常见风险：

  • 实现了相邻功能，但没有解决核心 bug。
  • 修了前端显示，没有修后端状态。
  • 改了默认值，绕过真实边界。
  • 任务要求只改内容，却顺手重构组件。

可以问：

请检查 diff 是否严格围绕任务目标。
指出任何无关改动、过度实现或遗漏的验收点。

回归风险

很多 bug 不在新增逻辑里，而在旧行为被改坏。

重点看：

  • 旧入口是否还可用。
  • 旧数据格式是否兼容。
  • 默认值是否变化。
  • 排序、过滤、分页、权限判断是否被间接影响。
  • 移动端、空状态、加载状态是否还正常。

可以问：

请从回归风险角度审查这次改动。
列出哪些已有路径可能被影响，以及应该补哪些验证。

边界条件

AI 生成代码常覆盖常规路径，但容易漏边界。

重点看：

  • 空数组、空字符串、null、undefined。
  • 重复提交、重复点击、重复请求。
  • 超长文本、特殊字符、编码问题。
  • 网络失败、超时、接口返回半结构化数据。
  • 权限不足、资源不存在、用户未登录。
  • 时区、排序、分页最后一页。

可以问：

请只审查边界条件。
不要评价整体实现。
列出当前代码可能漏掉的输入、状态或异常路径。

安全、权限和数据

这部分不能只靠 AI，但 AI 可以帮忙做第一轮扫描。

重点看：

  • 是否绕过鉴权或权限校验。
  • 是否把用户可控输入拼进 SQL、命令、路径、HTML。
  • 是否把 token、cookie、API key 打到日志或前端。
  • 是否把服务端校验移到前端。
  • 事务边界是否正确。
  • 重试是否幂等。
  • 缓存是否会脏读。
  • 并发下是否会超卖、重复扣减、重复创建。

可以问：

请从安全、权限和数据一致性角度审查。
重点找越权、注入、敏感信息泄露、事务缺口、幂等问题和竞态条件。
不要给泛泛安全建议，只列和 diff 相关的问题。

测试缺口

AI Review 最有价值的输出之一，是告诉你“哪些路径还没被验证”。

不要只问“测试够不够”，要问：

请根据 diff 推断应该有哪些测试。
标出当前测试覆盖了什么，缺了什么。
按风险优先级给出最小补测建议。

好的测试建议应该具体：

  • 空输入应该返回什么。
  • 权限不足应该是什么状态码。
  • 重复请求是否只创建一次。
  • 修改排序后第一页和最后一页是否稳定。
  • 旧数据格式是否还能解析。

“建议增加单元测试和集成测试”这种话太空，基本没有帮助。

可维护性

可维护性不是“我不喜欢这个写法”。

更具体的问题是：

  • 有没有复制已有逻辑。
  • 有没有绕开项目已有请求封装、错误处理、状态管理。
  • 有没有把复杂逻辑塞进入口文件或大组件。
  • 有没有引入一个只用一次的新抽象。
  • 有没有把业务规则写死在 UI 层。
  • 有没有新增依赖，但项目里已有等价工具。

可以问：

请审查这次改动是否符合项目既有模式。
只指出会增加维护成本的具体问题，不评价个人风格。

AI 生成代码的特殊失败模式

AI 写出来的代码，有几类“看起来没问题”的风险，review 时要特别留意。

看起来修了，其实绕开了

测试失败是因为权限逻辑没处理好，模型可能改测试、放宽断言、跳过分支，让测试通过。

可以问：

这次改动有没有通过放宽校验、跳过错误、降低断言来让问题消失？

发明不存在的约定

模型可能调用一个项目里不存在的 helper，或者假设某个环境变量、接口字段、配置项存在。

要检查：

  • 新 API 是否真的存在。
  • 新字段是否前后端都对齐。
  • 新配置是否有默认值和文档。
  • 新依赖是否真的安装。

过度工程化

一个小 bug 被修成一套新框架，是 Agent 很容易犯的错。

要检查：

  • 是否为了单个场景新增复杂抽象。
  • 是否改了太多不相关文件。
  • 是否把原本清楚的流程拆得更难读。

忘记用户路径

代码层面通过了，但用户路径没通：

  • 按钮文案不对。
  • 错误提示没有显示。
  • 移动端溢出。
  • 空状态没有入口。
  • 加载状态卡住。

前端改动不能只看 diff，还要看页面。

推荐工作流

我会把 AI Review 放在实现之后、提交之前。

实现改动
-> 自查 diff
-> 跑测试 / build
-> 让 AI Review 找风险
-> 人工裁决哪些要修
-> 修复
-> 再跑验证
-> 提交

如果任务风险高，可以用两个模型：

模型 A 实现
模型 B 审查
人类裁决
模型 A 或人类修复
验证

多模型不是银弹。审查模型也会误判。它的价值是增加一个角度，不是替代最终责任。

可复制的 Review Prompt

下面这个 prompt 可以直接作为起点：

你现在做代码审查，不负责改代码。

背景：
- 任务目标：
- 验收标准：
- 已运行验证：
- 未运行验证：
- 项目规则：

请优先找：
1. 可能导致 bug 的行为变化
2. 回归风险
3. 边界条件遗漏
4. 安全 / 权限 / 数据问题
5. 缺失的测试
6. 与项目既有模式不一致的实现

输出要求：
- 只列发现的问题
- 按严重程度排序
- 每条包含：级别、位置、风险、原因、建议验证方式
- 不要泛泛评价代码风格
- 不要重复总结 diff
- 如果没有发现高风险问题，请明确说明，并列出剩余风险

如果只想审测试缺口，可以更窄：

只审查测试缺口。
根据 diff 推断最小必要测试集。
不要建议大而全的测试计划，只列合并前最应该补的 3-5 个用例。

如果只想审安全：

只从安全和权限角度审查。
重点找越权、敏感信息泄露、注入、服务端校验缺失、危险配置。
没有和 diff 直接相关的问题就说没有发现。

提示词越窄，结果越有用。

哪些改动必须 review

这些改动不应该跳过 review：

  • 权限、登录、角色、租户隔离。
  • 支付、订单、库存、积分、余额。
  • 数据迁移、批量删除、导入导出。
  • 生产配置、proxy、CORS、密钥、日志。
  • 公共组件、公共 API、共享状态。
  • 并发、缓存、队列、定时任务。
  • 大范围重构。

这些可以轻一点：

  • 文案调整。
  • 小范围样式修复。
  • 明确错别字。
  • 只改草稿内容。
  • 有完整测试覆盖的小逻辑修正。

判断标准很简单：错了会不会影响用户、数据、安全或后续维护。会，就认真审。

最后

AI Code Review 最怕变成一句“看起来没问题”。

真正有用的 AI Review 应该像一个挑剔但克制的同事：只盯风险，只说具体问题，只给可验证建议。

模型负责发现盲点，人负责判断取舍。最后能不能合并，不看模型语气有多自信，而看风险是否处理、验证是否跑过、剩余问题是否被明确接受。

这才是 AI 参与代码审查最稳的方式。

Brief

AI code review is useful when it is asked to find concrete risks, not when it is asked whether code looks good.

The best inputs are the task goal, acceptance criteria, diff, project rules and verification results. The best outputs are prioritized findings with locations, risks and ways to verify them.

The model can help discover blind spots, but humans still own the final decision, especially for security, data, permissions and user-facing behavior.

返回全部文章