这也太反常识了吧！GitHub 做了个省 Token 的实验，结果有些输出压短之后，整个任务反而更费 Token、跑得更久了。
这就有点尴尬了。
他们前几天测试了一个叫 RTK 的工具，把命令输出压短，再交给 Copilot 读取。
少读一点，单次消耗确实可以降下来。但有些被删掉的内容，AI 后面做任务还要用。
怎么办？重新打开完整输出，或者把命令再跑一遍。
这一来一回，多了调用轮次，还要继续带着上下文。按他们这次测试的配置，任务平均消耗的 Token 更多，耗时也更长。
当然，这个结果有范围，不能直接说 RTK 在所有场景都没用。
GitHub 自己做压缩也遇到过类似问题：早期把 `git diff` 压得太狠，AI 又跑回去读原始内容，后来就取消了这项过滤。
所以他们最终保留源码、代码差异等内容，重点压缩安装、构建、测试输出里的重复信息。
所以说，折腾省额度方案的时候，得把一个任务从头到尾跑完再算账。
只看某次输出少了多少 Token，很容易高兴早了。后面为了找回那点信息多跑几轮，省下来的可能还不够补。
尤其是改代码，哪些地方改过、为什么报错，往往就藏在那些看起来很长的输出里。清理之前，至少得知道删掉的是什么。
我们需要更关心这几个结果：任务做对了没有，总共花了多少，等了多久，中间有没有反复找同一份资料。
想试省 Token 的工具，可以挑几个常做的任务，开着跑一次，关掉再跑一次，看看完整结果。一次结果可能有偶然性，有差异就多试几回。
能少花钱、少等待，还能把活做好，那才值得留在自己的工作流里。别把单次输出压得漂漂亮亮，最后让 AI 来回补课，自己坐旁边干等。
