读者点单·05｜Token 节省专题：把 AI 编程账单砍 60% 的 7 个工程化手段

📚 读者点单·端午投票系列 · 第5/10篇

✅ 第1篇：Android 性能治理的「全景图」

✅ 第2篇：Android 启动优化实战

✅ 第3篇：Compose 与传统 View 混用的 12 个真实坑

✅ 第4篇：Android 内存治理实战

📖 第5篇：Token 节省专题（本篇）

回应丹耀/锋点单的「Token 节省」话题。端午篇先开了个头，这里给完整版——从真实账单出发，拆解 7 个可操作的工程化降本手段，不讲玄学，只讲落地。

📰 今日要闻

• Anthropic 搁置 Claude Agent SDK 新计费方案——因开发者集体反对 Token 按量计费变更，官方宣布暂缓执行。Token 成本已成为行业痛点。

• Claude Code 让工程师季度代码产出提升 8 倍——Anthropic 工程师 Fiona Fung 在播客中透露内部数据，但产出 8 倍也意味着 Token 消耗激增。

• 豆包专业版正式上线，采用三级阶梯定价——国内 AI 编程工具竞争加剧，成本敏感度进一步提高。

• SK 海力士已提交美国 IPO 申请；马斯克身家蒸发 3400 亿美元——半导体新股暴涨 900%，霍尔木兹海峡对商船完全开放 60 天，国际油价下跌。

• 美国 6 月制造业裁员接近金融危机水平——S&P 数据显示，尽管制造业指数好于预期，但主要靠库存重建驱动，就业端大幅恶化。

引子：一次对话 5 美元的血泪教训

上周我在 Claude Code 里重构一个中型项目的模块结构。一个会话开了两小时，中间让它反复看了几个文件、改了几版方案、跑了几轮测试。会话结束后打开 Dashboard——$5.12。

我当时就懵了：我就重构了个目录结构，又不是写新系统，怎么就花了 5 块？

后来拆解了一下 Token 消耗明细，真相是这样的：

Token 总消耗 ~520K

↓

📚 80% → 读上下文（将整个仓库结构 + 文件内容反复填入 prompt）

🧠 17% → 模型思考（reasoning/chain-of-thought）

✍️ 3% → 实际生成的代码和回复

80% 的钱花在“读”上下文。模型每一次回复，都要把你之前说的所有话、读过的所有文件、系统提示词全部“重读”一遍。会话越长，每次回复的“读”成本就越高。这个结构性问题，就是我们要治理的核心。

今天这篇，我把自己这半年用 AI 编程的降本经验拉通了讲。7 个手段，每个都有具体的操作步骤和代码示例。实测综合下来，月帐单从 500 左右降到了 180——算不上 60%，但也差不多了。

第 1 招：会话长度治理——什么时候该开新会话

这个问题的答案反直觉。

很多人觉得“新会话 = 省钱”，因为新会话上下文短。但实际上，如果你频繁开新会话，每次都要重新给模型“介绍项目背景”，重新 @file 让它读代码，重新解释需求——这些“重建上下文”的 Token 是全价的（没有缓存）。

开新会话的时机判定

反直觉发现：宝玉博客的实测显示，在 Claude Code 中，如果你每做 5 分钟任务就开新会话，总 Token 消耗比“一口气聊完 1 小时”还贵约 40%。因为每次新会话都要重新加载 CLAUDE.md、项目结构、相关文件——这些全是全价输入。

所以正确策略是：任务边界切换时开新会话，同一任务内尽量继续。

第 2 招：摘要卡片——5 份文档→1 页摘要

很多同学用 AI 编程的时候，喜欢直接把整个文件 @file 进去。PRD 文档 3000 字、设计稿说明 2000 字、接口文档 1500 字——一股脑塞进去就是 6500 Token，每次模型回复都要重读一遍。

更聖明的做法是：先拿一个小模型做摘要，再把摘要卡片嗂给大模型。

