一、背景

在实际迭代开发中，不同需求的代码规模差异很大，有些需求涉及上千行代码，有些则只有一两行。且对于前端的代码验收，主要侧重在界面功能，通过功能验收，没法确保每一行代码都测试到的，以及功能的代码逻辑是否合理，是否健壮、是否规范等问题，都需要通过人工代码 CR 来进一步兜底验收代码的质量，尽量降低业务线上出错的可能。但当面对上千行的代码变更时，人工 CR 也是心有余而力不足。

传统的代码审查依赖人工，面对大规模代码变更时效率有限，而 AI 代码审查能够实现自动化、标准化的质量检查，有效补充人工审查的不足。

二、前端研发 CR 现状与可优化点

CR 现状

目前前端研发同学主要使用的代码质量保障工具有前端 Apex 插件智能体、Uraya 质量分检测。其中 Apex 插件智能体是通过前端研发自助点击或 git hook 自动触发 CR 智能体执行，智能体内定制了 CR 规则以及与 MCP 的结合，利用 Cursor IDE 的 Agent 能力进行本地 AI CR ，找出代码问题、本地解决问题。Uraya 质量分检测是在创建 MR 后，通过流水线自动触发，Uraya 质量分检测代码变更的质量分浮动，产出具体问题的记录，引导研发优化代码。

可优化点

• 本地触发 CR 需要研发同学主动点击触发或者通过 Apex git hook 执行 CR 智能体，当开发的需求多、分支多、提交次数多的时候，时长容易漏触发、忘记点。
• 对于 MR 评审人员，如果希望通过 Cursor CR 时，需要在本地通过调用 CR 智能体再执行一遍，获取 CR 结果，在目前 Cursor 按量计费的背景下，重复执行 CR 智能体的成本需要及时关注。
• 当前流水线 Diff + 大模型 API 的 AI CR 方式，误报率较高，研发使用意愿较低。

三、AI CR 方案对比分析

基于以上现状分析，我们对不同 AI CR 方案进行了深入对比。

Cursor Agent CR 主要优势

流水线集成 CR 与本地 AI CR 差异

四、技术方案设计

结合目前现状与可优化点，我们期望能像 Uraya 质量分检测一样，在 MR 过程中通过流水线自动触发，中途每次代码提交也能自动触发，对于流水线中的 CR 不满意时，可以结合 Apex CR 智能体进行本地 CR 调整代码。

为此我们考虑结合 Cursor Agent CLI 在流水线中增加一个 AI CR 的任务，自动触发 Cursor Agent 代码 CR，并记录 CR 结论，及时展示给研发或者代码评审的同学，辅助代码质量优化。

整体链路设计如下：

• 当研发创建 MR 后，流水线配置了 AI CR 检测流水线后，将会自动触发 Cursor Agent CR 任务。
• 接收到检测任务后，将会前置将该仓库准备好，并将 MR 的信息以及制定的 CR 规则，一并交给 Cursor Agent CLI 执行，待执行完成，会得到一份 CR 报告。
• 接收到检测任务完成后，目前会通过 MR 评论的方式添加到对应的 MR 中，引导用户查看。
• 对于开发者视角，打开审查报告，可以根据审查出的问题，进行修改。
• 对于 CR 人员视角，打开审查报告，可以根据审查出的问题，一键添加到评论，引导开发者修改。

五、MR 流水线接入与 AI CR 报告

自动触发

以下图 MR 为例，在 MR 流水线中，添加了仓库流水线 AI 检测的检测任务，当创建 MR 时，会自动触发执行一次，在 MR 未合入的过程中，每次代码变更也会自动触发。

添加审查报告评论

检测完成后会自动添加一条 MR 评论，通知研发已完成检测，可以点击查看 CR 报告。评论概览中有审查摘要，显示聚类问题的数量；还有审查总结，即对所有反馈的总结，概览问题。

AI CR 报告

以下为实际 MR 生成的 CR 报告，可以看到，报告主要包括：MR 的基础信息、问题的分类 Tab、问题的具体描述、问题的操作。

具体问题列表

首先报告列表会对问题进行聚类，分为严重问题、警告、建议三类，切换对应 Tab 可以看到问题列表。具体的问题信息，主要有类型、问题代码、修复后代码、描述、文件路径、行号、操作等列。

添加到评论

点击操作列的添加到评论，将会一键将相关问题的信息，生成格式化描述，添加到 MR 的评论中，提醒开发者关注问题、解决问题。

AI 智能解决

点击操作列的 Cursor 解决，将会一键将相关问题的信息，生成解决问题 Prompt，一键打开本地 Cursor ，创建 Agent 对话去解决问题。打开链接后，Cursor 会先接收 Prompt ，你可以简单浏览下，点击 Create Chat ，即可一键创建 Chat，回车执行修复。

Cursor Prompt 预览

Cursor Prompt 预览 确认填入 Chat 执行

复制 Prompt

点击复制 Prompt，支持一键复制修复问题 Prompt，可以放到期望的 IDE 里使用。如下图，就是复制的 Prompt 示例。

六、推荐研发流程实践

