圣狗子1. 先弄明白Token是怎么被“吃”掉的：计费逻辑与消耗路径
我最早用CodeArts Agent的时候，根本不在乎Token。反正平台送了配额，写代码嘛，能有多费？结果一个月还没过半，配额就见了底，后续每次对话都提示用量不足，项目正写到关键处，AI助手直接“罢工”，那个难受劲儿我现在还记得。
后来我才意识到，想要省钱，第一步不是学提示词技巧，而是搞清楚Token到底消耗在哪儿。
1.1 Token的本质：不是“字数”，而是“分词块”
很多人有个误区，以为Token就是汉字数量，一个汉字等于一个Token。实际上Token是模型处理文本的基本单位，它是把输入内容按某种算法切分后得到的一个个小片段。对中文来说，一个汉字大概对应1到2个Token，一段没有换行的长代码可能被打包成更少的Token，而英文单词可能一个词被拆成两三个Token。
举个例子，你贴进去一段200行的Java代码，看起来不长，但实际消耗的Token可能远超你的直觉。因为这段代码会作为“输入Token”被完整编码一次，然后模型在生成回答时，你看到的回复又是“输出Token”。这两个方向都要计费。
关键来了：CodeArts Agent这类工具，它在和你对话的过程中，不止处理你当前发的那句话，它还要把历史对话记录一并喂给模型。因为模型没有记忆，每次回答都等于“重新看一遍所有聊天记录再作答”。
1.2 一次对话到底消耗了多少Token
我做个拆解你就明白了。假设你打开一个新会话，发了这么一句话：
“帮我写一个Java方法，解析这个JSON字符串，提取name字段。”
这条输入很短，可能只消耗几十个Token。但助手为了回答你，会生成一段代码，输出可能一两百个Token。看起来不多对吧？可是如果你的会话里已经聊了20轮，每一轮都贴过代码片段，第21轮你只是问了一句“这个字段为什么要判空”，模型实际接收的输入是：
前20轮所有你发的内容 + 前20轮所有助手的回复 + 第21轮你的提问
这加起来，可能已经累积到几万Token了。而你这一问，消耗的就是几万Token，不是几十。
这就解释了为什么很多人的感受是“会话用着用着就变贵了，而且越到后面越贵”。不是平台改了计费规则，是同一会话内的历史上下文在滚雪球。
1.3 哪些操作最容易烧Token
从我日常使用的经验来看，下面这几类操作属于Token消耗大户，需要特别留意：
- 整文件粘贴：把几百行代码一次性贴进对话框，让AI分析或修改。读代码本身就是高消耗，改完输出又是高消耗。
- 反复让AI重写：“不对，换个实现方式”“还是不行，再改改”“你改成另一种写法”，每重写一次，AI要把之前所有代码和对话重新读一遍，再重新生成一遍，双重消耗。
- 长会话不清理：一个会话从早上用到晚上，什么任务都往里塞。上下文越来越长，后面每一轮都在为前面所有的内容付费。
- 一边写代码一边让AI纠正：不是一次性说清需求，而是让AI猜一步、你纠一步，来来回回好几轮。
理解了这个逻辑，你会发现省钱的核心思路其实就一句话：减少模型需要“重新阅读”的内容量，减少来回试探的轮次。 下面几个章节，全是围绕这句话展开的实操方法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 提示词层面的省钱术：把需求一次说清楚，比什么技巧都管用
我观察了一个现象：同样是让CodeArts Agent干活，有人一句话就能让AI给出可用的结果，有人来回折腾七八轮还不对。前者花几百Token，后者花几万Token。差别主要在提示词上。
2.1 上下文要“切片”，不要“整块”
很多人让AI看代码，习惯把整个文件直接甩过去。文件短还行，文件长了就是灾难。
我之前负责一个老项目的改造，一个Service类有两千多行。最初我直接把整个文件贴给Agent，让它帮我找出所有未捕获的异常。结果对话还没开始，上下文已经塞进去五六千个Token。AI倒是看完了，但回复质量并不好——因为代码太长，它重点被分散了，遗漏了好几个关键点。
后来我换了个方式：先自己定位到相关的几个方法，只把这几个方法摘出来给Agent看，再配上说明“这是xxService里的方法A和方法B，帮我检查异常处理”。效果立刻不一样，回复更精准，消耗的Token少了七八成。
贴代码前先问自己三个问题：
- 这段代码里，和我要做的事真正相关的部分是哪几行？
- 能不能只贴核心方法、关键类，去掉无关的getter/setter和依赖？
- 如果必须看整个文件，能不能用一句话描述文件全貌，再单独贴关键片段？
尤其