本地 AI Code Review 探索及落地

近期在参与实现本地 AI Code Review 的事情，以下是一些思考输出。感兴趣的小伙伴可以在评论区一起讨论～

引言

从 AI Code Review 的目的上看，我们更多的是需要增强代码的健壮性和稳定性，然后是代码的可读性及保证风格统一，持续推进项目标准化、规范化。

这样既能保证发布后的产品稳定，又能确保项目可以有节奏地、清晰地进行演进，还能让其他同学在 CR 过程中取长补短、查漏补缺，进行自我提升。

目标

那有哪些问题是我们需要在 CR 中找出并必须让同学进行修改的？我认为有以下几种：

• 明显的语法问题、边界问题、异常处理、竞态问题等；
• 潜在的逻辑漏洞或者其他 bug；
• 业务逻辑耦合，可读性和可维护性差！
• 不符合项目规范，代码风格差异大；
• 存在安全漏洞；
• 代码变更风险等级：主要通过静态分析来进行评估，分为深度和广度。
  • 深度：比如该代码属于基础函数，被多个其他函数所使用；
  • 广度：比如该代码属于公共函数，被多个模块所使用；
  • 其实从业务层面来讲，这里也可以 hack 一些风险数据，不同的模块会命中不同的风险等级；

而 CR 本身也应该从两个维度进行：

• 个人本地 CR（AI 主力 - 模型为 GLM 4.6）
  • 缺点：高频触发 CR，耗费时间
  • 解决：制定一些软链、工具或者直接脚本，将是否触发交给开发人员。但默认需要触发！
• 团队 CR（AI + 人工协作）

应该

在实际过程中，我们应该参考或者遵循以 Spec 驱动的方式来制定 CR 规范。比如通用的 CR 规则 + 项目编码规范和工作流程 + 团队内部知识库积累。

这里列举一些比较常规的 Spec：

• 项目编码规范；
• 内部框架或当前使用框架文档；
• 最佳 Code Style 以及优秀的案例文档；
• 遵循 MR（Merge Request）规则，明确规定需要使用 Git 的哪些命令获取正确的 diff 文件和内容；
• 其他

需要了解的前置知识

既然要实现 Code Review，那么就需要知道 Code Review 的时机以及内容。

通常来说，我们一般只有在提交完代码，并发起一个 Merge Request （MR）的时候，才会触发 Code Review。而需要评审的内容：是自开发分支从指定分支（比如 master 或者 main）分叉以来的增量代码（避免把指定分支上最新的变更都算进来）。

可以认为是在本地以 merge-base 为基准的三点比较，这是与 PR/MR 最接近的 Diff 手段。同时还需要启用 -M（重命名检测）和 -C（复制检测），避免混入一些不必要的文件内容到 CR 当中。

对于本地 AI CR 来说，我们把 CR 时机放在 pre-commit 这一环节，那 CR 的内容就是「已提交的内容 + 暂存区」的内容，最简单的实现方式就是：

# 计算变更基线
BASE=$(git merge-base origin/master HEAD)

# 查看差异文件
git diff --name-only --cached "$BASE"

# 查看完整补丁
git diff --cached -M -C "$BASE"

用 merge-base 作为变更基线的什么意思呢？

要知道在做分支比较时，我们不会直接拿 master 的快照来当左侧基线，而是先找到 master 与当前分支的“共同祖先”（通常来说就是分支分叉点），使用它来作为对比起点。这样得到的差异就是——从分支创建以来你真正引入的改动，从而避免被 master 分支上后续 push 进去的代码提交所污染。

用 merge-base 就是获取该分叉点的主要手段，git diff master...HEAD （或者 git merge-base master HEAD) 只会展示——从分叉点到你当前分支头部的增量，在 PR/MR 中基本都采用这种三点（...）语义。

为什么要在 pre-commit 发起 AI CR？

• 很多开发者都有一些“陋习”，只管码代码，不自测。这就导致一些很低级的代码问题被提交到仓库；
• 开发任我行，和项目编码规范偏差十万八千里，在整个项目“一枝独秀”；
• 能 “run” 不能看，业务耦合度堪称防御性输出典范——谁敢动我的代码试试！
• 「commit-push -> CR -> 修改」流程，往返好几遍才达到发布标准；评审人员也无法保证立即 CR 你的代码，整个流程下来费时费力

综上，我们在 pre-commit 环节借助 AI CR，可以缩短整个评审周期和发布周期。既减少了 commit 次数，又能保证代码质量和功能稳定，还能减轻评审人的压力，何乐而不为？

落地

我们直接使用 Shell 脚本的方式搭配 Claude Code 或者 iflow 来实现本地 AI Code Review。以 iflow 为例：

• 首先需要进行安装 npm install -g iflow；
• 然后在项目根目录中的 .husky/pre-commit 文件中增加调用脚本
  • 先设定获取 diff 的脚本，主要是上述内容中 Git diff 的命令；
  • 再通过 iflow -y -p "your_prompt" 的形势，触发 iflow 终端运行
  • 通过“必须通过项”或者 AI 打分的形势，在不符合预期时进行拦截，直至开发者修改通过后方可 commit 成功；
  • iflow 报错不可 block 用户 commit 操作；
  • 需要提供跳过 AI CR 的能力，防止在一些紧急状况下拦截开发者提交；
  • 基于上一条，可以选择继续评审，但将评审结果和代码一起提交至仓库
• 最终的形式是脚本 + AI CR

附加项

• 是否增加 RAG 和内部知识库

这个是扩展项，如果从知识库的角度来进行 Code Review，可以有效地提高准确率（预期）。