大模型做 Code Review，我把它放在 CI 的哪一层
跑了两周，结论很干脆：放在 lint 之后、人工评审之前，只写 PR comment，不参与合并判定。
为什么不直接拦
lint、类型检查、单测已经能把确定性问题拦住。模型的价值在于它能给出不太确定的判断，比如这个函数在并发下会被重复调用。这类判断当拦截条件是灾难：误报一次，全组就开始把它静音。当 comment 则不同，工程师可以把它当成多一个同事顺手提的意见。
四个坑
- 分片。单个 patch 超 400 行就切，按文件分组，组内再按 hunk 切。不分片的代价是模型只能拿到摘要，而它会把摘要当全文来评论。
- 上下文。只送 diff 不看实现，误报主要来源在此。我们的做法是被调函数体一并送进去，控制在 200 行，多的用行号占位。
- 噪声。它最爱报命名与风格，这类直接丢弃。保留四类：并发、边界、资源泄漏、错误处理。
- 成本。小模型做初筛，可疑片段再交给大模型复核。这一步把单次评审的费用降到三分之一。
我的判断
模型替代不了 reviewer，它替代的是 reviewer 不愿看的那部分琐碎。两周里真正被采纳的意见，大多是这个分支没处理超时这种细节，而不是架构层面的判断。前者交给模型后，人工评审时间实实在在少了一半。
下一步想把采纳与否回收成标注数据，让它逐步适应仓库的固定写法。但这件事的前置条件是 CI 已经稳定，否则模型只是在垃圾上堆幻觉。