1. 从一次账单惊吓说起为什么token节约是个真问题上个月帮一个做跨境电商的朋友看他们的客服工单分类系统跑了一个月下来API账单比我预估的高出三倍多。我第一反应是模型选错了结果拉出调用日志一看模型没选错是上下文塞得太满——每一条工单分类请求都带着一份两千多字的系统提示词、一份完整的产品目录、还有前五轮对话历史。真正用于判断分类的核心信息可能就那几十个字。这件事让我意识到一个很现实的问题现在大家聊AI应用聊得最多的是模型能力、提示词技巧、RAG架构但很少有人认真聊token经济学。而token就是钱尤其是当你的应用从demo走向日均几万次调用的时候token消耗的差异会直接决定这个项目是盈利还是亏损。所谓Skill节约token策略说白了就是一套系统性的方法让AI技能Skill可以理解为一个封装好的AI能力单元比如工单分类摘要生成意图识别在完成同样任务的前提下消耗尽可能少的token。它不是一个单点技巧而是贯穿在提示词设计、上下文管理、缓存机制、模型路由、输出控制这五个环节里的一整套工程实践。这篇文章适合三类人看一是正在把AI应用从原型推向生产环境的开发者二是负责AI产品成本控制的工程师三是自己搭AI工作流、按量付费的个人用户。不管你是哪种只要你的调用量上来了这里面的东西迟早用得上。我下面会把这套策略拆成可落地的步骤配上我实际踩过的坑和验证过的参数你基本可以照着抄。2. 先搞清楚token到底花在哪成本结构拆解2.1 一次调用的token构成很多人对token消耗的认知停留在输入输出这个层面但实际上一次完整的API调用token消耗可以拆成更细的几块。以一次典型的对话式调用为例消耗环节典型占比是否可控说明系统提示词20%-40%高度可控每次调用都重复发送是最大的浪费源上下文历史15%-35%高度可控多轮对话累积容易失控检索/注入内容10%-30%中度可控RAG场景下的文档片段用户实际输入5%-15%不可控用户说什么你管不了模型输出10%-25%中度可控可通过格式约束压缩这张表是我在几个项目里统计出来的经验值不同场景差异很大但规律是一致的真正不可控的部分用户输入往往只占很小一块大头都在你自己能控制的地方。这意味着token节约的空间非常大而且不需要牺牲用户体验。2.2 为什么系统提示词是重灾区系统提示词的问题在于它的重复性。假设你有一个500 token的系统提示词日均调用1万次那光系统提示词一天就是500万token。如果这个提示词里有一半是冗余的客套话、重复的约束、可以合并的示例那你每天就在白白烧掉250万token。我见过最夸张的一个案例某团队的系统提示词写了1800多token里面包含了三段几乎重复的你是一个专业的助手、五条意思相近的输出格式要求、还有两个功能重叠的示例。精简之后压到400 token效果没有任何下降。这就是典型的提示词肥胖症。2.3 上下文历史的隐性成本多轮对话是另一个陷阱。很多框架默认把完整历史都带上第10轮对话的时候前面9轮的内容全在上下文里。但问题是大部分历史信息对当前这一轮是无用的。用户第3轮提到的某个偏好可能还有用但第2轮问的今天天气怎么样对第10轮的技术问题毫无价值。这里有个反直觉的点不是历史越长效果越好。上下文过长反而会稀释模型的注意力导致它抓不住当前问题的重点。所以节约token和提升效果在很多情况下是同一个方向的事不是取舍关系。3. 提示词瘦身从1800 token压到400 token的实操3.1 系统提示词的三层结构法我现在写系统提示词习惯用三层结构来组织这样既能保证信息完整又方便做精简角色层一句话说清楚AI是谁、干什么。比如你是电商客服工单分类器。这一层控制在20 token以内。规则层用最紧凑的方式列出判断规则和边界条件。能合并的合并能删的删。输出层明确输出格式越具体越好因为格式约束能大幅压缩输出token。三层加起来一个功能明确的Skill系统提示词完全可以控制在300-500 token。我实测过一个意图识别Skill从原来的1200 token压到380 token准确率从91.2%微升到91.8%——因为精简掉的都是干扰信息。3.2 删掉那些看起来很重要的废话提示词里有一类内容特别隐蔽就是那些看起来专业但实际无用的表述。我列几个常见的请仔细思考后再回答——模型不会因为你说了这句就思考得更仔细反而可能触发更长的推理输出。你是一个拥有十年经验的专家——除非你的任务真的需要特定领域知识否则这种身份设定对分类、抽取类任务几乎无影响。如果遇到不确定的情况请说明原因——这句话会让模型在边界case上输出一大段解释直接推高输出token。重复的示例——两个功能重叠的few-shot示例留一个信息量更大的就够了。注意精简提示词的前提是你有评测集。没有评测集就删提示词等于蒙眼开车。我建议至少准备50-100条覆盖各类边界的测试样本每次精简后跑一遍对比。3.3 用结构化格式替代自然语言描述自然语言描述规则很占token而且模型理解起来还有歧义。改用结构化格式比如JSON schema或者紧凑的键值对能省一大截。举个例子自然语言版约80 token你需要判断用户的问题属于以下哪一类如果用户询问订单状态、物流信息归为物流类如果用户询问退换货政策归为售后类如果用户询问产品功能归为咨询类。结构化版约35 token分类规则 - 物流类订单状态、物流信息 - 售后类退换货政策 - 咨询类产品功能信息量完全一样token省了一半多。这个技巧在规则条目多的时候效果更明显。4. 上下文管理让历史对话不再拖后腿4.1 滑动窗口不是最优解最简单的上下文管理是滑动窗口只保留最近N轮。但这个方法有个明显缺陷它按时间顺序丢弃而不是按信息价值丢弃。用户第2轮说的我是VIP客户可能比第8轮的寒暄重要得多但滑动窗口会先丢掉第2轮。我现在更常用的是摘要关键信息提取的组合策略。具体做法是每轮对话结束后用一个极低成本的小模型或者规则提取这轮对话里的关键信息存成一个结构化的对话状态。下一轮调用时不传完整历史只传这个状态摘要。4.2 对话状态摘要的具体实现假设一个多轮客服场景对话状态可以设计成这样{ user_intent: 退换货, product: 无线耳机, order_id: 已提供, sentiment: 不满, resolved: false }这个状态大概30-50 token而它替代的可能是前面5轮、上千token的完整历史。每轮对话结束后更新这个状态成本极低。实测下来一个平均8轮的客服对话用完整历史平均消耗约2400 token的上下文用状态摘要后降到约200 token压缩比超过90%而任务完成率没有下降。这个策略的关键在于状态字段的设计要贴合业务字段选对了信息就不丢。4.3 什么时候必须保留原文状态摘要不是万能的。有两类场景必须保留原文一是需要精确引用的场景比如法律文书问答、代码调试摘要会丢失细节。二是用户明确要求回顾之前内容的场景。这两种情况下我建议用按需检索的方式——把历史存在外部需要时再检索相关片段注入而不是全程携带。5. 缓存与复用把重复计算的钱省下来5.1 提示词缓存的实际收益现在主流模型服务商基本都支持提示词缓存Prompt Caching原理是把不变的前缀部分缓存起来后续调用命中缓存时按更低的费率计费。这个功能对系统提示词长、调用频繁的场景简直是救命稻草。我实测过一个场景系统提示词800 token日均调用2万次。开启缓存前光系统提示词部分每天消耗1600万token开启后缓存命中部分按约10%的费率计费相当于这部分成本直接降到160万token当量。前提是你的系统提示词要放在最前面且保持稳定如果每次调用都变缓存就命中不了。5.2 语义缓存的适用边界除了提示词缓存还有一层语义缓存——把意思相同的请求直接返回缓存结果不调用模型。比如用户问怎么退货和退货流程是什么语义上是一回事可以命中同一个缓存。语义缓存适合高频、同质化的查询场景比如FAQ、标准工单分类。但它有风险语义相似不等于答案相同阈值设低了会返回错误答案。我的经验是相似度阈值设在0.92以上比较稳妥同时要有一个缓存结果被用户否定就立即失效的机制。缓存类型命中条件成本节省适用场景风险提示词缓存前缀完全一致50%-90%系统提示词稳定的所有场景低语义缓存语义相似度超阈值接近100%高频FAQ、标准分类中需防误命中结果缓存请求完全一致接近100%幂等查询低5.3 缓存失效策略缓存最怕的是该更新的时候没更新。比如产品政策变了但语义缓存里还是旧答案。我的做法是给缓存加版本号任何底层知识变更时版本号递增旧缓存自动失效。这个机制简单但极其重要我见过因为缓存没失效导致客服答错政策、引发投诉的案例。6. 模型路由与输出控制把合适的任务交给合适的模型6.1 不是所有任务都需要大模型这是token节约里最容易被忽视、但收益最大的一环。很多团队习惯所有请求都走同一个大模型但实际上任务难度是分层的。意图识别、情感判断、简单分类这类任务小模型完全够用成本可能只有大模型的十分之一甚至更低。我一般会做一个任务分级L1 简单任务意图识别、关键词抽取、情感分类 → 小模型或规则L2 中等任务摘要生成、多轮对话、结构化抽取 → 中等模型L3 复杂任务推理、创作、复杂决策 → 大模型关键是先分级再路由。分级本身可以用一个极轻量的分类器甚至规则来做成本几乎可以忽略。我实测过一个客服系统把60%的请求路由到小模型后整体成本降了约55%用户满意度没有明显变化。6.2 输出token的压缩技巧输出token往往比输入token贵所以控制输出同样重要。几个实用技巧明确输出格式要求输出JSON而不是自然语言能省大量token。一句请用JSON格式输出只包含字段x和y能砍掉一半以上的输出。限制输出长度明确说不超过50字比不说强很多。禁止解释分类任务里加一句只输出类别标签不要解释能省掉大量废话。用枚举替代自由文本让模型从固定选项里选而不是自由生成。提示输出格式约束要放在系统提示词的最后靠近用户输入的位置这样模型遵循度最高。这是位置效应实测有效。6.3 流式输出与提前终止对于长输出场景流式输出本身不省token但配合提前终止可以省。比如你只需要答案的前半部分检测到关键信息出现就中断生成。这个在摘要、抽取类任务里很有用。不过要注意中断生成需要你的客户端支持且要处理好中断后的状态。7. 常见问题与排查技巧实录7.1 token节约的常见误区误区一以为节约token一定会牺牲效果。实际上大部分token浪费在冗余信息上删掉它们效果不降反升。真正需要权衡的是那些有用但非必需的信息。误区二只盯着输入忽略输出。输出token单价通常更高而且输出长度完全由你的提示词控制。很多人输入精打细算输出却放任模型长篇大论。误区三一次性优化不做持续监控。token消耗会随着业务变化而漂移。今天精简好的提示词三个月后可能因为需求变更又胖回去了。必须建立持续监控。7.2 排查token异常的速查表现象可能原因排查方法解决方向账单突然翻倍上下文变长/缓存失效对比调用日志的token分布检查历史管理、缓存版本单次调用token远超预期提示词膨胀/检索注入过多打印实际发送的完整prompt精简提示词、限制检索条数缓存命中率低前缀不稳定检查系统提示词是否每次变化固定前缀、变量后置输出token占比过高缺少格式约束统计输入输出token比例加格式约束、限长小模型路由后效果下降分级阈值不合理对比路由前后准确率调整分级规则、扩大评测集7.3 我踩过的几个坑第一个坑是过度精简导致边界case失败。有一次我把一个分类Skill的提示词压得太狠把几个罕见的边界情况说明删了结果那部分case准确率从85%掉到60%。教训是精简要有评测集兜底边界case的说明往往不能删。第二个坑是缓存版本管理混乱。早期我没做版本号结果产品更新后旧缓存还在生效用户拿到过期答案。后来加了版本号机制才解决。这个坑很隐蔽因为缓存命中率高的时候你根本不会去查内容对不对。第三个坑是模型路由的级联失败。我一开始用规则做分级规则写得太粗把一些复杂请求误判成简单请求路由到小模型结果答非所问。后来改成规则小模型置信度双重判断置信度低的一律升级到大模型才稳定下来。7.4 建立token监控的基本框架节约token不是一次性动作得有监控。我一般会记录这几个指标每次调用的输入token、输出token、缓存命中情况、路由层级、任务成功率。按天聚合看趋势。一旦某个指标异常波动就能快速定位。这套监控不需要很复杂一个简单的日志表加一个看板就够了。关键是要有人看而且要设定告警阈值。我见过太多团队做了监控但没人看等发现的时候账单已经烧了一个月。8. 一套可复制的token节约落地清单把上面这些串起来我给一个可以直接照着做的落地顺序先测量拉出最近一周的调用日志统计输入输出token分布、缓存命中率、各Skill的消耗排名。没有数据不要动手。建评测集每个Skill准备50-100条测试样本覆盖正常和边界情况。这是后续所有优化的安全网。精简提示词按三层结构重写系统提示词删冗余、合并规则、结构化表达。每改一版跑一次评测。改上下文管理把完整历史换成状态摘要按需检索替代全程携带。开缓存固定系统提示词前缀开启提示词缓存高频同质查询加语义缓存配版本号。做模型路由任务分级简单任务走小模型复杂任务走大模型置信度低自动升级。压输出加格式约束、限长、禁解释。上监控记录关键指标设告警持续看。这套流程我在三个不同规模的项目里跑过token成本普遍能降50%-70%效果基本持平甚至略有提升。降幅最大的一个项目降了78%主要因为它的系统提示词原本极其臃肿且大量请求可以走小模型。最后分享一个我个人的小习惯每次上线新Skill之前我会先估算它的单次token消耗和预期调用量算出月度成本写进项目文档。这个动作花不了几分钟但能让你在成本失控之前就发现问题。很多token浪费其实在设计的阶段就已经埋下了事后优化不如事前算清楚。