任何省 Token 的做法都不是大模型的最佳实践

“省 Token"背后的思维陷阱

省 Token 的做法通常基于一个隐含假设：Token 是成本，越少越好。

但这个假设本身就是错误的。Token 不是成本——Token 是投入。就像你不会说"省工资是企业的最佳实践"一样，省 Token 也不应该成为使用大模型的指导原则。真正应该关注的是：每个 Token 产生了多少价值。

这两种思维方式导向完全不同的行为：

省 Token 思维	价值最大化思维
尽量用短 prompt	写清楚问题，给足上下文
砍掉 system prompt	精心设计 system prompt 来约束产出质量
用最小的模型	根据任务复杂度选择合适的模型
减少对话轮次	通过多轮迭代逼近最优解
避免"浪费"在探索上	大胆探索，快速试错

省 Token 思维的人，表面上每次调用花的钱少了，但产出质量也跟着下降了。最终的结果是：你省了 Token，但浪费了时间——而你的时间远比 Token 贵。

为什么上下文越充分，结果越好

大模型的核心机制是"根据上下文生成最可能的下一个 token”。这意味着你给的上下文越充分、越准确，模型的输出质量就越高。这不是可选的"高级用法"，这是模型工作的基本原理。

例子：一个代码调试场景

省 Token 的做法：

这段代码有 bug，帮我修：
func process(data []byte) { ... }

充分上下文的做法：

这是一个 Go 语言的数据处理服务，负责解析来自 Kafka 的消息。
当前的问题是：在高并发场景下（QPS > 1000），偶尔出现 panic，
错误信息是 "index out of range [3] with length 3"。

以下是相关代码（包含调用方和被调用方）：
[完整代码]

以下是出错时的日志：
[日志片段]

我怀疑问题出在切片的并发访问上，但不确定。请帮我分析根因并给出修复方案。

第一种方式省了几百个 token，但模型很可能给出一个泛泛的、甚至方向错误的回答，你需要多轮追问、补充信息、纠正方向——最终消耗的 token 反而更多，而且浪费了你 20 分钟。

第二种方式多花了几百个 token（成本可能不到 1 分钱），但模型一次就能定位到问题的根因，给出高质量的修复方案。

这就是"省 Token"的悖论：你越省，实际上花得越多。

省 Token 的五种常见反模式

1. 压缩 Prompt 到不可读

有些人把 prompt 写成"电报体"：去掉冠词、省略主语、用缩写替代完整词汇。这对人来说勉强能读懂，但对模型来说丢失了大量语义信号。

❌ "gen func, input: str list, output: sorted unique, py"
✅ "请用 Python 写一个函数，输入是一个字符串列表，输出是去重并按字母排序后的列表。"

省掉的那几十个 token 的成本大约是 0.001 美分，但它可能导致模型理解偏差，输出不符合预期。

2. 砍掉 System Prompt

System prompt 是控制模型行为最有效的手段之一。一个好的 system prompt 可以：

定义输出格式和风格
设定专业领域的上下文
规定约束条件和边界
减少幻觉和胡说八道

有些人为了省 token 完全不写 system prompt，或者把它压缩到一两句话。结果就是模型的输出质量不可控，你需要花更多轮次来纠正。

3. 过早切换到小模型

“这个任务很简单，用个小模型就行”——这话经常是错的。很多看起来"简单"的任务，其实对模型的推理能力有很高的要求。比如：

“帮我重命名这个变量” → 看起来简单，但需要理解整个代码的语义才能选择好的名字
“总结这段文字” → 看起来简单，但高质量的总结需要深度理解和信息筛选
“把这个 JSON 转成 YAML” → 看起来简单，但边界 case（嵌套引用、多行字符串）需要强模型才能正确处理

小模型在简单任务上确实够用，但"简单"的判断本身往往是错误的。用强模型处理所有任务的"浪费"，远小于用弱模型处理复杂任务的"翻车"成本。

4. 截断上下文窗口

为了省 token，有些人会手动截断对话历史，只保留最近几轮。但大模型的一个核心优势恰恰就是长上下文理解——它能综合整个对话的信息来给出更准确的回答。

截断上下文就像是跟一个有健忘症的人协作：你每隔几分钟就要重新解释一遍背景，效率反而更低。

5. 把多个问题塞进一个 Prompt

