1. 从一次账单异常说起：为什么你的AI调用成本总比预期高
上个月帮一个做数据报表自动化的朋友看他的API账单，发现一个很典型的现象：他每天跑批处理任务，输入内容其实高度重复——同一份数据字典、同一套字段说明、同一段业务规则，每天都要重新塞进上下文里。一个月下来，光这部分重复内容的token消耗就占了总成本的六成以上。他一开始以为是模型选贵了，换了个更便宜的模型，结果账单没降多少，输出质量反而掉了。
这个场景其实非常普遍。不管是做数据分析、内容生成还是代码辅助，只要涉及大模型调用，token就是真金白银。而绝大多数人优化成本的第一反应是"换更便宜的模型"或者"压缩输出长度"，却忽略了一个更根本的问题：你每次请求里，有多少token是真正必要的？
这篇内容就是围绕"Skill节约token策略"展开的。所谓Skill，在这里指的是把一类可复用的能力（比如数据清洗、字段映射、报表生成）封装成相对固定的调用单元，而不是每次从零拼prompt。核心思路是：通过结构化的技能封装、上下文复用、缓存分层和输入裁剪，把每次调用的token开销压到最低，同时不牺牲输出质量。
适合谁看？如果你正在做AI应用开发、数据分析自动化、或者任何需要频繁调用大模型的场景，并且开始关注成本问题，那这篇内容里的思路和实操细节应该能直接拿去用。如果你只是偶尔调用几次，那可能感受不深，但了解这些策略对理解token计费逻辑也有帮助。
下面我会从token消耗的真实结构讲起，然后逐层拆解Skill封装、上下文管理、缓存策略、输入裁剪这几个核心环节，最后给出一套可以直接落地的组合方案。中间会穿插我自己踩过的坑和实测数据，尽量让每个结论都有依据。
2. 先搞清楚钱花在哪：token消耗的四个隐藏来源
2.1 系统提示词的固定开销被严重低估
很多人写系统提示词的时候，习惯把角色设定、输出格式、注意事项、示例全都塞进去，觉得越详细越好。这本身没错，但问题是这段内容每次请求都会完整计费。我见过一个系统提示词写了1800个token的案例，按每天调用5000次算，光系统提示词一天就是900万token的输入消耗。如果用的是按输入计费的模型，这笔钱花得悄无声息。
更关键的是，这1800个token里，真正影响输出质量的可能只有300到400个。剩下的要么是冗余描述，要么是模型本来就能理解的常识性说明。比如"你是一个专业的助手，请认真回答用户问题"这种话，删掉之后输出质量几乎没变化，但每次请求都能省下十几个token。
2.2 重复上下文是最大的浪费源
在数据分析场景里，这个现象特别明显。你有一张表，字段说明、数据类型、业务含义、枚举值映射，这些内容每次调用都要带上，否则模型不知道字段是什么意思。但问题是，这些内容在同一个任务周期内是不变的。每天重新传一遍，等于每天重新交一遍"资料费"。
我做过一个粗略统计：在一个典型的字段映射任务里，如果每次请求都完整携带数据字典，输入token里有70%到85%是重复的。也就是说，你花的钱里，大部分是在重复购买同一份信息。
2.3 输出格式约束带来的隐性成本
要求模型输出JSON、XML或者特定格式的表格，本身会消耗token。这倒不是问题，问题是很多人把格式约束写得太啰嗦。比如要模型输出一个包含五个字段的JSON，有人会写"请按照以下格式输出：第一个字段是name，类型是字符串，表示名称；第二个字段是age，类型是整数……"这种写法，格式说明本身就占了大量token。
更高效的做法是给一个极简的示例，让模型照着模仿。一个20个token的示例，效果往往比200个token的文字描述更好。
2.4 多轮对话中的历史累积
如果是对话式调用，每一轮都要把之前的历史带上。轮次越多，输入越长。很多人不注意控制历史长度，导致第十轮的时候，输入token已经是第一轮的十几倍。而实际上，前几轮的内容可能早就没有参考价值了。
这四个来源里，系统提示词和重复上下文是可控性最强、优化空间最大的部分。下面几节会围绕这两个核心，展开具体的策略和实操。
3. Skill封装：把重复内容变成可复用的"技能包"
3.1 什么是Skill，为什么它能省token
Skill这个概念，你可以理解成把一类任务的"固定部分"抽出来，做成一个模板或者配置，每次调用时只传"变化部分"。打个比方：你每次做饭都要买一遍油盐酱醋，那成本肯定高；但如果你家里常备这些调料，每次只需要买新鲜食材，开销就小很多。
在AI调用里，Skill就是那个"调料架"。具体来说，一个Skill包含：
- 固定的角色设定和任务说明
- 固定的输出格式约束
- 固定的领域知识（比如数据字典、业务规则）
- 可变的输入参数（比如具体的待处理数据）
把前三个固定下来，每次调用只传第四个，token消耗能直接砍掉一大半。
3.2 一个数据分析场景的Skill封装实例
假设你有一个任务：把用户上传的原始数据表，按照预定义的字段映射规则，转换成标准格式。原始做法是每次调用都把字段映射规则完整写进prompt。封装成Skill之后，结构大概是这样的：
# Skill定义（只存一次，后续复用） SKILL_DEFINITION = { "role": "数据字段映射专家", "task": "将输入数据按映射规则转换为标准格式", "mapping_rules": { "user_name": "姓名", "user_age": "年龄", "reg_date": "注册日期" }, "output_format": "JSON数组，每个对象包含标准字段名和值", "constraints": "日期统一为YYYY-MM-DD格式，年龄转为整数" } # 每次调用时，只传变化部分 def build_prompt(raw_data): return f"{SKILL_DEFINITION}\n\n待处理数据：\n{raw_data}"这样做的效果是：Skill定义部分的内容虽然每次也在prompt里，但它可以被缓存（后面会讲），而且结构固定，模型理解起来更高效。更重要的是，你可以把Skill定义压缩到最精简的程度，因为不需要每次都考虑"怎么把规则说清楚"，只需要说一次，之后反复用。
3.3 Skill粒度怎么定：太粗和太细都不行
这里有个实操中的关键决策：Skill的粒度。我试过两种极端：
一种是粒度太粗，一个Skill管所有数据任务，结果Skill定义本身变得巨大，每次调用还是要带一大堆用不上的规则。另一种是粒度太细，每个字段一个Skill，结果调用次数暴增，管理成本反而更高。
比较合理的做法是按"任务类型"划分。比如：
| Skill类型 | 包含内容 | 适用场景 |
|---|---|---|
| 字段映射Skill | 字段对照表、类型转换规则 | 数据清洗、格式转换 |
| 报表生成Skill | 报表模板、指标计算逻辑 | 周报月报自动生成 |
| 异常检测Skill | 阈值规则、异常判定逻辑 | 数据质量监控 |
| 摘要提取Skill | 摘要长度、关键信息优先级 | 长文本压缩 |
每个Skill的定义控制在200到400个token之间，既能说清楚，又不会太臃肿。超过500个token的Skill，就要考虑拆分了。
3.4 把Skill定义外置：从prompt里搬到配置里
更进一步的做法是，把Skill定义从prompt里彻底搬出来，放到外部配置文件或者数据库里。每次调用时，通过一个简短的标识符来引用。比如：
# 外部配置 skills = { "field_mapping_v1": "……（完整定义）……", "report_gen_v2": "……（完整定义）……" } # 调用时 prompt = f"使用技能[{skill_id}]处理以下数据：{data}"这样做的好处是，Skill定义本身不占用每次请求的token，只有在你需要模型理解技能内容时才注入。但这里有个前提：模型需要能够通过标识符理解技能内容。如果模型不支持这种引用方式，那就需要把定义注入进去，但可以通过缓存机制来降低成本。
注意：Skill外置的前提是你有一套稳定的调用框架，能够管理技能版本和映射关系。如果只是临时用几次，直接写在prompt里更省事。
4. 上下文复用与缓存：让重复内容只花一次钱
4.1 缓存机制的基本原理
现在很多模型服务都支持上下文缓存（Context Caching）。简单说就是：如果你连续几次请求的前缀内容相同，这部分内容只计费一次，后续请求命中缓存的部分按更低的费率计算，甚至免费。
这个机制对Skill场景简直是量身定做的。因为Skill定义、数据字典、业务规则这些内容，天然就是每次请求都相同的前缀。只要把它们放在prompt的最前面，就能最大化缓存命中率。
4.2 怎么组织prompt才能最大化缓存命中
缓存命中的关键是"前缀匹配"。也就是说，从prompt的第一个token开始，连续相同的部分才能被缓存。一旦中间有一个token不同，后面的内容就全部失效。
所以prompt的结构应该是：
[固定不变的部分：Skill定义 + 数据字典 + 业务规则] [可变部分：本次待处理的具体数据]千万不要把可变内容放在前面。我见过有人把用户ID放在prompt开头，结果每次请求前缀都不同，缓存完全用不上。
4.3 缓存的实际节省效果
我做过一组对比测试，同一个字段映射任务，处理1000条数据：
| 策略 | 输入token总量 | 缓存命中率 | 实际计费token |
|---|---|---|---|
| 无缓存，每次完整传 | 约120万 | 0% | 约120万 |
| 有缓存，固定前缀 | 约120万 | 约78% | 约38万 |
| 有缓存+Skill精简 | 约65万 | 约82% | 约18万 |
可以看到，缓存加上Skill精简之后，实际计费token降到了原来的15%左右。这个节省幅度在批量任务里非常可观。
4.4 缓存的边界和注意事项
缓存不是万能的，有几个坑要注意：
第一，缓存有有效期。不同服务的缓存时间不一样，有的是几分钟，有的是几小时。如果你的任务间隔太长，缓存可能已经失效了。所以批量任务最好集中跑，不要分散在一天里零散调用。
第二，缓存对prompt的稳定性要求很高。哪怕你只是改了一个标点符号，缓存就可能失效。所以Skill定义一旦确定，就不要频繁改动。需要调整的话，最好批量调整，然后重新预热缓存。
第三，不是所有模型都支持缓存。用之前先确认一下你用的服务有没有这个能力，以及计费规则是什么样的。有的服务缓存命中后按折扣价计费，有的直接免费，差别很大。
5. 输入裁剪：把不必要的token挡在门外
5.1 数据字典的按需加载
在数据分析场景里，数据字典往往很大，但每次任务可能只涉及其中几个字段。如果每次都把完整字典传进去，浪费非常严重。
做法很简单：根据本次任务涉及的字段，从字典里筛选出相关的部分。比如你有100个字段的字典，但这次只需要处理5个字段，那就只传这5个字段的定义。
def get_relevant_schema(full_schema, target_fields): return {k: v for k, v in full_schema.items() if k in target_fields}这个操作看起来简单，但效果立竿见影。我实测过一个案例，完整字典是3200个token，筛选后平均只有280个token，输入直接少了90%。
5.2 历史对话的滚动窗口
如果是多轮对话，不要把所有历史都带上。比较实用的策略是保留最近N轮，或者保留最近M个token的历史。更精细一点的做法是，只保留与当前问题相关的历史片段。
我一般用"最近3轮+关键信息摘要"的方式。具体来说，把之前轮次里的关键结论提取出来，压缩成一两句话，放在系统提示里，而不是把完整对话历史都带上。
5.3 输出格式的极简表达
前面提到过，输出格式约束不要写得太啰嗦。给一个最小示例，比写一段文字描述更省token，效果也更好。
比如要模型输出一个包含姓名和年龄的JSON数组，不要写"请输出一个JSON数组，每个元素是一个对象，包含name字段和age字段，name是字符串类型，age是整数类型"，直接给：
[{"name": "张三", "age": 25}]模型看到这个示例，自然就知道该怎么输出了。省下的token可能不多，但积少成多，在批量任务里也很可观。
5.4 用结构化格式替代自然语言描述
在传递数据的时候，能用CSV就不用自然语言，能用JSON就不用散文。结构化格式的token效率通常更高，而且模型解析起来更准确。
比如要传递一批用户数据，不要写"用户张三，年龄25岁，注册日期是2024年1月1日；用户李四，年龄30岁……"，直接给：
name,age,reg_date 张三,25,2024-01-01 李四,30,2024-01-02同样的信息量，token消耗可能只有自然语言的三分之一。
6. 组合策略实战：一个完整的数据分析Skill优化案例
6.1 优化前的基线情况
假设有一个任务：每天处理一批用户行为数据，按照预定义的规则进行清洗和分类，输出标准格式的结果。原始做法是每次调用都把完整的规则说明、字段定义、输出格式要求写进prompt。
基线数据大概是这样的：
- 系统提示词：约600 token
- 字段定义：约1200 token
- 规则说明：约800 token
- 输出格式：约300 token
- 实际数据：约500 token
- 合计输入：约3400 token/次
- 每天调用200次，总输入约68万token
6.2 逐层优化过程
第一步，把系统提示词精简到200 token以内，去掉所有冗余描述。
第二步，把字段定义和规则说明封装成Skill，外置到配置文件，通过缓存机制注入。由于这部分内容固定不变，缓存命中后实际计费大幅降低。
第三步，输出格式改成极简示例，从300 token降到50 token。
第四步，实际数据用CSV格式替代自然语言，从500 token降到200 token。
优化后的结构：
| 组成部分 | 优化前token | 优化后token | 节省比例 |
|---|---|---|---|
| 系统提示词 | 600 | 180 | 70% |
| 字段定义 | 1200 | 1200（缓存后约240） | 80% |
| 规则说明 | 800 | 800（缓存后约160） | 80% |
| 输出格式 | 300 | 50 | 83% |
| 实际数据 | 500 | 200 | 60% |
| 合计 | 3400 | 约830（缓存后） | 约76% |
6.3 优化后的效果和注意事项
优化后，每次调用的实际计费token从3400降到了830左右，降幅约76%。每天200次调用，从68万token降到约16.6万token。如果按常见的输入计费价格算，一个月能省下一笔不小的开支。
但有几个注意事项：
第一，缓存命中率不是100%，实际节省可能略低于理论值。要留一定的余量。
第二，Skill定义精简后，要验证输出质量有没有下降。我一般会跑一组对照测试，确保优化前后的输出结果一致。
第三，这套策略适合批量、重复性高的任务。如果是每次任务都完全不同的场景，缓存和Skill复用的效果会打折扣。
7. 几个容易踩的坑和我的实际体会
7.1 过度精简导致输出质量下降
省token的前提是不影响效果。我早期犯过一个错误，把系统提示词砍得太狠，结果模型对任务的理解出现偏差，输出格式经常不对，反而增加了重试成本。后来我给自己定了一个原则：精简的是冗余描述，不是核心约束。角色设定可以简，但输出格式的关键要求不能省。
7.2 缓存失效的隐蔽原因
有一次我发现缓存命中率突然从80%掉到了20%，排查了半天，最后发现是Skill定义里有一个时间戳字段，每次调用都会变。这个字段本身是为了记录版本，但它放在prompt前缀里，导致整个缓存失效。后来我把时间戳移到可变部分，问题就解决了。
这个坑的教训是：任何会变化的内容，都不要放在prompt的固定前缀里。哪怕它看起来很小，也会让缓存全部失效。
7.3 Skill版本管理的重要性
Skill定义一旦被多个任务引用，修改就要特别小心。我有一次直接改了一个正在用的Skill定义，结果所有依赖它的任务输出都变了，排查了很久才发现是Skill变更导致的。后来我养成了习惯：Skill定义修改必须新建版本，旧版本保留一段时间，确认新版本稳定后再下线。
7.4 不要为了省token牺牲可维护性
省token是为了降低成本，但如果因此把代码搞得极其复杂，维护成本反而更高。我见过有人为了省几个token，把prompt拼接逻辑写得像迷宫一样，后来自己都看不懂了。我的建议是：在可维护性和token节省之间找平衡。优先做那些改动小、收益大的优化，比如缓存和Skill外置。那些需要大量重构才能省一点token的操作，除非量特别大，否则不值得。
7.5 实测数据比理论计算更重要
不同模型、不同任务、不同数据分布，token消耗的结构都不一样。我上面给的数字是基于我的场景实测的，你拿去用的时候，一定要先跑一组基线测试，搞清楚自己的token花在哪，然后再有针对性地优化。盲目套用别人的策略，效果可能适得其反。
最后分享一个我常用的排查方法：把每次调用的prompt完整记录下来，按部分统计token占比。通常你会发现，排名第一的消耗源往往不是你以为的那个。找到它，优化它，效果立竿见影。
