跳转到内容

AI 代码审查:怎么发现风险而不是只听解释

AI 协作 · 经验分享 · 2-3 小时

让 AI 按功能、边界、安全、性能和测试逐项检查。

尚未进入本轮核验

AI 代码审查:怎么发现风险而不是只听解释 配图
学习结果
形成一套每次上线前都能执行的 AI review checklist。
时长
2-3 小时
难度
经验分享
核验
尚未进入本轮核验

正文

审查先看差异和意图。读任务目标、改动文件与上下文,再检查新增行为;只读最终代码容易漏掉被删除的权限、日志或错误分支。把每项发现绑定到具体文件与路径,不用“建议优化”代替能解释影响的缺陷。

功能审查沿用户路径走。列表到详情、提交到保存、付款到权益都需要完整链路。检查新入口是否真的调用已有接口,成功提示是否等待可信结果;空数组、缺字段和上一请求迟到可能暴露只在正常样例下工作的实现。

安全边界以服务端为准。检查权限校验、输入约束、敏感字段返回和秘密暴露,前端隐藏按钮不等于拒绝访问。来自用户的HTML或URL不能未经约束进入危险渲染与跳转;依赖新增也需关注许可证、维护状态和实际必要性。

性能问题应描述成本来源。检查是否重复请求、每次渲染做大排序、图片未经压缩或无界列表一次全部输出。不要为了性能口号先引入缓存与并发;缓存可能隐藏过期数据,优化应基于可测量瓶颈并保留正确性。

测试要覆盖失败路径和回归点。一个成功案例不足以证明异步竞态、权限和布局正确。给出复现输入、预期结果和实际观察,优先补保护当前行为的测试。模型认为会失败的情况需标为推断,未执行测试不得写为通过。

问题排序依据影响而非语气。会泄露用户资料或错误开通权限的问题先处理,阻断核心路径其次,局部视觉瑕疵再后。确认问题后修根因并复核相关调用方,不只压掉警告。最终记录已解决、仍存在和未检查的范围,避免假装全系统都已审计。

AI 代码审查:怎么发现风险而不是只听解释 · 图解 1

AI 代码审查:怎么发现风险而不是只听解释 · 图解 2

AI 代码审查:怎么发现风险而不是只听解释 · 图解 3

学习步骤

  • 要求 AI 先读 diff,不要只看最终文件。
  • 按用户路径检查行为是否改变。
  • 检查空状态、错误状态、移动端和权限边界。
  • 要求给出文件和行号。
  • 把发现的问题转成可执行修复任务。

场景拆解

审查异步筛选改动

模拟实现通过接口加载分类结果,用户连续选择A与B时,A的慢响应可能覆盖B列表。审查还需确认空结果、错误反馈和原站链接没有被改坏。

  1. 查看差异是否新增请求但没有处理响应时序。
  2. 用延迟不同的样例连续切换分类,观察最终选择与结果。
  3. 修复请求竞争后检查失败与空结果,再核对旧链接行为。

正确结果始终对应当前选择,而不是最后到达的请求。问题记录应注明复现条件和受影响文件;若只根据代码推测竞态,应明确尚未实际复现,不宣称测试已经通过。

补充材料

思维导图、练习、清单和参考资料可按需展开。

01

思维导图和离线文件

适合读完后下载到自己的知识库里继续整理。

按用户路径审查代码

  • 功能:目标行为是否完成
  • 边界:空值、失败与重复操作
  • 安全:认证、权限与敏感数据
  • 性能:查询、请求与渲染成本
  • 测试:覆盖改动与回归路径

审查结论的依据

  • Diff 与相关调用位置
  • 可复现的输入与操作
  • 构建、测试与页面截图
  • 风险影响范围与修复记录

代码审查不能只听解释

  • 描述正确不代表路径可运行
  • 正常输入不能覆盖边界状态
  • 前端限制不能代替服务端权限
  • 修复需要回到原问题复验

AI 代码审查:怎么发现风险而不是只听解释 思维导图

02

实践练习

根据文章内容记录自己的判断与依据。

审查异步筛选改动

从差异分析请求竞态,用延迟样例复现旧结果覆盖,并将可证明的问题转成有影响范围的修复单。

练习场景

模拟实现通过接口加载分类结果,用户连续选择A与B时,A的慢响应可能覆盖B列表。审查还需确认空结果、错误反馈和原站链接没有被改坏。

准备材料

  • 准备任务说明、差异和相关调用方。
  • 使用脱敏数据与可控请求延迟。

检查点

  • 这条审查意见能说明具体坏结果吗,还是只有个人偏好?

练习步骤

01 / 读差异

时间: 20-30 分钟

目标: 识别被新增或删除的边界

操作:

  1. 对照目标查看相关改动。
  2. 找成功、失败与取消分支。

参考结果: 新异步请求需要考虑响应时序。

预期产出: 影响路径列表。

检查: 审查覆盖删除代码而非只看新增行。

02 / 复现竞态

时间: 20-30 分钟

目标: 证明结果与当前选择一致

操作:

  1. 让A响应慢于B。
  2. 连续切换并检查当前分类和列表。

参考结果: 选择B后到达的A不能覆盖B。

预期产出: 复现记录。

检查: 观察与推断明确分开。

03 / 形成修复单

时间: 20-30 分钟

目标: 把发现变成可执行任务

操作:

  1. 按影响排序问题。
  2. 列相关调用方和回归条件。

参考结果: 修复后仍保留原站链接与错误提示。

预期产出: 修复与验证清单。

检查: 未执行的检查没有被写成已通过。

完成检查

  • 审查覆盖删除代码而非只看新增行。
  • 观察与推断明确分开。
  • 未执行的检查没有被写成已通过。
03

清单、模板和关键词

用于项目记录和自查。

项目记录

  • Diff:____
  • 用户路径:____
  • 边界状态:____
  • 安全:____
  • 性能:____
  • 测试:____
  • 回归风险:____

审查发现单

文件与位置:;目标行为:;复现输入:;预期:;实际或推断:;影响用户:;严重度依据:;根因:;建议修复:;回归检查:。例:A慢响应覆盖B会展示错误分类,应控制过期请求提交结果。

上线审查单

功能路径:;空和错误状态:;请求竞态:;服务端权限:;敏感数据:;不可信输入:;依赖变化:;性能成本:;键盘与手机:;实际测试:;未检查项:。不是每项都能仅靠代码阅读确认,证据类型须标明。

关键概念

  • Diff
  • 用户路径
  • 边界状态
  • 安全
  • 性能
  • 测试
  • 回归风险

容易误判

  • 只看新增代码忽略删掉的边界
  • 推测复现写成实际结果
  • 安全问题只在前端隐藏
04

工具和参考资料

本篇涉及的工具和参考链接。

可参考工具

  • Notion
  • Tally
  • Airtable
  • ChatGPT
  • Codex

参考资料