上下文工程：为什么你的AI输出平平无奇（以及如何修复输入）

你的输出平平无奇，是因为输入臃肿、过时或排序混乱——而不是因为措辞有问题。Anthropic的官方文档直言不讳："更多上下文并不自动意味着更好的结果。随着token数量增加，准确性和召回率会下降，这种现象被称为上下文腐化（context rot）"（Claude平台文档）。上下文工程正是解决之道——Anthropic将其定义为在LLM推理过程中精心筛选"最优token集（信息）"（Anthropic Engineering）。

数字对"多多益善"的习惯毫不留情。在NoLiMa基准测试中，13个声称支持128K以上上下文的模型里，有11个在32K token时准确率跌破了短上下文得分的一半（arXiv:2502.05167）。

这是一本面向ChatGPT、Claude、Gemini和Copilot使用者的实战手册——而非框架开发者——告诉你该拧哪个旋钮、在哪个产品中拧，以及它的实际价值。

上下文工程取代了提示魔法

如果你的输出差强人意，提示词的措辞几乎从来不是问题所在。上下文工程正是解决这一问题的实践：Anthropic将其定义为"一套在LLM推理过程中精心策划并维护最优token集（信息）的策略——包括所有可能出现在提示词之外的其他信息"，并称其为提示工程的自然演进（Anthropic Engineering）。问题的核心从"我该怎么措辞？"转变为"什么样的上下文配置最有可能让模型产生我想要的行为？"

从"我该怎么措辞？"到"窗口里应该放什么？"

措辞在边际上仍然重要，只是不再是关键杠杆所在。一个措辞完美的问题配上臃肿、半相关的窗口，输给措辞直白但上下文干净的同类问题——本文余下内容基本上都是这一论断的佐证。

我们追踪的212个提示工程工具中，绝大多数只优化你输入的那句话，几乎没有一个触及与它共享窗口的其他五项内容。

你实际可以控制的五类输入

每次请求都会将以下几部分组合成一个窗口，而这些部分你都能看到并修改：

• 系统指令——无论是自定义GPT的指令字段、Claude Project的描述，还是代码仓库中的CLAUDE.md文件。
• 记忆：产品跨会话为你保存的内容，通常不向你展示完整文本。
• 附加文档及其解析质量——这是整个技术栈中最被低估的变量。
• 检索到的文本块（如果工具支持检索），以及检索器认为相关的内容。
• 对话中的历史轮次，包括你二十条消息前放弃的每个死胡同。
• 工具定义——无论是否调用工具，都会消耗token。

算下来是六项，你在产品界面就能控制它们全部——无需框架，无需API密钥。

因此，这是一本面向输入侧的实战手册，专为ChatGPT、Claude、Gemini和Copilot的用户而写，而非在这些工具之上构建智能体系统的开发者。告诉你该拧哪个旋钮、在哪个产品中拧，以及2026年的数据显示这样做的价值几何。

AI上下文窗口解析：宣传尺寸 vs 可用尺寸

规格表上的数字是存储上限，而非性能保证。一个能接受百万token的模型会欣然接受它们，然后给出比3,000 token时更差的回答。把宣传的窗口大小理解为房间的天花板高度，而不是你能实际工作的桌面面积。

哪些内容真正占用窗口

比你以为的多得多。API请求的每个部分都占用同一预算：系统提示、线程中的每条消息（包括工具结果）、图片和PDF、工具定义本身，以及模型自身的输出（包括扩展思考过程）（Claude平台文档）。缓存的前缀同样占用窗口。提示词缓存改变的是你为这些token付出的费用，而非它们是否计入总量。

因此，一段感觉很短的对话，实际可能携带了4万个token的附加PDF、工具模式和你从未看到的历史推理内容。这正是那些百科全书式介绍文章所遗漏的部分。

规格表上没有的32K悬崖

NoLiMa基准测试剔除了问题与埋藏在干草堆中的答案之间的字面重叠，然后对13个声称支持128K以上上下文的模型进行了测试。在1K token以下时表现良好；到32K时，13个中有11个跌破了各自短上下文基线的一半，Llama 3.1 70B从94.3%跌至42.7%（NoLiMa, arXiv:2502.05167）。该预印本发表于2025年2月，早于下表中的所有模型。这一发现的走势在更新的研究中依然成立，但具体百分比是正在老化的证据，而非当前的排行榜。

当前窗口的真实情况（2026年数据）

Anthropic提供这个1M窗口无需beta请求头，也无附加费用（Claude平台文档）。OpenAI的窗口名义上更大，但定价方式不同：在GPT-5.4上超过272K输入token后，整个会话将按"输入价格2倍、输出价格1.5倍"计费（OpenAI API文档）。在那里，臃肿是实实在在的账单条目，而不仅仅是质量损耗。

