如果你用过AI代码审查工具，可能有过类似的体验：它有时能找到真正的问题，有时又像个"代码观光客"——打开一堆文件，翻来翻去，最后给的评论却没什么实质帮助。

GitHub的Copilot代码审查团队最近也遇到了这个问题。而且问题的起因，说来有些反直觉：他们给Copilot换上了更好的工具，结果代码审查反而变差了。

一个反直觉的回归

Copilot代码审查背后是一套agent系统。它读取Pull Request的diff，然后探索周围代码来发现问题。过去，这套系统用的是自己维护的一套代码探索工具。当GitHub决定把这些工具换成Copilot CLI（命令行工具）共享的那套——grep、glob、view——团队预期这是一次"干净升级"：共享工具更成熟、维护更好，应该能提升审查质量。

离线基准测试的结果却让人意外：审查成本上升了，发现问题数量下降了。

问题不在工具本身。Grep还是那个grep，glob还是那个glob。出问题的是工具的使用方式——或者说，agent被教导如何使用这些工具的方式。

问题出在指令设计

Copilot CLI的工具是针对"编码助手"场景设计的。当一个开发者问"解释一下这个仓库的架构"或者"帮我在这个项目里加个功能"时，agent需要广泛搜索、全局理解、大胆推测。这种"宽泛探索"的行为模式在那种场景下是正确的。

但代码审查是另一回事。

一个审查者看Pull Request时，起点是diff。他的思考方式不是"让我了解这个仓库的全貌"，而是"这个改动引入了什么问题？我只需要最少的上下文来确认或排除这个风险"。

旧指令让agent以"编码助手"的方式使用工具——广泛搜索、猜测路径、读取大量无关文件。这导致两个问题：一是每次工具调用返回的结果都变成context window里的token，成本随之增加；二是大量无关信息稀释了模型的注意力，真正的问题反而更难被发现。

把"编码助手"改造成"审查者"

解决办法不是换工具，而是重写指令。

团队重新设计了工具的使用流程，核心逻辑只有几句话：从diff出发。先用grep和glob窄化搜索范围。找到具体路径后，用view精确读取需要的内容。如果grep没找到，用简化的搜索重试。如果路径不对，用glob重新定位而不是继续猜测附近的路径。

效果是直接的：审查成本降低了大约20%，同时审查质量保持不变。

这个案例真正有意思的地方不在于技术难度——它不涉及什么复杂的算法创新——而在于它揭示了当前AI应用开发中的一个普遍问题：很多团队在给agent更换工具时，只考虑"工具能不能用"，很少考虑"工具的使用方式是否需要随场景变化"。

对开发者的启示

如果你在自己的项目中接入了Agent框架（无论是Copilot还是其他平台），很可能也继承了一套工具指令。这些指令在原始场景下能工作，但当你的使用场景偏离了它们的设计目标，工具会"安静地"开始跟你对着干——不是出明显错误，而是效率慢慢下降，却很难定位原因。

就像Copilot团队发现的，问题往往不在工具本身，而在"工具+指令+场景"三者的匹配度。工具可以通用，但指令需要针对场景重新设计。这个道理说起来简单，但在实际工程中，很多团队会忽略"指令"这个中间层，直接在工具层面找原因。

未来AI工具的竞争，不只在模型能力，也在谁更能理解"工具应该怎么被使用"这个问题。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）