# summarize_context.py
import anthropicdef make_summary_card(
docs: list[str]
) -> str:
client = anthropic.Anthropic()
# 用便宜的 Haiku 做摘要
resp = client.messages.create(
model=(
"claude-sonnet-4-"
"20250514"
),
max_tokens=800,
messages=[{
"role": "user",
"content": f"""
把以下文档压缩为一页摘要卡片：
- 保留接口名/关键参数/异常 case
- 去掉背景介绍和废话
- 输出不超过 500 字{chr(10).join(docs)}
"""
}]
)
return resp.content[0].text

这个技巧的效果数据：

任务完成率只降了 3%，但 Token 消耗降了 87%。而且这 3% 的丢失通常是边缘场景，补一句 follow-up 就能解决。

第 3 招：精准信息包——Bug 修复的「最小上下文」原则

我见过最贵的一类用法，是把整个报错日志贴进去，然后说“帮我看看哪里错了”。一个 crash log 可能 200 行，模型其实只需要其中 5 行。

我现在给模型报 bug 的模板是这样的：

## Bug 信息包模板现象: 点击“提交订单”后白屏 3s
复现路径: 首页 → 购物车 → 提交
关键报错:
NPE at OrderVM.kt:47
orderList.first() on empty
相关文件:
OrderVM.kt (42-55 行)
CartRepo.kt#getItems()
已排除: 网络正常，登录态有效

对比一下效果：

Token 少了 87%，一次解决率反而提高了 25 个百分点。因为你把干扰信息去掉了，模型能更快定位问题。这与 SHERLOC 论文的发现一致：LLM Agent 要花 50% 的 budget 在“定位故障”上——精准定位等于省一半钱。

第 4 招：子 Agent 返回格式约束——只要结论，不要明细

如果你用过 Claude Code 的子 Agent（Task 工具）或者自己搭的多 Agent 系统，你会发现一个痛点：子 Agent 默认会返回一大堆“思考过程”，而父 Agent 要把这些全部读一遍。

Claude Code 源码里有一段注释透露了它的设计思路：子代理是 fire-and-forget 设计，结果会被压缩后返回给主 Agent。我们自己做的时候也应该这样：