“反正发一次请求也要花 token，不如把三个问题一起问”——这种想法看起来是在"优化"，实际上严重影响了每个问题的回答质量。模型的注意力是有限的，当你把三个不相关的问题塞进一个 prompt，每个问题获得的"思考资源"都被稀释了。

分成三次问，每次都能得到聚焦、高质量的回答。总 token 多了一些，但每个回答的价值远超"打包处理"的结果。

什么才是真正值得优化的

如果"省 Token"不是正确的优化方向，那什么才是？

1. 优化 Prompt 的信噪比

不是让 prompt 更短，而是让每一句话都传递有效信息。去掉的不应该是上下文，而是废话和噪音。

❌（冗长但低效）：
"你好，我是一名程序员，我有一个问题想请教你。我最近在做一个项目，
这个项目是关于电商的。我遇到了一个bug，就是……（省略200字寒暄）"

✅（精炼但充分）：
"电商项目中的购物车模块，当用户快速连续点击'加入购物车'按钮时，
商品数量会多加。技术栈：React + Redux。以下是相关代码：[代码]"

两者 token 数可能差不多，但后者的信噪比远高于前者。

2. 优化任务分解

与其在一个超长 prompt 里试图一次性解决所有问题，不如把复杂任务分解成多个清晰的子任务。每个子任务都给足上下文，让模型聚焦解决一个问题。

这看起来用了"更多 token"，但总体效果远好于把所有东西糊在一起。

3. 优化模型选择策略

不是一刀切地用最便宜的模型，而是建立一个分层策略：

强模型（如 Claude Opus）：用于需要深度推理的任务——架构设计、复杂 bug 分析、方案评审
标准模型（如 Claude Sonnet）：用于日常开发任务——写代码、写测试、代码审查
轻量模型（如 Claude Haiku）：用于简单的格式转换、分类、提取等机械性任务

关键是按任务匹配模型，而不是按预算选模型。

4. 优化上下文的结构化

与其减少上下文，不如让上下文更结构化：

## 任务目标
[一句话说清楚你要什么]

## 背景信息
[为什么要做这个，有什么约束条件]

## 相关代码/数据
[完整的、相关的代码或数据]

## 期望输出
[你想要什么格式和粒度的输出]

结构化的上下文能让模型更高效地利用每一个 token，产出质量显著提升。

一个算术题：Token 到底值多少钱

让我们做一个简单的计算来说明"省 Token"有多荒谬：

以 Claude Sonnet 为例，输入 token 价格约为 $3/百万 token。一个"充分的" prompt 大约 2000 token，比"精简的" prompt 多约 1500 token。

多出来的 1500 token 的成本是：1500 / 1,000,000 × $3 = $0.0045

不到半美分。

而你因为 prompt 不够充分导致的额外沟通、返工、调试的时间，按每小时 $50 的时薪计算，即使只多花 5 分钟，成本就是 $4.17。

多花 $0.0045 的 token 来节省 $4.17 的时间，这笔账谁都会算。

省 Token 的 ROI 是负的。它省下的那点钱远远不足以弥补由此带来的质量下降和时间浪费。

Token 是弹药，不是负担

我在上一篇文章里提到过"每天用光可支配的 token"。这个观点的本质就是：Token 是你的弹药，不是你的负担。

一个优秀的猎人不会因为"省子弹"而不敢开枪。他会确保每一颗子弹都打到有价值的目标上。同样，使用大模型的最佳实践不是省 Token，而是让每一个 Token 都产生最大的价值。

具体来说：

不要省 system prompt → 投入 token 来精确控制模型行为
不要省上下文 → 投入 token 来给模型充分的信息
不要省对话轮次 → 投入 token 来迭代逼近最优解
不要省探索 → 投入 token 来尝试不同的方案
不要为了省钱而用弱模型做强模型的活 → 投入 token 来获得高质量的产出

结语

在 AI 成本持续快速下降的今天，省 Token 是一种用过去的稀缺思维来应对未来的丰裕现实的做法。一年前 GPT-4 的价格是今天的 10 倍以上，一年后今天的价格大概率又会被腰斩。你今天为了省 token 养成的坏习惯，会限制你明天充分利用更强、更便宜模型的能力。

真正的最佳实践不是省 Token，而是：给足上下文，用对模型，追求每个 Token 的价值最大化。

省下来的那点钱买不了你的时间，但浪费掉的时间再也买不回来。