手把手带你实践历时一年总结的 AI Code Review 最佳工作流！

引言：AI Code Review 好做吗？

因为公司一直非常注重 Code Review，基本上每一个功能合并到版本分支都需要代码审核，并且可能还会有多人审核，所以从 2024 年底我就开始着手公司内部的 AI Code Review ，一开始团队自建了 Code Review 工具，并且迭代了很多版，效果总的来说都不太行，后来又用了商用付费的产品 ，觉得太贵了，总体性价比不高 ，去年 SKills 出来之后，我找到了最佳实践。真的是做了一年，我来说一下我的历程吧。

本文会详细从工程化的角度，平衡团队支出和收益的 ROI ，得出的本地 AI Code Review 方案，我觉得这才是中小团队、业务研发组的最优解，整体方案是以 Cursor 为核心，结合 MCP 能力和自定义 Skills ，用团队过去一年的真实 PR 作为数据源，然后可以不断提高 AI Code Review 的落地方案，既不用承担自建的高成本，也能规避第三方商用付费产品的黑盒问题，让 AI 审代码真正贴合团队的真实研发场景。

按照惯例，依旧先提出一个问题，符合团队流程和规范的 AI Code Review 好做吗？

一、当下AI Code Review的两大主流路径

目前行业内做 AI Code Review 主要有两个方向：自建平台和用第三方工具。但在我实际落地和调研中，这两条路都存在难以解决的硬伤，看似美好，实则很难在团队中持续落地。

1.1 自建AI Code Review平台：核心设计思路与实战细节

我们团队最初是自建 AI Code Review 平台， 24 年底 25 年初的时候我对 AI 很狂热，有点盲目崇拜打鸡血的感觉，觉得 AI Code Review 搭建难度不高，做好了 KPI 应该会不错，就一拍脑袋 就做了------初期快速做了多个demo，一开始挺兴奋的，想着先闭环，再提质，再工程化，不追求一步到位，而是分阶段聚焦核心痛点解决。

第一个版本通过 Github Action 事件驱动触发，然后 AI Review ，然后评论到评论区。仅能完成基础语法、代码风格检查，缺乏业务理解和上下文感知能力，落地效果不佳。

第二个版本加上了 RAG （将历史问题、项目部分业务点和模块、代码规范向量化存入向量库 ），包含了业务、历史 PR 的数据，维护了一个向量库 ，算是做到了部分业务的感知能力，因为 RAG 维护需要精力，RAG 的速度和质量也很难把控，并且需要自己维护 Token 长度和上下文，成本一下子就上去了，并且总体 Review 效果还是没达到我的预期。

总的来说，当时落地有4个点让我有点棘手：

业务理解断层，即便有RAG，也难精准捕捉跨文件业务约束(时间成本太高，我们只是想做代码 Review，却自己要实现一套代码的 RAG 方案)；
长Diff处理复杂，需做 Token 估算、优先级排序和多 Chunk 结果聚合，否则质量和时效会失衡；
RAG召回噪音，知识召回不准，导致 AI 幻觉和误报，需要加人维护；
安全合规，业务代码外发公有 API 有泄露风险，最终必须投入高成本做内网私有化部署，虽然当时我们内部已经有私有化部署的模型，但私有化部署的模型能力往往比闭源的傻很多很多，所以效果更加不好了。

最终实现下来，就发现投入产出比很低，投入的人越来越多，但反馈却很差。一步一步的失去了士气，陷入"投入大于回报 "的困境，最终平台无人维护了。那一刻我真的意识到，好的 Code Review 工具真的不容易做出来。

1.2 第三方AI Code Review工具：贵且不贴合的黑盒

后来想着自建不行，那就找找第三方的工具吧，一开始先是找了一些开源的工具，然后又找了一些收费的，我们当时找的是 PR-Agent ，类似还有GitHub Copilot、Cursor Bugbot ，还有今年 Anthropic 推出的 Claude Code Review ，但这些工具也各有各的问题，总结下来就是价格高、按人头收费，Review 偏黑盒化、部分工具定制化程度低，容易绑定某一家产品（全家桶）。

因为我们公司有 Github 团队商业版和 Cursor 团队版，后来我又试用了 Cursor 的 Bugbot ，说实话能力还可以，但他的上下文感知能力貌似没有本地的强，并且价格太贵了，团队伙伴一个人一个月 40 美金，还是在Cursor 之上另外收的（加起来70美金），还会有团队的 PR 200次一个月的上限，咱实在用不起 。

1.3 半自建 + 服务器安装 Cursor 审查流水线