尽早创建 MR

当需求分支第一次提交后，就可以创建到 release 或 test 目标分支的 MR 了，后续每次提交代码都将会自动触发检测，产出 AI CR 报告。

研发自主查看与解决

研发收到 AI CR 报告的通知后，可以及时打开 CR 报告查看，确认反馈的疑问点是否需要调整，如果需要调整可以通过 Cursor 一键解决，将问题解决前置到提测以前，这样所有的改动可以尽可能的被测试同学验证到。

人工 CR

发布前最后的人工 CR 可以通过前置的 AI CR 发现与问题前置解决，大幅提升靠最后人工 CR 的反馈、修改等环节效率。特别是当业务需求代码量较大时，人工 CR 浏览的效率和质量也是无法保证的。

七、内置提示词工程

AI CR 其实就像给 AI 一个详细的检查清单。这个清单分两部分：一部分是基本规则，比如"你要扮演什么样的角色"、"按什么流程检查"；另一部分是具体的技术要点，比如"注意空指针问题"、"检查React用法是否正确"等。有了这个清单，AI 就能像有经验的程序员一样，系统地检查代码，发现各种潜在问题，让代码质量得到保障。

具体这个规则体系的结构如下：

.cursor/rules
├── 00-role-and-constraints.mdc          # 角色与约束 - 定义AI代码审查助手的角色和基本约束条件
├── 01-workflow-steps.mdc                # 工作流程步骤 - 描述代码审查的工作流程和步骤
├── 02-detection-standards.mdc           # 检测标准 - 定义代码问题的检测标准和准则
├── 03-output-format.mdc                 # 输出格式 - 规定代码审查结果的输出格式和规范
├── 04-best-practices.mdc                # 最佳实践 - 提供代码审查中的最佳实践建议
├── common                               # 通用规则目录 - 包含各种常见的代码问题检测规则
│   ├── 01-null-pointer-defense.md       # 空指针防御 - 防止空指针异常的最佳实践
│   ├── 02-react-hooks-usage.md          # React Hooks 使用 - React Hooks 的正确使用方式
│   ├── 03-data-merge-state.md           # 数据合并状态 - 处理数据合并时的状态管理问题
│   ├── 04-async-programming.md          # 异步编程 - 异步编程模式和常见陷阱
│   ├── 05-memory-leak-performance.md    # 内存泄漏性能 - 检测和防止内存泄漏问题
│   ├── 06-security-coding.md            # 安全编码 - 安全编程实践和漏洞防范
│   ├── 07-compatibility.md              # 兼容性 - 确保代码兼容性的检查点
│   ├── 08-git-conflict-detection.md     # Git 冲突检测 - 检测并解决 Git 合并冲突
│   ├── 09-code-quality.md               # 代码质量 - 代码质量评估和改进规则
│   ├── 10-resource-handling.md          # 资源处理 - 正确处理系统资源的规则
│   ├── 11-url-params.md                 # URL 参数 - URL 参数处理的安全和有效性检查
│   ├── 12-business-logic-consistency.md # 业务逻辑一致性 - 确保业务逻辑一致性的规则
│   └── 13-monorepo-dependency.md        # 大仓依赖 - Monorepo 架构中的依赖管理规则
└── README.md                            # 说明文档 - 规则系统的介绍和使用说明

八、模型选择

在 AI CR 环节，模型的选择需要考虑模型对于代码理解的复杂性、上下文长度需求以及推理准确性、模型的速度、模型的使用成本等考量。在 Cursor 的模型列表中，我们优先使用 Compose 1.5，当额度不足时，我们也会降级使用 Auto 模型。

以下为 Cursor auto 模型与 Composer 1.5 模型对比，可以看出，两个模型都找出了 4 个问题，但在时间上，Composer 1.5 进行需 44 秒即可完成，而 auto 模型需要 91 秒。

九、总结与规划

通过多个迭代实践与数据统计，Cursor Agent CR 挖掘的有效问题数可以达到 50% 左右，研发使用的意愿也相比原来有不少提升。当前我们也在将 AI CR 报告融合到 Cursor IDE 插件中，进一步融合到研发流程里。

随着 AI 生成代码在开发流程中越来越普遍，AI CR 的重要性将进一步凸显。相比传统的人工审查，AI 审查能够自动发现 AI 生成代码中可能存在的逻辑错误、安全性问题和规范性缺陷，提前在开发过程中消除隐患。同时，AI CR 还能确保 AI 生成的代码符合团队的技术规范和最佳实践，保持代码风格的一致性。为 AI 时代的开发流程提供了可靠的质保机制，让开发流程更加顺畅，是现代软件开发的重要保障。

往期回顾

1.从IDE到Terminal：适合后端宝宝体质的Claude Code工作流｜得物技术

2.AI编程能力边界探索：基于 Claude Code 的 Spec Coding 项目实战｜得物技术

3.搜索 C++ 引擎回归能力建设：从自测到工程化准出｜得物技术

4.得物社区搜推公式融合调参框架-加乘树3.0实战

5.深入剖析Spark UI界面：参数与界面详解*得物技术

文 /大圣

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。