上下文预算
定义
上下文预算 是指：在与 AI 或 LLM 协作时，对要放进模型上下文窗口的资料进行有意识的取舍、压缩、分层和组织。
它的核心不是窗口容量本身，也不是单纯讨论“最多能塞多少 token”，而是讨论：在一次任务里，哪些信息今天必须出现，哪些只需摘要，哪些会制造冲突，哪些必须保留原文不能被改写。
因此，上下文预算本质上是一种上下文管理方法，而不是一句更花哨的 Prompt 写法。它解决的不是“怎么把一句指令写漂亮”，而是“怎么把模型工作所需的资料桌摆干净”。
在本文中的语境
该概念出现在 GPT-5.6 发布的讨论中，但原文强调的重点不是模型参数或入口资格，而是一个更长期的趋势：强模型时代，普通用户需要从“会写一句 Prompt”升级到“会管理上下文”。
原文先明确边界：GPT-5.6 当时仍处于 limited preview，这篇讨论不是教用户去哪里打开模型，也不是复述模型档位，而是借发布时一并被讲清楚的 token 价格与 Prompt caching，提醒用户理解 AI 工作的基本成本结构。
这里的关键信号是：AI 每次工作，都要先读取你给它的上下文。课程要求、论文草稿、面试 JD、项目背景、写作限制，都会进入 input tokens；模型产出的总结、建议、改写稿，则会形成 output tokens。
所以，上下文预算在本文中不是开发者 API 优化技巧，而是普通用户在日常学习、写作、求职、研究中都需要掌握的协作能力。
为什么它叫“预算”
“预算”这个词强调的不是穷，而是有限资源下的配置。进入上下文窗口的内容越多，并不自动代表结果越好；如果内容重复、冗长、混乱，反而会同时带来三类代价：
- token 成本上升：同一段背景反复粘贴，系统就要反复处理重复内容。
- 等待时间上升：模型需要读更长的输入，整体响应更慢。
- 误解空间上升：当旧要求、新要求、无关材料、不确定来源混在一起时，模型更容易抓错重点，或把不该算数的东西当成当前约束。
因此，上下文预算并不是“为了省 token 而省 token”，而是在成本、稳定性和理解准确度之间做内容治理。
“书桌”类比：好上下文与坏上下文
原文把上下文比作一张书桌：你这次把什么资料摆上桌，AI 就看着什么资料做事。
一张清楚的书桌，至少应当包含以下结构：
- 目标：这次到底要完成什么。
- 背景：完成任务必须知道的固定前提。
- 资料来源：哪些信息来自原文、规范、老师反馈、岗位描述或既有材料。
- 禁止事项：什么不能做，什么不能编，什么不能越界。
- 输出标准：结果要写成什么样，多长，按什么格式，是否要标出依据与不确定点。
这种上下文的特点是：模型不需要猜用户是谁，也不需要从一堆历史要求里推断到底哪个要求现在仍然有效。
相反，一张混乱的书桌会把下面这些东西堆在一起：
- 旧要求
- 新要求
- 无关材料
- 来源不确定的信息
在这种情况下，即使强模型表面上“写得很顺”，也不代表方向没有偏。语言流畅不等于任务约束被正确执行，这正是上下文预算要解决的问题。
四类信息的处理判断
原文把上下文预算的关键操作，落在对不同信息类别的区分上。至少要把以下四类内容分开处理：
1. 必须保留的信息
这类信息一旦拿掉，任务就会失真或无法执行。例如：
- 当前任务目标
- 当前适用的最新要求
- 必须遵守的边界条件
- 直接影响答案方向的背景事实
这部分不应因为“想省篇幅”而删除，否则模型只能靠猜。
2. 可压缩的信息
这类内容重要，但不一定要逐字保留原长文本。它们可以被概括成更短的背景说明、要点列表或结构化摘要。例如：
- 较长的项目背景
- 重复出现的课程说明
- 多轮交流里已经稳定、不再变化的共识
可压缩不等于可忽略，而是可以把长材料整理成更省 token、却仍可执行的版本。
3. 纯干扰信息
这类内容会增加长度，却不帮助模型完成当前任务，甚至制造噪声。例如：
- 已失效的旧要求
- 与本次任务无关的材料
- 暂无根据的猜测性内容
- 不知道是否可信、又未标明状态的来源
这类信息应尽量移出当前上下文，否则就会抬高成本并扩大误解空间。
4. 必须保留原文的信息
有些信息不能只给模型“意思差不多”的摘要，而要保留原句或原段。原文点明的典型情况包括：
- 课程要求
- 老师反馈
- 不能乱改的段落
- 岗位 JD 中关键表述
- 资料中必须基于原文作答的部分
原因在于，这些内容一旦被二次改写，可能丢失约束、改变语气或误伤细节。上下文预算不只关心长度，也关心保真要求。
与 Prompt caching 的关系与边界
Prompt caching 在本文中被拿来帮助用户理解上下文预算，但两者不是一回事。
原文特别强调，Prompt caching 最容易被误解成“模型终于长期记住我了”，这是不准确的。更合适的理解是：如果你刚把一份常用资料放在桌上，并在接下来一段时间继续使用它，系统可以更便宜、更稳定地复用这部分重复内容。
文中提到官方材料给出的工程边界包括：
- 更可预测的 prompt caching
- explicit cache breakpoints
- 30-minute minimum cache life
- cache writes billed at 1.25x uncached input rate
- cached-input reads 继续享受 90% discount
这些细节说明缓存是一种工程复用机制，而不是人格记忆、长期记忆或永久免重复提供资料的承诺。
也正因如此，上下文预算 不是被缓存替代的：即使有缓存，你仍然要决定什么值得反复复用，什么不该继续带着走，什么已经过期，什么必须换成当前版本。
面向普通用户，而不只是开发者
原文明确反对把上下文管理理解成“只有程序员才需要关心的 API 小字”。即使不写代码，普通用户也在不断给 AI 喂上下文。
文中列出的非编程场景包括：
- 论文修改：需要提供课程要求、论文主题、老师反馈，以及不能乱改的段落。
- 面试准备：需要提供岗位 JD、个人经历、项目细节和回答边界。
- 读书笔记整理：需要区分哪些是原文、哪些是自己的理解、哪些地方仍不确定。
如果这些信息总是想到哪发到哪，模型就会反复猜背景，并出现典型错误，例如：
- 把参考资料当成事实
- 把用户猜测当成结论