GitHub: 更好的工具让Copilot代码审查变差了——重写提示词在降低20%成本的同时恢复了质量
GitHub发现，将Copilot代码审查迁移到更好维护的工具后，结果起初变差了——原因不是工具，而是不适配新工具和实际工作流程的过时提示词。通过将提示词重写为diff优先方式（批量发现后再读文件，分析锚定在PR diff上），他们在保持同等质量的前提下将平均审查成本降低了约20%。
🤖
本文由人工智能基于一手来源生成。
2026年7月10日，GitHub发布了一篇罕见坦诚的工程博客：当Copilot代码审查切换到更好维护的工具时，结果起初反而变差了。分析显示，问题不在工具，而在于提示词（代理指令）与代码审查员实际工作流程不匹配。
错误在哪里？
旧提示词引导代理进行「广泛探索」——在聚焦于变更之前先审查仓库的大部分内容。这在代码审查pull request时通常不需要的上下文上浪费了token和时间。当更强大的新工具拿到这些旧提示词时，只是更高效地做了一件错误的事情。
Diff优先方式如何运作？
解决方案是围绕两个原则重写提示词。第一：批量发现操作（分组收集信息）先于读取单个文件，而非交替探索。第二：分析锚定在PR diff上——代理从实际发生变化的内容出发，只在必要时才获取更广泛的上下文。结果是平均审查成本降低约20%，质量保持不变。
为何这一教训具有普遍意义？
这一发现是对arXiv论文「Harness Effect」所量化论点的具体证明：AI代理的经济性由编排（提示词、流程、上下文）而非模型本身决定。GitHub的案例也展示了反面——升级模型或工具而不调整提示词可能使结果变差。对于所有构建AI编码工具的人，信息是实际的：换模型之前，先阅读并重写提示词。
常见问题
- 为何更好的工具让Copilot代码审查变差了？
- 因为提示词既未针对新工具进行调整，也不符合实际的审查工作流程——旧的「广泛探索」逻辑在审查不需要的上下文上浪费了资源。
- GitHub如何解决这个问题？
- 将提示词重写为diff优先方式：读取文件前先进行批量发现操作，分析锚定在PR diff上，而非对整个仓库进行广泛探索。
- 节省了多少成本？
- 在保持同等结果质量的前提下，平均审查成本降低了约20%。