prompt 太长 成本 翻倍

很多人习惯把背景、规则、示例、历史对话全塞进一个提示词里，觉得一次说清楚最省事。等到月底看账单，才发现单次调用的花费比自己估的高出一截。这篇不讲模型原理，只拆两件事：长提示词的成本到底花在哪几个位置，以及在不影响效果的前提下，按什么顺序把它压下来。

很多人写提示词的习惯是：背景、规则、示例、历史对话一股脑全塞进去，觉得一次说清楚最省事。等到月底翻账单，才发现单次调用的花费比自己估的高出一截，尤其是每天跑几百上千次的那种脚本。这篇不讲模型原理，只拆两件事：长提示词的成本到底花在哪几个位置，以及在不影响效果的前提下，按什么顺序把它压下来。

有个前提先说明白：成本膨胀不是「提示词长」这一个原因造成的，输入、输出、重试三者会互相叠加。所以下面讲的办法，有的针对输入，有的针对连带效应，你按自己的场景挑着用就行，不用全上。

输入膨胀为什么会把单次成本抬起来

按量计费里，输入和输出是分开计价的两段。长提示词吃的是输入那一段，单轮看可能不显眼，可一旦进入多轮对话，同一段背景每轮都要重发一遍，累积起来是乘法关系而不是加法关系。这是很多人账单超预期的主因：不是某一次贵，是同一段字被反复计费了几十次。

除了输入本身，还有两个连带项。一是输出长度：上下文越长，模型越倾向于跟着一起啰嗦，输出那一段也跟着涨。二是重试概率：提示词越长越容易出格式错、答非所问，一旦你写脚本自动重试，等于同一份长输入又跑了一遍。这两项加起来，单次实际花费可能比你以为的高出不少。

先定位：长提示词里到底哪一段最占体积

动手删之前先分堆。把提示词按功能切成六类：角色设定、业务背景、格式规则、少样本示例、历史对话、工具返回结果。分开之后你会发现，占体积的往往不是你以为的那一段，角色设定通常很短，历史对话和工具返回才是大头。

判断依据不是字符数，而是 token 数。中英文混排的时候，同样一段字数，中文对应的 token 往往更多，用字数直接估算会偏。拿不准某一段占多少，先到站内工具量一遍，别凭感觉删。

压缩顺序：从便宜的动作做起

1. 第一步：删冗余把重复表达、模型本身就知道的常识、从来没被输出引用过的示例整段去掉。这一步不动结构、不改语义，是零成本的，先做。
2. 第二步：改结构把长段落拆成分点，把口语化表述换成紧凑写法。信息量保持不变，减掉的是连接词和解释性废话，验证方式是改完对照 token 数有没有降。
3. 第三步：做外置把稳定不变的背景和规则抽出来，放到固定位置或走缓存机制，减少每轮重复发送的量。适合那种一天跑很多次、提示词主体几乎不变的场景。
4. 第四步：拆任务把一个大提示词拆成两到三步的小调用。调用次数变多了，但总 token 往往更低，代价是延迟可能上升，得按你的实时性要求权衡。

• 先删历史对话里已经没用的轮次，这一步收益通常最大
• 工具返回结果只保留真正被后续逻辑用到的字段，别整段塞
• 少样本示例控制在能说明格式的最少数量，其余换成一句规则描述
• 格式规则写成条目式，不要写成一段解释
• 背景信息能外置就外置，不要每轮重发

这四步是有顺序的，别跳着来。先删冗余再改结构，最后才考虑拆任务；反过来先拆任务，你会发现拆出来的每一步里都还带着一堆没删干净的废字。

改完要验证，别自己觉得省了就完事

压缩最容易犯的错是「凭感觉觉得省了」。正确做法是同一批输入在压缩前后各跑一次，把输入 token 和输出 token 分开对比。只看总价会分不清是哪一段在变，也没法判断效果损失是不是值得。

留一份对照记录：改动点、压缩前后两组用量、效果有没有肉眼可见的下降。攒几次之后你会形成自己的经验值，知道哪类压缩在你的任务上通常安全、哪类容易翻车。效果如果下降，先回退最激进的那一步，通常是删示例那一步。

还有一种情况要单独说：对输出格式极其敏感的任务，比如必须严格套模板、字段一个都不能错的场景，压缩格式规则的收益低、风险高，这类就别在格式描述上省，把精力放到历史对话和工具返回上。

另外，具体到你用的那家接口，输入和输出分别怎么计价、有没有缓存折扣，各家规则不一样，别拿别人账单上的比例直接套自己。到站内价格页核对当时的数字，再决定压缩重点放在哪一段。