因为之前自建过 Code Review，我手上有闲置的服务器资源，我就想到一个骚操作，就是单独拿一个 Cursor 的团队号部署在服务器上面，然后每次 Webhook 触发 PR 事件的时候，就在那台服务器上命令行运行 Cursor 的 Code Review 命令 ，然后一个月有 500 次的 Claude Opus，一下子就把成本打下来了。相当于原来的 40 $∗团队人数的成本，降低成了一个月30 * 团队人数的成本，降低成了一个月 30$ ∗团队人数的成本，降低成了一个月30，并且把 200 的次数变成了 500 的次数，并且因为相当于本地 Codebase ，感觉 Code Review 更加准了。

1.4 到底是自建还是第三方呢？

虽然上面这个骚操作挺好用的，但这 3 个方案有 2 个我觉得很不舒服的问题。

不管是自建还是第三方工具都是通过事件触发 PR，AI Review 完之后会自动输出代码报告到 Github 评论区，有些同事会完全信任 AI 的评论，然后看了一下就直接点了通过（AI真的能背锅吗 ），而我会觉得应该是 AI 辅助，然后 Review 代码的人选取 AI 的报告，手动填写到上面，这样会更加可信
Code Review 评论留在 Github 上，如果业务很复杂，改的人还需要打开编辑器去理清逻辑，这一步很麻烦，为什么不能直接在编辑器里面 Review 呢？（虽然后面的一些 PR 工具能直接在 Github 页面一键唤醒编辑器）

二、工程化本地AI Code Review方案：Cursor 为核心的闭环落地

既然自建和第三方都有硬伤，那有没有一种方案能兼顾低成本、高定制、易落地？

因为在自研和使用第三方工具的过程中，第三方工具确实有一些好的点记在我的脑子里。随着去年 Cursor 能力的不断提升和 Skills的出现，我发现时机到了，我就设计了一套以 Cursor编辑器为核心的工程化本地AI Code Review方案 ------利用Cursor的Codebase能力、MCP接口，结合自定义Skill，再用团队真实PR数据形成"数据采集-规则优化-效果验证"的闭环，让AI Code Review真正融入团队的日常研发，而且全程无需高成本投入，普通研发就能维护。

这套方案的核心逻辑很简单：AI不是替代人做Code Review，而是成为人的"辅助助手"，责任人始终是研发和Reviewer，AI 只负责按照团队的规范，快速筛查重复、常见的问题，节省人工Review 的时间。而 Cursor 作为当下对代码库理解能力数一数二的编辑器，自带的 Codebase 功能能完美解决上下文感知问题，无需自建 RAG。

这是一套符合团队业务的工程化工作流，而不是具体的 Code Review 细节和规范

下面我用一个实际案例，完整拆解这套方案的落地流程，大家可以直接照抄。

2.1 案例背景：场景角色与核心目标

场景角色 - 场景角色：研发团队（10人），有明确的代码规范（如金额计算用高精度数值类型、禁止硬编码魔法值、接口必须做参数校验），日常使用GitHub管理代码，每人每天提交1-2个代码合并请求。
核心目标：用AI辅助完成 Code Review，快速筛查团队常见问题，让人工 Review 聚焦于架构设计、业务逻辑等核心环节，同时保证 AI 的审查规则完全贴合团队规范，成本控制越低越好。
准备工作：团队 GitHub 仓库近 1 年的代码合并请求评论、团队已制定的代码规范文档，越完善越好、并且有使用任意一款 AI Coding 工具（我这里以 Cursor 举例）。

2.2 落地流程：从规则梳理到闭环形成

这套方案的落地分为四个核心步骤，全程由团队的前端/后端研发就能完成，每一步都有具体的操作方法和产出，落地性极强。

步骤1：采集团队真实PR数据，提炼常见审查问题

AI 审代码要贴合团队规范，首先要知道团队最常出现的问题是什么。我是用脚本抓取团队代码仓库中近 1 年的所有代码合并请求评论，这是最真实的**"问题库"**，比凭空制定规则更有价值。

以 GitHub 为例，可编写一个简单的脚本，通过GitHub接口拉取所有代码合并请求的Review评论，将其整理并保存到 review-log.md 文档中，执行脚本时只需配置GitHub的授权令牌即可完成采集。

采集完成后，对收集到的评论进行归类分析，提炼出团队出现频率最高的问题，比如常见问题分类有：

