长文档 总结 怎么 省 token

几万字的合同、几十页的财报、一整本手册，直接整篇丢给模型，输出还没出来账单先吓人。问题往往不在模型贵，而在你把大段重复内容和无关段落一起塞进了上下文。这篇给一套从切分、筛选到缓存复用的流程，也说明哪些情况不适合这么干，比如需要全局推理的跨章节任务。

几万字的合同、几十页的财报、一整本手册，直接整篇丢给模型，输出还没出来，账单先吓人。问题往往不在模型贵，而在你把大段重复内容和无关段落一起塞进了上下文。这篇给一套从切分、筛选到缓存复用的流程，让每份长文档只被读一次、只读该读的部分。

先说清楚：这套流程适合「文档长、但问题相对局部」的场景，比如按章节抽结论、按条款找风险。如果任务本身需要全局推理，比如找全文前后矛盾、判断整篇情绪基调，那就不该硬切，得单独走整篇路线，下面会标出来。

先搞清钱花在哪：长文档总结的 token 都去哪了

多数人第一反应是「输出太贵」，其实长文档总结的账单主要压在输入侧。你贴进去几万字，模型吐出来的可能就几百字，输入是输出的几十倍。所以省 token 的重点从来不是让模型少写，而是让它少读。

• 整篇塞进去时，输入 token 通常是输出的几十倍，账单大头在输入侧
• 同一份文档反复提问会重复付输入费，这是最容易被忽略的浪费
• 分块总结再合并，和一次性整篇总结，token 走势完全不同，先看自己属于哪种
• 计费口径和上下文概念想对齐，到 /ai-dict/category/basics 核对当时的定义，再对着自己的用量记录看

切分与预筛：让模型只读该读的部分

切分的目的是让每一段都能独立成事。切得好，后面合并就轻松；切得碎，结论会被切断，反而要多跑几轮。判断标准很简单：随便抽一块给模型，它能不能在这块内部得出一个完整结论。

1. 按结构切块优先按标题层级切，没有标题就按固定段数或字数切，块之间留少量重叠，避免结论刚好卡在边界上。验证方式：抽两三块的边界处看看，结论有没有被切成半句。
2. 预筛低密度段落用规则或关键词先剔掉目录、页眉页脚、免责声明、重复附录、版权页。验证方式：统计筛掉的字符占全文比例，太低说明规则没抓对地方。
3. 给每块打一句话索引每块生成一句摘要当索引，先让模型只读索引挑出相关块，再读原文。验证方式：拿一份已知答案的文档试，看索引挑块有没有漏掉关键块。
4. 判断要不要切如果任务是找全文矛盾点、判断整体基调，别切，直接整篇走。切了反而会丢掉跨块信息，结论不可信。

索引这一步最容易被跳过，但收益往往最大。一份几十页的手册，真正相关的可能就几页，先读索引再读原文，输入能砍掉一大半。

压缩与复用：把重复上下文留在缓存里

多轮追问同一份文档时，最容易的浪费是每轮都把原文重新贴一遍。只要文档部分不变，就该把它固定在请求前缀位置，让缓存命中，而不是每轮重付一遍输入费。

前缀稳定

不变的文档内容放前面，变化的问题放后面，顺序别乱动

中间结果落盘

逐块总结的结论先存下来，合并阶段只喂这些结论，不喂原文

摘要代替原文

第二轮开始的输入用人能读的摘要，而不是把原文反复回传

缓存写法

命中条件和写法差异到 /prompt-caching-cost-guide 核对当时的说明，别凭感觉设

这里有个常被忽略的点：压缩不是把原文删几个字，而是换一种表示。一段五行的原文压成一句话的中间结论，第二轮输入直接短一截，而且模型读起来更聚焦。

验证与控量：怎么知道这套流程真的省了

省不省不能靠感觉，得对比。最直接的办法是同一份文档跑两条路线：一条整篇总结，一条分块加索引，然后把两次的用量记录摆在一起看输入输出字段。差别一眼能看出来。

• 跑几份不同类型的文档，把每份的处理耗时和 token 记成表，趋势就出来了
• 给单次任务设用量上限，超了就停，先排查是切分没做好还是文档本身太杂
• 别只看 token 数，换算成钱到 /tools/model-cost-calculator 过一遍，感知更直接
• 把验证结果反过来改索引和筛除规则，跑几轮后规则会越来越准

跑几轮之后你会发现，省 token 的瓶颈通常不在模型，而在切分粒度和预筛规则。规则调好了，同一份文档的输入能稳定降下来，而且结论质量不会掉。