代码不再是瓶颈，理解才是

随着编码代理的普及，软件开发中稀缺的资源正在发生变化。生成一个看似合理的代码变更所需的时间越来越少，但团队仍需决定该变更是否合适、如何重塑系统以及下一步该做什么。通过的测试并不能回答这些问题。这就是“可解释性鸿沟”。模型可以承担更多上下文并并行工作，但人类的理解能力却无法以同样的方式扩展。瓶颈从生产代码转向了足够理解代码以指导它。当团队无法解释一个变更时，它就不再塑造系统，而是开始接受输出。

大多数审查界面从文件、行和注释开始。这些证据必不可少，但当一个系统变更涉及路由、提供者、模板、测试和配置时，从这里开始是很糟糕的。审查需要更高层次的抽象，但并非要求盲目信任的摘要。它需要一条从意图到系统行为再到代码的路径，并且每个声明都可追溯到差异。

理解保持判断力活跃。审查者的工作不是统计更改的文件数量，而是回答一组不同的问题：系统层面发生了什么变化？系统的哪些部分一起移动？边界和假设在哪里？什么值得人类关注？这个设计是否应该成为系统的一部分？测试、静态分析和代理可以验证更多的实现细节，但人们仍需决定边界是否合理、权衡是否值得、以及变更是否将系统引向有用的方向。如果没有一个对变更的工作模型，审查者只能批准或拒绝；有了它，审查者可以改进设计、质疑假设或将变更与下一个决策联系起来。

差异是证据，而非路线。仓库路径告诉审查者代码的位置，但不能解释为什么多个文件一起更改或哪个文件应该先读。仓库按实现组织代码，而审查者则思考行为和决策。一个行为可能跨越路由、提供者、配置文件、模板和测试。差异仍然是确凿的证据，但它需要一种有用的阅读顺序。

同一个变更，两种阅读顺序。CodeRabbit 最近引入了“变更堆栈”，这是一种审查视图，根据系统行为将相关编辑分组为命名路径，然后将每条路径链接回确切的文件和行。以 TanStack/cli 拉取请求 #490 为例，该变更涉及 45 个文件，涵盖认证、环境处理、模板、包配置和测试。变更堆栈将相同的差异组织成基于相关系统行为的六条审查路径。这两种视图回答不同的问题：GitHub 显示代码在哪里更改，变更堆栈则提出哪些更改应该一起判断。

有用的单位是行为。一条变更堆栈路径可能将十个文件连接成一个单一的登录流程。没有一个文件包含审查者需要判断的行为；它存在于路由、提供者、回调、配置和测试之间。系统行为图给出了一个模型，审查者可以对照代码进行测试。第一个问题从“这个流程是什么？”变成了“它正确、完整且安全吗？”作者、审查者和维护者可以挑战同一个提议的流程，而不是带着三个对差异的私人解释。

地图必须引回代码。当抽象止于精美的摘要时，它是廉价的；可追溯性则更难。在这种审查中，审查者可以从拉取请求移动到变更层，从层到系统流程，再从流程到语义实体、文件和行。他们可以在高层次判断行为，然后针对实现验证每个声明。抽象只有在两个方向都保持开放时才有用：缩小以恢复意图和行为，放大以验证地图与代码。每一层都有一个职责：意图解释变更为何存在；系统行为显示部件如何交互；层设定审查边界；语义实体命名相关的函数、路由或类型；文件和行提供证据。去掉上层，审查者需要从坐标重建系统；去掉下层，审查者被要求相信一个无法验证的故事。

审查界面应成为一个堆栈，而非更漂亮的摘要。随着编码代理产生更多、更大的差异，更长的摘要不会使工作变得可控。两者都让审查者去重建系统。一个有用的审查模型应该是可检查、可纠正和可讨论的。每个层次回答不同的问题，并且每个层次都连接回代码。没有一种表示是足够的；价值在于能够在意图、行为和确凿证据之间移动而不中断链条。目标不是阅读更少的代码，而是将阅读代码的时间用于测试一个连贯的模型，而不是从零开始构建一个。机器可以组织变更并暴露路径，而人类则决定模型是否准确、边界是否合理以及方向是否值得。差异仍是基本事实，堆栈使其可用于判断。