@TOC
先说一个反直觉的事实：你的 token 大部分不是花在「写代码」上，是花在「找代码」上。
让 AI 改一个函数，它要先找到这个函数、读一遍、找调用方、再读几个相关文件，然后才开始写。真正生成代码的那部分输出，可能只占整次请求的一小部分，剩下全是输入——而输入 token 也是要钱的。
这篇讲清楚钱花在哪，以及六个我实际在用的降本做法。不是「换个便宜模型」这种废话。
一、先搞清楚计费结构
一次请求的成本由两部分组成：
| 部分 | 内容 | 特点 |
|---|---|---|
| 输入（prompt） | 系统提示 + 历史对话 + 你贴的代码 + 工具返回的内容 | 量大，容易失控 |
| 输出（completion） | 模型生成的内容 | 量小，但单价通常更高 |
关键在于两点。
输入是累加的。 多轮对话里，第五轮请求会把前四轮的全部内容重新发一遍。所以一个聊了二十轮的会话，最后几轮每次都在为前面十几轮的内容付费。
工具调用的返回值也算输入。 AI 每读一个文件、每跑一次搜索，返回的内容都会进上下文。它搜了五次没找到，这五次的结果全都计费了，而且还占着后续请求的空间。
这就是为什么「找代码」比「写代码」贵：写代码是一次性输出，找代码是反复的输入累积。
上面这张图可以对照着看：系统提示、代码注入、记忆召回、对话历史，这几块加起来就是你每次请求的输入成本。真正的生成内容只是最后那一小段。
二、六个实际做法
做法 1：明确指定文件，别让它自己找
这是性价比最高的一条。
对比一下两种问法的实际开销：
问法 A：「CreateOrder 这个函数有什么问题？」
→ 模型先搜索函数名 → 返回一堆候选 → 读文件 → 可能读错了再读一个
→ 三到五次工具调用，每次的返回都进上下文
问法 B：「@order_service.go 里的 CreateOrder，参数校验部分有什么问题」
→ 直接读指定文件 → 一次工具调用
差别可能是好几倍。我现在的习惯是能指定就指定，用 @ 引用具体文件或符号。在 wescode 里用符号引用最省事，打函数名就行，不用记文件路径。
做法 2：换话题就新开会话
前面说过输入是累加的。一个长会话的成本增长不是线性的，是接近平方的——第 N 轮要把前 N-1 轮都带上。
判断标准很简单：新问题和上一个问题不需要共享背景，就新开。 讨论完 A 模块去问 B 模块，新开一个。
我在 wescode 里是 Ctrl+Shift+L 新建会话，成本几乎为零，但省下来的可能是几千 token。
做法 3：选中代码提问，而不是贴整个文件
想问某段逻辑，选中那几十行按 Cmd+L，比把整个八百行的文件 @ 进去便宜得多。
@ 引用也支持行号范围：
@payment.go:120-180 这段的事务边界对吗
问具体问题时，范围越精确越好。别图省事整个文件扔过去——多出来的七百行你不看，但都付了钱。
做法 4：简单任务用小模型
不是所有活都需要最贵的模型。我的分配大致是：
| 任务 | 用什么 |
|---|---|
| 解释代码、格式调整、补注释 | 便宜的小模型够用 |
| 写测试、生成样板代码 | 中档模型 |
| 跨文件重构、复杂 bug 分析 | 旗舰模型 |
多数工具的模型选择器就在对话框旁边，切换是一次点击的事。养成习惯之后，日常大部分请求都能落在便宜档位上。
极端情况下可以把简单任务挪到本地模型，调用费直接归零——代价是能力弱一些，适合补全、解释这类活。
做法 5：让工具预先建好索引，而不是每次现搜
这条是结构性的，影响最大。
如果工具是靠「搜索 → 读文件 → 再搜索」来理解项目的，那么每次对话都要重新付一遍找路的钱。同一个问题问两次，第二次照样要搜一遍。
如果工具在打开项目时就把调用关系解析好存在本地，那么「谁调用了这个函数」这类问题直接查索引，不消耗 token。wescode 是后一种，代码结构在索引阶段就解析好了，对话时直接用——这部分工作不经过模型，自然不产生费用。
这个差别在大项目里特别明显。项目越大、调用关系越复杂，「找路」的成本占比越高。
做法 6：把项目约定存成记忆，别每次重复
如果你每次都要在 prompt 里写「用 errors.Wrap 不要用 fmt.Errorf」「handler 必须 Handle 开头」，这些字每次都在计费。
存成持久化的项目约定之后，就不用每次重复了。wescode 有记忆功能，我把这类规则存进去之后，日常提问能短不少。
注意记忆是按工作区隔离的——A 项目的约定在 B 项目不生效。这个设计是对的，不同项目的规范本来就不一样。
三、怎么知道自己花在哪了
光有做法不够，得能观测。
多数工具会显示单次请求的 token 用量，先养成看一眼的习惯。重点关注输入输出比：
输出 200 / 输入 15000 → 比例失衡，说明大量 token 花在喂上下文
输出 800 / 输入 3000 → 比较健康
如果经常看到第一种，说明你的提问方式需要调整——要么是会话太长，要么是引用范围太大，要么是让它自己找文件了。
另一个有用的观察点是工具调用次数。一次对话里它搜了七八次，说明它在项目里瞎转。这时候与其让它继续找，不如直接告诉它去哪个文件。
四、几个不值得做的「优化」
别为了省钱缩短问题描述。 把需求说清楚多花的那几十个 token，比它理解错了返工一轮便宜得多。该写清楚的必须写清楚——省输入的重点在于「别喂无关内容」，不是「别把话说完整」。
别过度拆分任务。 有人为了控制单次成本把一个任务拆成十次问，结果每次都要重新交代背景，总成本反而更高。一个完整的任务在一个会话里做完，通常最划算。
别只盯着单价选模型。 便宜模型如果理解不了你的需求，来回返工三轮，总成本比一次做对的贵模型还高。复杂任务用好模型是省钱，不是费钱。
五、什么情况下不用管这些
个人小项目。 一个月几块钱的调用费，花时间优化不如多写两行代码。
用包月订阅的时候。 定额付费的模式下，省 token 不直接省钱，优化的收益只体现在响应速度和不撞额度上限。
探索性工作。 你自己都不知道要什么的时候，多问几轮是必要成本，别为了省钱束手束脚。
真正值得认真优化的是这两种情况：团队规模化使用，人一多总量就上来了；以及大项目高频使用，找路成本占比高，优化空间也大。
小结
token 成本这件事，大部分人的直觉是「让它少写点」，但实际上输出只占小头。
真正的大头在输入侧：反复找文件、累积的会话历史、重复交代的项目约定。这三样对应的解法分别是——明确指定引用范围、及时新开会话、把约定持久化。
还有一层是工具层面的：项目结构是预先解析好的，还是每次现搜。这个差别在小项目上看不出来，项目一大就是数量级的区别。选工具的时候值得问一句。
最后，别把省钱当成目标本身。花两分钟把问题描述清楚，比花两分钟研究怎么省 token 划算得多。
文中的符号引用、会话隔离和项目记忆都是 wescode 里的功能，官网是 weisyn.com。你们有什么控制 AI 编程成本的办法，欢迎评论区交流。
