我平时用 ChatGPT、Claude 还有 API 比较多，后来发现一个挺有意思的事：
很多时候 token 真不是被"问题本身"吃掉的，而是被一些很没必要的上下文和废话吃掉的。
尤其是你用久了以后，一个对话窗口从上午聊到下午，前面塞了几万字，后面你只是问一句"这个函数怎么改"，模型每次都得重新带着前面的东西一起处理。
这个消耗其实挺夸张。
所以我现在如果比较在意 token，第一件事反而不是研究什么高级参数，而是勤开新对话。
比如我刚才还在让它分析一篇文章，过一会准备写 Python，那我基本不会继续在原来的窗口聊。
直接新开。
因为前面那些文章内容，对现在写 Python 基本没用。
有些人特别喜欢一个聊天窗口用一个月，什么都往里面问。看起来很方便，模型"记得上下文"，实际上如果按 API 的思路来看，这种用法挺费的。
特别是 Codex、Claude Code 这种涉及大量代码的场景，更明显。
一个项目几十个文件，如果你上来一句：
"帮我把整个项目看一下，然后看看这里为什么报错。"
模型很可能先读一大堆东西。
但实际上报错可能就涉及 3 个文件。
我现在一般会尽量告诉它：
"这个问题应该跟 login.ts、auth.ts 和 middleware.ts 有关，先只看这几个文件，其他文件先不要读取。"
这句话看着没什么技术含量，但省下来的 token 有时候比你折腾半天参数都多。
还有一个我自己经常用的小技巧，就是在提示词里直接限制回答长度。
不要写：
"详细分析一下。"
这种基本等于邀请模型开始写小论文。
我会写得很直接，比如：
"只告诉我问题原因和修改方法，300 字以内。"
或者：
"不要解释背景，只给修改后的代码。"
再或者：
"先给结论，如果没必要不要展开。"
效果其实很好。
现在很多模型有一个习惯，就是你不给限制，它会默认觉得"回答越完整越好"。
于是你问：
"这个报错是什么意思？"
它可能从报错原因讲到网络环境、版本兼容、最佳实践、排查流程......
你只是想知道一句话，它给你写了八段。
这种 token 完全可以省。
我甚至有时候会在长期提示词里直接写：
"默认简短回答，不主动总结，不重复我的问题，不解释我已经知道的背景，除非我明确要求详细说明。"
这种提示词非常实用。
当然这里有个坑。
别为了省 token，把提示词本身写成一篇论文。
我见过有人为了让 AI 简洁，前面先塞进去一两千字规则：
"你是一个专业助手，请遵守以下 28 条原则......"
那就有点搞反了。
如果每次请求都带着这一大坨 system prompt，你省下来的输出 token，可能还没有提示词本身消耗得多。
我的习惯就是规则尽量短。
比如：
简短回答，避免重复，不主动扩展无关内容。代码问题优先给可执行方案。
几十个字其实已经够用了。
还有一个特别容易被忽略的是：不要反复把完整内容贴给模型。
比如一篇 5000 字文章，你让它改标题。
改完以后又把整篇 5000 字贴进去：
"再帮我写个摘要。"
然后再贴一遍：
"帮我生成 10 个关键词。"
其实这种非常浪费。
如果是在同一个对话里，它已经有文章内容了，你直接说"基于上面这篇文章"就行。
如果是 API 场景，更好的方式是自己在程序里控制上下文，只传真正需要的内容。
比如做文章关键词，可能根本不需要完整 5000 字，摘要或者正文核心段落已经够用了。
代码也是一样。
能传 diff，就别每次传整个仓库。
能传一个函数，就别把整个文件塞进去。
能传报错附近 100 行，就没必要上传 3000 行日志。
我自己后来越来越觉得，省 token 这件事，说复杂也复杂，说简单其实就是一句：
少给模型没用的信息，也别让模型说没用的话。
输入和输出两边都得控制。
如果只是日常 ChatGPT 使用，我觉得最有用的基本就是这几个习惯：不同任务勤开新对话、明确限制回答长度、不要动不动要求"详细分析"、长文本和代码只给相关部分。
如果是 API 或 Codex 这种大量调用的场景，那就还可以继续往下做，比如限制 max output tokens、做上下文压缩、只传 diff、缓存固定提示词、用小模型先筛选内容再交给大模型。
不过日常用户其实不用搞那么复杂。
我目前的感觉是，很多人的 token 浪费，至少一半都不是模型能力造成的，就是上下文塞太多，再加上模型回答太热情。
把这两个地方管住，消耗马上就会明显下来。