GitLab 新评审人推荐流程怎样考虑负载与时区

GitLab 19.5 把评审人推荐从“凭经验点一个熟悉的人”变成了可解释的候选匹配：Recommend Reviewers Flow 会先根据审批规则和 CODEOWNERS 确定谁有资格，再综合可用状态、正在等待评审的 Merge Request 数量、个人时区和最近活动给出建议。它负责缩小选择范围和说明理由，最后是否添加评审人仍由团队成员决定。

官方文档：https://docs.gitlab.com/user/project/merge_requests/reviews/automatic_reviewer_assignment/

这项能力适合已经有审批规则、CODEOWNERS 或多人协作项目的团队。它解决的不是“团队里有没有人”，而是“这次变更现在应该交给哪位合格且有余量的人”。

这次发布到底改变了什么

GitLab 官方在 2026 年 10 月 15 日介绍了这项能力，并将它列为 GitLab 19.5 的一般可用功能。与旧式的整组指派或固定轮值不同，流程会把评审资格和当前协作状态放在同一个推荐结果里。

需要先区分两个容易混淆的概念：自动分配 Code Owner 是按变更文件直接把匹配的 Code Owner 设为评审人；Recommend Reviewers Flow 则是在审批规则允许的候选范围内给出推荐，读者仍要在 Merge Request 侧栏点击 Add reviewer。前者强调自动写入，后者强调可解释的选择。

推荐人不是随机轮询，而是先按规则缩小候选集

流程不是在所有组织成员中随意挑一个名字。它先读取 Merge Request 需要满足的必选和可选审批规则，并按规则所定义的候选人范围计算还缺多少个批准者。当前评审人已经满足某条规则时，该规则不再重复推荐；已经是评审人的成员也不会再次进入推荐结果。

进入候选集后，GitLab 文档列出四类比较信号：

• 可用状态：根据成员状态判断是否适合在当前时间承接评审。
• 评审负载：查看该成员正在等待其评审的开放 Merge Request 数量，避免总把任务压到同一个人身上。
• 个人时区：使用成员资料中的时区，减少把任务交给刚结束工作时段的人的情况。
• 最近活动：作为候选比较时的补充信号，帮助推荐更可能及时响应的人。

因此，“考虑负载与时区”并不意味着系统公布一个固定权重表，也不意味着低负载成员一定会被选中。审批规则先决定谁有资格，四类信号再帮助流程在合格候选人中做更合适的排序。

在项目里怎样让推荐结果出现

启用路径在顶层群组，而不是每个项目单独维护一套算法。顶层群组需要打开 Allow flow execution、Allow foundational flows 和 Recommend Reviewers；官方文档还要求操作者拥有顶层群组 Owner，以及项目 Maintainer 或 Owner 权限，并满足 GitLab Duo Agent Platform 的前置条件。

启用后，GitLab 会在项目中创建 Recommend Reviewers 的流程触发器。默认触发时机是创建 Merge Request，包括草稿和 ready 状态的 MR。若团队希望草稿 MR 只有在标记为 ready 后才推荐，可以先关闭自动创建的触发器，再在 AI > Triggers 中新建一个 Merge request 事件，并把运行条件设为 Marked ready。

当流程运行完成，推荐人会出现在 MR 右侧的 Reviewers > Recommended 区域。悬停在成员上可以查看选择理由；确认符合当前变更的工作背景后，再点击 Add reviewer。对于启用流程之前已经存在的 MR，需要在同一侧栏手动选择 Generate，才会请求一次推荐。

和固定评审人、整组指派相比怎么选

更稳妥的落地顺序是先整理 CODEOWNERS 和审批规则，再观察推荐理由是否符合团队实际，最后逐步把固定指派改成推荐加人工确认。这样可以先验证候选边界，避免把一个尚未整理好的权限模型交给流程解释。

使用时要留意的边界

第一，推荐不等于批准，也不等于强制分配。它只帮助找到更合适的人，最终动作和责任仍在项目成员。第二，默认 All Members 规则的候选范围有成员关系和权限限制：通过父群组或受邀群组继承权限的成员不一定进入候选集，项目没有直接成员时，该规则可能没有推荐结果。

第三，创建草稿 MR 和把草稿标记为 ready 的触发时机可以通过触发器配置区分，但不能把它理解成流程始终等待 ready。第四，推荐在后台运行，侧栏出现结果可能需要一点时间；如果推荐已经不合适，可以在 Recommended 区域使用刷新动作重新获取候选。

最后，团队应把成员资料中的时区和状态维护当成协作基础设施，而不是把所有延迟都归因于算法。时区过期、CODEOWNERS 范围过宽、审批规则缺少边界，都会让“负载与时区”这两个信号失去参考价值。

常见问题

它会自动把推荐人写进 Merge Request 吗？

不会。推荐结果显示在 Recommended 区域，拥有相应权限的成员查看理由后点击 Add reviewer，才完成分配。

只有一个评审人时还需要 CODEOWNERS 吗？

不一定。流程也可以依据审批规则寻找候选人，但 CODEOWNERS 能把文件路径与专业边界表达得更清楚；规则和成员范围越准确，推荐越容易符合团队预期。

负载是不是唯一优先级？

不是。文档把可用状态、评审负载、个人时区和最近活动都列为候选比较因素，真正的候选集合仍由审批规则决定。

总结

GitLab 19.5 的 Recommend Reviewers Flow 把评审分配拆成两层：审批规则和 CODEOWNERS 负责定义“谁有资格”，可用状态、待审 MR 数量、个人时区和最近活动负责帮助“从合格的人里怎么选”。流程给出带理由的建议，团队保留最后的确认权。准备采用时，优先检查规则边界和成员资料，再观察推荐理由是否真的能减少瓶颈。