你浪费了90%的上下文窗口
2026年，Claude 4.5的上下文窗口是200K tokens（约15万英文单词），GPT-5据称达到了256K。这听起来很多——你可以把一整本《代码大全》塞进去。
但实际情况是：大多数程序员在AI编程中使用的上下文窗口不到其容量的10%。不是因为他们不需要，而是因为他们不知道如何有效地填充上下文窗口。结果就是：AI只看到了你项目的冰山一角，生成了和你的代码库格格不入的代码。
金句：上下文窗口就像你的工资——不是越大越好，而是你利用得越好越好。
上下文窗口的三个层次
我总结了AI编程中上下文窗口利用的三个层次：
层次一：单文件上下文（10%利用率） 大多数程序员的默认操作：打开一个文件，选中一段代码，让AI分析或修改。此时AI只能看到当前文件的内容，对其他文件一无所知。这种模式下的AI代码生成，就像让一个工程师只看一个零件就设计整台机器。
层次二：多文件上下文（40%利用率）
进阶用法：在Cursor中用@file引用多个相关文件，在Claude Code中用/add-dir添加整个目录。AI能看到相关模块的代码，理解模块间的依赖关系。这种模式下，AI生成的代码能更好地融入现有代码库。
层次三：全项目上下文（80%利用率） 高级用法：使用代码库索引（Cursor的Codebase Indexing、Claude Code的项目索引）+ 相关文档 + 架构设计文档 + 编码规范 + 历史bug记录。AI不仅能看到你的代码，还能理解你的设计意图、编码风格和常见陷阱。
金句：给AI看代码是"授人以鱼"，给AI看文档是"授人以渔"。代码告诉AI"是什么"，文档告诉AI"为什么"。
上下文窗口的实战技巧
技巧一：优先级排序，不是越多越好
上下文窗口大，不代表你要把所有东西都塞进去。塞得越多，AI越容易"分心"。我的经验是：上下文窗口的填充遵循"二八原则"——20%的内容贡献了80%的准确性。
优先级排序：
- 要修改的目标文件（必须）
- 目标文件直接依赖的模块（重要）
- 项目的编码规范和架构文档（重要）
- 最近的git提交记录（了解最近的变更上下文）
- 类似功能的实现代码（参考）
- 测试文件和测试数据（辅助）
技巧二：使用"上下文模板"
不要每次都手动选择文件。建立一个"上下文模板"——根据任务类型，预设需要包含哪些文件。
例如，修改一个API接口时，上下文模板包括：
- 接口实现文件
- 接口的DTO/VO定义
- 相关的Service层代码
- 相关的Repository/DAO层代码
- 接口的测试文件
- API文档（如果有）
技巧三：利用AI的"注意力机制"
AI并非平等对待上下文窗口中的所有内容。开头和结尾的内容更容易被AI关注。所以：
- 最重要的信息放在上下文的最前面
- 具体的指令和要求放在最后面
- 中间放参考代码和背景信息
技巧四：定期清理对话历史
长时间对话时，AI的上下文窗口会逐渐被历史对话占满。当对话超过50轮时，新的代码生成质量会明显下降。我的经验是：
- 每完成一个功能模块，开启新对话
- 不要在一个对话中处理多个不相关的任务
- 如果对话超过30轮，考虑总结当前状态，然后开启新对话
上下文窗口的"隐形天花板"
即使有200K tokens，上下文窗口仍然存在一个"隐形天花板"：AI的注意力衰减。
研究表明，AI对上下文窗口中间部分的内容关注度最低，对开头和结尾的内容关注度最高。这就是所谓的"Lost in the Middle"现象。如果你把关键信息放在上下文窗口的中间位置，AI可能会忽略它。
破解方法：不要在上下文窗口中间放重要信息。把最重要的信息放在开头（“以下是核心需求和约束”），把具体的指令放在结尾（“请实现以下功能”），把参考代码放在中间。
上下文窗口不是越大越好
2026年，AI公司正在竞相扩大上下文窗口——从200K到500K，再到1M tokens。但更大的上下文窗口也带来了问题：
- 推理成本上升：更大的上下文窗口意味着更高的API调用成本
- 推理速度下降：处理更多上下文需要更长的时间
- 注意力稀释：关键信息被淹没在大量无关信息中
- 过度依赖：开发者倾向于"把所有东西都扔给AI"，而不是精心挑选上下文
金句：2026年的AI编程不是"谁的上下文窗口更大"，而是"谁更会用上下文窗口"。前者是厂商的竞争，后者是你的竞争力。
结论
200K tokens的上下文窗口是2026年AI编程的标配。但大多数程序员只用了它的10%。精通用好上下文窗口，你的AI编程效率能再提升50%——不需要升级模型，不需要换工具，只需要改变你使用工具的方式。
下次你打开AI编程工具时，花30秒想一下：AI看到了什么？它没看到什么？它需要看到什么？这三个问题，决定了你的AI编程效率的天花板。