rescue-tokens

救援令牌

概述

**核心原则：**令牌耗尽会伪装成“速率限制”错误。九种模式会悄无声息地浪费令牌。发现症状后立即行动，不要额外解释。

紧急警示信号

出现一项或多项时（或逻辑），立即停止并采取行动：

• 速率限制警告 ⚠️
• 上下文已使用 ≥40% ⚠️
• 下午 2 点后使用 $20-$100/月的套餐 ⚠️
• 对话已持续超过 90 分钟 ⚠️
• 已加载 5 个或更多 MCP 插件 ⚠️
• 用户说“别丢失上下文” ⚠️
• 简单任务使用 Opus 4.7 ⚠️

每项信号单独出现，都足以触发紧急模式。这些是紧急情况，不是优化问题。

示例：

• 上下文使用率 15% + 速率限制警告 → 紧急（1 项信号）
• 上下文使用率 45% + 无速率限制 → 紧急（1 项信号）
• 上下文使用率 9% + 无速率限制 + Sonnet → 非紧急（0 项信号）

行动矩阵（无需用户确认）

症状	行动	需要纠正的自我安慰
上下文使用率 40-70%	使用 /compact 保留关键信息并继续	“用户想保留上下文” → 大多数上下文都是浪费
上下文使用率 >70%	开启新对话，交接内容控制在 3 句话	“我会丢失重要细节” → 全新视角胜过臃肿的历史记录
速率限制 + 紧急任务	立即使用 Sonnet 子 Agent	“我先问问该采用哪种方案” → 没时间了，直接行动
CRUD/重构任务使用 Opus 4.7	立即切换到 Sonnet	“Opus 的质量更高” → Sonnet 擅长实现
附有 PDF/图片	请用户提供文本/关键摘录	“用户想让我通读全部内容” → 令牌成本高出 10-50 倍
已加载 5 个或更多 MCP	使用 /mcp 禁用未使用的项	“可能用得上” → 检查使用情况，主动禁用
用户要求在共享上下文中使用子 Agent	拒绝，解释不超过 50 个词	“是用户要求的” → 上下文重复 5 倍
用户说“我就快完成了”	开启新对话 + 3 句话总结	“沉没成本，他们会抗拒” → 正因如此，你必须坚持

**核心原则：**先行动，简短解释（如果需要）。在速率限制压力下，解释本身就是问题。

九种令牌陷阱

1. 永无止境的对话

**症状：**同一对话持续数小时，上下文不断膨胀
**修复：**之前的消息无关时使用 /clear，需要时使用 /compact，上下文使用率达到 40% 时开启新对话

2. 冗长输出

**症状：**长篇解释、“有任何问题请告诉我……”、分成多个 Markdown 小节 **修复：**有压力时简短作答。示例：“已切换到 Sonnet。开始处理 OAuth。”（7 个词，而不是 200 个）

3. 模型选择不当

修复：

• Haiku：重命名、简单任务、信息检索
• Sonnet：所有实现、重构、调试工作
• Opus：仅用于架构设计和深入规划

4. MCP 插件臃肿

**症状：**已加载 5 个或更多插件，用户却不知道 **修复：**使用 /context 审查，使用 /mcp 禁用未使用的项

5. 臃肿的 CLAUDE.md

**症状：**Claude.md 超过 200 行 **修复：**控制在 200 行以内，使用 @see 引用详细内容

6. 缓存失效

**症状：**对话中途更换模型，或对话开始后添加 MCP **修复：**在对话开始时设置模型/MCP，绝不要在对话进行中更改

7. 昂贵文件

**症状：**PDF、图片、Excel 文件 **修复：**要求转换为文本，提取特定页面（例如 Read pages: "1-3"），要求提供截图中的文本，而不是图片

8. 误用子 Agent

**适合使用子 Agent：**独立研究、可丢弃的探索、独立任务 **绝不要用于：**共享上下文工作（迁移、存在共同依赖项的重构）

