作者：浓云
背景
随着代码评审进入智能化时代，AI 已成为提升 Code Review 效率与代码质量的重要助手。但当一次合并请求（MR）包含大量提交或巨量变更时，把所有 diff 一次性交给 AI 审查，容易导致判断失真、遗漏细节或误解改动意图。为此，云效 Codeup 推出“单提交评审”模式，把每个 commit 作为独立评审单元，有针对性地结合 commit message 给出意见，有效解决大 MR 场景下的智能评审痛点。
功能介绍
什么是单提交评审？
- 默认评审模式：将 MR 中所有提交合并成一次整体 diff 来评审，适合小型、原子化的变更。
- 单提交评审模式：对 MR 中的每一次 commit 逐一评审，AI 会把对应的 diff 与 commit message 联合分析，产出风险提示、代码问题与可操作的修复建议。
单提交评审能解决哪些问题？
默认评审模式的痛点
- 上下文太复杂，细节信息被淹没：把多个提交合并成一份大 diff 后，由于 AI 无法在冗长且混杂的上下文中同时关注多个维度信息，因此容易忽视小而关键的改动（边界条件、微小逻辑修正、注释或文档改动），导致遗漏真实问题或忽视细微回归风险。
- 无法有效利用提交说明：合并为单一 diff 后，原本与每条提交对应的 message 与具体代码改动失去直接对应关系，AI 难以把握开发者的真实意图，容易给出不贴切或误导性的建议。
单提交评审如何缓解这些痛点？
- 降低上下文复杂度，保留并放大细节可见性：每个 commit 的变更更小、更语义集中，AI 在更聚焦、更一致的上下文中判断，微小但关键的改动更容易被检测和解释，不会在海量变更中被掩盖。
- 评审时结合提交说明：逐个评审 commit 时通过将 commit message 带入上下文中，AI 能关联起 diff 与对应的 message，理解开发者的真实意图（bug 修复、性能优化、兼容性调整等），从而给出更贴切的建议和更少的误判。
在哪些场景下推荐使用单提交评审？
- 大 MR 多提交：MR 中总变更行 >= 500，commits 数量 >= 5；
- 小提交：单个 commit 包含变更行 <= 100；
- 线性提交：一次评审中的提交代码尽量保证线性修改，避免反复修改、“左右摇摆”，或提交到 MR 之前在本地整理提交历史。
如何使用单提交评审？
1. 修改自定义 AI 评审规则文件
参考自定义 AI 评审规则，在源分支下的 AI 评审规则文件 .aliyun/code/code_review.yaml 中设置评审模式 review_mode 为 BY_COMMIT，即单提交评审模式。
2. 新建合并请求并执行 AI 评审
等待 AI 评审完成，可以看到所有评审评论发表。
2.1 提出更多更详细的评审意见
为了说明单提交评审相对于默认评审的效果提升，对同样的 MR 分别执行默认评审和单提交评审，对比二者的评审意见数量：
仅从评审意见数量的对比可以看到，单提交评审模式能找出数倍于默认评审模式的代码问题。
2.2 挖掘代码实现与提交说明不一致问题
当实际代码改动与提交说明的描述不一致时，单提交评审模式能找出仅从代码层面评审无法发现的问题：
3. 评审提交说明
在单提交评审模式下，评审 commit message 功能默认开启，在代码评审报告中增加“提交说明建议”模块。
在该模块内，会参考 Conventional Commits 规范对每个提交说明逐个评审，包括提交说明的格式问题、内容质量等。
如果期望关闭该功能，请修改自定义规则中的 enable_review_commit_message 字段为 false。
reviews: review_mode: "BY_COMMIT" enable_review_commit_message: false # 默认为true，该字段只有结合单提交评审模式才生效
单提交评审有什么局限性？
相比于默认评审模式，单提交评审由于单次只评审一个提交，当提交数量较大时会使评审耗时显著提高，极端情况下耗时会达到默认评审模式的 3 倍以上。请结合具体需求选择合适的评审模式。
相关链接：
[1]《开发效率翻倍！编码助手+云效 AI 评审如何破解代码质量与速度难题？》
[2] 代码评审 AI 助手
https://help.aliyun.com/zh/yunxiao/user-guide/ai-intelligent-code-review
[3] Conventional Commits
https://www.conventionalcommits.org/en/v1.0.0/
[4] How to Write a Git Commit Message
[5] 单提交评审模式示例代码库
