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