我们用 Cursor，把 Code Review 时间从 45 分钟降到 10 分钟

NacoStack
1,618 阅读7分钟

我们用 Cursor，把 Code Review 时间从 45 分钟降到 10 分钟

大家好，我是 Naco。

在日常后端开发中，Code Review（CR） 是保障代码质量的关键环节。但在高频迭代的现实下，CR 正在变成一件高消耗、易疲劳、且质量高度依赖个人状态的事情。

在实际工程实践中我越来越明确一件事：

人类更擅长判断业务逻辑和上下文是否合理，但在重复性、规则性检查上，反而非常容易出错。

比如：

  • 团队规范很多，但某一次 CR 很容易被忽略
  • 空指针、边界判断、异常处理等低级问题，在连续 Review 时极易漏掉

因此，我们在团队中引入了一种方式：
👉 先用 AI 做一轮前置 Code Review，再由人完成最终 Review。

这篇文章记录的是我在团队中，使用 Cursor 提升 Code Review 效率的一次工程化实践。

CR产出成果-部分展示：

image.png

image.png

image.png

一、问题背景：为什么人工 CR 越来越“累”

在双周甚至更快的迭代节奏下，人工 CR 普遍面临这些问题：

  • Review 时间长，精力消耗大
  • 边界条件、异常分支检查容易疲劳
  • Review 质量随 Reviewer 状态波动

尤其是一些业务价值不高，但线上风险极大的问题（如空指针、越界、异常处理），非常适合交给 AI 处理。

二、传统 CR 的局限

不使用 AI 的情况下，CR 主要依赖：

  • Reviewer 的个人经验
  • 团队规范文档
  • 口头或代码评审中的反复强调

这会带来几个明显问题：

  • 新人学习成本高
  • 代码量一大就容易漏审
  • 难以形成统一、可复用、可持续演进的检查流程

整体效率和稳定性都有限。

三、AI 介入方案：Cursor + 命令式 Review

在多种尝试之后，我选择使用 Cursor 来辅助 Code Review。

Cursor 自带的 Diff with Main 功能是可用的，但它更偏“个人工具”，
并不适合做 团队级、可维护、可演进 的 CR 流程。

我的做法是：
👉 把 Code Review 这件事，封装成一个“命令”，让 AI 按统一规则执行。

四、整体方案概览

这套方案的核心是三点：

  1. 用 review.md 统一定义 CR 规则
  2. 用 Cursor 的 Command + MCP Git 执行审查
  3. 输出 结构化 Review 报告，作为人工 CR 的前置输入

1️⃣ 环境准备

  • Cursor 2.3.35 (Universal)
  • Git
  • MCP 中的 Git 工具

Git MCP 配置示例：

image.png

{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": ["mcp-server-git"]
    }
  }
}

2️⃣ Review 规则维护

image.png

所有 CR 规则统一维护在 review.md 中：

👉 github.com/ApolloNaco/…

核心思想只有一句话：

把“人脑里的 Review 经验”，写成 AI 可以稳定执行的规则。

五、如何执行 AI Review 命令

image.png 有了 review.md 规则后，团队成员只需运行一个命令，即可让 Cursor 按规则执行 AI Code Review。

/review --b 当前分支

执行流程说明

  1. 指定分支

    • --b 当前分支：对当前开发分支进行审查

    • 可选参数：

      • -o：输出报告
      • --file：审查指定文件

  2. AI 自动执行规则

    • 读取 review.md 中定义的规则
    • 按文件类型过滤
    • 对代码进行规范检查、问题分级分析

  3. 生成结构化报告

    • 包含变更分析、问题列表、风险评估和合入建议
    • 输出到 Terminal，也可直接同步到 PR 评论或 CI

  4. 开发者操作简化

    • 不需要手动比对 diff
    • 不需要逐行检查低级错误
    • 人只需聚焦 业务逻辑和架构决策

执行一次命令，即可完成前置 AI 审查，保证低级错误被拦截，同时提高 Review 效率和一致性。

Review Command 的核心设计