# 子 Agent 的 system prompt 末尾
# 加这段约束RETURN_FORMAT = """
你的返回必须严格限制在 200 字以内。
格式：
- 结论：[一句话结果]
- 变更文件：[列表]
- 风险点：[有则写，无则省略]
禁止返回你的思考过程。
"""

实测效果：子 Agent 的平均返回从 1500 Token 降到 150 Token。父 Agent 读这些返回的成本降了一个数量级。如果你一天触发 50 次子 Agent，光这一招就能省 67K Token。

进阶操作：在 OpenClaw/Claude Code 中，可以给 sub-agent 设置 lightContext: true，让子 Agent 不继承父 Agent 的完整会话历史，只拿到精简的任务描述。

第 5 招：项目级 Prompt 缓存——技1分钱变 0.1 分

这是降本效果最显著的一招。原理很简单：Claude API 的 Prompt Caching 机制会缓存 system prompt 和靠前的 messages，命中缓存的 Token 价格是正常输入的 1/10。

Claude Code 的核心省钱机制就是这个。它的 CLAUDE.md 并不是放在 system prompt 里的——而是通过 XML 标签注入到 messages 数组的固定位置，这样所有用户共享同一个 system prompt 缓存。

工程化落地方案

# 项目级 system prompt 模板
# 放在 CLAUDE.md / .cursorrulesSYSTEM_TEMPLATE = """
你是一个 Android 工程师。
项目技术栈：
- Kotlin + Compose + Hilt
- 架构：MVI + Clean Arch
- 网络：Retrofit + OkHttp
- 数据库：Room
- 测试：JUnit5 + Turbine编码规范：
- 函数不超 30 行
- 禁止 !! 操作符
- 报错用 Result 包装
"""# 这段内容每次请求都会被缓存
# 5 分钟内的后续请求只付 1/10 价

核心原则：把不变的内容尽量往前放，变化的内容往后放。缓存是按前缀匹配的，一旦中间内容变了，后面的全部失效。

腾讯内部 tRPC-Agent-Go 的实践数据显示，合理配置后缓存命中率可以达到 75-85%，综合成本降低约 60%。

第 6 招：模型路由——简单任务用小模型

不是每个任务都需要 Opus。我现在的实践是“三级火箭”模型策略：

任务进入

↓

复杂度判断？

↓

简单（改名/加注释/变量重命名）→ Haiku ($0.25/MTok)

中等（写新函数/修单个 bug）→ Sonnet ($3/MTok)

复杂（架构重构/多文件联动）→ Opus ($15/MTok)

Anthropic 最新定价：Fable 5 只要 1/MTok、Sonnet 4.6 是 3/MTok、Opus 4.8 是

# 简单的模型路由逻辑
def route_model(
task: str
) -> str:
# 简单任务关键词
simple = [
"rename", "comment",
"format", "typo",
"import"
]
# 复杂任务关键词
complex_ = [
"refactor", "architect",
"migrate", "redesign"
]
task_lower = task.lower()
if any(
k in task_lower
for k in simple
):
return "claude-haiku"
if any(
k in task_lower
for k in complex_
):
return "claude-opus"
return "claude-sonnet"

第 7 招：成本监控仪表盘——看见钱花在哪

你无法优化你看不见的东西。我建了一个简单的本地监控脚本，每天给我发一份报告：

# token_monitor.py
import json
from pathlib import Path
from datetime import datedef daily_report(
log_dir: str
) -> dict:
today = date.today()
log = Path(log_dir) / (
f"{today}.jsonl"
)
total_in = 0
total_out = 0
by_task = {}for line in log.open():
r = json.loads(line)
total_in += r["input_tokens"]
total_out += r[
"output_tokens"
]
task = r.get(
"task", "unknown"
)
by_task[task] = (
by_task.get(task, 0)
+ r["input_tokens"]
)# 找出最贵的 3 个任务
top3 = sorted(
by_task.items(),
key=lambda x: x[1],
reverse=True
)[:3]return {
"total_input": total_in,
"total_output": total_out,
"top_consumers": top3,
"est_cost": (
total_in * 3 / 1e6
+ total_out * 15 / 1e6
)
}

这个脚本每天跑一次，告诉我：

• 今天总共花了多少 Token

• 哪 3 个任务最耗 Token（这些是优化重点）

• 预估费用

有了数据，优化就有方向。我发现我最贵的任务不是写代码，而是“看代码”——code review 类任务把整个 diff 塞进去，成本极高但产出只是几句评论。后来改成只塞关键变更的 hunk，成本立刻降了 70%。

总结：7 招的综合效果

这些手段不是互斥的，而是叠加的。我自己的综合效果是从月均 500 降到 180，降幅约 64%。RunPod 的优化 Playbook 显示更极端的案例可以从 1.84/MTok 降到 0.55/MTok——降幅 70%。

最后说一句心里话：Token 省下来不是目的，用同样的钱做更多的事才是目的。我省下来的那 $320/月，现在全部投在了更多的实验性任务上——让 AI 帮我试更多方案、做更多原型。这才是「降本增效」的真正含义。

下一篇预告

下一篇回到性能治理主线——《读者点单·06｜Android 帧率治理：从 Choreographer 到 SurfaceFlinger 的卡顿排查链路》。从 Vsync 信号开始讲，拆解掉帧的完整分析链路。

📚 读者点单·端午投票系列 · 第5/10篇

基于端午《聊聊学习节奏》评论区读者票选生成的系列文章

✅ 第1篇：Android 性能治理的「全景图」

✅ 第2篇：Android 启动优化实战

✅ 第3篇：Compose 与传统 View 混用的 12 个真实坑

✅ 第4篇：Android 内存治理实战

📖 第5篇：Token 节省专题（本篇）

⏳ 第6篇：Android 帧率治理

⏳ 第7篇：ANR 治理实战

⏳ 第8篇：AI × Android 端侧落地

⏳ 第9篇：Android 包体积治理

⏳ 第10篇：系列复盘