几十万字的合同、手册、会议记录一股脑丢给模型，跑一次就能把预算吃掉一半，质量还未必好。这篇不劝你换模型，而是把「一次性全塞」「分块流水线」「先摘要再问答」三种常见做法摆在一起，说清各自在什么条件下划算、什么条件下不划算，再给一套先拿小样试跑、量出真实消耗再放量的做法。
几十万字的合同、产品手册、几小时会议记录，一股脑丢给模型，跑一次就能把当月预算吃掉一截，结果质量还未必好。问题往往不在模型选得差，而在处理路径选错了。这篇不劝你换模型，只把三种常见做法摆一起，讲清各自在什么条件下划算、什么条件下不划算。
先把结论前提说清楚：做法没有绝对优劣，判断的锚点是你的任务要「原文细节」还是「整体结论」，以及你要问几轮。下面每一节都给可执行的判断标准和动作，最后给一套先拿小样试跑、量出真实消耗再放量的流程。
三种做法各是什么，代价在哪
- 一次性全塞
- 整篇进上下文直接提问，链路最短，但每一轮问答都要重新为全文付费，轮次一多最贵。
- 分块流水线
- 切开逐块处理再汇总，单次调用便宜、可并行，但块间上下文会丢，跨段落问题容易答错。
- 先摘要再问答
- 先压成提纲或摘要，再基于摘要回答，token 消耗通常最低，代价是细节和数字可能在压缩时失真。
真正的分水岭不是哪个先进，而是任务对「可追溯」的要求有多高。要逐字引用、要条款号和具体数字，压缩就会伤到你；只要整体判断和方向性结论，压缩反而是省钱利器。选之前先问自己一句：答错了会不会有人拿着原文来对质。
| 做法 | 成本特征 | 适合的任务 | 主要风险 |
|---|---|---|---|
| 一次性全塞 | 随轮次线性上涨 | 文档不长、问题少、要反复追问同一篇 | 多轮追问时账单失控 |
| 分块流水线 | 首次处理成本高，追问几乎不涨 | 要精确引用、定位到段落或章节 | 块间上下文断裂、跨块问题答错 |
| 先摘要再问答 | 通常最低，追问便宜 | 整体判断、归类、提要点 | 细节和数字在压缩时失真 |
什么情况选哪种：按任务和文档量对照
先按任务性质分，再按文档量微调。这个顺序别颠倒，很多人先看文档多大，结果选了最便宜的路径，却答不了需要出处的问题，返工成本比省下的还高。
- 只要整体判断、不要逐字出处，且文档很长：先摘要再问答更稳
- 要精确引用原文、条款号、数字：分块流水线配合定位，比全塞更可控也更便宜
- 文档不长、问题只有一两个、要反复追问同一篇：一次性全塞反而省事，别为了省 token 把流程搞复杂
- 需要多轮追问：全塞成本随轮次上涨，分块和摘要的成本主要在第一次处理，追问几乎不再涨
- 任务要跨段落推理（比如前后条款是否冲突）：分块要额外加一层回顾步骤，否则容易漏
- 预算紧但质量要求高：先用摘要筛出相关块，再只对相关块做精读，是折中路线
先拿小样测一遍：具体怎么做
别凭感觉估成本，抽小样实测一遍只要十几分钟，能避免写完一整套流水线才发现方向错了。关键是取样要代表全文，而不是取开头那几页。
- 取样从文档里抽一小段有代表性的内容，长度按实际文档的十分之一左右估。避开开头几页，开头往往是目录和概述，不能代表全文密度。
- 三种做法各跑一遍用同一个问题分别跑全塞、分块、先摘要，记录输入和输出 token，以及答案质量。质量自己打勾就行：引用准不准、细节丢没丢。
- 折算全量用站内工具把这次小样的 token 折算成钱，再按全文倍数放大，得到单次全量处理的量级估计。具体单价和换算到 /tools/model-cost-calculator/tools/model-cost-calculator 与 /tools/token-price-calculator 核对当时的数字。
- 记录留档两份记录都留着：一份是这次实测的 token 和倍率，一份是问题答案的对照。下次换文档类型时可以复用这个基准。
- 再决定小样测完再决定路线。只相信你这次实测出来的倍率关系，不要照搬别人的经验值，文档类型不同差异很大。
这里有个容易犯的错：小样只跑一次就下结论。建议同一个问题换一两个措辞再跑，如果答案差异很大，说明这个任务对提示词敏感，token 估算也要留出余量。
容易被忽略的成本点
很多人算成本只算了「处理一次全文要多少」，漏掉下面这几项，实际账单会明显高于预期。把这几项单独列出来估一遍，比事后惊讶划算。
- 多轮追问是隐形大头：全塞模式下每一轮都在为同一篇全文重复付费，问五轮就是五倍
- 重试和失败调用也算钱，流水线越长、调用次数越多，这部分越不可忽略，建议按总调用数的百分比预留
- 输出长度也是成本，让模型「详细总结」和「列要点」的账单差得不小，先定好输出格式再跑
- 不同模型处理同一篇文档的价格差可以很大，选型前先看任务级的对比方法论，到 /ai-nav/category/ai-note/ai-nav/category/ai-note 看当期整理
- 缓存和批处理能压一部分成本，但不是所有接口都支持，用之前确认清楚
想知道某类模型在长文档任务上的当期价格分布，别靠记忆，直接到 /price-watch/price-watch 看当时的数字和变动趋势。价格是波动的，任何写死在文章里的数字都会过期。
动手前的检查清单
把下面这几条当放量前的闸门，一条条过。任何一条没过，就先别跑全量。这套检查也适合团队里当交接文档，谁接手都能按同样标准判断。
| 检查项 | 过关标准 | 不过关怎么办 |
|---|---|---|
| 任务类型确定 | 已明确要细节还是要结论 | 先和相关方对齐需求再动手 |
| 小样实测完成 | 三种做法的 token 与质量都有记录 | 补测，别跳步 |
| 总成本估算 | 单次成本乘预估次数在预算内 | 改路线或缩范围 |
| 日志字段固定 | 每次调用的消耗都被记录 | 先定义字段再跑量 |
| 止损线设定 | 涨到某条线就停下来重估 | 没设就先设，别裸跑 |
止损线怎么定：按你能接受的单次任务成本上浮一定比例作为触发点，超过就暂停排查。这比事后对账有用，因为能在预算爆掉之前拦住。
最后提醒一句判断的边界：上面这套方法针对的是文本类长文档。如果文档里有大量表格和图片，token 估算的误差会明显变大，取样时要把这类内容的占比考虑进去。
下一步想知道各家中转站在长文档任务上的实际表现和价格波动，到 /sites 查看当前整理的站点列表，再结合 /tools/speed-test 自己跑一轮小样验证，比看任何二手结论都可靠。→常见问题
文档特别长，是不是必须分块？
不一定。如果只要整体结论，先摘要再问答往往更省；如果必须引用原文细节，分块加工定位更稳。判断标准是你的任务对原文的依赖程度，不是文档长度本身。建议先抽一小段实测再决定，别凭直觉。
先摘要会不会把关键信息弄丢？
会，尤其是数字、条款编号、否定表述这类细节。规避办法是摘要阶段明确要求保留数字与专有名词，并把原文留着，需要精确引用时再回到分块定位。如果任务本身就是要逐字引用，直接选分块路线更合适。
怎么知道我的做法到底烧了多少钱？
靠记录，不靠感觉。每次调用记下输入输出 token 和次数，再用站内计算器换算。同类任务的记录攒几轮，就能看出哪种做法在你的场景下更便宜。具体单价随时间和渠道变，以站内当期数字为准。
