如何通过 Prompt 压缩技术在不损失精度的情况下降低 Token 成本

把长达 2k token 的上下文强行塞给 LLM，不仅账单难看，而且容易触发“中间丢失”现象（Lost in the Middle），导致模型忽略关键指令。我最近在处理一个复杂且重复的 API 文档检索任务时，尝试了一套基于语义压缩的 Prompt 策略，成本直接砍掉了 40% 以上。

最粗暴但有效的方法是语义符号化。不要在 Prompt 里反复写「请根据以下用户提供的订单详情信息并结合历史交易记录进行分析」，直接定义一套简写协议。

在 System Prompt 里先建立映射表：

# Context Compression Protocol
[UD] = User Detail / 用户详情
[HT] = History Transaction / 历史交易
[R] = Analysis Result / 分析结果

然后正文直接写：Analyze [UD] based on [HT], output [R]. 这种方式在处理长上下文时，能极大地节省重复词汇的 Token。

另一个实操技巧是结构化剪枝。很多开发者习惯把 JSON 整个丢给 AI，但 JSON 里的 Key 极其浪费 Token。我写了个简单的 Python 脚本，在发送给 Claude 之前，把冗余的 Key 映射成单字母，拿到结果后再还原。

压缩前：

{"user_profile_id": "12345", "user_geographic_location": "Beijing", "last_login_timestamp": "2023-10-01"}

压缩后：

{"a": "12345", "b": "Beijing", "c": "2023-10-01"}

配合一个简单的映射指令：a:id, b:loc, c:time，模型完全能理解这种对应关系，且 Token 消耗降低了近 60%。

踩过的一个大坑是过度压缩导致指令漂移。如果你把指令压缩得太像电报，模型在推理复杂逻辑时容易跳步。我的经验是：数据部分极致压缩，指令部分保持自然语言。

对于需要频繁调用相同背景知识的任务，建议采用 Prompt Caching（提示词缓存）。以 Claude 为 例，将不变量（如 API 定义、业务规则）放在 Prompt 前端，并在该部分末尾打上缓存标记。

具体配置步骤：
1. 将静态知识库置顶
2. 在静态内容结束处，通过 API 参数指定 cache_control 为 ephemeral
3. 动态的用户输入放在最后

这样除了第一次全量计费，后续重复请求的静态部分只需支付极低的缓存读取费，响应速度快了不止一个量级。