Code Review 为什么需要 AI 帮忙

人工 Code Review 有两个老问题：一是 reviewer 不够，团队人人都很忙，PR 排着队没人看；二是 reviewer 状态不稳定，累了看漏了就放过一个 bug。AI 辅助审查就是来补这两个缺口的——PR 一提交，AI 先扫一遍，把明显问题标出来，reviewer 只需要看 AI 挑完剩下的。

AI 不会取代人的审查，但会把人从机械的检查里解放出来。格式问题、明显的 bug、安全隐患这些 AI 一眼就能扫出来的，就让 AI 做。人专注看架构设计、业务逻辑、代码可读性这些需要判断的部分。

AI 做初审，人做复审。AI 负责挑机械问题，人负责判断设计好坏——分工明确效率最高。
本文核心知识点
  • 静态分析规则化检查，快但死板，查不出语义问题。
  • LLM 审查能理解代码意图，发现逻辑问题，但可能误报。
  • 双层审查静态分析加 LLM 结合，互补效果最好。
  • CI/CD 集成PR 提交自动触发审查，不增加人工负担。
代码审查配图：左侧带勾选标记和警告标的文档，右侧放大镜和机器人眼睛图标，蓝色渐变扁平风格
AI 代码审查的示意：代码变更经过静态分析和 LLM 审查两道关卡。

传统静态分析能做什么不能做什么

静态分析工具（比如 ESLint、Pylint、SonarQube）已经存在很多年了。它们能查格式问题、未使用变量、类型不匹配、常见的安全模式。这些是「规则」能覆盖的东西——你定规则，工具检查。但静态分析查不出逻辑错误，比如「这个循环条件写反了」「这个边界 case 没处理」——这些需要理解代码意图，规则工具做不到。

审查类型静态分析LLM 审查
格式规范强弱（不如工具快）
常见 bug 模式强中
逻辑错误弱强
安全漏洞中强
架构建议弱中

LLM 代码审查：它能看懂什么

大模型看代码的能力越来越强了。你把一段 diff 给它，它能理解这段代码在做什么、有没有逻辑问题、有没有安全隐患。它能发现「这个 if 判断写反了」「这个变量可能是空指针」「这个 SQL 有注入风险」这类需要理解上下文才能发现的问题。

# 把 diff 送给 LLM 审查的基本提示
# 1. 给 diff：这是本次 PR 修改的代码
# 2. 给上下文：这个函数是做什么的
# 3. 给审查标准：安全/性能/可读性
# 4. 要求输出：列出发现的问题，按严重程度排序

# 输出格式建议：
# - [严重] 问题描述 + 行号 + 建议修改
# - [警告] 问题描述 + 建议
# - [建议] 改进建议

把 AI 审查接入 CI/CD 流水线

AI 审查最自然的接入点是 CI/CD 流水线。PR 一提交，CI 先跑静态分析，然后把 diff 送给 LLM 做审查，结果自动评论在 PR 上。这样开发者提交完 PR 马上就能看到 AI 反馈，不用等人工 reviewer。

接入 CI/CD 的关键点
  • 触发时机PR 提交自动触发，不用手动跑。
  • 评论格式AI 意见直接贴在 PR 评论里，和人工 review 混在一起。
  • 误报过滤太频繁的误报会让人忽略，要调提示词控制噪音。
  • 只看 diffAI 只审变更部分，不是全量代码。

审查提示词怎么写

LLM 审查的效果很大程度上取决于提示词怎么写。写得太宽泛，它会给一堆没用的建议；写得太死，它又不敢发现新问题。好的审查提示词应该告诉模型：你是资深工程师，重点看什么，输出格式是什么，哪些不用管。

# 一个好的 LLM 审查提示词
# 角色：你是一个资深软件工程师，做代码审查
# 任务：审查下面的代码 diff，找出潜在问题
# 重点：
#   1. 安全漏洞（注入、越权、敏感信息泄漏）
#   2. 逻辑错误（边界条件、空指针、异常处理）
#   3. 性能问题（不必要的循环、内存泄漏）
# 格式：按严重程度列出问题，每行一个
# 不要：不要给风格建议（格式有 lint 管）
# 不要：不要夸代码写得好（只说问题）