如果你要跨厂商比较容量，请查看模型自身的规格页面，而不是某篇汇总文章：2026年窗口已经变更过两次，过时的表格随处可见。我们的324个AI模型目录是找到正确页面的起点。

上下文腐化：为什么增加内容通常会让输出变差

这种退化有其机制，并不神秘。Transformer需要对n个token之间的n²个成对关系建模，因此每增加一个token，其他所有token就要更激烈地竞争模型的注意力。Anthropic工程团队将其称为有限的注意力预算，类比人类的工作记忆，并指出随着上下文增长，注意力会"被摊薄"。他们的处方直截了当：找到"能最大化某一期望结果的、最小可能的高信号token集"。

注意力预算问题

Anthropic自己的产品文档承认了这一点，而非掩饰。平台文档写道："更多上下文并不自动意味着更好的结果。随着token数量增加，准确性和召回率会下降，这种现象被称为上下文腐化。"这是卖给你1M token窗口的厂商在告诉你不要填满它。

同一问题、同一答案，375倍的噪声

Chroma测试了18个模型，包括GPT-4.1、Claude 4、Gemini 2.5和Qwen3，发现即使是检索和单词复述这类简单任务，较长的输入也会导致可靠性下降（Chroma）。其中LongMemEval的运行结果最值得记住：在所有模型家族中，仅包含约300个token相关轮次的专注提示词，表现均优于携带约113k token完整对话历史的完整提示词，Claude系列模型的差距最为显著。同一问题，两种情况下答案都在上下文中，唯一的变量是它被多少无关内容包围。

Chroma还发现，在所有18个模型中，模型在乱序干草堆上的得分高于逻辑连贯的文档。连贯的周围文本给模型提供了更多看起来合理的落脚点。该报告发布于2025年7月14日，距今已超过一年，早于当前这代模型。

这一效应并未随时间消退。在MonitorBench上，在前面追加800k token的良性无关动作，使Opus 4.6的召回率从98.6%跌至88%（arXiv:2605.12366）。任务本身没有任何变化，变的只是填充内容。

在日常使用中的具体体现

你肯定遇到过这种情况，只是没有给它命名。第12条消息时准确理解你需求的对话，到第90条时开始输出千篇一律的废话——因为你的需求说明已被78条半成品草稿的消息淹没。你为了求全往NotebookLM里加了40个来源，却发现答案比加8个时更模糊。编程会话中，模型忘记了你一小时前声明的某个约束，然后自信地绕过它重写了代码。

这些都不是模型在偷懒。是你把注意力预算花在了不值得的token上。

文档准备：几乎所有人都跳过的步骤

文档在提示词中的位置会影响你得到的答案。对于超过20,000 token的输入，Anthropic的提示指南要求将长篇数据放在顶部，位于查询、指令和示例之上："在测试中，将查询放在末尾可将回复质量提升高达30%，尤其是在复杂的多文档输入场景下"（Claude平台文档）。大多数人做的恰恰相反——先打出问题，再把报告粘贴在下方。

把长内容放在顶部

同一份文档还给出了一个值得原样复用的结构：用<document>标签包裹每个文档，并加上<source>和<document_content>子标签，让模型能分辨一个文件在哪里结束、下一个从哪里开始（Claude平台文档）。然后让它在回答前引用相关段落。这一行指令迫使模型在文本中定位证据，而不是凭半印象重构，当答案看起来有问题时，你也有了可核查的依据。

<document>
  <source>Q3-board-deck.pdf</source>
  <document_content>...full text here...</document_content>
</document>
<document>
  <source>renewal-contract-2026.pdf</source>
  <document_content>...full text here...</document_content>
</document>

Before answering, quote the passages you relied on.
Question: which renewal terms conflict with the Q3 revenue plan?

为来源打上标签，以便模型引用

在将此做法标准化之前，有一点需要注意：各厂商的建议并不一致。Anthropic建议长数据放前面；Google的指南则相反，要求在末尾放置指令。因此，从Gemini教程搬来的提示词模板，在Claude中使用时可能表现不佳，却看不出明显问题。在你实际付费使用的模型上，用同一组文档分别测试两种顺序，各问十个问题，保留胜出的那种排序。这二十分钟的工作，对应的是高达30%的质量提升。

解析器的选择决定了模型能看到什么

