GitHub 复盘：工具升级后 Copilot 代码审查为何变差

TL;DR： GitHub 为 Copilot 代码审查提供了更好的共享工具，但复用了通用指令——审查变得更贵、更不准确，直到他们针对审查者实际的工作方式重写了指令，成本降低了约 20%，质量没有下降。

迁移到共享工具后，Copilot 的审查变得更贵、更不准确

共享工具本应是轻松取胜的做法：减少重复代码、减少需要维护的东西、改进能自动惠及所有产品。GitHub 自己的说法——将 Copilot 代码审查迁移到其共享 CLI 工具集——让人有理由对这一假设至少抱有一点怀疑。

Copilot 代码审查此前运行自己的代码探索工具——列出目录、搜索文件、搜索目录、读取代码——这些工具是为早期能力较弱的模型专门打造的。而 GitHub 的 Copilot CLI 运行一套更广泛的 Unix 风格工具集——grep、glob、view——其他几个 Copilot 产品也在使用。

GitHub 决定将 Copilot 代码审查迁移到这套共享 CLI 工具集上——弃用自己的工具，改用其他地方已经在用的同一套 grep、glob 和 view。其吸引力本质上在于减少重复的工程投入，以及一套只需改进一次就能被所有使用方继承的工具集。

在离线基准测试中，结果恰恰相反。审查成本上升，标记出的有用问题却更少。GitHub 软件工程师 Napalys Klicius 指出，迁移到共享 CLI 工具集本应通过为智能体提供更灵活的代码探索工具来改善结果，但一旦他们查看智能体实际在做什么，这一预期就站不住脚了。

“问题不在工具，而在指令，”Klicius 写道——指的是提示层面的指导，即告诉智能体何时以及如何使用每个工具。

“一旦我们按照审查者实际阅读拉取请求的方式重写这些指令，这一退步就变成了胜利。”

每次审查的成本下降了约五分之一，而审查质量没有下滑。

Klicius 将工具描述和系统指令比作 API 文档——当文档混乱时，开发者最终会做出更糟的调用，不是因为底层工具有缺陷，而是因为围绕它的指导辜负了他们。

“不清晰的工具提示对 LLM 也会产生同样的影响；措辞上的微小变化会影响成本、质量以及调查的形态，因为它改变了智能体分配注意力的方式，”Klicius 写道。

工具追踪显示智能体在探索代码，而不是审查差异

这里让基准测试有用的不是分数本身——而是 GitHub 能够准确调出智能体调用了哪些工具、以什么顺序调用、每次返回了多少内容。这份记录显示的是一个行为不太像审查者、更像初次翻看代码库的人的智能体——撒下大网，猜测相关代码可能在哪里，拉回远超任何单个审查问题所需的内容。

Before — a simplified illustration of the general-purpose behavior we observed: widening the search, guessing paths, and accumulating context. — 之前——我们观察到的通用行为的简化示意：扩大搜索范围、猜测路径、不断累积上下文。（GitHub）

这些额外材料都没有被丢弃——它们在审查剩余过程中一直留在智能体的工作记忆里，推高了成本，却未必帮助智能体得到更好的答案。

这一切都不是不合理的——如果你的助手在动代码之前先熟悉代码库，这正是你希望它表现出的行为。但审查拉取请求是另一项不同的任务。目标不是对代码库建立广泛的理解，而是收集刚好足够的上下文，以判断某个具体改动是否引入了问题。

新指引收窄了智能体的搜索范围，将审查成本削减了五分之一

工具本身没有任何变化。变化的是智能体被要求使用这些工具的顺序——从 diff 开始，用 grep 和 glob 缩小候选范围，只有当它真正知道哪个文件或哪段行范围重要时，才调用 view。连失败处理也变得更具体：返回为空的搜索应该用更简单的词重试一次，而不是把它当作开始猜测邻近文件的信号。

After — a simplified illustration of the review-shaped behavior the prompt guided toward: stay anchored to the diff, narrow with grep and glob, then read focused ranges with view. — 之后——对提示词所引导的“审查形态”行为的简化示意：始终锚定在 diff 上，用 grep 和 glob 缩小范围，然后用 view 读取聚焦的行范围。（GitHub）

在生产环境中，这一转变得到了验证：平均审查成本下降约 20%，而审查质量保持不变。值得指出的是，这是 GitHub 根据自身基准测试报告的数据，并非独立验证的数字。

更有意思的结果来自在一个没有帮助的地方测试同样的修复。GitHub 尝试在 Copilot CLI 本身内部应用同样的“审查形态”指引，却没有看到同等的收益，因为 CLI 会话没有单一的拉取请求作为锚点——开发者可能在任务进行到一半时改变整个任务方向，所以一开始就没有可供收窄范围的 diff。工具从来都不是那个关键变量。真正重要的是围绕它的指引是否与智能体实际被要求完成的任务相匹配。

证明这一修复的基准测试

如果没有测试的方法，这一切都不会被发现。GitHub 之所以能够识别出这一回归——并证明重写有效——是因为它有一套基准测试套件，可以重放前后相同的审查，同时衡量成本和质量。没有这些证据，新工具很容易成为替罪羊，而真正的原因——不再与任务匹配的指令——可能会一直无人察觉。

这与 Tessl 的评估模型背后的原则相同：在每次改动前后测试和衡量一项技能的指令，把它们视为需要持续验证的东西。GitHub 为 Copilot 代码审查在内部构建了这套评估基础设施。跨多个智能体和多种工具管理技能的团队，也需要同样可重复的证据，以区分真正的改进与仅仅改变了智能体行为的改动。

更广泛的教训是，任何正在整合工具、升级模型或跨智能体标准化指令的团队，都在做与 GitHub 相同的赌注：共享组件在它们被使用的所有地方都会表现一致。这个赌注失败时不会自我宣告——它只会表现为稍微变差的输出，而没有人足够密切地衡量以捕捉到它，这正是要在改动发布之前就把这种衡量机制建立起来的理由。