系统提示词里那句“友好专业”一年烧掉708美元

每个聊天机器人教程的开头都一样：写系统提示词。你写了一段，队友加了一段语气要求，有人把公司历史粘贴进去，三个月后这份提示词更像一份 README。

问题在于，没人给这份 README 定价。因为它从不作为单独条目出现，而是作为每次调用的输入 token，永远存在。

一个 token 大约是 ¾ 个英文单词，API 按百万 token 计费。系统提示词是用户消息之前发送的指令块，而 API 是无状态的——它不会在调用之间记住这些内容。你每次请求都要重新发送，也每次都要重新付费。

真实流量的样子

先看一组来自某网关的实测数据：在 16 个客户账户的 5,546 次成功聊天调用中（统计区间为原文所述时段），中位数请求携带 1,280 个输入 token，返回 108 个输出 token。请求比回答大 12 倍左右，而典型机器人中，大部分输入都是同一段固定指令文本，一遍又一遍地发送。这就是系统提示词在账单上的样子。

给一段典型提示词算账

作者为一家虚构的电子产品商店写了一个真实感十足的支持机器人提示词：角色设定、退货政策、回答格式、升级规则、四个少样本示例（展示期望风格的示例对话），以及一行今天的日期。然后用 tiktoken 和 o200k_base（当前 GPT 模型背后的分词器）进行计数。

完整提示词共 946 个 token。政策占 234 个，示例占 192 个，回答格式占 127 个。其中一段占了 97 个 token：“记住你是一个乐于助人、友好且专业的助手。始终尽力给出准确、完整、结构良好的回答……”——八十一个单词，而每个现代模型默认就会这样做。

一段话的价格

以下是这 97 个 token 按官方输入价格计算的年度成本，取决于模型和每日调用量：

模型（输入 $/百万）	1K 次/天	10K 次/天	100K 次/天
Gemini 3.1 Flash Lite ($0.25)	$9	$89	$885
Claude Sonnet 5.5 ($2.00)	$71	$708	$7,081
GPT-6 Astra ($10.00)	$354	$3,541	$35,405

公式只有一行：tokens × calls_per_day × 365 / 1,000,000 × input_price。在便宜模型上，这段话是舍入误差。在中端模型的中等流量下，它是一份你并不需要的月度订阅。在旗舰模型的大规模场景下，它是一份工资。

有人会说“输入便宜，输出才是贵的”。按 token 单价看是的，但按请求看不是：1,280 token 的请求加 108 token 的回答，即使输出单价贵五倍，输入总成本仍然超过输出。

少样本示例（few-shot examples） 是提示词中嵌入的若干组“用户提问—理想回答”配对，用来向模型示范期望的回答风格、格式和推理模式。它的作用类似于在不微调模型的情况下进行“上下文学习”（in-context learning）：模型从这些示例中推断出任务模式，再将其应用到真实用户消息上。少样本示例通常效果显著，但代价是每个示例都会永久占用输入 token——四个简短示例就可能达到 200 token 左右，在大流量下会形成可观且持续的成本。当示例只是在重复模型已经掌握的常识风格时，往往属于可裁剪对象。

审计提示词：先砍，再缓存

逐段检查提示词，只问一个问题：如果删掉这段，回答会变吗？

砍掉模型本来就会做或从不使用的内容。在示例中就是“乐于助人”那段（97 token）、公司历史和使命宣言（106 token——机器人处理退货不需要知道成立年份），以及格式部分逐字重复的两条规则（23 token）。总计 226 token，占提示词的 24%，在 Sonnet 5.5 上按每天 1 万次调用计算，每年约 1,650 美元。砍完后跑一遍评估集；如果质量不变，这些 token 就只是装饰。

缓存又长又稳定的内容。提示词缓存是指提供商保留请求的开头部分，对重复读取按正常输入价格的一小部分计费。问题在于：它只对逐字节相同的开头有效。原始提示词把今天的日期和客户名字放在顶部——一行变化就让整个提示词无法缓存。把所有动态内容移到末尾：

messages = [
    {"role": "system", "content": ROLE + POLICIES + FORMAT + EXAMPLES},  # never changes
    {"role": "system", "content": f"Today: {today}. Customer: {name}."}, # changes
    {"role": "user",   "content": user_message},
]

砍和缓存不是二选一。先砍，因为删掉的 token 成本为零，而缓存的 token 每次调用仍要花一点钱，缓存过期时还要付全价。

提示词缓存（prompt caching） 的工作机制值得展开：提供商在服务端保留请求前缀的键值缓存（KV cache），当后续请求的开头与之前逐字节完全一致时，直接复用已计算的状态，而不必重新处理这些 token。因此计费上通常分为“缓存写入”（价格略高于普通输入）和“缓存读取”（价格显著低于普通输入，常见为一折左右）。命中条件非常严格——前缀中任何一个字符变化都会导致缓存失效，这也是为什么必须把日期、用户名等动态内容移到提示词末尾。此外，缓存条目通常有存活时间（如 5 分钟到 1 小时），流量稀疏时缓存容易过期，命中率下降，写入溢价就无法摊薄，因此低频场景下缓存可能不划算。

这解决不了什么

缓存有盈亏平衡点：写入比正常输入贵，命中率低时反而可能推高账单。有些提供商只缓存超过最小长度的开头——依赖之前先查文档。token 计数来自 OpenAI 的分词器；Anthropic 和 Google 的分词方式不同，数字会有几个百分点的偏差。而且该网关自己的使用记录还没有拆分缓存 token，所以无法展示真实的缓存命中率。

以上价格是厂商官方价。该网关以低于官方的价格转售相同模型——Claude Sonnet 5.5 每百万输入 token 1.70 美元，而官方为 2.00 美元——这把那 708 美元的段落降到 602 美元。这是一个固定百分比折扣，它不会删掉那段话。为你不需要的 token 打折，仍然是在为你不需要的 token 付费。

打开你的系统提示词，在上面跑一遍脚本，找出最贵的那一段。它很可能是没人记得写过的那段。