这一切都无法挽救一次糟糕的提取。一张扫描发票表格被解析成一长串连续文字，一篇双栏论文被逐行交错混排，一个脚注被插入句子中间——模型会忠实地读取这些乱码并从中作答。提取步骤决定了准确率的上限，所有下游工作都受制于此。将解析器视为质量决策，在正式使用前用你最难处理的真实文件测试两三种方案。我们的目录收录了217个AI文档和PDF工具，好与差之间的差距体现在你的输出上，而不是它们的营销页面上。

检索卫生：更少、更好的文本块胜过更多的文本块

在搭建检索层之前，先想清楚你是否真的需要它。Anthropic自己的指南指出，如果你的知识库小于200,000 token（约500页），你完全可以将整个知识库直接放入提示词，无需任何检索（Anthropic Engineering）。大多数内部Wiki、产品手册和政策文件都在这个限额以内。

你真的需要检索吗？

如果你的语料库放得下，就跳过向量数据库。你将避免分块决策、嵌入漂移，以及一类无声的失败——正确段落从未进入提示词。配合提示词缓存使用，这样你无需为同样的20万token每次全价付费。

超过这个规模，检索就不再是可选项，质量提升变成了一系列小修复的叠加效果。

三个叠加生效的修复措施

Anthropic逐项进行了基准测试。在嵌入前为每个文本块追加块级上下文，将top-20检索失败率从5.7%降至3.7%，约减少35%。加入上下文感知的BM25混合搜索，将失败率降至2.9%，减少49%。在此基础上叠加重排序，降至1.9%，总体减少67%（Anthropic Engineering）。每一步单独看都不起眼，三者叠加的改善效果大约是第一步的三倍。

精简工具定义同样重要

工具模式也是上下文。如果你给模型传入40个工具定义，而它只需要其中两个，你为38个干扰项付了钱。RAG-MCP的工作只检索相关模式，而非列出全部，在工具选择准确率从13.62%提升至43.13%的同时，提示词token减少了一半以上（arXiv:2505.03275）。这与文本块筛选是同一套纪律，只是应用在了上面一层。

Anthropic的子智能体模式将其进一步延伸：专门的智能体负责深入挖掘，并向协调智能体返回约1,000至2,000 token的压缩摘要，使主上下文永远看不到原始搜索记录（Anthropic Engineering）。如果你在挑选组件而非自己编写，我们的目录收录了550个AI智能体以及一批开箱即用地实现了这些模式的检索与智能体框架。

记忆功能：在每个工具中该拧哪个旋钮

每个消费级AI产品现在都会将你未曾输入的内容注入上下文——已保存的事实、历史对话、应用活动、上传的项目文件。在你说第一句话之前，窗口里就已经有东西了，不搞清楚这一点，就谈不上在聊天应用中做上下文工程。

一条错误的记忆比没有记忆的代价更高。它是看起来高度可信的文本，模型将其视为事实，而且它紧挨着你的指令，而那里的注意力是最强的。过时的职位头衔、旧客户名称、你为一次性任务设置的偏好——每一个都在悄悄影响此后的每一个回答。

ChatGPT：两个独立的开关

ChatGPT的记忆机制分两套，不是一套。已保存记忆是你可以逐条阅读和删除的离散事实，而对话历史引用则通过独立的检索路径从你的历史对话中提取内容（Embrace The Red）。关掉其中一个，另一个依然在运行。如果你清除了已保存记忆后输出仍带有上个月项目的味道，那你漏掉的是历史记录开关。

Claude：项目知识与对话中途的记忆写入

自2026年8月25日Cowork统一更新以来，Claude改为在对话中途写入记忆，而非只在会话结束时写入，因此你在对话中的随口一说也会延续到后续会话（TechCrunch）。这意味着一句无心的题外话可能成为持久的上下文。

项目知识是更好的杠杆，因为它是你主动选择的语料库。保持在Anthropic建议的20万token（约500页）以内，它就可以整体随行，无需检索层来猜测哪些文本块重要（Anthropic）。像管理阅读书单一样修剪它，而不是像档案室那样堆放。

Gemini：三套重叠系统，"关闭"并不等于"删除"

Gemini叠加了个人上下文、你自己写入的已保存信息，以及来自已连接Google应用的活动数据。禁用一个来源只是停止新的写入，并不删除已存储的内容，因此审计意味着要分别访问每项控制并逐一删除，而不是简单地切换开关。

NotebookLM：来源受限的替代方案

NotebookLM对每个笔记本的来源数量设有上限，而这个上限对你有利。它强制执行其他三款工具让你省略的筛选工作，与Anthropic的处方如出一辙：找到能达到期望结果的最小高信号token集（Anthropic）。当一个问题需要八个文档而不是八十个时，从那里出发。

