很多人以为“节省 token”就是把提示词写短一点，其实这只做对了一半。真正影响消耗的，主要有两部分：你发给模型的输入内容，以及模型生成出来的输出内容。对话越长、上下文越多、回复越啰嗦，token 消耗就越大。
所以，真正有效的省 token，不是单纯“少说话”，而是做到三件事：少输入无关信息，少让模型重复思考，少让模型输出废话。抓住这三个原则，不管你是普通用户，还是接 API 做产品，都能明显降低消耗。
一、先搞清楚：token 到底浪费在哪
最常见的浪费，不是用户一句话太长，而是下面几种情况。
第一种，是把一大堆和当前任务无关的背景一起塞进去。比如你只是想改一段文案，却把整篇历史聊天、所有设定、十几段附件内容一起贴给模型。模型会全部接收，这些内容都会计入 token。
第二种，是让模型输出过多。你本来只需要 5 个要点，却写成“请尽可能详细分析”。结果模型生成上千字，输出 token 自然就上去了。
第三种，是重复发送相同内容。比如每次请求都把相同的规则、示例、背景完整重发一遍。尤其是做开发时，这种重复特别浪费。
二、普通用户最实用的 6 个省 token 方法
-
一次说清任务，但别把无关背景全扔进去
高效提问，不是越短越好，而是越准越好。
比如不要说：
“帮我分析一下这个行业，越详细越好。”
更省 token 的说法是：
“请从市场空间、竞争格局、盈利模式三个角度分析这个行业，先给 5 条结论，每条不超过 40 字。”
这样做的好处是，输入更聚焦，输出也更可控。
-
先要提纲，再决定要不要展开
很多 token 是被“过度展开”浪费掉的。正确做法不是一上来就让模型写 3000 字，而是先让它给提纲、结论或者目录，再挑你最关心的部分继续展开。
比如：
“先给我 5 个结论，我确认后，再展开第 2 条，控制在 800 字内。”
这样往往能省掉大量无效输出。
-
明确限制字数、条数和格式
模型在没有边界时，通常会默认“尽量完整”。想省 token，就要主动加边界。
你可以直接这样写：
“只输出 3 条建议。”
“每条不超过 30 字。”
“只给结论，不展开过程。”
“输出成一段话，不要分点。”
“如果信息不足，只回答‘信息不足’。”
限制越明确，模型越不容易跑偏，也越不容易啰嗦。
-
话题变了，就开新对话
很多人喜欢把一个聊天窗口当成万能工具箱，今天聊股票，明天聊提示词，后天聊代码，结果历史上下文越来越长。模型为了维持连续性，会把这些历史都当成潜在上下文负担，token 消耗自然会增加。
所以很简单：
同一主题继续聊，跨主题就新开。
这不是麻烦，而是最省 token 的习惯之一。
-
长文处理时，先摘要，再深挖
如果你要分析一篇很长的文章、一份报告或者一段会议纪要，不要直接让模型“全文详细分析”。更好的做法是分两步：
第一步：先摘要。
第二步：只针对摘要里你感兴趣的部分继续问。
这样相当于先把大上下文压缩成小上下文，再进行第二轮处理，消耗会低很多。
-
少用“越详细越好”这种话
这是最常见的 token 黑洞之一。
“越详细越好”“全面分析”“尽可能展开”这种表达，等于在鼓励模型多生成。你以为是在提高质量，实际上很多时候只是把废话写长了。
更好的表达是：
“深度够，但不要重复。”
“结论优先。”
“举 2 个例子即可。”
“只写我能直接执行的部分。”
三、如果你是 API 用户，这几招最省钱
-
把固定内容放前面，把变化内容放后面
如果你每次调用时，都有一部分内容是固定不变的，比如系统提示、角色设定、输出格式说明，那就尽量保持它们不变，并放在前面。每次变化的用户输入放在后面，这样更容易复用，效率也更高。
一句话总结：
能固定的，就固定；能复用的，就别乱改顺序。
-
别每次都把完整历史重发一遍
很多开发者习惯每一轮都把全部历史消息重新发一次，其实这会非常浪费。更好的方式是只保留当前任务真正需要的上下文，把不重要的历史压缩、摘要，或者直接丢掉。
不要把“重复搬运上下文”当成默认方案。
-
严格控制输出上限
对于 API 调用来说，最直接的省 token 方法之一，就是控制输出长度。能 300 token 解决的问题，就不要放任模型输出 3000 token。
尤其是摘要、提取、改写、问答这类任务，通常都可以通过限制输出字数来大幅节省消耗。
-
结构化输出尽量简洁
如果你需要模型输出 JSON、表格或者结构化信息，字段名、层级、描述都尽量简洁。不要为了“看起来更规范”，把一个本来很简单的结果包装成特别复杂的结构。
因为结构本身也会占 token。
-
简单任务别上大模型
不是所有任务都值得用最强模型。像分类、提取、改写、摘要这类高频简单任务，可以优先用更轻量、更便宜的模型处理。真正复杂、需要推理和高质量表达的部分，再交给更强的模型。
一个实用思路是：
小模型做初筛、清洗、分类；
大模型只处理真正复杂的环节。
-
批量任务尽量集中处理
如果任务不要求实时返回，比如夜间批量生成摘要、批量打标签、批量改写文案，就不要一条一条即时调用。集中处理，往往更省资源，也更方便统一管理。
-
先数 token，再发请求
很多人是“先调用，后心疼”。更好的习惯是先预估一下文本长度，看看有没有必要压缩、分段或者先做摘要。尤其是做开发时，这一步非常有必要。
四、一套通用的省 token 提问模板
你以后可以直接套这个模板：
请基于以下资料回答问题。
要求：
-
先给结论，再补充理由；
-
控制在 5 条以内；
-
每条不超过 50 字；
-
不要重复原文；
-
信息不足就直接说明。
资料：
……
问题：
……
这个模板的核心，不是单纯把字写短，而是同时限制了输入范围、输出长度和废话空间。
五、最后总结
节省 token 的本质，不是抠字数，而是减少无效沟通。
对普通用户来说，最有效的是三件事：问题聚焦、输出限长、跨主题开新对话。
对开发者来说，最有效的是四件事：固定可复用内容、减少重复历史、控制输出上限、把简单任务交给更轻量的模型。
真正会用大模型的人，不是把模型喂得越多越好，而是知道什么时候该多给，什么时候该少给。你给得越精准，模型越省；你问得越清楚，结果往往也越好。
本文来自转载硬核科技屋 ，不代表发现AI立场，如若转载，请联系原作者；如有侵权，请联系编辑删除。
