LLM Prompt结构技巧：稳定内容前置可节省78%成本

Modern LLM APIs 会缓存 prompt 前缀部分的 key-value 状态。同样的开头 token 发送两次，第二次调用的计费大约只有第一次的十分之一，且响应明显更快。正是这一事实，彻底重构了我们书写所有高频 prompt 的方式。

所有稳定不变的内容放在最前，确保每次调用字节级一致：系统规则、输出格式、few-shot 示例、参考表格。所有易变的内容放在最后：任务本身、检索到的文档、用户的输入文本。缓存从第一个不同的字节处断裂，因此只要头部里有一个时间戳，就会导致整个前缀缓存失效。

[ 系统规则            ]  稳定，版本化管理      ─┐
[ 输出格式            ]  稳定，版本化管理       ├─ 缓存前缀，约占 91% 的 token
[ 12 个 few-shot 示例  ]  稳定，版本化管理      ─┘
[ 检索到的上下文       ]  易变 ──────────────── 全额计费
[ 实际任务            ]  易变

在我们的一个抽取流水线上实测：相同的模型、相同的准确率，成本降低 78%、速度提升一倍——改动仅仅是调整了段落的顺序。

运营层面的影响

前缀按 API 的方式版本化管理。编辑它是一个经过深思熟虑的发布行为，因为每次编辑都会刷新全量缓存并造成可观的成本尖峰。我们给每个 prompt 打上版本常量，像数据库迁移一样滚动发布。

批量队列按前缀排序。共享相同前缀的请求相邻执行，这样缓存能保持温热，不会被两次调用之间的其他请求驱逐出去。

命中率是一个被记录的核心指标。API 会报告每次调用的缓存 token 数量，我们将其绘制成图表。命中率悄无声息地下降时，曾两次在账单到来之前就捕获到了意外的 prompt 编辑。

随机性在前缀中被彻底禁止。不允许时间戳、请求 ID、字典顺序轮赌。序列化采用规范格式，key 排序输出——这和构建系统要求确定性输入的理由一样。

所有这些措施都不影响输出质量。这只是针对一项大多数团队根本不知道自己正在浪费的资源，施加的纯粹的系统卫生工作。