上下文窗口即 IDE：AI 编程智能体成败的关键在于它能看到什么

METR 针对 246 个任务的研究发现，使用 AI 编程工具的有经验开发者比不借助辅助的开发者慢了 19%。与此同时，各厂商宣称提速 24%——营销数字与实测数据之间存在 43 个百分点的差距。瓶颈不在于模型智能，而在于上下文：智能体能看到什么，以及看不到什么。

上下文窗口才是 AI 编程智能体真正的 IDE。模型、温度参数、系统提示词——这些都远不如智能体从你 1 万个文件的代码库中检索到的那 20 个文件重要。把这 20 个文件选对，一个中等水平的模型也能生成正确且高度契合项目的代码。选错了，地球上能力最强的模型也只会产出貌似合理的废话，调试起来比自己从头写还费时间。

这不是等待下一代模型解决的能力问题，而是一个今天就已存在的信息架构问题。正在解决它的团队，用的是和其他人一模一样的工具，却在收获截然不同的结果。

注意力预算是真实存在的

上下文窗口中的每一个 token 都在争夺模型的注意力。Transformer 架构在 token 之间建立 n² 的两两关系——当上下文只有 4,000 个 token 时，这还可以接受；当达到 200,000 个 token 时，数学逻辑就从根本上变了。

对长上下文性能的研究揭示了一种一致的模式，称为"中间迷失"（lost in the middle）：模型能以 85-95% 的准确率回忆起上下文开头和结尾的信息，但位于中间的内容会下降到 76-82%。这不是等待修复的 bug，而是注意力机制的架构特性，每位从业者都需要将其内化。

由此产生的实际后果，是一些研究者所称的"愚蠢区间"。当上下文使用量超过窗口的大约 40% 时，智能体的可靠性就会下降——不是因为模型变差了，而是因为信噪比崩溃了。一个塞满了 18 万个勉强相关代码 token 的 20 万 token 窗口，远不如一个装着精准选出的 3 万个 token 的 3.2 万 token 窗口。

这意味着上下文工程已经取代提示词工程，成为影响 AI 编程质量的首要杠杆。问题不再是"我该怎么措辞我的请求？"——而是"当智能体尝试完成任务时，它能看到什么？"

为什么检索质量胜过模型质量

不同的编程智能体采用截然不同的检索策略，结果差距悬殊。

像 Aider 这样高效的智能体使用基于图的排序，上下文利用率仅为 2-7%——也就是说，它们只用精准靶向的代码填充了可用窗口的极小一部分。使用混合语义-词法索引的中等效率智能体利用率为 15-18%。而那些填充了 40% 以上上下文的智能体，往往产出最不可靠的结果。

检索技术本身构成一个谱系：

• 稀疏检索（BM25、TF-IDF）：快速词法匹配，能找到精确的关键词引用，但会遗漏语义关系
• 密集检索（CodeBERT、专用嵌入）：捕捉语义的神经嵌入，但可能错过结构依赖
• 基于图的检索：利用 AST 和调用图追踪依赖链，擅长跨文件推理
• 混合方法：综合多种信号，通常效果最佳，但计算成本更高

以 Cursor 为例，它使用 tree-sitter 解析文件，在函数定义等有意义的边界处切分，计算 Merkle 树以实现高效的变更检测，并每十分钟重新索引一次。这套基础设施并非附带品——它本身就是产品。模型是可替换的，检索管道才是护城河。

对于大型代码库（20 万个文件以上），两阶段方法占主导：先从向量存储中初步检索缩小候选范围，再由 LLM 按与具体任务的相关性过滤和排序结果。没有这个过滤步骤，上下文窗口就会被结构上相关但与任务无关的代码塞满。

项目记忆文件是上下文工程的变体

CLAUDE.md、AGENTS.md 以及类似的项目记忆文件的爆发，代表着比文档更深层的东西——它是开发者在手动解决上下文检索问题。

当你在 CLAUDE.md 中写下"使用 yarn 而非 npm"或"永远不要编辑 src/generated/ 下的文件"时，你是在预加载那些智能体否则需要通过反复试错才能发现（或者根本发现不了）的上下文。每一行都要和智能体需要处理的实际代码争夺注意力，这也是为什么实践者建议将这些文件控制在 300 行以内。

一个针对 10.8 万行 C# 分布式系统的案例研究，展示了这种方法的规模。团队构建了三层知识体系：一份自动加载的 660 行"宪法"，19 份合计 9,300 行的专项智能体规范，以及 34 份按需调用、涵盖 16,250 行的文档。知识与代码的比率达到了 24.2%——每四行应用代码，就对应大约一行上下文基础设施。

