主题
13.7 省 Token 与提质量的统一决策框架
省钱和提质量在大多数动作上是同一件事。本篇给出那张按收益排序的动作表，以及三处它们会打架的地方。
读完你能做什么：按收益/成本排序执行一份 22 条的优化清单，识别省钱与质量冲突的三种情形，并落地一套可直接抄的默认配置。
一、为什么两个目标基本重合
text
上下文变长 ──┬─→ 每轮计费的 token 变多 → 更贵
└─→ 注意力被摊薄（context rot） → 更差同一个自变量，两个因变量同向。所以「找到能达成目标的最小高信号 token 集合」这一条原则同时优化了两件事。
这也意味着一条判据：如果一个优化只省钱不提质量，或者只提质量不省钱，那它大概率是在做权衡而不是改进，需要单独论证。
二、三处冲突点
| 冲突 | 省了什么 | 亏了什么 | 怎么处理 |
|---|---|---|---|
| 压缩 | 后续每轮的输入量 | 摘要必然丢信息；压缩本身是一次完整请求 | 在任务边界做，带保留指令；关键状态先落盘再压 |
| 延迟加载 | 常驻上下文 | 多一次往返，首次使用变慢 | 高频少量工具用 alwaysLoad，其余延迟 |
| 换便宜模型 | 直接成本 | 复杂推理的质量 | 按任务分层：主会话用强模型决策，扫描/格式化交给 Haiku |
第三条还有个隐藏项：弱模型走错路会产生额外轮次，可能比省下的单价更贵。判断标准是任务的「验证成本」——能被测试或脚本立刻验证的任务，用弱模型风险小；需要判断力的任务不要省这个钱。
三、按收益排序的动作清单
收益量级按「一个 50 轮的中型会话」估算。
🔴 第一梯队：数量级收益
| # | 动作 | 收益 | 实施成本 | 风险 |
|---|---|---|---|---|
| 1 | 切换到无关任务时用 /clear | 直接砍掉平方项 | 零 | 丢失连续性 |
| 2 | 大量读取 / 探索交给子代理 | 主会话侧压缩 20～50× | 低 | 摘要可能漏细节 |
| 3 | 把 CLAUDE.md 压到 200 行以内 | 每轮省数千 token | 中（要做取舍） | 无 |
| 4 | 工具输出加 Hook 过滤 | 单次省数千到上万 | 中（写脚本） | 过滤掉了需要的信息 |
| 5 | 默认模型从 Opus 降到 Sonnet | 约省 60% | 零 | 复杂任务质量 |
| 6 | 会话开头定死模型与 effort | 避免每次切换全量重算 | 零 | 无 |
| 7 | 确定性操作写成脚本而非文档 | 代码零上下文 + 结果确定 | 中 | 无 |
🟡 第二梯队：显著但非数量级
| # | 动作 | 收益 | 实施成本 | 风险 |
|---|---|---|---|---|
| 8 | MCP 保持 tool search 默认开启 | 省数万常驻 token | 零（默认） | 多一次往返 |
| 9 | 关掉不用的 MCP server（/mcp） | 每个省数千 | 零 | 无 |
| 10 | 能用 CLI 就不用 MCP | 常驻归零 | 中（配权限规则） | 无 |
| 11 | 走错路用 /rewind 而不是 /compact | 省一次完整请求 | 零 | 无 |
| 12 | 有副作用的 Skill 加 disable-model-invocation | 常驻归零 + 避免误触发 | 零 | 无 |
| 13 | 扫描类子代理指定 model: haiku | 该部分省约 80% | 零 | 无 |
| 14 | 在 CLAUDE.md 里要求简洁输出 | 输出的复利成本减半 | 零 | 无 |
| 15 | 长文档改索引 + 按需精读 | 单轮成本大幅下降 | 中 | 索引质量 |
| 16 | 只在改某类文件时相关的规范做成 paths: rule | 常驻归零 | 低 | 压缩后会丢失 |
| 17 | 简单任务降 effort 档或关思考 | 输出 token 显著减少 | 零 | 复杂任务质量 |
🟢 第三梯队：值得做但量级有限
| # | 动作 | 收益 |
|---|---|---|
| 18 | 一次说清需求，减少澄清轮次 | 直接减少 N |
| 19 | 让多个独立操作并行执行 | 减少轮数 |
| 20 | 复杂任务先进计划模式 | 避免走错方向的重做成本 |
| 21 | 脚本化调用用 --bare | 跳过 hooks / skills / plugins / MCP / auto memory 的加载 |
| 22 | 给出验证目标（测试用例、期望输出） | 让它自查，减少来回 |
第 22 条常被当作质量建议，但它同时是最有效的省钱手段之一：一次能自我验证的执行，胜过三轮「不对，再改改」。
四、四象限：拿到一个任务先判断
text
上下文需求大
│
拆成多个短会话 │ 派子代理 / fork
+ 外部状态文件 │ + 只回摘要
│
─────────────────────┼───────────────────── 推理难度
│
直接做，用 Haiku │ 直接做，主会话
或 --bare │ 用强模型 + 计划模式
│
上下文需求小| 象限 | 典型任务 | 配置 |
|---|---|---|
| 小上下文 / 低难度 | 格式转换、重命名、生成样板 | Haiku，或 claude --bare -p |
| 小上下文 / 高难度 | 算法设计、架构取舍、疑难 bug 定位 | 主会话，强模型，计划模式，高 effort |
| 大上下文 / 低难度 | 全库扫描、批量替换、依赖盘点 | Haiku 子代理，只回清单 |
| 大上下文 / 高难度 | 跨模块重构、遗留系统迁移 | 拆成阶段，每阶段独立会话 + PROGRESS.md |
右下角那格是唯一应该毫不犹豫花钱的地方。左上角那格是最容易浪费钱的地方。
五、一份可以直接抄的默认配置
~/.claude/settings.json：
json
{
"model": "sonnet",
"fallbackModel": "haiku",
"effortLevel": "medium",
"autoMemoryEnabled": true,
"statusLine": {
"type": "command",
"command": "~/.claude/statusline.sh"
},
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "~/.claude/hooks/filter-test-output.sh" }
]
}
]
}
}项目级 .claude/settings.json：
json
{
"claudeMdExcludes": [
"**/vendor/**",
"**/monorepo/other-team/**"
]
}项目 CLAUDE.md 的骨架（目标：150 行以内）：
markdown
# 项目名 · 一句话定位
## 绝对规则
（3～7 条，违反即错的硬约束）
## 构建与测试
（可直接粘贴执行的命令）
## 目录约定
（表格，一行一个目录）
## 输出偏好
- 回复保持简洁，不要复述已完成的步骤
- 改代码前先说改哪些文件、为什么，不要长篇解释
# Compact instructions
压缩时优先保留：未解决的失败用例、已定的架构决策、正在改的文件路径。
可丢弃：已通过的测试输出、成功的构建日志。会话级习惯：
text
开始新任务 → /clear
复杂任务 → Shift+Tab 进计划模式
走错方向 → Esc 打断，/rewind
任务告一段落 → /compact 带保留指令
定期核对 → /context 看常驻构成，/usage 看用量归因六、反模式清单
| 反模式 | 为什么错 | 改成 |
|---|---|---|
| 一个会话从早开到晚 | 每条消息都按全天历史计费 | 按任务切分，/clear |
| 「把整个 src 读一遍再说」 | 一次性灌入几十万 token，且大部分用不上 | 先 Grep 定位，或派子代理 |
把所有流程细节堆进 CLAUDE.md | 无关任务也要付这笔常驻 | 拆成 Skill |
靠 /compact 续命而不是 /clear | 每次压缩都是一次完整请求，且累积失真 | 无需连续性时直接 /clear |
| 中途反复切模型试效果 | 每切一次全量重算 | 会话开头定好，要比较就开两个会话 |
| 装满 MCP server 备着 | 每个连着的 server 都有常驻成本与连断风险 | /mcp 定期清理，优先 CLI |
| 让 Claude 现场写一次性校验代码 | 代码进上下文，且每次结果可能不同 | 固化成 scripts/ 里的脚本 |
| 把长参考资料贴进提示词 | 一次性巨额输入，且注意力被稀释 | 落盘 + 索引 + 按需精读 |
| 用「改进一下这个代码库」这类模糊指令 | 触发全库扫描 | 指名文件与目标 |
| 代理团队开一堆成员 | 每个成员一套独立上下文，计划模式下约 7 倍消耗 | 保持小队伍，用完及时关闭 |
七、把框架变成一句话
每一次要往上下文里加东西之前，先问：这一步真的需要它吗？如果不是这一步需要，能不能只留一个指针？
其余全是这句话的推论。