用 Claude Code 这类 AI 编程助手，有个问题容易被低估------终端输出太吃 Token 了。
你让它查个编译错误，它先跑 git status，再跑 ./gradlew build，单元测试再转一圈。构建工具的输出动辄几百行，进度条、警告、调试信息、重复堆栈，全被原样塞进上下文。Token 跑得快不说，模型还容易被无关信息干扰，关键报错反而淹没在日志海里。
最近试了个开源小工具 RTK（Rust Token Killer） ，专门解决这个场景。跑了快一周，说说实测情况。
核心机制：终端输出过滤，而非压缩
RTK 的定位很窄：只处理 AI 执行终端命令时的 stdout/stderr。
github上的 star数 74.2K
它在 shell 层挂一个钩子，拦截命令输出后做一轮过滤，把冗余内容砍掉再把精简结果交给 Claude Code。过滤策略是规则驱动的，不是用模型做摘要------所以没有额外 Token 开销，延迟也可以忽略不计。
具体砍掉的内容包括：
- 进度条（
[====>...]这类动态刷新行） - 连续空行和重复分隔线
- 构建工具的无信息量日志（比如 Maven 的下载进度、Gradle 的 task 列表）
- 成功路径上的冗余堆栈帧
保留的是：报错信息、测试失败用例、关键 diff、exit code 非 0 的完整上下文。
换句话说，RTK 不改变信息语义，只去掉视觉噪音。
实测数据：Token 省 60%~90%
我拿手头一个中型 Spring Boot 项目做了几组对比，场景是：
让 Claude Code 排查一个单元测试失败，执行
./gradlew test --tests *FooTest
| 指标 | 不开 RTK | 开 RTK |
|---|---|---|
| 终端输出行数 | 847 行 | 112 行 |
| 终端输出 Token 数（估算） | ~3800 | ~520 |
| 单次请求总 Token | ~5900 | ~2600 |
| 终端输出占比 | 64% | 20% |
这个场景下，终端相关 Token 减少了 86% ，总 Token 消耗降了 56% 。
其他场景也有不错表现：
git diff查看改动 → 省约 70%grep -r搜索代码 → 省约 65%（主要砍掉权限警告和二进制文件提示）./gradlew build全量构建 → 省 80% 以上（构建日志的冗余度最高）
不过要说明：省多少完全取决于你的命令输出有多"脏" 。如果本身输出就很精炼（比如 git status --short），RTK 的收益有限。反之，构建和测试命令是重灾区，收益最明显。
安装和使用
RTK 是 Rust 写的单二进制，Windows 下解压到任意目录，加进 PATH 就行。
绑定 Claude Code 只一条命令：
bash
csharp
rtk init --global --hook-only这会在 shell 配置文件里挂一个钩子，之后 Claude Code 调用的所有命令输出都会被自动过滤。重启 IDE 即生效，不需要改 Claude Code 的任何配置。
卸载同样干净：
bash
csharp
rtk init --uninstall日常用得上的命令：
bash
bash
# 看省了多少 Token（统计过滤前后的字符数对比）
rtk gain
# 关掉数据上报（默认会发匿名统计数据）
rtk telemetry disable
# 临时关闭过滤，只跑这一次
RTK_DISABLED=1 ./gradlew test优点
轻量：Rust 单二进制，启动和过滤都是毫秒级，对终端响应速度没有可感知的影响。
侵入性极低：不改 IDE 配置，不改 AI 使用方式，绑上就生效，拆了就恢复。
过滤策略克制：我测了大概四五十个命令，没有出现误删关键报错的情况。开发者刻意只做"保守过滤"，拿不准的内容会放行而不是截断。
省 Token 效果直接：对于构建、测试、git 这类输出密集的操作，收益非常稳定。
局限性（必须说清楚）
只管终端输出，不管文件读取
Claude Code 的 read_file、glob 搜索、项目目录扫描等操作不走终端，RTK 碰不到。这部分日志消耗得靠 .claudeignore 自己控制。
深度调试时可能需要关掉
极少数情况------比如排查 Gradle 插件本身的 Bug，或者分析构建性能------精简后的输出可能丢失时序细节。这时候 RTK_DISABLED=1 临时绕过即可，不算大问题。
不是通用的 Token 节约方案
RTK 只解决"终端输出"这一个点。如果你主要的 Token 消耗在代码上下文、对话历史、文件读取上，它帮不了你。但它解决的问题恰恰是很多用户容易忽视的一块。
适合什么场景
如果你符合以下几条，RTK 值得一试：
- 重度使用 Claude Code、Cursor 或类似 AI IDE
- 经常让 AI 跑构建、测试、Git 操作
- 注意到终端日志经常出现在对话上下文中，占用比例不低
- 不想改变现有工作流，希望"装上就见效"
反之，如果平时只让 AI 做代码补全和文件读写，很少执行终端命令，这工具对你意义不大。
总结
RTK 是一个定位极其明确的小工具：只干一件事，把终端输出的水分挤掉。
它没有野心去解决所有 Token 浪费问题，也不试图用 AI 做日志摘要（那反而增加开销）。就是一套规则过滤，简单直接。
实测下来效果扎实，接入成本几乎为零，也没有引入新的问题。对于被 Claude Code 终端日志吃掉大量 Token 的用户，装上就能看到账单变化------或者说，额度更耐用了。