超越 grep：倡导丰富上下文的 AI 工具

一篇文章将质量优秀的AI代码助手的关键从其模型转移到其“马具”——决定将代码库的哪些部分展示在用户面前的那一层。解读一篇重新将上下文工程置于核心的文章。

出发点

每个资深开发者都经历过的一个具体案例：打开IDE，要求助手“重构此函数以使用新的内部API”——它生成的代码语法上看起来合理，但忽略了项目的三个约定、两个内部依赖项，以及三十行后已存在的一个辅助函数。模型并非“不够聪明”，只是没有看到需要看到的内容。

这正是Vinay Perneti（Augment Code）在接受《Ars Technica》采访时提出的论点——《超越 grep：支持丰富上下文的 AI 编码工具》中所捍卫的：由工具链（选择、排序并将上下文注入提示的机制集合）的权重，如今已超过底层模型的选择。

“贫乏”工具链的作用

本质上是高级 grep：

• 对仓库文件进行简单的嵌入搜索，
• 在光标周围打开上下文窗口，
• 可能还包括当前文件的全部内容。

这对本地任务（重命名变量、修正签名）有效。但当需要理解为何三个模块外的测试失败时，它便土崩瓦解。

“丰富”工具链的作用

三个累积构建的模块，沿袭 Perneti 在 Augment Code 的主张：

1. 代码依赖关系图——导入、调用、继承：工具链沿着边缘追踪，带回真正有用的定义，而非仅按文本接近性返回文件。
2. 执行历史——测试跟踪、日志、上次 pytest 或 cargo test 的输出。模型看到的是导致故障的内容，而非仅是故障的代码。
3. 会话记忆——先前对话中做出的决策（“我们选择了库 X 而非 Y”），避免助手在每一轮对话中重新质疑这些决定。

最近的开源项目展示了这些模块的每一个——tree-sitter 生态系统用于结构化分析，围绕 ripgrep 的工具与语义索引结合，以及维护“草稿板”的代理框架。

为何这是关键

两个经济原因：

• token 价格下降，上下文窗口扩大：我们可以发送更多内容。但无法发送全部——一个拥有 50 万行代码的单体仓库仍无法触及。因此必须筛选。
• 模型在正确时刻展示的内容上推理得更好，而非在杂乱无章的内容中排序。优先级正确的工具链胜过模型在其自身窗口中排序不当的情况。

换言之：区分一个我们能容忍的助手与一个我们依赖的助手的关键，不再是模型的规模。它在于其感知环境的软件工程。

记住

• “工具链”（上下文工程）已成为代码助手的真正差异化因素——由 Vinay Perneti 在 Augment Code 公开捍卫的论点。
• 丰富的工具链结合代码图、执行历史和会话记忆——而非仅文本搜索。
• 如今选择工具，既要评估其工具链，也要评估其嵌入的模型。