Claude Code 团队：每层代码一个评审
One reviewer per layer: splitting code review by the way code is read
随着 Claude Code 团队每日合并的代码量从 2500 次激增至 30000 次，传统逐行阅读已无法应对。他们不再依赖单一评审者通读所有代码，而是将评审拆解为六个层级：从意图、形式、局部语义到系统连接、运行时行为及最终使用体验。这种“每层一个评审者”的策略，配合树状代理结构，让每个 AI 代理只需关注特定抽象层级的上下文，极大提升了评审效率。文章指出，代码审查不应是线性的，而应像信息隐藏一样，通过分层和分视角（如安全性、历史、可逆性）的矩阵式审查，确保在 AI 生成代码爆发的时代，系统依然稳健可靠。
编写和阅读代码并非单一学科，而是层层堆叠的多种技能，每一层都需要不同的思维模型。
- visarga
我觉得这对今年来说是个不错的方法，但它漏掉了一个关键点：在历经数周甚至数月的多次会话、不断调整方向后，你怎么知道代码依然符合你的初衷？消息在会话中流转，很快就被滚出视野，而在会话压缩或开启新会话时，它们往往被遗忘。为了解决这个问题，我会把每条用户消息都记录在聊天日志里，并时不时回顾，以此提炼出用户意图的最新形态。
这里和 Anthropic 的文章里都没提到的另一种评审是“计划评审”。我会为某段工作生成计划，然后让一个或多个代理（agent）对这个保存为文件的计划进行评审。这能在执行前将计划与项目约束进行核对。
如果我们能解决测试问题，那么编码就几乎可以完全自动化了。剩下的唯一问题始终是信任：我们凭什么信任这段代码？如果你手动阅读，那就像骑摩托车一样；如果你不读，就需要某种方式来降低风险。目前有很多关于如何实现这一点的想法在流传，OP 和 Anthropic 展示了他们的观点。不过我认为这种方法因项目而异，没有通用的方案。
- jwpapi
我目前的问题是，各种评审流程都增加了不必要的复杂性，这反过来会降低你的敏捷性，增加成本，并导致性能下降。
如果你有一个功能，却经过 6 个不同的评审者，逻辑很容易变得臃肿。我想知道其他人是怎么处理的？我完全支持并希望这套机制能行得通，但这确实是我目前的瓶颈。
我经常从评审监控中得到糟糕的建议，因为它们有时会搞错。当然，有时我也会得到好建议，甚至是非常好的建议，但有些确实很差。所以我总是倾向于只看关于 Bug 的评审，但我担心经过 6 个评审者后，那只是一堆令人困惑的文字，最终结果反而比我亲自查看关键问题更糟。我的上下文窗口也有限，完全放手不管又不够可靠……
大家是怎么做的？
- zomtorg
我想知道，是否会有更多的工程团队从 git 转向 Sapling？我们确实需要刷新一下代码评审和发布的流程。
我知道 GitHub 最近推出了堆叠 PR（stacked PRs），但从易用性和可靠性角度来看，与 Meta 以及 Anthropic 内部使用的方案相比，这似乎还有很长的路要走。