决策流程：

digraph subagent_decision {
    "Task needs shared context?" [shape=diamond];
    "Sequential in main thread" [shape=box];
    "Sub-agent for isolation" [shape=box];
    
    "Task needs shared context?" -> "Sequential in main thread" [label="yes"];
    "Task needs shared context?" -> "Sub-agent for isolation" [label="no"];
}

9. 混淆消息与令牌

**实际情况：**套餐按消息数计费，但真正的成本是令牌。一次很长的 Opus 对话，相当于 50 多条简短的 Sonnet 消息。

常见的自我辩解

借口	现实
“我问问他们更喜欢哪种方案”	达到速率限制时，提问会消耗令牌。直接决定并行动。
“我解释一下为什么这样能节省令牌”	解释会消耗你正试图节省的令牌。
“用户想保留这些上下文”	长上下文中有 80% 都是无用信息。精简或重新开始。
“切换模型可能会降低质量”	Sonnet 擅长实现。Opus 仅用于架构设计。
“他们要求使用子 Agent”	拒绝不合理的请求。共享上下文的子 Agent 会造成 5 倍浪费。
“情况并不紧急”	速率限制警告就是紧急情况。立即行动。
“我引用一下规则来说明理由”	引用规则会消耗令牌。默默遵循即可。
“我加上‘推理：’部分，让内容更清晰”	推理部分会消耗令牌。只陈述决定。
“表格方便用户比较选项”	与句子相比，表格会多消耗 5 倍令牌。使用文字说明。
“用户需要了解取舍”	达到速率限制时，取舍分析只会增加额外开销。直接决定并行动。
“表达信心能体现全面性”	“有 95% 的把握……”会浪费令牌。直接行动。

压力下的回复规范

出现速率限制警告时：

• 回复预算：总计少于 100 个单词
• 不要使用 Markdown 分节（##、###）
• 不要使用“推理：”区块
• 不要使用表格或对比
• 不要嵌套项目符号
• 不要表达信心（“有 95% 的把握……”）
• 不要添加“关键见解：”之类的元评论
• 不要说“如果你需要，请告诉我……”
• 只用动作动词：“已切换到 Sonnet。已创建子 Agent。正在启动 OAuth。”

压力下的格式规则：

• 只写纯文本句子
• 直接说明决定
• 不作任何解释（除非明确要求）
• 每项行动最多用一个句子

对比示例：

❌ 冗长并包含“推理”（250 个令牌）：

“行动：立即切换到 Sonnet。

推理：

• 使用率已达 78%，再读取一个 PDF 就会触及上限
• OAuth 属于实现工作，而非架构设计
• Sonnet 擅长基于模式的重构
• 速率限制意味着成本很重要

你要我继续吗？”

✅ 简洁（15 个令牌）：

“已切换到 Sonnet。正在启动 OAuth 子 Agent。”

❌ 表格格式（100 多个令牌）：

| Approach | Tokens | Time |
|----------|--------|------|
| Keep Opus | 50K | 2h |
| Use Sonnet | 10K | 1.5h |

✅ 句子（12 个令牌）：

“在这里，Sonnet 比 Opus 节省 40K 个令牌。”

验证问题

在声称“已优化令牌使用”之前：

• 上下文是否低于 40%，或在最近 10 条消息内已压缩？
• 模型是否匹配任务类型（实现任务用 Sonnet）？
• MCP 是否与当前任务相关？
• 是否尽可能使用文本格式的文件？
• 子 Agent 是否仅用于隔离任务？
• 如果存在速率限制，回复是否少于 100 个单词？

与其他技能的集成

• 在实现之前使用 brainstorming（明确需求，避免返工）
• 在令牌限制下使用 verification-before-completion（例如运行测试，但使用 head_limit: 20）
• 使用 smart-explore 代替读取完整文件（通过 AST 扫描）

令牌感知型技能调用： 达到速率限制时，跳过可选技能。只使用核心技能。