⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/ClaudeCodeCodex-chengbenbaojiang-80deshenjikaiyuangongjuzhihaolewodeTokenjiaolv/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

一下午烧 6000 万 token，凶手不是代码

上周用 Claude Code 重构 https://github.com/YunaiV/yudao-cloud 的某个核心模块——把 OAuth 单元的依赖整理一遍、加几个新接口、跑一轮全量测试，干了整整一下午。代码改了、测试过了、Git 提交也做了，一切都很顺。

心情正美，顺手看了一眼 Token 用量——直接傻眼：一个下午烧了 6000 多万 Token，套餐余额直接告急。

明明只改了几十个文件，怎么耗了这么多？翻了一遍对话历史才发现：真正的”凶手”根本不是我写的代码，而是那些命令输出：

mvn clean install -pl yudao-module-system 跑一次，依赖下载 + 编译输出几百行；
mvn test -pl yudao-module-system 跑完，几百个用例全是绿字；
git status 列出一堆 untracked 文件 + 改动文件；
kubectl logs 拉一段 Pod 日志，红框堆栈 + 中间一堆心跳。

这些内容全被原封不动塞进了 LLM 的上下文窗口。

AI 真正需要的信息可能只有 5%，剩下 95% 都是日志噪音。

如果你也遇到过类似问题，那 RTK（Rust Token Killer） 这个工具值得你花三分钟了解一下。仓库地址：github.com/rtk-ai/rtk，截至 2026 年 5 月 GitHub Star 已经 41k+。

提前说一下边界——RTK 本质是 trade-off：用更少的上下文换更低的成本。大多数场景被压掉的是噪音，对结果影响很小；极少数需要完整上下文的场景（比如复杂调试），可能要手动查看原始输出。

它解决的不是「AI 太贵」，是「AI 看的 95% 都是日志噪音」

很多文章吹 RTK 时强调它”省钱”。省钱只是结果，不是原因。

RTK 的反向定位很清楚——它不让你「少用 AI」，是让 AI「少看不该看的」。

RTK 是一个用 Rust 写的 CLI 代理工具，专为 AI 编程助手设计。它的定位很明确：在命令输出到达 LLM 之前做一轮智能压缩——把噪音去掉，只留信号。

设计哲学一句话：

你照常用 Claude Code、照常执行命令，只是 token 消耗悄悄降下来了。

技术细节也对得起 Rust：启动延迟 < 10ms、内存占用 < 5MB、单一二进制文件、零依赖。几乎不会成为工作流负担。

官方 README 列出的支持工具清单（截至本文发稿）：

Claude Code、GitHub Copilot（VS Code + CLI）、Cursor、Gemini CLI、Codex、Windsurf、Cline / Roo Code、OpenCode、OpenClaw、Kilo Code、Google Antigravity、Mistral Vibe（planned）

——基本覆盖主流选择。

4 层压缩策略，每层针对一类噪音（来自官方 README）

RTK 的核心能力是 4 种压缩策略——这 4 个名字全部来自官方 README，每种针对不同类型的命令输出，组合使用。

策略 1：Smart Filtering（智能过滤）

官方原话：Eliminates unnecessary content like comments, excess whitespace, and boilerplate.

终端输出里有大量给人类看的装饰物——LLM 完全用不上：

ANSI 颜色码（mvn install 的绿色 BUILD SUCCESS、红色报错）；
进度条和旋转光标；
多余空行和装饰性分隔线。

举例：git push 原始输出 15 行约 200 Token（远程仓库信息、对象计数、压缩进度），RTK 过滤后只剩一行 ok main，约 10 Token。

ruoyi-vue-pro 实战体验：跑完 mvn deploy 那 200 多行的输出，RTK 直接精简到只剩两条关键信息——「BUILD SUCCESS」+「部署到 Nexus 的 URL」。

策略 2：Grouping（分组聚合）

官方原话：Consolidates similar items (organizing files by directory, errors by category).

输出大量同类信息时，按目录或类型分组聚合。

举例：ls -la 列出 100 个文件，原始输出 100 行——RTK 会变成「yudao-module-system/ 目录下 45 个 .java 文件 + 12 个 .xml 文件」。实测 ls / tree 类命令：2000 → 400 Token，省 80%。

yudao-cloud 实战体验：让 AI 看一眼 microservices 整体目录结构，以前 1500 Token 的目录树现在只要 200 Token。

策略 3：Truncation（截断保留）

官方原话：Preserves relevant context while cutting redundant information.

测试命令是 Token 浪费的重灾区。ruoyi-vue-pro 跑一次 mvn test，几百个 case 全通过——每个 case 一行 Tests run: 1 Failures: 0 Errors: 0 Skipped: 0，加起来上千 Token，对 AI 毫无价值。

RTK 的做法：保留失败的 case 详情和错误堆栈，通过的只显示一行摘要——Tests passed: 487。实测 mvn test / npm test：25000 → 2500 Token，省 90%。

关键细节：RTK 的截断策略优先保留尾部输出——大部分构建和测试工具习惯把错误信息放在最后，保尾部 = 更大概率保留真正有用的诊断信息。

策略 4：Deduplication（去重合并）

官方原话：Collapses repeated log lines and replaces them with occurrence counts.

