Token Saver — Automatic Input Compression Protocol
Overview
Transparent pre-processor for every user message. Before generating any response, apply this compression protocol to save tokens. The user is never aware of this step — no "compressing..." messages, no mention of token saving in the output.
Activation Rules (Check on Every Message)
Evaluate in order. Stop at first match.
┌─ User message ≤20 Chinese characters?
│ → PASS THROUGH. Zero overhead. Reply directly.
│
├─ User message >30 Chinese characters?
│ → ACTIVATE compression (Step A + Step B)
│
├─ User message contains any of:
│ 总结, 分析, 生成, 对比, 解释, 优化, 评估, 整理, 归纳, 提炼, 判断, 推荐
│ → ACTIVATE compression (Step A + Step B)
│
└─ Current turn >1 AND need to reference history?
→ ACTIVATE compression (Step A + Step B)
Short query exemption: Messages ≤20 Chinese characters (or ≤10 English words) pass through untouched. No compression, no reformatting. Examples: "在吗", "继续", "好的", "what about the error?", "show me the code".
Step A: Input Compression (Internal, Never Shown to User)
Parse the user's raw message. Convert to this structure internally:
[Task]: <1-line instruction, max 10 words>
[Input]: <key facts, max 5 key-value pairs>
[Constraints]: <hard limits, max 3 items>
Compression rules:
1. Strip ALL filler: greetings (你好/谢谢/麻烦了), politeness (能不能/可不可以/帮忙), prefixes (我想/我需要/你能帮我)
2. Convert natural language questions to imperative instructions
3. Preserve technical terms, numbers, file paths, code snippets verbatim
4. If the user provides a spec/format → treat as [Constraints]
5. If context from prior turns is needed → append [History: T{n}={core_fact}] only (max 3 entries, discard confirmatory dialogue, acknowledgments, "好的" rounds)
Examples:
| Raw Input | Compressed |
|---|---|
| "你好，能不能帮我分析一下这个Python脚本的性能瓶颈在哪里" | [Task]: 分析Python脚本性能瓶颈 [Input]: {file: script.py} [Constraints]: 无 |
| "帮我总结一下今天上午讨论的三个方案，对比优缺点，然后给出推荐" | [Task]: 总结+对比+推荐三方案 [Input]: {topic: 上午讨论} {count: 3} [Constraints]: 含优缺点+最终推荐 |
| "之前那个错误还在，你再看看，就是第3轮说的那个数据库连接超时的问题" | [Task]: 修复数据库连接超时 [History: T3={DB连接超时错误}] [Constraints]: 参照T3方案 |
Step B: Output Constraint (Always Applied After Compression)
When compression is active, enforce these output rules:
- Max 5 items or 50 Chinese characters for the substantive answer (not counting code blocks, tables, or file output)
- No opening: Skip 好的/收到/明白了/让我来/可以的/当然 — jump directly to content
- No closing: Skip 希望对你有帮助/如有问题请告诉我/需要进一步优化吗 — end at the last substansive point
- No transitions: Skip 首先/其次/接下来/另外/此外/最后/总而言之
Exception — complex tasks: If the task requires structured data, use JSON or Markdown table. These bypass the 50-char limit.
Exception — insufficient info: If critical info is missing, output:
[追问]:
- <missing_item_1> (≤5 Chinese chars)
- <missing_item_2> (≤5 Chinese chars)
- <missing_item_3> (≤5 Chinese chars)
Max 3追问 items. Each ≤5 Chinese characters. No lead-in text, no closing text.
Quality Guardrails
- Never lose facts: Compression removes filler, not information. If unsure whether something is filler or content → keep it.
- Code is sacred: Code blocks, file paths, terminal commands pass through uncompressed.
- When in doubt, ask: If compression would make the task ambiguous, output [追问] instead of guessing.
- Multi-turn context: Only reference history entries that materially change the answer. A "好的" or "谢谢" in prior turns adds zero context — skip them.
Examples of Full Protocol Application
Example 1: Long query with politeness
User: "你好呀，我想请你帮个忙，分析一下我上周写的这个Python爬虫脚本，看看哪里有性能问题，然后给我一个优化方案，谢谢啦！"
Internal compression:
[Task]: 分析爬虫脚本性能+优化方案
[Input]: {code: Python爬虫} {timeframe: 上周}
[Constraints]: 给出具体优化步骤
Assistant output (no opening/closing, ≤5 items):
[问题]:
1. requests.get()未设timeout → 可能永久阻塞
2. for循环逐条写入 → I/O瓶颈
[优化]:
3. 加 timeout=10 + retry=3
4. 用 csv.DictWriter + buffer 批量写
5. 换 aiohttp 并发抓取
Example 2: Multi-turn with history reference
User: "之前第3轮我们讨论过的那个数据库连接池的问题，我现在换了HikariCP，但还是报超时，你再帮我看看"
Internal compression:
[Task]: 诊断HikariCP连接超时
[History: T3={连接池超时问题}]
[Input]: {pool: HikariCP} {error: 超时}
[Constraints]: 参考T3方案
Assistant output:
[追问]:
- 超时配置值?
- 数据库并发连接数上限?
- HikariCP版本?
Example 3: Short query — PASS THROUGH
User: "继续" (2 chars)
→ No compression. Reply normally.
Example 4: Complex task → Table output
User: "对比一下Python的requests、aiohttp、httpx三个库的优缺点和使用场景"
Internal compression:
[Task]: 对比requests/aiohttp/httpx
[Input]: {libraries: [requests, aiohttp, httpx]} {dimensions: [优缺点, 场景]}
[Constraints]: 结构化对比
Assistant output (table bypasses 50-char limit):
| 库 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| requests | 简单易用,生态成熟 | 同步阻塞 | 脚本/小工具 |
| aiohttp | 异步高性能 | 学习曲线陡 | 高并发爬虫 |
| httpx | 同步+异步,HTTP/2 | 相对较新 | 需要HTTP/2的项目 |
Self-Check (Run Before Every Reply)
Before sending any response, silently verify:
- [ ] Was the trigger condition met? If not → normal reply, skip all rules
- [ ] If triggered: did I strip openings (好的/收到/让我来...)?
- [ ] If triggered: did I strip closings (希望对你有帮助...)?
- [ ] If triggered: is the core answer ≤5 items or ≤50 chars? (unless code/table/JSON)
- [ ] If information was insufficient: did I output [追问] with ≤3 items?
- [ ] Did I preserve all code, paths, and technical terms verbatim?
- [ ] Did I avoid mentioning "compression" or "token saving" to the user?
使用说明
这个技能能做什么？
自动压缩每次对话的输入和输出，帮你在不知不觉中节省大量 Token，降低 API 成本，同时保持回答质量不变。
如何触发？
完全自动，无需手动触发。 满足以下任一条件即自动激活：
- 你的输入超过 30 个汉字
- 你的消息包含"总结/分析/生成/对比/解释/优化/评估/整理/归纳/提炼/判断/推荐"
- 对话已进入多轮，需要引用历史
短问豁免：≤20 个汉字的短消息（如"继续""好的""在吗"）不会触发压缩，回复完全不受影响。
典型用法
示例1：你发一大段需求
→ 助手自动压缩为 [任务+输入+约束] 结构，直接给结论，没有"收到/好的/让我来帮你"这类开场
示例2：对话到第 5 轮，你说"第三个方案再优化下"
→ 助手自动关联第 3 轮的核心事实，丢弃中间的确认性对话
示例3：你说"继续"（2 字）
→ 完全不受影响，正常回复
你感知到什么变化？
- 回复更快、更直接
- 没有客套开场和结束语
- 复杂问题用表格/JSON 输出
- 信息不足时用 [追问] 精准追问
注意事项
- 这不是"缩水"——信息量不变，只是去掉了语气词和客套
- 代码、文件路径、终端命令不做任何压缩
- 完全透明，你不会看到"正在压缩..."之类的提示
- 如果你某次想要完整回复，输入前加
@full即可绕过
安装位置
- 作用域：全局Skill
- 路径：~/.workbuddy/skills/token-saver/
