rtk-ai/rtk 评测

1. 基本情况

在你的 AI 编程助手和终端之间架一层"过滤器"，把命令输出压缩之后再喂给 AI。名字是 Rust Token Killer 的缩写。

痛点很具体：你让 Claude 跑一句 npm test，它可能吐出几百行，其中 99% 是"通过、通过、通过"。这几百行会一字不落地进入 AI 的上下文——既花钱，又把有限的上下文挤满。RTK 拦在中间，把这几百行压成"通过 312 个，失败 2 个"外加那 2 个的详情。

它认识 100 多个常用命令，会按命令类型分别处理：

技术上是一个 Rust 编译出来的可执行文件，零依赖，开销小于 10 毫秒——装上基本感觉不到。

装好后跑 rtk init --global，它会在 Claude Code 里装一个钩子，之后你正常敲命令，它自动接管，你不用改任何习惯。

这个项目最难得的是它的诚实。 README 里专门有一节澄清：

RTK 削掉的是你的 AI 读到的命令输出，最高 90%。这不等于账单降 90%。命令输出只是输入 token 的一部分，输入 token 又只是账单的一部分（还有输出 token）。这个折扣在每一层都会被稀释。

绝大多数项目会直接把"省 90%"印在标题上，它却主动把话说清楚。这种自我克制本身就是个质量信号。

它戳中了什么痛点

用 AI 编程助手的人都撞过同一堵墙：上下文不够用，而且花钱。 你让它跑测试、看 git 状态、翻目录，每一次的原始输出都全额进入上下文。真正有用的可能就三行，剩下几百行是噪音——但你照样为它付钱，而且它挤占了本该留给代码的空间。

它是怎么做到的

四种压缩手段：分组（把相似的归拢）、截断（留关键、砍冗余）、去重（重复日志折叠）。有公开的按命令统计：cargo test 省 91.8%、git status 省 80.8%、find 省 78.3%、grep 省 49.5%。

为什么是它赢了

这个思路不新，但它做对了三件工程上的事：一个二进制文件、零依赖、零配置。竞品往往要装 Python 环境、写配置文件、改工作流；它装完跑一句 rtk init --global 就接管了，你连命令都照旧敲。Rust 带来的 <10 毫秒开销也让"加一层代理"不再是负担。

大家在夸什么

省钱、省上下文、装了不用管。有测评的标题直接叫「一个 CLI 工具砍掉 80% 的 AI 编程账单」。

大家在骂什么 / 需要留心的

我这次检索没有找到成规模的批评——这既可能说明它确实没什么槽点，也可能说明关注它的人还不够多、用得还不够深。别把"没找到差评"当成"没有问题"。

但有两个结构性风险是可以推理出来的，你实测时该盯：

压缩必然丢信息。 它把"通过的测试折叠成一个数字"，那如果 AI 恰好需要看某个通过用例的输出呢？压缩的收益和信息损失是同一枚硬币。 这一点没有任何一篇评测量化过。
"省 90%" 和"账单降 90%"是两回事——这一点连作者自己都在 README 里主动澄清了（见上一节）。但转述它的文章标题往往只留"省 80%"。

已有的评测

	star	最近更新	定位	关键差异
rtk	79,165	2026-09-07	压缩命令输出	拦在终端和 AI 之间，100+ 命令，Rust 单文件零依赖
headroomlabs-ai/headroom	69,189	2026-09-07	压缩各种输入	工具输出、日志、文件、RAG 片段都压；有库、代理、MCP 三种形态
affaan-m/ECC	251,933	2026-09-07	全套工程流程	上下文控制只是它几十项功能之一
thedotmack/claude-mem	93,369	2026-09-07	跨会话记忆	压缩的是会话历史，不是命令输出
davila7/claude-code-templates	30,550	2026-09-07	配置 + 监控	帮你看清token 花在哪，但不替你压

这几个其实在解决不同环节的问题，容易被混为一谈，我拆开说：

你主要痛点是"跑个测试就把上下文塞满了" → 选 rtk。它在这一件事上做得最专，而且装完不用管。
你要压的不只是命令输出，还有大段 JSON、日志、检索片段 → 选 headroom。注意它的宣称比 rtk 保守得多：编程场景省 20%，JSON 场景省 60–95%。rtk 说 60–90%、headroom 说 20%，同样是压缩，差距这么大，说明两边的测量口径根本不同——这一点没有任何评测澄清过。
你的问题其实是"换会话就忘" → 那不是压缩能解决的，去看 claude-mem。
你连"钱花在哪"都还不清楚 → 先用 claude-code-templates 看一周数据，再决定要不要压。没测量就优化，是最容易白忙的。
rtk 和 headroom 可以叠加（一个管命令、一个管其他输入），但叠加之后省了多少，没人测过。

一句话：rtk 胜在专注和零摩擦，headroom 胜在覆盖面。 如果你 80% 的上下文是被 npm test 和 git diff 撑满的，rtk 更对症。

省下来的钱到底是多少（最值得验）。作者自己都在 README 里澄清"省 90% 输出 ≠ 省 90% 账单"。装之前记一周账单，装之后再记一周——这个真实数字全网没有，你测出来就是独家。
压缩会不会误伤。它把通过的测试折叠成一个数字，那 AI 需要看某个通过用例的输出时怎么办？故意制造一次"需要完整输出"的场景，看它会不会因此答错。 这是压缩类工具最本质的风险，却没人验过。
rtk 和 headroom 的口径差。两个都装，同一段任务各跑一遍，看实际 token 数。这能一次性回答上面那个"20% 还是 90%"的疑问。
中文项目上好不好使。它的压缩规则是按命令输出格式写的，中文路径、中文报错会不会让规则失效？没人验过。
卸载之后会不会留钩子。它往 Claude Code 里装了 PreToolUse 钩子，卸载干不干净值得确认。

还没有亲自试过这个工具。

客观数据来自 GitHub 接口，生成于 2026-09-07。判断部分仅供参考，动手前请以你自己的实测为准。