构建日志里反复出现的「Compiling…」、容器日志里统一格式的时间戳前缀——这些重复模式会被 RTK 识别并合并。

举例：mvn clean install 跑 yudao-cloud 多模块构建时，输出几十行类似 [INFO] Building yudao-module-xxx 0.0.1——RTK 压缩成一行「Built 22 modules」。Kubernetes 的 Pod 启动日志里那种「连接数据库 / 注册 Nacos / 启动监听端口」三连重复，也能被合并到一行。

Auto-Rewrite Hook：透明拦截，不入侵主循环

你可能会问：RTK 是怎么拦截命令输出的？要改 Claude Code 的代码吗？

不需要。RTK 的核心技术是 Auto-Rewrite Hook——利用 Claude Code 等工具提供的 Hook 机制（通常是 PreToolUse hook），在命令执行完毕后、输出喂给 LLM 之前，透明地拦截并重写输出。

流程：

你让 AI 执行 npm test
   ↓
AI 通过 Bash 工具执行命令，拿到完整输出
   ↓
Hook 触发，RTK 接管这段输出
   ↓
RTK 应用压缩策略，生成精简版本
   ↓
精简版本喂给 LLM；原始输出仍在你的终端里显示

对 Claude Code 来说，它完全不知道输出被改过——只知道命令执行完了、结果是这些。对用户来说，原始输出仍然显示在你的终端里，不会丢失任何信息。

这个设计很关键——RTK 不入侵主循环、不改工具链代码、不改变使用习惯。它就像一个翻译器：把给人看的长篇大论变成给 AI 看的精简摘要。

如果 AI 真需要完整输出怎么办？

RTK 用 tee 机制解决——原始输出被压缩后并未丢弃，而是通过 tee 管道保存在临时位置。AI 确实需要查看完整输出时（比如调试一个奇怪的测试失败），可以通过特定命令调取原始版本。

就像快递打包——把大箱子换成小箱子节省运费，但大箱子还寄存在快递站，随时能取回。

省了多少？算一笔账

换算成钱（以 Claude Sonnet 4.7 定价为例：输入 $3/M、输出 $15/M）：

一次 30 分钟会话压缩前 ~118K token，压缩后 ~23.9K token，省 ~94K；
按混合定价粗算，一次会话省 $0.3-0.5；
一天开 5 个会话，一个月省 $45-75；
用 Opus 或更贵的模型，这个数字翻几倍。

有用户反馈在 Claude Code 上累计节省了 10M token（89%）。

RTK 提供两个命令查看节省：

rtk gain          # 查看累计节省
rtk gain --graph  # 30 天趋势图

rtk discover 还能分析你过去一段时间的命令历史，给出哪些命令消耗最多 token、哪些命令有最大压缩空间的洞察报告。

30 秒装好

两种方式任选：

brew install rtk

或者：

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

执行一次初始化（按你用的 AI 工具选择）：

# Claude Code
rtk init -g

# Cursor
rtk init -g --agent cursor

# Codex
rtk init -g --codex

# Windsurf
rtk init --agent windsurf

-g 表示全局配置——之后你在任何目录启动 AI 编程工具，RTK 都会自动接管命令输出。

重启 AI 编程工具就生效，整个过程不超过 30 秒。

卸载也是一行：

rtk init -g --uninstall

横向对比：和其他省 token 方案的差别

这几个方案不冲突，可以叠加使用。我的建议：

终端命令密集型工作（测试 / 构建 / Git 频繁）→ RTK 或 tokf 是首选；
大型项目文件多，AI 经常读不相关文件 → 配 .claudeignore；
上下文窗口快满 → 开 Compact Mode。

RTK vs tokf：RTK 胜在支持工具更多（12 款 vs tokf 的几款），且提供 rtk gain 和 rtk discover 等分析工具；tokf 更轻量。两者都试，选自己顺手的。

适用场景与局限

✅ 适合：

重度使用 Claude Code / Cursor / Codex；
频繁执行测试 / 构建 / Git 操作；
Token 消耗是真实痛点（成本或 context 上限）。

❌ 不太需要：

偶尔用 AI 写点代码、token 消耗本来就低；
主要用 AI 做代码解释 / 文档生成，很少执行命令；
已通过其他方式把 token 控制在合理范围。

⚠️ 局限：

压缩本质是删减——有概率删掉 AI 真正需要的信息，比如调试偶发测试失败时 AI 可能需要看完整输出；
对于非标准格式 / 自定义脚本输出，RTK 内置规则可能覆盖不到，压缩效果打折扣。

不过说实话，这个风险和省下来的成本比，我觉得是可以接受的。误删关键信息的次数屈指可数，大部分时候压缩后的输出对 AI 来说够用了。

我的判断

RTK 解决的问题很小众但很真实：AI 编程助手的 token 消耗，很大一部分被命令输出噪音吃掉了。

它的价值在三个字：

省——80-90% token 节省，按当前模型定价回本很快；
稳——单一二进制 + 零依赖 + < 10ms 启动，不影响原工作流；
透——透明 Hook 拦截，不入侵主循环、不改工具链。

如果你是 AI 编程工具的重度用户，30 秒装一下 RTK，余额会感谢你。

项目地址：github.com/rtk-ai/rtk

芋道源码 —— 纯源码解析博客

Claude Code / Codex / Cursor 成本爆降 80%！