一分钟五个 commit：评审合并的四个招

一道系统设计题把 AI 代码审查的成本要害摆了出来：开发者一分钟连推五个提交，系统怎么既不烧五次昂贵的模型评审，又能马上给出有用的反馈？ 题面列出的九条需求里，真正定生死的是"防重复分析"和"控推理成本"两条——它们共同指向同一个动作：合并。四个招可以顺着这条线排开。 第一招是去重合并：一分钟内的提交按仓库和作者归并成一个审查单元，只对合并后的差异跑一次评审，尾随的提交直接复用已有结果。第二招是空闲窗延迟：非阻塞的重评审不抢在提交那一刻，压进一小段静默窗口攒批——开发者要的"即时反馈"先由轻量静态检查顶上，模型深审随后补发。 第三招是增量与缓存：只把上次评审点之后的差异送给模型，仓库级上下文走缓存，避免每次全量重读大仓——长上下文的钱花在刀刃上。第四招是分级路由：按变更风险分流，小改动走便宜快模型，只有高风险路径才动用重模型，让预算跟着危险走。 这四招合起来是同一个判断：模型评审该按"批次"计费，而不是按"事件"计费——事件天然碎，批次才是人真实的工作节奏。它和之前那条把轮次当成本放大器的判断互为表里：省的从来不是单价，是重复触发的次数。 评审系统从事件驱动改成批次驱动之后，反馈速度反而可能更快——你的流水线里，还有哪些环节在按事件白白触发模型？