我是谁 & 遇到什么问题
做了4年Java后端，日常就是CRUD加偶尔写点中间件。7月初开始重度用TraeWork，那会儿对积分消耗完全没概念——写个代码审查脚本一口气丢进去几千Token，改个Bug跟AI对话七八轮，月底一看账单直接傻眼：日均消耗3200+积分，按这个速度一个月得48000。
后来花了三周时间摸索出一套"Token省钱"的工作方式，到7月底日均消耗稳定在1100左右。这篇把最核心的5个习惯分享出来，都是实打实跑出来的数据。
习惯1：别一上来就把整个项目丢给AI
这个坑我踩了整整一周。每次让AI帮忙看代码，习惯性地把整个模块的文件全打开，结果光读取上下文就吃掉好几百Token。
后来改成：先自己想清楚要改哪几个文件，只打开相关的代码片段，用一句话描述上下文背景。光这一步，单次操作就能省下200-300个Token。
习惯2：模型分级，别什么都用最贵的
简单任务（格式化代码、写个注释、生成getter/setter）用Doubao-Seed-Code就够了。复杂的业务逻辑重构、架构设计才上GLM 5.2。
我后来养成了一个习惯：每次提问前先想1秒——这个任务复杂度值不值得用好模型。大部分日常操作其实用基础模型就行，省下来的积分留给真正需要深度思考的场景。
习惯3：结构化Prompt，一次说清楚需求
跟AI对话越来回，Token消耗越高。如果需求说得模模糊糊，来回改三四轮，消耗的积分是"一次性说清楚"的三四倍。
我现在的Prompt模板：
- 目标：做什么（一句话）
- 上下文：用的什么框架、什么版本、什么场景
- 约束：性能要求、代码风格、不能动的地方
- 输出格式：期望什么格式返回
这样AI基本一次就能给出接近预期的结果。平均对话轮数从3.5轮降到了1.8轮。
习惯4：批量处理 > 逐个操作
TraeWork支持多文件编辑的时候，别一个文件一个文件地改。我会先把所有需要改的文件和改动规则列出来，一次性让它批量处理。
虽然单次消耗的Token看起来多，但比起逐个文件分别操作的总消耗，批量处理能省大约40%。因为每次新对话都要重新加载上下文，这个开销其实很大。
习惯5：定期清理工作区上下文
长时间用TraeWork之后，工作区会积累很多临时文件和缓存，这些都会影响上下文窗口的大小。
我每天下班前会花2分钟清理一下：关掉不需要的标签页、清除临时输出文件。第二天启动的时候上下文窗口是干净的，Token消耗也会低一些。
效果数据
| 指标 | 7月初 | 7月底 | 变化 |
|---|---|---|---|
| 日均Token消耗 | 3200 | 1100 | -65.6% |
| 月度积分消耗 | ~48000 | ~17000 | -64.6% |
| 平均对话轮数 | 3.5轮 | 1.8轮 | -48.6% |
关键产出没下降，代码审查效率反而提升了——因为每次对话的质量更高了。
经验总结
说到底就一句话：不是少用，是精用。
- 把上下文喂饱比堆文件数量重要
- 选对模型能省一半积分
- 一次说清楚需求是最便宜的Token用法
- 批量处理永远比逐个操作划算
- 定期清理工作区，保持上下文轻量
希望对大家有帮助，有更好的一起交流。