产品教程把优化变成习惯＋30 秒自查
体系层四件事、25 项自查清单、工具地图与两个可复制 Prompt——最后一个延伸实践：把你的优化器做成一个 Skill。
这份笔记是什么
前两课解决的是「这一轮怎么省」。这一课解决的是「怎么让它一直省下去」——把动作沉淀成模板、清单和 Skill，不用每次重新想。
L5｜体系层：真正省钱的，是把优化变成习惯
1. 持续度量：先找到最大的浪费点
看缓存命中率、工具调用次数、Token 分布。不看数据就动手，很容易优化了不重要的一层。
2. Prompt 模板化：高频场景沉淀成文件
/prompts
meeting-summary.md
requirement-review.md
data-analysis.md
code-review.md
weekly-report.md每次只替换 {{input}}、{{date_range}}、{{output_format}} 这些变量。
3. 批处理：多个同结构小任务一次做完
按照同一规则分析以下 5 个需求。
统一输出：
ID | 核心目标 | 风险 | 待确认问题
A. ...
B. ...
C. ...
D. ...
E. ...一次处理多个同结构任务，可以省掉重复的背景、固定的 Prompt 和初始化开销。
4. 缓存友好：稳定内容放前面
对于支持 Prompt / Prefix Caching 的系统：
稳定内容放前面：System Prompt / 工具定义 / 固定规则
变化内容放后面：本次问题 / 本次数据不要无意义地频繁改动固定前缀。 改一个字的代价，是整段前缀缓存失效。
优化不是一次性的「瘦身」，而是一个可度量的循环。
30 秒自查：你的 Token 浪费在哪
课堂现场只需要问这四个问题，就能定位最大的漏点：
| 编号 | 问题 | 判断标准 |
|---|---|---|
| 01 | 上下文膨胀？ | 超过 10 轮 / 超过 15K Token / 多任务混用 |
| 02 | 工具过载？ | 缓存命中低 / Skill 与 MCP 装太多 / tools 定义太大 |
| 03 | 输出冗长？ | 没指定格式 / 大量解释 / 实际只需要三分之一 |
| 04 | 模型过度？ | 简单任务也用最强模型 / Prompt 冗余 |
先找到最大漏点，再优化。 四条里哪一条最像你，就从那一条动手。
完整自查清单（课后逐项过一遍）
A. 输入
- 我是否一句话说清楚了目标？
- 定义、公式、边界是否明确？
- 是否有大量「专业、认真、详细」等不改变行为的描述？
- 能否用列表 / JSON / 表格替代长段自然语言？
- 是否重复粘贴模型已经知道的信息？
B. 输出
- 是否明确输出格式？
- 是否规定最大条数 / 长度？
- 是否真的需要背景介绍和扩展知识？
- 是否要求模型不要复述输入？
- 模型跑偏时是否及时停止？
C. 上下文
- 当前会话是否混入多个无关任务？
- 长会话是否应该摘要后开新会话？
- 是否把整个 PDF / 日志 / 代码库都塞给模型？
- 能否先搜索，再只读取相关部分？
- 已解决的调试过程是否仍在持续占上下文？
D. 模型与工具
- 简单任务是否用了过强模型 / 过高推理强度？
- 当前加载的 Tool / MCP / Skill 是否都需要？
- 是否可以延迟加载工具？
- 工具输出是否可以先用脚本过滤？
- 是否有多个功能重复的工具？
E. 体系
- 高频 Prompt 是否模板化？
- 相同结构的小任务能否批处理？
- 固定 Prompt / 工具定义是否保持稳定以利于缓存？
- 是否定期看 Token、延迟、缓存命中或工具调用数据？
- 是否记录优化前后的实际差异？
工具地图：你到底该用哪一类
| 想解决什么 | 目标 | 代表思路 / 工具 |
|---|---|---|
| 找代码 | 少翻文件、少 grep | CodeGraph、Claude Context、Codebase-Memory |
| 压输出 | 少吞 diff / test / log | RTK、Headroom |
| 管上下文 | 自动精简、按需取 | Context Mode、OpenViking |
| 看消耗 | 看清预算与缓存命中 | Tokalator、rtk gain 等自带统计 |
| 减少猜测和返工 | 结构化 Prompt、模板 | Prompt 模板库 |
| 少塞整份资料 | 先检索再读取 | RAG / 语义搜索 / 按需读取 |
| 复用高频能力 | 一次做好、长期使用 | Skill / Prompt Library |
一句话记住这张表：少找 · 少读 · 少存 · 看清楚。
工具会变，思路不会变。上面这些名字当作「这一类工具长什么样」的示例，正式使用前查一下最新官方文档。
最后只记住这 3 个动作
01 · 少喂
Prompt 更确定，上下文更干净，工具按需加载。这一步解决的是「进来的 Token 有多少是没用的」。
02 · 少吐
限制字段 / 格式 / 长度；能脚本算的，就别让模型展开写。输出通常比输入更贵，这是收益最快的一步。
03 · 多复用
稳定缓存前缀，Prompt 模板化，批处理高频任务。把一次性的优化变成可重复使用的东西。
低消耗 ≠ 降能力，而是把 Token 花在真正有价值的地方。
记忆口诀
该省省、该拆拆、该缩缩。
- 该省省：不要生成不需要的内容；
- 该拆拆：不同任务拆会话，不要让上下文无限长；
- 该缩缩：日志、文件、历史信息先过滤、摘要、检索，再交给模型。
最终目标不是追求「最低 Token」，而是：用尽可能少的无效 Token，获得尽可能高质量的结果。
可复制 Prompt
Prompt 一｜Prompt 自我优化
请优化下面的 Prompt。
目标：
在不损失任务关键信息和约束的前提下：
1. 删除重复和无效描述；
2. 补齐会导致模型猜测的关键定义；
3. 改成结构化格式；
4. 明确输出格式和长度；
5. 不增加无关要求。
输出：
A. 优化后的 Prompt
B. 删除了什么
C. 补充了什么
D. 为什么这样更高效
原 Prompt：
{{prompt}}Prompt 二｜长会话压缩
见第二课 Demo 2，可直接复制使用。
延伸实践：把 Demo 做成你的第一个 Skill
课上跑过的 Demo，如果每天都要用，就该把它做成 Skill，而不是每次重新粘贴 Prompt。
建议优先做「Prompt 优化器」——它正好是全课最通用的那个动作。
Skill 的核心指令
你的任务是优化用户 Prompt 的 Token 利用效率，而不是机械缩短字数。
原则：
1. 保留完成任务必须的信息。
2. 删除重复、客套、无效角色描述。
3. 补齐会导致模型猜测的定义、边界和判断标准。
4. 优先使用"目标 / 输入 / 规则 / 输出 / 限制"结构。
5. 限制不必要的输出。
6. 不擅自改变用户原始目标。
7. 信息不足时指出缺口，不自行编造业务规则。
输出：
## 优化后的 Prompt
...
## 删除
- ...
## 补充
- ...
## 为什么更高效
- ...发布前先脱敏
- 删除真实客户名、公司名和内部项目名；
- 删除 API Key、Token、账号和内部 URL；
- 示例数据改为虚构数据；
- 检查日志、截图、配置文件里的隐私信息；
- README 写清适用场景、输入、输出和限制。
发布渠道和详细流程看这两个地址：
- SkillHub 官网：https://www.skillhub.cn/
- SkillHub 发布教程：https://www.skillhub.cn/tutorials
参考链接
- SkillHub 官网：https://www.skillhub.cn/
- SkillHub 发布教程：https://www.skillhub.cn/tutorials
- RTK（Rust Token Killer）：https://github.com/rtk-ai/rtk
工具版本、安装命令、模型价格和缓存规则都可能变化。正式使用前请查看对应项目或供应商的最新官方文档。
30 秒收尾
如果今天只记住一件事，请记住：
Token 优化不是抠字数，而是减少模型的猜测、无关上下文和无效输出。
先把 Prompt 写确定，再只加载需要的工具；
长对话及时压缩，重复任务做成模板和 Skill。
当你开始问"这段信息真的需要进入上下文吗？"
你就已经开始真正优化 Token 了。