很多人把 Skill 理解成“保存一段常用提示词”。
但如果只是把几千字说明全部塞进 SKILL.md，每次任务仍然完整加载，它并不会天然省 Token，反而可能让上下文更重。
真正有效的 Skill，是把 AI 已经探索成功的知识、脚本和流程保存下来，让重复任务不必再次从零开始。
Skill 节省的不是输入的几个字，而是模型反复理解、探索、开发和修 Bug 的过程。
一、Token 真正浪费在哪里？
以日志分析、数据采集、报表生成这类重复项目为例，没有 Skill 时，模型每次都可能重新经历：
读取项目资料
→ 理解业务规则
→ 寻找相关文件
→ 编写或修改脚本
→ 执行报错
→ 分析并修复
→ 调整输出格式
最终结果可能只有几百字，真正消耗 Token 的，却是前面的重复探索和返工。
Skill 的价值，就是把这条已经走通的路线固化下来。
二、三类 Skill，减少三种重复消耗
1. 知识型 Skill：减少重复理解
适合保存长期稳定的内容，例如：
- 字段说明；
- 项目结构；
- 接口规范；
- 业务规则；
- 输出标准。
但不要把全部知识一次写进主文件，而应按需拆分：
project-skill/
├── SKILL.md # 触发条件、核心步骤
├── references/ # 字段、规则、项目知识
└── examples/ # 合格结果示例
模型先读取精简的 SKILL.md，只有任务涉及某项规则时，才继续读取对应资料。
这就是渐进式披露：需要什么，加载什么。
固定规则保持稳定、本次需求放在最后，也能让上下文更具缓存友好度。
需要注意的是，Skill 不能保证底层模型一定命中缓存，但稳定的上下文结构可以减少重复读取和重新理解。
2. 脚本型 Skill：减少重复开发和修 Bug
数据清洗、日志提取、格式转换、文件扫描等确定性任务，不应该每次都让模型重新写代码。
第一次完成脚本并验证后，将它保存到 Skill：
python scripts/analyze.py input.log
后续任务直接调用，模型只负责读取结果和处理异常。
这样可以跳过：
重新生成代码
→ 执行失败
→ 分析报错
→ 修改代码
→ 再次执行
能由程序稳定完成的事情，就不要让大模型每次现场发挥。
3. 流程型 Skill：减少重复寻找工作规律
复杂任务最容易浪费 Token 的地方，是模型每次都要重新判断下一步该做什么。
流程型 Skill 可以直接固定执行路线：
检查输入
→ 读取相关规则
→ 调用已有脚本
→ 校验执行结果
→ 按模板生成产物
模型不再反复决定该读哪个文件、调用什么工具、如何验证结果，而是沿着已经验证过的流程执行。
三、实际项目对比：重复任务能省多少 Token？
我用一个真实的 RPA 转 Python 数据采集项目进行了测算。
项目实际包含：
- 273 行 Python 脚本；
- 81 行流程文档；
- 18 个分类；
- 11 个采集字段；
- 登录、页面导航、数据拆分、异常处理等多项规则。
项目中的代码和流程文档合计约 12 KB。
按照中文文档与 Python 代码的混合内容估算，模型每次完整读取约需 4000～6000 Token。
不使用 Skill
每次调整采集规则时，模型都要重新读取代码和流程文档，再寻找偏差、修改脚本、分析报错。
单次相似任务预计消耗：
6000～10000 Token
连续完成三个相似需求：
18000～30000 Token
使用 Skill
第一次将项目整理为：
brand-crawler/
├── SKILL.md # 核心执行流程
├── references/ # 页面路径、字段和业务规则
├── scripts/ # 已验证的采集程序
└── templates/ # Excel 字段与输出格式
第一次建立 Skill 仍需要整理规则和验证脚本，预计消耗 7000～10000 Token。
但第二、第三次任务只需读取本次相关规则，并调用已有脚本，每次预计消耗 1500～3000 Token。
| 执行方式 | 第一次 | 第二次 | 第三次 | 三次累计 |
|---|---|---|---|---|
| 每次重新探索 | 6000～10000 | 6000～10000 | 6000～10000 | 18000～30000 |
| 使用 Skill | 7000～10000 | 1500～3000 | 1500～3000 | 10000～16000 |
按照区间中位数计算：
普通方式：约 24000 Token
Skill 方式：约 13000 Token
累计减少：约 46%
Skill 并没有让第一次任务明显变便宜。
它省下的是后续任务中的：
- 项目资料重复读取；
- 业务规则重新理解；
- 相同脚本重复开发；
- 已解决问题再次排查；
- 工具和执行路径重新探索。
任务只做一次，Skill 未必划算；任务不断重复，Skill 才会持续产生收益。
四、一个省 Token 的 Skill，应该怎么设计？
我总结为五条：
- 主文件要短：
SKILL.md只写触发条件、核心流程和结束标准。 - 知识要拆分：详细资料放入
references，需要时再读取。 - 脚本要复用：验证通过的程序不要重复生成。
- 流程要固定：明确执行顺序、检查点和异常处理方式。
- 动态内容后置：稳定规则与本次需求分离，提高上下文稳定性。
不要做一个越来越长的提示词文件，而要做一个可以按需调用的能力包。
五、什么时候值得做成 Skill？
我的判断标准很简单：
同类任务预计还会出现三次以上，就值得考虑做成 Skill。
例如：
- 周报、月报和固定报表；
- 日志分析和故障排查；
- 批量文件或表格处理；
- 固定规范的代码检查；
- 重复执行的数据采集；
- 相同结构的文档生成。
重复次数越多，知识、脚本和流程的复用价值越高。
最后
很多人节省 Token 的方式，是让提示词少写几个字。
但大模型真正昂贵的部分，往往不是用户输入，而是执行过程中不断重复的理解、搜索、试错、开发和返工。
- 知识型 Skill，减少重复理解；
- 脚本型 Skill，减少重复开发；
- 流程型 Skill，减少重复探索；
- 渐进式披露，减少无关内容加载。
把一次成功的探索保存下来，让下一次任务直接从正确路径开始。
这才是 Skill 降低 Token 消耗、提高稳定性的核心价值。