合并请求审批强度应当随变更风险变化：当变更触及生产配置、数据库结构、公共接口、权限或支付逻辑，且回滚困难、出错代价高时，值得增加评审人数、指定领域负责人并要求测试证据与回滚方案；普通文档修改、测试补充和低风险内部重构维持一名评审人的轻量审批即可。判断依据是变更影响范围、不可逆程度和出错代价，而非统一加严。
要点总览（TL;DR）
- 判断是否加严审批，看变更的影响范围、不可逆程度和出错代价；三项都低的变更维持一名评审人的轻量审批即可。
- 生产配置、数据库结构与迁移、支付与权限逻辑、对外接口协议变更属于高风险，应增加评审人数、指定领域负责人，并要求测试证据与回滚方案。
- 审批防住的是测试难以覆盖的设计缺陷与影响范围误判，不能替代测试、灰度和监控；强度过高会拉长合入周期、造成变更积压。
- 加严需要分级规则、责任评审人和紧急修复通道作为前提，工具侧要能按分支、路径或标签区分审批要求。
- 先用一类高风险变更试点，观察评审周期、拦截问题和返工情况，再决定保留、扩大或回退。
先判断：哪些合并请求值得加严审批
提高审批强度是一项有成本的控制措施，适合用在“一旦合入出错，修复代价明显高于评审等待成本”的变更上。团队可以先从三个维度给合并请求打分，再对照决定审批强度。
- 影响范围：变更被多少用户、系统或下游服务使用。影响面越广，一次判断失误波及的范围越大。
- 不可逆程度：合入后能否快速、干净地回滚。数据库结构变更、已发布的数据迁移、对外接口协议调整，回滚往往需要额外脚本或协调窗口。
- 出错代价：故障会造成什么后果。涉及资金、权限、隐私数据或核心交易链路的缺陷，代价通常高于内部工具和展示层调整。
三个维度中任意一项偏高，就值得考虑加严；两项以上同时偏高，应当明确加严。三项都低的变更，维持轻量审批更符合投入产出。
| 风险等级 | 典型变更 | 建议审批强度 |
|---|---|---|
| 高 | 生产环境配置、数据库结构与数据迁移、支付与权限逻辑、对外公共接口协议变更 | 至少两名评审人，其中一名为领域负责人；要求测试证据与回滚方案；必要时安排发布窗口评审 |
| 中 | 核心业务逻辑调整、跨模块调用改动、依赖升级、性能敏感代码 | 一名熟悉该模块的评审人，必要时增加第二名；要求说明影响范围与验证方式 |
| 低 | 文档修改、注释与格式调整、测试用例补充、内部工具小改动 | 一名评审人快速通过，重点看改动是否符合描述 |
低风险变更维持轻量审批的理由很直接：这类变更出错后的修复成本低，回滚简单，增加评审轮次带来的收益有限，却会占用评审人力、拉长合入时间。把评审资源集中到高风险变更上，整体质量控制效果更好。
审批强度解决的是什么问题
审批拦截的是合入前的判断失误和责任缺位。代码作者对自身改动容易形成盲区，测试覆盖也可能遗漏边界条件；审批通过意味着至少有一位具备相应经验的人确认了改动意图、影响范围和验证情况。当变更出错时，审批记录也能帮助团队回溯当时的判断依据。
审批强度不能替代测试、灰度和监控，它们各自防住不同类型的风险：
- 自动化测试防住可被断言覆盖的功能回归，属于合入前的机器验证。
- 审批防住测试难以覆盖的设计缺陷、影响范围误判和规范偏离，属于人的判断。
- 灰度发布防住小概率线上异常，把故障影响控制在有限流量内。
- 监控与告警负责发现合入后的问题，缩短故障发现时间。
如果测试覆盖充分、灰度机制成熟，审批可以聚焦在设计与影响范围判断上，不必重复检查机器能验证的内容。反过来，缺少测试和灰度的团队，也不能指望靠增加评审人数兜住所有风险。
审批强度过高会带来等待成本。评审人排队、多轮往返、跨时区协作都会拉长合入周期，变更积压后单次合入的改动量变大，反而增加评审难度。审批强度应当与风险匹配，而不是越高越好。
适合提高审批强度的变更与团队条件
是否加严，可以从变更侧和团队侧分别判断。变更侧决定“这次改动值不值得加严”，团队侧决定“这个仓库有没有必要长期维持更严的规则”。
变更侧条件
- 改动位于核心链路，例如下单、支付、登录、结算等直接面向用户或资金的主流程。
- 涉及数据库结构变更、数据迁移或批量数据修正，执行后难以原样回退。
- 修改对外接口的请求或响应结构，影响其他团队或外部调用方。
- 涉及安全、权限、鉴权逻辑或敏感数据处理。
- 修改生产环境配置、部署脚本或基础设施定义。
团队侧条件
- 仓库由多人协作维护，代码所有权分散，单一评审人难以覆盖全部改动。
- 团队新人占比较高，作者对模块历史和隐含约束的熟悉程度有限。
- 跨团队依赖多，一次改动可能影响其他团队的排期和联调计划。
- 发布节奏紧张或处于关键发布窗口，合入后留给修复的时间有限。
- 所在业务有合规或审计要求，需要留存评审记录和责任人信息。
这些条件同时出现时，加严审批的必要性更强。例如一个多人协作的支付模块仓库，在新人参与核心逻辑改动、又临近大促发布窗口时，就属于典型的应当加严场景。
提高审批强度要付出什么
加严审批的投入主要体现在三个方面，团队在决定前应当评估是否承担得起。
- 评审人力：高风险变更需要指定领域负责人参与，这类人通常时间紧张。评审人数增加，意味着更多人的日程需要协调。
- 等待时间：多轮评审和跨时区协作会拉长合入周期。如果缺少明确的响应时限，合并请求可能在评审队列中停留较久。
- 规则维护成本：分级规则需要有人定义、解释和更新。规则模糊时，作者和评审人对“这次算不算高风险”容易产生分歧。
落地加严审批还需要几个前提：
- 有明确的分级规则，说明哪些路径、分支或变更类型适用更严的审批，并指定每类变更的责任评审人。
- 有紧急修复通道，允许在故障处理时由指定人员快速审批合入，事后补充评审记录。
- 工具侧支持按分支、路径或标签配置不同的审批规则，避免所有仓库共用一套统一要求。
在工具配置层面，团队通常需要把“哪些目录对应核心模块、哪些分支对应生产发布、哪些标签表示高风险变更”转化为可执行的审批规则。ONES 的合并请求审批配置可以承接这类按仓库和分支区分审批要求的需要，让高风险路径走更严的评审设置，低风险改动保持轻量流程；具体支持的配置维度和粒度，以团队实际使用版本的官方说明为准。
什么情况下应暂缓加严
加严审批并非在所有阶段都合适。以下情况建议先维持现状，等条件成熟再推进。
- 变更频率高但影响面小的模块：例如样式调整、文案修改、内部脚本维护。这类模块加严后，评审队列会迅速积压，收益有限。
- 团队规模小、评审人力不足：只有两三名可评审人时，要求两名以上评审人容易造成等待，甚至出现作者自行绕过流程的情况。
- 缺少分级规则、只能全量加严的阶段：一刀切加严会让低风险变更也承担高成本，团队容易产生抵触，规则也难以持续。
- 紧急修复通道尚未建立：线上故障需要快速合入时，如果没有明确的例外流程，加严规则会被临时打破，反而削弱规则的严肃性。
暂缓不等于放弃。团队可以先记录哪些变更类型反复出问题，积累判断依据，再针对这些类型设计分级规则。
用小范围试点验证审批强度是否合适
加严审批是否值得，可以用一类高风险变更先行试点来验证，而不必一次性推广到所有仓库。
试点范围建议选择影响范围明确、变更量适中的对象，例如某个核心服务的生产配置目录，或某个对外接口仓库的发布分支。范围太小看不出效果，太大则难以归因。
试点期间可以观察三类指标：
- 评审周期：从提交合并请求到获批合入的平均时长，与试点前对比。
- 拦截问题：评审中发现的、若合入可能造成故障或返工的问题数量与类型。
- 返工情况：合入后因评审遗漏导致的修复、回滚或线上问题的次数。
根据结果调整规则：如果拦截问题明显增加且评审周期在可接受范围内，可以保留或扩大试点；如果评审周期显著拉长而拦截问题没有增加，说明当前强度偏高，可以缩减评审人数或缩小适用范围；如果出现紧急修复被规则阻塞的情况，应优先补齐例外通道再继续。试点结论应当形成书面记录，作为后续调整分级规则的依据。
常见问题
团队只有两三名可评审人，还能提高审批强度吗？
评审人力不足时，直接要求两名以上评审人容易造成排队等待，甚至出现作者绕过流程的情况。更可行的做法是缩小加严范围：只对生产配置、数据库迁移、支付与权限逻辑这类高风险变更指定第二评审人，其余变更保持一名评审人。同时明确评审响应时限，避免合并请求长时间停留在队列中。等评审人力补充或跨团队评审机制建立后，再扩大加严范围。
线上故障需要紧急合入，加严的审批规则怎么处理？
加严规则应当配套紧急修复通道，而不是在故障时临时打破规则。常见做法是由指定人员（如值班负责人或模块负责人）快速审批合入，事后补充评审记录并说明原因。如果团队尚未建立这条通道，建议先补齐例外流程再推进加严，否则规则会在紧急场景下被反复突破，削弱其严肃性。
自动化测试覆盖比较充分，还需要加严审批吗？
测试和审批防住的风险类型不同。自动化测试覆盖可被断言验证的功能回归；审批针对的是测试难以覆盖的部分，例如设计取舍是否合理、影响范围是否被低估、是否偏离团队规范。测试覆盖充分时，审批可以聚焦在这些判断上，不必重复检查机器能验证的内容，但涉及数据库结构、对外接口协议、权限逻辑的变更仍值得保留更严的评审要求。
加严后评审周期明显变长，应该怎么调整？
先区分周期变长的原因。如果是评审人排队导致，可以缩减加严的适用范围，或为高风险变更设定响应时限；如果是多轮往返导致，说明分级规则不够清晰，作者和评审人对“这次算不算高风险”存在分歧，应把规则细化到具体路径、分支或变更类型。如果评审周期拉长但拦截问题没有增加，说明当前强度偏高，可以减少评审人数或回退到试点前的设置。
按分支、路径配置不同审批规则，落地时要注意什么？
先梳理清楚三类对应关系：哪些目录对应核心模块、哪些分支对应生产发布、哪些标签或变更类型表示高风险。规则要写成可执行的判断条件，并指定每类变更的责任评审人，否则规则容易停留在文档层面。规则上线后还需要有人负责解释和更新，随着模块拆分、发布流程调整同步修订。工具是否支持按这些维度配置审批要求，以团队实际使用版本的官方说明为准。