类型安全 适用于：类型断言绕过检查、非空断言、不安全的数组索引访问、类型导入不规范、运行时缺少类型校验、函数入参过宽、常量类型收窄缺失。
模块与边界 适用于：路径组织不清晰、模块暴露过多内部细节、全局类型污染、依赖引用层级过深、模块职责边界不明确。
组件与交互 适用于：未复用统一封装组件、组件 API 设计不一致、重复实现相似交互、弹层类组件显隐控制不当、列表渲染方式存在 key 风险、桌面端与移动端能力未合理复用。
请求与状态 适用于：请求触发方式不合理、轮询实现不规范、异步状态设计不完整、派生状态落地、状态冗余、卸载时未清理状态、副作用管理不当、独立异步任务未并行处理。
样式与主题 适用于：硬编码样式值过多、未使用统一设计变量、类名管理方式不统一、文本截断方案不一致、样式覆盖方式不合理、可访问性相关样式配置不当。
命名与结构 适用于：命名含义不清、未使用代码残留、职责混杂、嵌套过深、缺少 early return、文案 key 过于通用、常量组织无序、重复实现已有能力。
错误处理与安全 适用于：环境变量使用方式不当、本地持久化数据缺少校验、用户隔离数据清理不完整、下载或跳转方式不安全、资源未正确释放、依赖管理不稳定、错误处理缺失或被静默忽略。
数据展示 适用于：空值展示不统一、数值兜底不合理、金额或计数字段展示规则错误、特殊值展示存在歧义。
测试适用于：测试文件组织不规范、测试框架使用不统一、回归测试命名不一致、测试配置覆盖方式不合理。

步骤2：编写Cursor Custom Skill，固化团队审查流程与规则

Cursor 的Custom Skill是这套方案的核心，它可以把团队的Code Review流程、审查规则、问题处理方式固化下来，让AI严格按照团队的要求进行审查，相当于给AI制定了"工作流"。

基于我们团队的Review流程和重点关注的点，我主要设计了 7 个步骤

获取 diff -> 变更摘要 -> 影响点评估 ->架构评估 -> 逐文件审查 -> 格式化输出-> AI自动修改

针对这 7 个步骤，我又详细写了规范，具体规范参考自己项目的实际情况，无非就是写 Prompt,如果不知道怎么写 Prompt 可以阅读我之前写的文章企业级 Prompt 工程实战指南（下）：构建可复用 Prompt 架构平台。

Skill.md 里面要明确审查的触发场景，规定审查的先后顺序，明确禁止绕过静态检查等核心约束，同时细化逐文件审查的优先级，重点聚焦团队高频问题，还规定了每条审查反馈的格式和严重等级标签，确保反馈清晰、可落地。

这里有个关键动作：Cursor 的 Skill 编写本质是梳理团队的常规 Review 流程，不需要复杂的开发能力，只要把团队的 Review 流程、规则写清楚即可，普通研发半天以内就能完成。

步骤3：对接MCP能力，实现本地/远程PR的无缝审查

Cursor 可以通过本地 git 或者 github mcp 工具、即时的拉取或者对比代码差异内容，全程无需离开编辑器，研发可以在写代码、提代码合并请求的过程中随时触发AI Code Review，体验会好很多。

触发方式非常简单，在 Cursor 中输入指定指令即可：审查本地变更或审查指定编号的GitHub代码合并请求 。AI会严格按照自定义Skill的规则进行审查，输出结构化的反馈，比如针对"金额计算用普通浮点类型"的问题，会明确指出问题所在的文件路径和行号，说明问题的危害（如精度丢失），并给出具体的修复建议（替换为高精度数值类型并补充参数校验） 。研发能直接从编辑器的反馈中看到问题、原因和修复方案，效率大幅提升。

这里为什么要把原来远端的 Code Review 放到本地呢？

1.对于开发的同学，有些粗心的同学写完代码都不 Review 一下自己的烂代码就推送上去了，放到本地可以让开发在推送代码前，自己可以运行一下命令，看看是否可以优化代码，防止把屎山推上去。

2.对于 Review 的同学，防止他们完全信任 AI，AI 只是辅助，所以 AI 不会输出评论到 Github 上，Review 的同学需要看完 AI 的结果，手动写评论到 Github 上（有时候 AI 有幻觉或者 SKill 写得不好，AI 输出质量不行），如果觉得没问题，那就写上 LGTM（look good to me） 这时候责任人就是 Review 的同学，而不是 AI 了

步骤4：形成数据闭环，持续优化Skill规则

一套好的AI Code Review方案，不是"写好Skill就完事"，而是要基于团队的真实使用数据持续优化，形成**"数据采集→规则优化→效果验证"的正循环，让AI的审查能力越来越贴合团队的需求。**

具体操作方法：每1个月执行一次数据采集脚本 ，采集这 1 个月的仓库的合并请求的Review 评论；因为评论是人写上去的，而不是 AI 写上去的，所以基本上都是质量高的 review 评论数据。然后**将新的问题、新规范添加到Custom Skill中，补充对应的审查逻辑和反馈建议；**优化后，随机抽取几个代码合并请求进行AI审查，对比人工Review的结果，验证AI的问题识别率是否提升。

我在的团队经过3次规则优化，AI的高频问题识别率从最初的 70%提升到90% ，人工Review的时间 平均减少了60%，Bug 数下降 20% ，原本一个代码合并请求的 Review 需要15分钟，现在只需5分钟就能完成核心环节的审查。