选择一个工具作为你的记忆承载助手，其余的保持干净。在我们目录中的13,174个AI应用中，那些能按条目审计记忆的工具，比那些承诺"记住一切"的工具更有价值。

项目级指令是可复用的上下文

你能写的最划算的上下文，是那种只写一次的上下文。每个严肃的AI工具现在都有一个槽位，用于存放注入每次会话的常驻指令：代码库中的AGENTS.md和CLAUDE.md、Claude Projects、ChatGPT自定义指令、Copilot指令文件。大多数人让这些槽位空着，然后在每次新对话中重新键入同样的三段背景说明。

为什么常驻指令文件优于重复解释

一项跨越10个代码库、124个Pull Request的研究测量了仓库级AGENTS.md文件对智能体行为的影响，结果不仅仅关乎正确性。中位运行时间下降了28.64%，从98.57秒降至70.34秒；在完成率相当的情况下，输出token减少了16.58%（arXiv:2601.20404）。智能体不再需要花时间探索去弄清楚你已经知道的事情。

这就是一句话的论据。良好的常驻上下文让模型更快、更便宜，而不仅仅是更准确——因为智能体消耗token的大部分原因，是在重新发现你的代码规范。如果你在我们目录的260个AI编程助手中做选择，工具是否读取项目指令文件，是比大多数功能对比更好的筛选标准。

指令文件里该写什么

保持足够简短，以至于你自己也会去读它。以下五类内容值得占据一席之地：

• 代码中没有明确声明的约定——比如哪个测试运行器是实际在用的，哪个已经废弃。
• 你的词汇表。如果"account"和"tenant"在这里含义不同，请明确说一次。
• 你想要的输出形式，以你需要的格式（差异对比、表格、五条要点）。
• 简短的禁止事项清单。不要修改生成文件，不要未经询问就添加依赖项。
• 事实来源在哪里，这样模型会去查询它而不是猜测。

不要写任何工具自己能读到的内容——目录树、文件列表、重申的函数签名、README摘要。这些token花在了重复智能体一次调用就能获取的信息上，却在与真正重要的指令竞争注意力。当文件开始被忽视时，重写它——这通常意味着它变得太长了。

上下文臃肿有价格标签

草率的上下文不只是让输出质量下降，还会让账单数字变大。两种定价机制使这一点具体可见，两者都奖励同一个习惯：一个小而稳定、有序排列的前缀。

GPT-5.4的272K阶梯函数

OpenAI的GPT-5.4拥有1,050,000 token的上下文窗口，最多支持128,000 token的输出，但超过272K输入token的提示词将"以2倍输入价格和1.5倍输出价格对整个会话计费"（OpenAI API文档）。请仔细阅读这句话。越线一次并不是对超出部分多收一点费用。它会对整个会话重新定价，包括输出——因此一次粗心地粘贴30万token的内容，会让此后每一轮的输入账单翻倍。

你正在为最有可能拖累答案质量的那些token支付双倍价格。

缓存奖励稳定的前缀

Claude API将缓存读取定价为基础输入价格的0.1倍（90%折扣），而缓存写入在5分钟TTL时为1.25倍，1小时TTL时为2倍（Claude平台文档）。他们的计算示例：10万token复用10次，费用为$1.075，而不缓存则需要$5.00，节省78.5%。

这个折扣只有在前缀字节完全一致时才能生效。缓存基于精确前缀匹配，因此如果你调整文档顺序、在系统提示中插入时间戳，或在轮次之间打乱工具定义的顺序，你将再次支付写入价格而非读取价格。保持缓存热度的习惯，与保持高召回率的习惯完全一致：将稳定的内容以固定顺序放在前面，只让末尾的查询内容发生变化。

本周就能执行的上下文审计

这里的所有内容都不需要API密钥或工程工单。每一项都是你已经拥有的旋钮。

下次长会话前的六项检查

1. 1开启新对话，而不是延续昨天的。Chroma的专注提示词（约300 token的相关轮次）在所有测试模型家族中均优于完整的11.3万token历史记录，Claude的差距最大（Chroma）。
2. 2阅读你已保存的记忆，删除过时的条目。已保存的事实无论是否有帮助都会被注入。
3. 3附加三个好文档，而不是十二个平庸的——并用<document>标签和<source>子标签包裹每一个，以便模型能区分它们（Claude文档）。
4. 4将长内容放在问题上方。对于超过2万token的输入，这种排序方式在Anthropic的测试中可使回复质量提升高达30%（Claude文档）。
5. 5把常驻指令写下来，一次性搞定。仓库级AGENTS.md在124个PR中将中位运行时间降低了28.64%，输出token减少了16.58%（arXiv）。
6. 6在每轮对话中保持前缀完全一致。稳定的前缀可以按0.1倍输入价格命中缓存（Claude文档）。

