一个编码智能体写完功能、发起合并请求，转头就去干下一个任务。而需要看懂这次改动的工程师，还在评审昨天的那批代码。
生成变快，可能带来更大的合并请求，也可能带来更多的合并请求，或者两者兼有。如果真正有意义的评审跟不上节奏，交付队列就会越堆越长——哪怕写代码这一端看起来在加速。
一个可行的思路是把几件事组合起来：更强的自动化检查、与改动后果相匹配的审批规则、给评审者的 AI 辅助，再加上渐进式发布。每一部分各自解决一个不同的约束。
小合并请求只解决一部分问题
三十个中小型合并请求，未必比十个大请求更好评审。这个比较取决于改动做了什么、彼此如何交互，以及评审者需要重建多少上下文。
小而内聚的改动仍然有价值。谷歌的工程指南把有用的改动描述为自包含的：包含相关测试，以及足以理解它的上下文。按文件边界随意切分一个功能，反而会背离这个目标。
比如一次订单重试的改动。把重试策略、重复请求防护和对应测试拆成三个合并请求，每个可能都很短。但评审者仍然需要理解它们合在一起的行为。短 diff 不等于小决策。
更合理的做法是保留内聚的改动，同时看整个队列：有多少工作在等待、哪些需要人来判断、什么证据能让这个判断更容易。评审已经饱和时还在生成更多工作，这本身就是限制在制品数量的理由。
把保护关键行为的检查自动化
编译通过和覆盖率阈值，表达不了所有交付要求。需要的是与故障方式挂钩的检查：业务规则、真实的依赖交互、服务契约、安全边界和恢复行为。
还是订单重试的例子。一个有用的场景是：请求成功了，但响应丢了。客户端重试。系统是又创建了一个订单，还是识别出这是同一个操作？只检查成功响应的测试，回答不了这个问题。
智能体可以帮忙实现测试，但预期结果应当来自需求本身。这个预期要独立于实现去评审。检查项和管辖它们的策略，要防止在功能改动中被顺手削弱。
流水线应当报告它检查了什么、什么失败了、还有什么没测。这给评审者提供了具体的证据，也给编码智能体一个明确的失败点去修复。
按后果设定审批要求
改个措辞和改个授权逻辑，应该得到不同的关注度。光看 diff 大小判断不了：一行改动就可能把访问权限扩大到所有客户的数据。
一个可以拿来和团队讨论的起步策略是：按风险分类设定所需审批人数，前提是组织要求允许。这些数字是提议的策略选择。额外审批只有在评审者理解相关风险时才有用；反过来，零审批应当是一个刻意收窄的类别，有明确的责任人和可审计的历史。
GitLab 的审批规则说明了底层机制：指定所需人数和审批人，包括代码所有者。但上面的风险分类是团队决策，不是审批计数器自动提供的能力。
智能体可以提议一个分类并解释理由。强制执行应当来自约定好的策略，不确定的情况交给人判断。对审批策略或其检查项的改动，本身要当作敏感改动处理。diff 变化时，重新评估分类。
给评审者有用的 AI 辅助
评审者也可以有自己的智能体。它的职责是帮工程师找到有后果的决策，并高效地验证它们。
对订单重试这个例子，一份有用的评审简报会指出：重试的触发点、用来识别同一操作的身份标识、强制唯一性的位置，以及覆盖响应丢失的测试。它应当指向相关代码，包括那些重要但未改动的依赖。
机械性改动可以单独分组并附上说明。“生成的文件”和“琐碎改动”不是忽略一次改动的充分理由。重新生成的客户端可能引入有意义的契约差异；一处小的配置修改可能改变运行时行为。
给评审智能体的提示词可以这样写：阅读这个合并请求及其依赖的代码，解释预期的行为变化，找出最可能影响正确性或运维的决策，把每个关注点链接到代码和测试证据。机械性改动单独分组并说明分类理由。列出假设和缺失的上下文。不要批准改动，不要修改文件。
工程师随后拿这份简报对照实现，去查重要的路径。摘要是评审的辅助，它不能证明被省略的代码无害。
渐进发布，并提前想好何时停
评审和自动化检查都发生在新行为接触生产条件之前。发布控制提供了另一个观察问题、控制暴露面的机会。
用金丝雀发布，让一小批有代表性的用户接触新版本，并与现有版本对比。选择与本次改动相关的信号。对订单重试来说，可以是重复订单检测、成功完成率、重试量，再加上错误和延迟。
在开始之前就定义好暂停或回滚的条件。给这批用户足够的流量和时间，让要评估的故障模式暴露出来。如果几乎没人走过改动路径，部署后安静的仪表盘是很弱的证据。谷歌的 SRE 指南解释了代表性流量、可归因指标和对照组的重要性。
小批次不保证小影响。两个版本可能共用数据库或队列。一次破坏性迁移或一波重试流量，也可能影响到金丝雀之外的客户。这些共享依赖要纳入发布评估。
功能开关提供另一种控制：不部署新版本就能开启或关闭特定行为。保留可用的回退路径，并测试相关的开关状态。给临时开关指定负责人，用途完成后移除。
关掉重试功能可以阻止未来的重试，但删不掉已经重复的订单，也逆转不了已经完成的外部操作。数据修复和恢复计划，要和止住进一步暴露的开关分开管理。
从一个类别开始，度量整条路径
先在一个边界清晰的改动类别上试点。在把策略推广到整个仓库之前，先定义好它所需的证据、审批策略、评审简报和发布控制。
跟踪这些指标：等待评审的时间、花在评审上的人力、到部署的时间、逃逸的缺陷，以及恢复所需的投入。比较合理相似的改动，并让样本量保持可见。光是合并请求变多，说明不了交付变好。
用结果来调整策略。如果评审者经常在简报里发现重要遗漏，就改进简报和它的验证方式。如果某个类别产生了意外事故，就重新审视它的检查项、审批要求和发布限制。如果队列持续增长，就减少并发工作，同时处理那个约束。
值得抛给团队的问题很具体：哪些改动可以少一些人工审批就发布，需要什么证据和恢复控制，才能让这个选择是负责任的？
热门跟贴