AI 审查代码，该补充哪些上下文

AI 代码审查该读多少文件？作者给出的判断是：先明确改动必须保住什么行为，再找依赖这些行为的代码。相关文件可能让审查发现新的缺陷，也可能只是增强已有判断；单纯增加输入量，不能证明审查会更好。

原文用一个 JavaScript 队列说明问题：给共享函数加一次排序，页面显示正确了，任务调度却选错了对象。这个例子对前端和全栈开发很贴近，但边界也很明确：它是虚构的代码推演，没有实际进行 AI 审查实验。

页面排对了，为什么程序仍然可能出错

程序里有两个需求。任务按到达顺序进入队列，runner 必须选择最早到达且已经就绪的任务；页面则要把就绪任务按预计耗时从短到长展示。

原文输入包含三个任务：J1 的 ready 为 false、minutes 为 1；J2 的 ready 为 true、minutes 为 10；J3 的 ready 为 true、minutes 为 2。

所以，runner 应该选择 J2，页面却应该先显示 J3，再显示 J2。两处使用同一批数据，但需要不同顺序。

共享文件 ready-jobs.js 中的 readyJobs(jobs) 原本只执行 jobs.filter(job => job.ready)。filter 返回新数组，同时保留元素原来的相对顺序，结果就是 J2、J3。页面文件 queue-screen.js 再用 map(job => job.id) 提取 ID，因此显示顺序还不符合要求。

一个看起来很省事的修改，是直接在共享函数的 filter 后追加 .sort((a, b) => a.minutes - b.minutes)。页面马上得到 J3、J2，两个就绪任务也都还在。

问题藏在另一个调用方里。

多读一个调用方，才能解释排序的后果

runner.js 用下面这段代码选择任务，它把共享函数返回的第一个元素当成下一项工作：

// 任务按到达顺序进入队列。
// 选择最早到达且已经就绪的任务。
function nextJobId(jobs) {
  return readyJobs(jobs)[0]?.id ?? null;
}

要看的是 [0]：它让返回数组的顺序直接参与业务决策。后面的 ?.id ?? null 则在没有任务时返回 null。

修改前，这段代码选择 J2；共享函数加上排序后，它选择 J3。J2 明明更早到达，而且已经就绪，却被跳过了。

返回相同的元素，不等于保留相同的行为。

只读改动行，可以知道排序方式变了，却还不能把它判定为调度缺陷。读到 runner 的选择逻辑，再结合「最早就绪任务优先」的要求，才能说明改动违反了什么规则。

这就是相关上下文的价值。它补上了从代码变化到业务后果之间的连接。作者没有展示模型先批准、补充文件后再拒绝的过程，也没有测量审查结论改变的比例，不能把这个例子包装成 AI 审查能力提升的实验结果。

排序属于页面，就把它留在页面

原文的修正方式是保留共享函数原来的筛选行为，在页面调用方内部排序。下面这段代码解决展示需求，同时让 runner 继续获得原来的就绪顺序：

function visibleJobIds(jobs) {
  return readyJobs(jobs)
    .sort((a, b) => a.minutes - b.minutes)
    .map(job => job.id);
}

这里要注意 .sort(...) 操作的是 readyJobs(jobs) 返回的新数组。虽然 sort 会原地修改数组，但在这个实现中，它修改的是筛选结果，输入队列的顺序不会受到影响。

对给定输入，页面显示 J3、J2，runner 仍然选择 J2。空输入、没有就绪任务时，runner 返回 null；只有一个就绪任务时，它仍是被选中的对象。

这些推演也有范围：例子假设任务 ID 唯一，预计耗时互不相同且都是正数。非法输入不在讨论之内，代码也没有真正执行任务。几个简单情况符合要求，不代表所有输入都已经得到验证。

我的判断

我赞同作者把审查重点放在「行为依赖」上。共享工具函数的风险，经常来自调用方对返回结果的隐含要求，例如依赖顺序、读取首项。只检查当前页面是否显示正确，很容易漏掉这类回归。

和只提供 diff 相比，加入相关调用方能提供更完整的判断依据；和把整个仓库塞给模型相比，围绕具体问题选择文件，也更容易解释每份上下文的用途。不过，后者是否更省钱、更快、缺陷检出率更高，原文没有对照数据，只能视为一种审查思路。

这个例子还有一个关键前提：runner 的业务要求已经写清楚了。如果真实项目只有 [0]，没有注释、测试或需求说明，审查者仍需确认「第一个」究竟代表什么，不能自行补出业务规则。

作者还提到自己的审查项目 Robin：2.12.2 在 native fallback patches，也就是备用文件变更列表中，省略编码后的二进制载荷；后续 v2.12.3 则在复用此前对话消息时保留模型的私有推理细节。这是两项不同修正，发布说明没有提供速度、成本或审查质量的测量，不能拿来证明上下文越少越好，或保留越多越好。

能拿来做什么

• 审查共享函数时，先写清必须保持的行为，再检查调用方。本例最有用的问题是「排序会不会改变 runner 的下一次选择」，比泛泛要求模型检查潜在问题更具体。
• 给 AI 提供上下文时，把改动代码、相关调用方和业务要求放在一起。新增文件应当回答一个明确问题，例如谁依赖返回顺序。
• 页面需要排序时，先判断它是否只是展示规则。本例可以在 visibleJobIds 内排序，因为 readyJobs 返回新数组；自己的代码也要先确认这一条件。
• 用聚焦的测试固定跨调用方的要求。本例可以同时断言页面输出 J3、J2，runner 选择 J2，让展示修复与调度回归在同一组输入下显现。