这几天大家因为TRAE的付费机制改革，导致更多的人关心积分(核心本质是Token)的消耗，恰好官方也发布了 节省积分、爽用 Work 技巧 的活动，接下来我就来以四个方面分享一下我在日常使用时如何更加合理的减少不必要的Token浪费！
其一：上下文的控制
在单对话过程中，上下文的占用其实是影响Token消耗和缓存命中的核心问题，这一点就要涉及到大模型的“记忆”概念了，我们在与大模型对话的过程中，其实大模型并没有我们人类理解的“记忆”概念，而是你每一次的提示词发送时，内部都会把之前的对话内容总结成核心的话连同提示词一起传给大模型，这样大模型才会拥有上下文“记忆”，但是也正是因为这个机制，导致一个任务对话轮数过多的时候，每一次新提示词就要把之前所有的对话内容都总结传给大模型，无形之中造成了很多Token浪费。
合理的做法是将一个复杂任务人为拆解，降低每个对话任务的对话轮次，这样可以有效的规避浪费，并且也可以规避轮次过多导致的上下文压缩次数过多，造成的“压缩碎片”问题(即压缩次数多了之后，关键内容可能在压缩中丢失，导致最后形成的上下文“记忆”碎片化，不成逻辑与体系，这也是轮数过多感到大模型降智的原因，因为大模型已经不懂之前干了什么)
其二：Skill&插件的合理开启与关闭
Skill作为大家日常办公和编程的得力助手，许多伙伴都添加了很多Skill，其实很多Skill可能只用过一次，但是用完没有关闭和删除，如果有了解Skill机制(渐进式披露机制)的伙伴，可能知道Skill在安装之后即使没有被大模型调用，Skill的yaml内容也会被加载在上下文中！(也就是说，如果你安装了很多Skill，即使你的提示词和任务不会用到Skill，Skill的yaml内容会被强制进入上下文中，耗费更多的Token！)
在TraeWork中插件的本质其实也是Skill，如下图所示！
合理的做法就是将长期不用的Skill和插件暂时关闭或直接卸载！
其三：选择合适的模型，而不是无脑顶配
目前TraeWork内置的模型中，根据模型的价格和强度分配了不同档次的积分倍率，但是一个项目并不是一个模型走到底，而且让合适的模型做合适的任务，在单个任务对话中，根据任务需求合理选择模型，例如在文档撰写类工作选择擅长文本处理的kimi-k2.6，qwen系列等；面对高复杂任务可以选择GLM系列和Kimi-K3、Kimi-K2.7-Code等；面对综合性任务可以使用seed系列模型和Minimax系列等(模型选择仅个人见解，不代表标准答案！)
模型擅长的任务虽然部分模型供应商提供过相关信息，但是因任务的复杂度和种种情况，每个人的体感是不一样的，这一点需要自己去慢慢体会区别，找到最适合自己的办公&编码任务的模型分类。
其四：在同一个任务对话中，不要频繁切换模型！！！
之所以这样说主要是因为，每个模型对同一套上下文的认知和理解不一样，最适合的配队就是原模型产出的上下文交给原模型处理。(乍一看和第三项冲突，但实际上我们结合第一项就可以了解到，讲一个复杂任务合理拆分之后，每个子任务再根据特点选择合适的模型，而在每个任务期间尽量不要频繁切换模型)
举个例子，比如在一个任务对话中，使用A模型产出了一部分上下文内容，这时如果切换为B模型进行后续开发，之前的上下文回滚到B模型的提示词内(原因在其一)，A模型产出的上下文内容，B模型不一定正确的理解和解读，可能造成需求的理解和执行结果出现偏差！
上述的四种方法就是一直以来我感觉能够有效节约Token的方法~希望对伙伴们有帮助~