结果很说明问题：人类提示词平均不超过 100 个词，因为预加载的上下文消除了在提示词中解释背景的必要。在 74 个独立会话中涌现出一致的行为，没有相关 bug。遵循计划-执行-审查循环的专项智能体，在复杂任务上的表现优于临时会话。

但这里有一个反直觉的发现。对 AGENTS.md 类文件的研究表明，LLM 生成的上下文文件实际上会将任务成功率降低 2-3%，并使推理成本增加 20% 以上。开发者编写的文件有约 4% 的小幅提升，但同样带来相近的成本代价。"上下文越多越好"的朴素假设并不成立——智能体不会优雅地过滤，它们会执行被给予的每一条指导，即便那些指导增加了并不能改善结果的步骤。

结论是：项目记忆文件在编码最少量、高信号的约束时效果最好——而非面面俱到的文档。

即时检索模式

最有效的上下文策略，与有经验的开发者实际的工作方式如出一辙。你不会记忆整个代码库，而是在脑海中维护一份索引，记住东西在哪里，在需要时再去查具体内容。

同样的模式对 AI 智能体也有效。高效的系统不是预加载所有可能相关的内容，而是维护轻量级标识符——文件路径、函数签名、模块描述——并仅在需要时动态加载完整内容。这是将渐进式披露（progressive disclosure）应用于机器认知。

三种技术让这在实践中奏效：

元数据即导航。 文件命名规范、目录层级和类型信息提供了线索，帮助智能体在读取完整内容之前理解什么是相关的。结构良好的代码库本身就是一套检索系统。

子智能体架构。 专项子智能体在干净的上下文窗口中处理聚焦的任务，向协调智能体返回精炼的摘要（1,000-2,000 个 token）。这隔离了细节性的搜索上下文，同时让主智能体专注于综合。研究表明，每个智能体超过 5-10 个工具时性能会下降——子智能体让你在不扩大工具集复杂度的情况下扩展能力。

对话压缩。 对于长时间运行的会话，在保留架构决策和未解决问题的同时，对已完成工作进行摘要，可以防止上下文腐烂。关键是先最大化召回率（不要丢失重要决策），再提升精确率（修剪冗余输出）。

这些模式解释了为什么像 Claude Code 这样基于终端的智能体，尽管界面更简单，却能在复杂任务上胜过 IDE 集成工具。上下文管道比界面外壳更重要。

生产力差距是可量化的

生产力差距并非微不足道。投入上下文工程的组织报告任务完成率提升 2-3 倍，API 成本降低 40-70%。成本降低尤其值得关注——更好的上下文意味着每次成功结果处理的 token 更少，而不是更多。

METR 研究中 19% 的速度下降直接源于上下文失败。开发者将总任务时间的 9% 花在审查和修改 AI 输出上——如果智能体一开始就看到了正确的代码，这些时间本不存在。在编码和手动向工具解释上下文之间不断切换，比任何模型局限都更能破坏心流状态。

考虑两种场景的差异。第一种：开发者要求智能体添加一个缓存层。智能体只看到当前文件，生成了一个独立的缓存实现，复制了三个目录之外已有的缓存工具，并使用了与项目规范不一致的模式。开发者花了 20 分钟调试集成问题并重写输出。

第二种：智能体的检索管道找到了现有的缓存工具、项目的配置模式，以及 CLAUDE.md 中关于首选缓存策略的条目。生成的代码第一次就顺利集成。同样的模型，同样的开发者，同样的任务——不同的上下文，不同的结果。

这对你的工作方式意味着什么

如果你正在使用 AI 编程工具却没有看到预期的生产力提升，问题几乎肯定出在上下文上，而非能力上。以下是应对方法：

审查智能体实际看到了什么。 大多数工具现在都会暴露其上下文内容（例如 Claude Code 的 /context 命令）。看一看典型任务加载了什么。正确的代码在那里吗？无关的代码在挤占它吗？

为约束而非文档编写项目记忆文件。 CLAUDE.md 的每一行都应该防止一类特定的错误。"使用 src/utils/cache.ts 中现有的 CacheManager"能防止重复实现。"我们的缓存方案"后面跟着三段哲学性论述则是在浪费注意力预算。

将代码库结构化为一套检索系统。 一致的命名规范、清晰的模块边界和描述性的目录结构，帮助智能体（和人类）找到正确的代码。一个组织良好的代码库，价值超过一套复杂的嵌入管道。

偏好更少、更精准的上下文 token。 如果你可以在一个加载 50 个文件的智能体和一个加载精挑细选的 8 个文件的智能体之间选择，选后者。低于 10% 的上下文利用率与最佳结果高度相关。

上下文窗口不只是一个技术约束——它是 AI 智能体理解你代码库的镜头。把它当作首要工程界面而非需要绕过的实现细节来对待的团队，才是那些在用 AI 工具高效交付代码、而非与之苦苦周旋的团队。