长对话越来越贵，先看每轮到底带了哪些内容

“我只追问了一句话，为什么输入还是很多？”原因往往在那句话前面：应用可能同时带上系统要求、专家或 Skill 指导、历史回答以及本轮材料。先看实际发送范围，再决定删什么，比单纯要求模型“回答短一点”更有用。

工作室并不会把所有旧消息无限带下去

当前有界工作室会从最近最多 20 轮已完成对话中选择历史，并继续受消息长度预算限制。界面里能翻到更早的记录，不等于那部分内容一定进入本轮请求。系统指令和当前问题也会占用输入空间。来源 1

因此，模型突然忘记较早的约定，不一定是温度或能力问题。先确认约定是否还在本轮可用上下文里，必要时明确重述。

用一个简单例子看累计输入

假设每轮新添 1,000 个 Token，而且每次都重发此前全部内容。十轮请求的累计输入是 1,000 ×（1＋2＋…＋10）= 55,000 Token，而不是 10,000。这个例子只解释重复携带的成本，不是工作室实际计数；真实请求还有回答、截断与缓存等因素。

“减少输出字数”和“减少下一轮输入”也不是同一件事。较短回答可能减少后续历史，但已经反复附加的长材料仍然存在。

换主题前做一份交接单

可以整理成下面这几项，再新建对话继续：

任务：给内部工具整理上线检查项
已确认事实：使用现有登录；只读查询；不接付款
已作决定：先覆盖一个部门，保留人工复核
未解决：谁负责异常处理，日志保留多久
本轮要做：列出仍需业务负责人确认的三个问题

这是一份虚构的交接示例。保留决定和依据，删除已经推翻的讨论；涉及准确数字、引用或代码时，仍要保留原始材料入口。不要把模型压缩后的摘要当成新的事实来源。

用用量验证有没有改善

在用量记录里，对比同一模型、同一分组下相近任务的输入量和费用。先看输入是否变少，再看缓存或价格档位是否改变。两个不同任务的账单不能直接证明“新建对话省了多少”。来源 2

哪些内容不宜只留摘要

合同原句、计算依据、故障日志和需要逐字引用的段落，应保留可回查版本。短交接单适合传递工作状态，不适合替代证据。整理前可按对话导出指南保存原记录，再开始新的任务。