---

name: prompt-token-diet
description: Prompt 瘦身与提示词缓存优化。当单次调用输入 token 过大、上下文塞不下、想提高缓存命中率、或者要在不掉效果的前提下压缩系统提示与少样本示例时使用。触发词：prompt 太长、上下文超限、token 超了、压缩提示词、精简 system prompt、缓存命中率低、few-shot 太多、上下文裁剪。不负责整体账单归因（走 llm-cost-audit），也不负责效果评测集设计（走 llm-eval-set）。

Prompt 瘦身

目标是在效果不掉的前提下减少输入 token，顺序永远是「先测基线，再动刀，再复测」。没有基线的瘦身等于随机劣化。

零、先立基线

准备 30 到 100 条真实样本和一个可自动判分的指标（准确率、格式合法率、关键字段召回率任选）。记录当前的：

• 平均输入 token、平均输出 token
• 指标得分
• 缓存命中率

后面每砍一刀都要复测这三项。指标掉超过 2 个百分点就回退。

一、结构先于措辞

大部分 prompt 的浪费不在用词，在结构。

把 prompt 切成两段：稳定段和易变段。

[稳定段]  系统角色 + 规则 + 工具定义 + 少样本示例 + 长文档
[易变段]  本次的用户输入、检索结果、时间戳

稳定段必须逐字节完全一致且放在最前面，这样才能命中提示词缓存。命中后这部分的价格通常降到十分之一。破坏缓存的常见元凶：

• 在系统提示里插当前时间或日期
• 把用户 ID、会话 ID 写进开头
• 用字典序不固定的 JSON 序列化工具定义
• 每次随机打乱少样本示例的顺序
• 系统提示里带 A/B 实验的随机分组标记

把这些统统挪到易变段。挪完先看命中率，通常这一步的收益比后面所有措辞优化加起来还大。

二、按收益排序砍

砍少样本示例。 做消融：从 N 个降到 N/2，再降到 3 个，每档跑一次评测。多数任务 3 到 5 个示例就到顶，再加只涨 token 不涨分。示例要覆盖边界情况，不要选五个长得一样的。

砍规则条款。 逐条注释掉再评测。经验上系统提示里有三分之一的规则是历史遗留，删掉指标不动。特别可疑的：

• 互相重复的表述（「要简洁」「不要啰嗦」「回答尽量短」）
• 模型本来就不会犯的禁令
• 针对某个早已修复的旧模型缺陷写的补丁

砍检索上下文。 召回 20 篇改成 5 篇，先看指标。如果掉了，说明排序有问题，该修排序而不是加数量。加重排序器比加召回数量便宜得多。

砍历史对话。 全量拼接改成「最近 N 轮原文 + 更早的滚动摘要」。摘要用小模型生成并缓存。

砍格式说明。 如果接口支持结构化输出或工具调用，用它替代「请严格按以下 JSON 格式返回」这一大段说明加示例。这一步经常能省几百 token 且提高格式合法率。

三、措辞层面

结构砍完再抠字眼，收益小但免费。

• 中文比英文的同义表达通常更省 token，规则部分可以用中文写。但别为了省 token 把中英文混着写，会降低指令遵循度。
• 删掉礼貌用语和自我介绍。「你是一个非常专业、经验丰富的……」压成「你是……」。
• 用祈使句，不用「你应该尽量……」。
• 长规则改成分点列表，比连续散文短且更容易被遵循。
• 重复三遍的强调删到一遍。真需要强调就放在最后一句，那是注意力最强的位置之一。

四、长文档的处理

单份文档超过几万 token 时，不要每次全塞。按这个顺序选方案：

1. 能预处理就预处理。 把文档结构化成表格或字段，通常能压掉 90%。
2. 能缓存就缓存。 文档固定不变且会被反复问，放在稳定段走缓存。
3. 能检索就检索。 文档大且每次只用一小部分，切块 + 向量检索 + 重排。
4. 能分层就分层。 先给目录和摘要让模型选章节，再取该章节原文。两次调用通常比一次全塞便宜。

五、验收

瘦身完成的标准：

指标	要求
评测得分	相对基线不低于 -2 个百分点
平均输入 token	有明确下降，记录下降比例
缓存命中率	稳定段不变的会话应接近 100%
格式合法率	不低于基线

三项达标后，把最终 prompt 连同评测结果一起归档。下次有人想加一段规则，让他先跑一遍评测。

六、反模式

• 凭感觉删。 没有评测就删，等于把效果风险转移给线上用户。
• 为了省 token 删掉边界情况的示例。 这类示例单价最高但价值也最高。
• 把稳定段压缩到失去可读性。 后面没人敢改了，维护成本远超省下的钱。
• 在稳定段里做 A/B 实验。 直接毁掉缓存。要做实验就整段切换，而不是在中间插变量。