改善大多数糟糕输出的一个习惯

在重写提示词之前，先看看窗口里已经有什么，然后删掉一些东西。Anthropic自己的文档说得明白："更多上下文并不自动意味着更好的结果"（Claude文档）。在改变你怎么问之前，先改变你喂给模型的内容。

常见问题解答

什么是上下文工程，它与提示工程有何不同？

Anthropic将上下文工程定义为"一套在LLM推理过程中精心策划并维护最优token集（信息）的策略——包括所有可能出现在提示词之外的其他信息"（Anthropic Engineering）。提示工程问的是如何措辞，上下文工程问的是什么样的上下文配置最有可能产生你期望的行为——它涵盖了占用窗口的一切：系统提示、每条消息（包括工具结果）、图片和PDF、工具定义本身，以及模型自身的输出（包括扩展思考过程）（Claude平台文档）。Anthropic将其定位为提示工程的自然演进，而非替代。

更大的上下文窗口总是意味着更好的AI输出吗？

不。宣传的上下文和可用的上下文是两个不同的数字：NoLiMa基准测试了13个声称支持128K或更大上下文的模型，在32K token时，13个中有11个得分跌破各自短上下文基线的一半，Llama 3.1 70B从94.3%跌至42.7%（arXiv:2502.05167，2025年2月）。Anthropic自己的平台文档直言："更多上下文并不自动意味着更好的结果。随着token数量增加，准确性和召回率会下降"（Claude平台文档）。填满窗口还会带来阶梯式而非线性的费用增长——OpenAI对超过272K输入token的GPT-5.4提示词按整个会话2倍输入、1.5倍输出的价格计费（OpenAI API文档）。

什么是上下文腐化，如何避免？

上下文腐化是指随着请求中token数量增加，准确性和召回率随之下降的现象——Anthropic在自己的文档中对此进行了命名（Claude平台文档）。Chroma的"上下文腐化"研究测试了18个模型，包括GPT-4.1、Claude 4、Gemini 2.5和Qwen3，发现即使是简单的检索和单词复述任务，较长的输入也会导致可靠性下降；在LongMemEval测试中，所有模型家族在约300 token的专注提示词上均优于同一问题被约11.3万token的对话历史包围时的表现，Claude系列的差距最为显著（Chroma，2025年7月）。避免方法：只粘贴相关段落、为新话题开启新对话而非延续旧对话，以及让专门的智能体返回1,000至2,000 token的压缩摘要，而非将完整记录传给协调智能体（Anthropic Engineering）。

我应该关闭ChatGPT、Claude或Gemini的记忆功能吗？

这取决于任务，因为记忆会将你未选择的token注入窗口，而那里的每个token都计入总量（Claude平台文档）。对于常规草稿撰写——模型了解你的角色、风格和技术栈能省去重复输入——可以保持开启。对于针对特定文档的高风险分析，请关闭记忆后开启一个干净的对话，因为Chroma发现所有模型家族在约300 token的专注提示词上，均优于同一答案被约11.3万token无关历史包围时的表现（Chroma）。将记忆视为你在每一轮都要付费的常驻提示词，像修剪系统提示一样修剪它。

我需要RAG吗，还是直接把文档粘贴到提示词里就够了？

Anthropic的指导意见是：小规模时检索往往并非必要——"如果你的知识库小于200,000 token（约500页内容），你可以直接将整个知识库放入提示词"（Anthropic Engineering，2024年9月）。超过这一规模，检索质量在Anthropic的基准测试中呈现叠加效应：在嵌入前追加块级上下文将top-20检索失败率从5.7%降至3.7%，加入上下文感知BM25混合搜索降至2.9%，再加重排序降至1.9%，整体减少67%。如果语料库放得下，直接粘贴是更好的默认选择，配合提示词缓存（缓存读取价格为基础输入的0.1倍），复用成本极低（Claude平台文档）。

长文档应该放在提示词的前面还是后面？

对于Claude，将长篇数据放在顶部，位于查询、指令和示例之上。Anthropic的提示指南将此作为超过2万token输入的具体规则，并指出"将查询放在末尾可在测试中将回复质量提升高达30%，尤其是在复杂的多文档输入场景下"（Claude平台文档）。同一份文档还建议用<document>标签（包含<source>和<document_content>子标签）包裹每个文档，并要求模型在回答前引用相关段落。各厂商在排序建议上并不一致，因此从一个厂商的文档中复制来的模板，在另一家的模型上可能表现欠佳——值得在你自己的任务上分别测试两种顺序。