提示词写法如何体现在账单上
更新于 September 1, 2026 · 首次发布 September 1, 2026
提示词的膨胀方式和配置文件一样。有人为修复某种故障添加一条指令，另一人添加一个示例，第三人再补一段解释第二条指令为何重要的文字。没有任何东西会被删除，因为删掉它可能让某个无人能复现的缺陷重新出现。六个月后，系统提示词有三千个 token，却没人说得清其中哪两百个真正起作用。
为什么会不断累积
输出会随任务变化，而提示词的开销则在每一次请求上以相同的数量被支付，而且永远如此。一个服务月均千万次调用的功能里，每次请求浪费一千个 token，就是每月一百亿个纯粹用于格式的 token。
在多轮对话中情况更糟：系统提示词每一轮都会重新发送，因此成本随轮数增长，而不是随请求数增长。在智能体循环中，用户的一次操作可能触发十几次模型调用，同一段臃肿的前置文字就要为这一件工作计费十几次。
真正浪费的是什么
不是礼貌用语，它只占几个 token，有时还能略微提高遵循度。真正的负担在于：冗余指令，用三种方式重复同一条规则；防御性模板，为已不再需要的模型代际而添加；重复的示例，它们没有覆盖不同情况，而是彼此复制；以及面向人类读者的解释，它们针对的是读提示词文件的人，而不是模型。
实践中第三类占比最大。少样本示例按 token 计价很贵，而团队很少重新审视：五个示例的作用，两个是否就能做到。
把提示词当作有预算的代码来对待
将固定的提示词开销按平均请求大小的占比来衡量。如果超过一半，那就是成本问题，而不是风格问题。把稳定的部分放在最前面，使缓存生效，这样即使不删除任何内容，剩余的冗余也会便宜得多。然后做一次消融实验：每次移除一个模块，运行你的评估，只有在质量不受影响时才保留删除。没有评估套件的提示词精简只是猜测，而那种失败模式，也就是客户发现的质量回退，代价远高于节省下来的 token。
相关
相关文章
想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 →