Java合并请求代码审查Skill：让每一次 Merge Request 都先过一遍「资深架构师」的眼
- 一个专门审 Java MR 的技能：mr-review 面向 51job 搜索推荐引擎（searchengine）这类 Java 后端项目，按「需求基线 → 代码变更 → 规范审查 → Merge 判定」的完整链路输出结构化审查报告。
- 先问需求，再看代码：技能把「需求上下文收集」设为阻塞步骤，没有需求基线就不允许拉取 diff，从流程上避免把技术设计当成产品需求。
- 审查维度非常具体：覆盖代码规范（阿里巴巴 Java 开发手册 + Google Java Style）、空指针与异常、并发线程安全、资源管理、性能与架构、日志、安全、项目特殊约定、测试规范共九大维度。
- 输出可直接用于评审会：报告含 MR 概述、需求符合度、架构一致性、按文件问题详情（带代码片段与修复建议）、统计汇总、Checklist、Merge 判定，问题分 Critical / Major / Minor / Info 四级。
- 适合谁用：Java 后端开发、技术负责人、代码评审人，尤其是使用 Spring Boot + Elasticsearch + gRPC 架构的搜索推荐类项目团队。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | Java合并请求代码审查Skill |
| 英文名 | mr-review |
| 技能 ID | 2120455933480566786 |
| 核心定位 | 对 Java 项目的 Merge Request / Pull Request / git diff 进行高质量 Code Review |
| 面向项目 | 51job 搜索推荐引擎（searchengine），可迁移到同类 Java 后端项目 |
它解决什么问题
在真实研发流程里，代码评审最常见的三个痛点是：
- 评审靠人肉、标准不统一：同一个 MR，不同评审人关注点完全不同，有人只看命名，有人只看逻辑，性能与并发问题经常被漏过。
- 需求与代码脱节：评审时没人对照需求文档逐条核对，导致「代码写得挺优雅，但需求漏了一半」，或者反过来「做了需求里没要求的功能」。
- 评审意见不可执行：只写「这里不太好」「建议优化」，没有代码片段、没有修复示例、没有规范出处，作者改起来全靠猜。
mr-review 的思路是把一位「10 年以上 Java 后端开发与架构经验」的审查专家的判断流程固化成一个技能：先锁定需求基线，再拉取变更，然后逐文件、逐维度审查，最后给出明确的 Merge 判定。它不是泛泛地「看看代码」，而是按一张写死的清单逐项打勾。
一键安装 AI 技能提升效率的思路与步骤
「一键安装」的本质，是把这个技能作为一个可复用的能力包挂载到你日常使用的 AI 编程助手或对话客户端中，之后每次审查 MR 时直接唤起，而不需要重复粘贴一大段提示词。
安装前提：
- 一个支持 Agent Skill / 自定义技能导入的 AI 编程助手或对话客户端（具体支持情况以官方说明为准）。
- 待审查的 Java 项目仓库访问权限（本例为 searchengine 代码库）。
- 若希望自动拉取 MR diff，建议提前配置好 GitLab MCP 或等价的 GitLab API 访问方式；未配置时可用手动粘贴 diff 的降级方案。
安装步骤（通用流程，具体命令与入口以官方说明为准）：
- 获取技能包：拿到 mr-review 技能文件（技能详情中以
name: mr-review与description标识，属于标准技能描述格式）。 - 导入技能：在客户端的技能管理入口中导入该技能，或将其放入客户端约定的技能目录。导入时请保留原有
name与description字段，这是技能被正确唤起的关键。 - 配置代码访问能力（可选但推荐）：配置 GitLab MCP，使技能可以通过
GET /api/v4/projects/{project_id}/merge_requests/{mr_iid}/changes这类接口获取 MR 变更；若不配置，则走手动粘贴 diff 的方式。 - 验证是否生效：新开一个会话，问一句「帮我审查一个 MR」。如果技能生效，它不会立刻要 diff，而是先反问你「本次 MR 是否有需求文档？请提供链接、粘贴需求文本，或明确回复『没有需求文档』」——这一步「先问需求、再取变更」的阻塞式提问，就是最可靠的生效信号。
- 跑一次真实 MR：提供 MR URL 或粘贴 diff，观察输出是否包含「需求符合度评估」「架构一致性评估」「按文件审查详情」「Merge 判定」等固定章节。
提示：技能详情中并未给出具体的下载链接、安装命令或定价信息，相关细节请以官方说明为准，不要轻信第三方转述。
该技能的主要功能和特点
- 阻塞式需求门禁（步骤 0）：在拿到任何代码变更之前，强制先确认需求基线状态，并记录为
provided（已提供可读链接或文本）、none（明确没有需求文档）、unavailable（只有无法访问的链接）三种之一。用户不回复，就不进入审查。 - 禁止自行「脑补」需求：明确规定不得从
.docs/、doc/、提交信息或代码中推断产品需求；技术设计文档只能作为实现背景，不能当作需求审查基线。这一点比大多数 AI 审查工具严谨得多。 - 需求追踪表：对每个需求点建立
需求编号 → 变更文件/符号 → 测试或运行证据 → 状态的追踪记录，状态只能是「已实现、部分实现、未实现、无法验证」四种，没有代码或测试证据就不许判定为「已实现」。 - 九大审查维度逐项覆盖：代码规范、潜在 Bug、并发与线程安全、资源管理、性能与架构、日志规范、安全性、项目特殊约定、测试规范。
- 架构一致性专项检查：新增 Service 是否满足 Interface + Impl + MonitorDecorator 三层结构、decorator 是否真正委托 delegate、构造器注入是否造成 Bean 歧义、gRPC 是否带
@GrpcService并继承*Grpc.*ImplBase、Pipeline 是否在BaseModuleProvider注册、召回类是否在RetrievalServiceChooser与RetrievalCreateFactory注册、排序特征是否在VariableShop注册、动态配置是否走 Nacos。 - 四级严重程度分级：Critical（🔴 必须修复后方可合并）、Major（🟠 强烈建议修复）、Minor（🟡 建议修复）、Info（🔵 可选采纳），并配套明确的 Merge 判定标准。
- 可执行的修改建议：每个问题都要求给出 2-6 行上下文代码片段和具体的修复代码示例，并标注违反的规范出处（阿里巴巴 Java 开发手册条款、Google Java Style 条款、Effective Java 条目或项目内部约定）。
- 只审变更、不背历史包袱：明确要求只审查本次 MR 的变更部分，不能把未修改的历史问题冒充成 MR 问题，避免评审报告变成「翻旧账」。
和普通工具相比强在哪： 传统静态扫描工具擅长发现语法级和规则级问题，但无法判断「这个 Service 少了 decorator 是否符合本项目约定」「这段代码是否覆盖了需求第 3 条」；而通用 AI 对话虽然能读代码，却缺少稳定的审查框架，每次输出的深度和口径都不一样。mr-review 把「规范检查 + 需求核对 + 架构约定 + 可执行建议」这四件事打包成了固定流程。
如何使用该技能？
第一步：唤起技能并回答需求问题
在会话中直接提出审查诉求，例如：
「帮我审查一下 searchengine 项目的这个 MR，链接是 {MR URL}。」
此时技能会先反问需求文档情况。你可以这样回答：
「需求文档在 {需求链接}，核心有两条：1）简历搜索支持按期望城市过滤；2）过滤条件为空时不改变原有召回结果。」
或者明确回复：
「没有需求文档，只做代码与架构层面的审查。」
也可以在一开始就把需求文本和 MR 链接一起给出，这样视为已完成提问，技能会直接记录为 provided。
第二步：提供代码变更
两种方式任选：
- 方式一（推荐）：已配置 GitLab MCP 时，技能通过 API 拉取 MR diff，你只需提供 MR URL，或 project_id + mr_iid。
- 方式二：在 GitLab 页面复制变更文件的 diff，或粘贴完整
git diff输出到对话中。
第三步：等待分阶段审查
技能会依次执行：理解变更范围（识别修改文件、判断所属模块如 resume/job/common/autocomplete/subscribe/sensitive-word/ai-nexus、确认变更类型是新增功能 / Bug 修复 / 性能优化 / 重构）→ 逐文件审查 → 需求符合度评估 → 架构一致性评估 → 汇总输出。
第四步：阅读结构化报告并处理问题
输出报告固定包含八个章节：MR 概述、需求符合度评估、架构一致性评估、按文件审查详情、统计汇总、审查 Checklist、Merge 判定、总结与建议。
举一个「按文件审查详情」中的典型问题样式（示意）：
- 问题：循环内逐条查询 Redis，存在 N+1 调用
- 严重级别：Major（🟠）
- 潜在风险：简历列表页单请求 Redis 调用次数随结果数线性增长，高峰期易触发超时
- 修改建议：改用批量
mget，或对热点数据引入 Caffeine 本地缓存 - 参考规范：阿里巴巴 Java 开发手册（性能规约）/ 项目内部约定
第五步：按 Merge 判定推进
报告的 Merge 判定只有三种结论：✅ 可以合并、⚠️ 建议修复后合并、❌ 不可合并。判定标准写得非常明确：存在 Critical、≥2 个 Major、业务逻辑缺陷或安全漏洞，一律「不可合并」；需求基线为 unavailable 时，不得以需求符合度作为通过依据。你可以直接把这份结论贴到 MR 评论区，作为评审记录。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| mr-review（本技能） | 面向 Java 后端 MR 的 AI 审查专家 | 需求门禁 + 九维审查 + 架构一致性核对 + 分级问题 + Merge 判定 | 需在支持技能的 AI 客户端中导入；可选配置 GitLab MCP；门槛中等 | searchengine 类 Java 项目、需对照需求评审的 MR | 优势：流程严谨、需求追踪可验证、建议可执行、贴合项目约定；不足：强依赖用户提供需求上下文，首次使用需回答门禁提问，非 Java 项目收益有限 |
| SonarQube 等静态代码扫描工具 | 规则引擎式代码质量平台 | 代码异味、重复率、覆盖率、安全规则扫描 | 需部署服务端与配置扫描流水线，门槛较高 | 持续集成中的自动化质量门禁 | 优势：自动化、可量化、覆盖率高、可接入 CI；不足：不理解业务需求，无法判断架构约定是否符合项目惯例，建议偏规则化 |
| 通用 AI 编程助手（对话式） | 通用代码理解与生成 | 代码解释、重构建议、Bug 排查 | 门槛低，直接对话即可 | 日常编码辅助、局部代码答疑 | 优势：上手快、灵活；不足：审查口径不稳定，缺少固定维度清单与需求追踪，容易漏项，难产出可归档的评审报告 |
| 人工代码评审（团队评审会） | 人与人之间的评审机制 | 经验判断、业务上下文、责任把关 | 无技术门槛，但占用资深工程师时间 | 高价值变更、关键模块上线 | 优势：业务理解最深、可做最终决策；不足：成本高、标准不统一、容易受时间与精力限制而形式化 |
选择建议：把 mr-review 当作「评审前置的自动化第一轮」，先让技能跑一遍产出结构化报告，再由人工聚焦在 Critical / Major 和业务判断上，既压缩了评审会议时间，也统一了团队口径。静态扫描工具仍然建议保留在 CI 中，两者并不冲突——一个管规则，一个管逻辑与需求。
该技能的典型应用场景与实际体验情况
场景一：后端开发提交 MR 前的自查
角色：Java 后端开发工程师。痛点：写完代码自己看不出问题，提交后被评审人打回，来回几轮耽误排期。
使用方式：提 MR 前先把 diff 和需求要点发给技能，让它跑一轮。重点看「潜在 Bug」「并发与线程安全」「项目特殊约定」三块。
实际体验：上手难度低，第一轮就能暴露不少「循环内远程调用」「catch (Exception e) 吞异常」「字段注入而非构造器注入」这类硬伤。注意事项：需求描述要写清楚，否则需求符合度一节会提示「无法验证」，无法发挥最大价值。
场景二：技术负责人做合并前的质量把关
角色：Tech Lead / 架构师。痛点：每天要看好几个 MR，逐个深挖不现实，但又怕放过 Critical 问题。
使用方式：把 MR URL 交给技能，直接看「统计汇总 + Merge 判定 + 必须修复项」三节，再抽查按文件详情中的 Critical / Major 条目。
实际体验：Merge 判定标准写得很死，不会给出模棱两可的「基本没问题」，这对把关很有帮助。注意事项：技能详情明确要求区分事实与建议——Critical / Major 是基于缺陷的客观判断，Minor / Info 是主观建议，评审时需要按这个权重分配注意力。
场景三：新增 Service / 新增入口的架构一致性核查
角色：模块 owner。痛点：新人加了 Service 却漏了 MonitorDecorator，或新增 gRPC 服务忘了正确继承基类、新增召回类没在 RetrievalServiceChooser 注册，上线后才发现监控缺失。
使用方式：在 MR 中标注本次为「新增 Service」或「新增框架入口」，让技能输出「架构一致性评估」表格，逐行核对「检查对象 / 预期约定 / 实际证据（文件与符号）/ 结论」。
实际体验：这是该技能最有辨识度的能力。技能会先检索同模块既有实现来判断约定是否成立，避免仅凭类名就断言「可选」；无法从 diff 证明注册成功时会标「无法验证」而不是默认通过。注意事项：需要保证 diff 完整，否则容易产生大量「无法验证」结论。
场景四：需求验收阶段的逐条核对
角色：需求方 / 测试 / 项目经理。痛点：需求文档写了 8 条，代码到底实现了几条没人说得清，配置项和开关还经常漏。
使用方式：提供需求文档链接或粘贴需求文本，让技能输出「需求点 → 实现状态 → 说明」的对照表，并检查需求中提到的配置项、开关、权限、接口兼容性和异常场景是否落地。
实际体验：技能明确要求「仅有 happy-path 代码不能视为完整实现」，能抓出边界条件缺失。注意事项：它不会自己去项目里翻需求文档，需求信息必须由你提供。
该技能能为用户带来的价值
1. 把评审标准从「人脑」变成「清单」 九大审查维度 + 十六项 Checklist + 四级严重程度 + 三档 Merge 判定，全部写死在技能里。团队不再需要每次都靠资深工程师临场发挥，评审口径天然一致，新人也能按同一把尺子改代码。
2. 需求遗漏在合并前就被拦住 「需求编号 → 变更文件/符号 → 测试或运行证据 → 状态」的追踪表，让「部分实现」和「未实现」无法被含糊带过。对需求交付质量敏感的团队，这一项的价值往往超过风格类检查。
3. 缩短评审往返轮次 每个问题都配有代码片段、风险说明和修复示例，作者拿到报告就能直接改，不必再来一轮「你说的是哪一行」「为什么要改」。评审会议从「逐行读代码」变成「聚焦关键结论」。
4. 降低架构约定的维护门槛
gRPC 注解与基类、Pipeline 注册、召回 Chooser/Factory、排序 VariableShop、Nacos 配置、构造器注入与 @Qualifier——这些项目内部约定通常只存在于老员工的经验里。技能把它们固化下来，等于给团队做了一份可执行的架构说明书。
5. 长期复用带来的复合收益 技能可以反复调用，每次审查的边际成本极低。随着使用次数增加，团队会自然沉淀出「哪些问题最常出现」的共性认知，反过来优化编码规范和模板代码。
常见问题 FAQ
Q1：这个技能怎么安装？需要提前准备什么？
在支持技能导入的 AI 客户端中导入 mr-review 技能包即可，导入时保留 name 与 description 字段。建议同时准备：待审查项目的仓库访问权限、可选的 GitLab MCP 配置（用于自动拉取 MR diff）、以及本次 MR 对应的需求文档。具体的下载入口、安装命令与配置方式请以官方说明为准。
Q2：为什么它老是先问我「有没有需求文档」，不能直接看代码吗？
这是设计上的强制门禁。技能要求「先提问、再取变更」，把需求上下文收集设为阻塞步骤，目的是避免把技术设计或代码意图误判成产品需求。你可以直接回复「没有需求文档」，它会将需求基线记录为 none，跳过需求符合度评估，只做代码与架构层面的审查；也可以给一个可访问的链接或直接粘贴需求文本。如果你在首条消息里就同时提供了需求，它不会重复询问。
Q3：收费吗？
技能本身的功能说明中未涉及定价信息，是否需要付费取决于你使用的 AI 客户端或平台，请以官方说明为准。
Q4：它适合谁用？非 Java 项目能用吗？
最适合 Java 后端开发、技术负责人和代码评审人，尤其是 Spring Boot + Elasticsearch + gRPC 技术栈的搜索推荐类项目团队。技能的规范基线是阿里巴巴 Java 开发手册、Google Java Style、Effective Java 和 OWASP 安全实践，并包含 searchengine 项目的专有约定（如 *MonitorDecorator 命名、Pipeline 与召回注册链路）。用于其他语言或其他架构的项目时，规范与约定部分需要做适配，效果会打折扣。
Q5：和静态扫描工具、通用 AI 助手怎么选？
二者互补，不必二选一。静态扫描工具放进 CI 做规则级门禁，覆盖面广、可量化；mr-review 用在评审环节做逻辑级、需求级和架构级的判断，输出可归档的评审报告。至于通用 AI 助手，日常答疑很方便，但缺少固定维度清单和需求追踪能力，容易出现「每次审得不一样」的问题。比较务实的组合是：CI 扫描 + mr-review 首轮 + 人工终审。