① Git 命令执行规范（最关键）

问题：
Git 命令在 Cursor 中非常容易被分页器（pager）卡住，导致流程失败。

解决方式：

  • 使用 git --no-pager
  • 统一通过 Cursor 内置 run_terminal_cmd 执行
  • 从命令输出中按需提取信息

👉 如果不处理这个问题，AI CR 基本不可用。

② 文件范围控制

只审查以下文件：

  • .java
  • .xml
  • .properties

目的只有一个：
👉 聚焦真正影响逻辑和行为的代码，提高审查效率。

③ 团队规范检查（强约束）

在 review.md 中的：

### 团队规范检查

这个模块下，由技术 Leader 维护必须被拦截的问题，例如：

  • 方法 / Map key-value 是否强制注释
  • 是否存在应抽取却未抽取的公共逻辑
  • 是否存在冗余 if/else 分支
  • URL / 配置是否走统一封装

原则很简单：

这些问题一旦出现，就不能被合入。

④ 问题分级机制

在规则中明确问题优先级：

  • 严重问题：线程安全、内存泄漏、安全漏洞、架构违规
  • 中等问题：性能问题、异常处理、数据一致性
  • 轻微问题：规范、可读性、可维护性

这样可以让：

  • AI 自动聚焦重点
  • 人类 Reviewer 快速扫高风险问题

避免被细节淹没。

⑤ 统一审查报告输出

AI 最终输出结构化 Review 报告，包括：

  • 变更内容分析
  • 问题列表（按严重程度）
  • 风险评估
  • 合入建议

可以直接同步到 PR 评论或 CI 流程中。

六、实际效果

效果展示： image.png

在真实项目中的效果非常直观：

  • 单次 Review 时间：30–45 分钟 → 10–15 分钟
  • 命名、规范、空指针等低级问题几乎被完全拦截
  • 新同学可以快速对齐团队规范
  • Review 质量明显更稳定

组内反馈非常一致：

“不用 Cursor 做辅助，Review 会明显更累。”

七、团队如何落地这套方案

1️⃣ 技术 Leader 如何维护

Leader 只需要维护两块内容：

  • 团队规范检查：定义哪些问题必须被拦截
  • 问题分级规则：决定哪些问题必须优先处理

本质上是把 Leader 的经验工程化。

2️⃣ 团队成员如何使用

  • 同步最新 review.md
  • 写完模块后，先执行一次 AI CR
  • 修掉低级错误，再提 PR

👉 把问题拦在最早的阶段。

3️⃣ 工作流嵌入

  • AI Review 输出直接同步到 PR 评论
  • 作为人工 CR 的前置输入
  • 形成半自动 Code Review 流程

八、为什么我认为这套方案在工程上是“对的”

这不是功能堆砌，而是几条清晰的设计原则：

  1. 写成了命令风格，对开发友好。只需要按照提示敲命令即可。例如：/review --b -o [需要CR的分支]

  2. 用了Cursor AI的内置函数 run_terminal_cmd 提高执行效率

  3. 解决了cursor调git命令发生的常见问题：

    1. 引入Git MCP
    2. git --no-pager [command] 处理代码时的分页问题
    3. git fetch --all --prune 避免了 CR的分支代码没有和最新的master分支对比的问题（多人开发尤其容易出现这个问题）

  4. 设置了“团队规范检查”点，你可以在这个模块下写你们团队的常见团队规范，让AI在代码CR的时候帮你发现问题

  5. 设置严格的问题分级，可以聚焦重点问题的处理。

  6. 可以让AI最后分析的结果输出报告，集成到你们企业的CI/CD流程中。

  7. 让团队成员在每次写完代码之后，都先自己用AI CR一遍，把常见的团队问题和代码规范、低级错误自己先通过AICR的方式去避免。

人负责判断业务和架构，AI 负责拦截低级错误。

九、不足与后续规划

目前这套 AI CR 仍有明显边界：

这些问题，我会在后续文章中展开

Naco

avatar
文章
阅读
粉丝