这套方案始终坚持"AI辅助，人为主导 "的原则：最终的代码评论权在人工Reviewer手中，AI不会成为**"背锅侠"**，这也解决了很多团队担心的"AI审错谁负责"的问题，随着 PR 越多，review-log 越丰富，规则越完善，AI review 越来越像人

HTML 复制代码

历史 PR 评论 ──采集──→ review-log.md
       ↓
   提炼规律 ──抽象──→ RULES.md
       ↓
   编排流程 ──执行──→ SKILL.md（AI 自动 Review）
       ↓
   新 PR 产生评论 ──再采集──→ review-log.md（更新）
       ↓
   发现新模式 ──再抽象──→ RULES.md（迭代）
       ↓
       ... 循环 ...

简单来说，整体流程是这样的，每一轮迭代：

跑一次脚本，拉取最新的 PR 评论
分析新评论中反复出现的新问题模式
提炼为新规则补充到 RULES.md
AI 下次 review 时自动应用新规则

最后执行 AI Review 之后，会产生这种效果

三、这套本地方案的核心优势，完胜自建和第三方

在多个团队落地验证后，我发现这套以 Cursor 为核心的工程化本地AI Code Review方案，完美解决了自建平台和第三方工具的痛点，核心优势体现在成本、适配性、落地性、可维护性四个方面，也是它能在团队中持续落地的关键：

3.1 零高成本投入，普通研发就能维护

无需搭建服务器、无需维护RAG体系、无需专业维护人员，仅需Cursor编辑器的基础费用（现在谁写代码不用 AI），大模型调用在Cursor内部完成，无需额外付费。Skill 的编写和优化由团队研发完成，半天内就能上手，后续的规则更新也只需修改Skill文件，维护成本极低。

3.2 天然的上下文感知，无需自建RAG

Cursor 的 Codebase能力是当下编辑器中对代码库理解能力数一数二的，它能深度分析团队的代码库结构、跨文件调用、业务逻辑，无需像自建平台那样搭建RAG、维护知识库，就能让AI拥有精准的上下文感知能力，审代码时能识别跨文件的问题。

3.3 100%定制化，完全贴合团队规范

自定义Skill可以把团队的所有规范、高频问题都固化进去，从通用的语法错误到团队特有的业务规则，AI都会严格按照规则审查，这是第三方工具无法做到的。而且Skill可以随时修改，团队新增规范、发现新问题后，只需更新Skill文件，AI就能立即适配。

3.4 融入研发流程，可迁移其他平台

这套方案全程在 Cursor 编辑器中完成，研发在写代码、提代码合并请求的过程中可以随时触发AI Code Review，无需切换到其他平台，发现问题直接在编辑器内让 AI 去解决，完美融入团队的日常研发流程。相比之下，自建平台需要研发学习新的操作流程，第三方工具需要切换平台，落地难度都远高于这套本地方案。而 Skill 是各家平台都支持**，Cursor 可直接复用到 Claude Code 上，0 成本**

3.5 形成数据闭环，AI能力持续进化

基于团队真实的代码合并请求数据持续优化 Skill 规则，让AI的审查能力越来越贴合团队的需求，形成正循环。而自建平台的RAG维护是**"被动更新"，第三方工具的规则的数据源是 AI + 人产生的，比当前这套"人过滤 AI评论之后"**的数据源质量要差很多。

四、总结与未来趋势：AI Code Review的核心是"贴合团队"

AI Code Review 的落地实践，除了我自己的实践之外，市面上我看到过很多自建的方案，我最深的感受是：AI Code Review 的核心不是技术多先进，而是能否贴合团队的真实研发场景。自建平台的技术再强，成本太高、维护太难，最终会沦为摆设；第三方工具再便捷，定制化差、无法贴合规范，参考价值极低。

而这套以 Cursor 为核心的本地方案，看似简单，但他 ------低成本、可落地、能直接抄。通过 "Codebase+MCP + 自定义 Skill+PR 数据闭环" 的组合，不用复杂配置，普通研发半天就能上手，真正融入日常流程。

本质上，**AI Code Review 的核心是人机协同：**AI 帮你筛掉以前出现过的问题，人聚焦架构设计、业务逻辑等核心环节，不用被琐事消耗。

最后想说：AI 审代码不是炫技，能落地才有用。 与其纠结高大上的自建平台或昂贵的第三方工具，不如直接套用这套可复制的本地方案 ------ 简单、好懂、抄了就能用，这才是中小团队最高效的提效选择。

顺便我会把这套能学会，抄的走的企业级 Code Review 方案送给我的粉丝们.

关注公众号：深入浅出AI ，并且回复，Code Review 获取这套方案的源代码，