把一个 9 行左右的 CLAUDE.md 扔到项目根目录里，Claude 的输出就能压缩 63%。听起来像 prompt 圈子常见的夸张标题，但这次我觉得值得认真看一眼。
原因很简单：这个项目讲的不是“让模型变聪明”，而是“别让模型把 token 浪费在废话上”。
我看到一条中文推文时，最有感觉的一句不是“下降 63%”，而是最后那个判断：
本质上，这是一个“用输入 token 换输出 token”的游戏。
这句话很准。它也刚好概括了 claude-token-efficient 这个仓库真正有价值的地方。
先看结果
这个仓库在 README 里给了一组很直接的对比。
同样 5 个提示词，不加 CLAUDE.md 时，输出总字数是 465；加上之后变成 170，整体下降约 63%。其中最夸张的一项是代码 review，从 120 个词压到 30 个词，下降 75%。
更有意思的是，它没有停在“字数变短”这个层面。README 还引用了一组独立 benchmark：3 个 coding challenge，所有配置都能通过测试，比较的只有到达“测试全绿”所花的钱。结果是 v8 配置从 $1.131 降到 $0.935，总成本下降 17.4%。
这两个数字放在一起，意思就明确了：
- 这不是在证明模型更强。
- 这是在证明输出习惯可以影响真实成本。
- 如果你的工作流里本来就有很多轮输出，省下来的不是“观感”，而是真金白银。
它到底做了什么？
如果你点开这个仓库，查看具体内容，我相信你的第一反应是——就这？
这个项目并没有发明什么复杂的 agent 框架，也没有引入新的工具链。
但是，这个仓库在短短的 3 天时间里面，竟然拿到了高达 2.2k 的 star。由此可见如此简单的一件事儿，有多少人是机器需要的！
它只是把一组“高频但低价值的默认行为”写进规则文件，让 Claude 在每轮对话里少做几件事：
- 少说开场白，比如
Sure!、Great question! - 少说结尾客套，比如
I hope this helps! - 不复述用户刚说过的话
- 不主动给没被要求的建议
- 不在明显错误的观点前面先来一句“你完全正确”
- 写代码前先读文件，改代码时尽量局部修改，结束前记得验证
图片里的中文总结，其实已经把精髓说透了：这些“礼貌”在聊天里也许不碍事，但在高频 coding workflow 里，全都在烧 token，而且几乎不增加信息量。
README 里最诚实的一点，是它没有把这件事包装成玄学。它直接承认：
规则文件本身会在每轮对话都进入上下文，因此它不是无成本的。
所以这件事不是“白拿收益”，而是一次很工程化的预算重分配。
为什么这招会有效
如果你每天只问模型两三个问题，这种做法可能没什么意义。
但如果你的场景是下面这些，情况就不一样了：
- agent loop
- 自动化流水线
- 一天几十到几百轮的重复 coding 任务
- 大量 code review、解释、修 bug、生成结构化输出
在这些场景里，真正贵的不是那几个输入规则，而是模型每一轮都在稳定重复的输出冗余。
开场寒暄一句，结尾客套一句，先复述你的问题，再补一段你没要的建议。单轮看起来没多少，但一旦进入批量调用，它们会变成稳定的成本项。
这也是为什么这个项目强调“规则要短”。因为你在做的，不是往上下文里继续塞偏好，而是在计算一个非常现实的账：
每轮多输入几十个 token，能不能换来每轮少输出上百个 token？
只要答案是“能，而且会持续发生”，这个策略就成立。
但它不是通用解药
我反而觉得，这个仓库最值得学的地方，是它把适用边界写得很清楚。
README 明确说了，下面这些情况不太值得用：
- 单次短对话
- 偶发的一次性聊天
- 需要大量探索和发散讨论的任务
- 依赖严格可解析输出的系统
- 每个任务都开一个全新 session 的流水线
原因并不复杂。
第一，低频时，规则文件的输入开销未必能靠输出缩减赚回来。
第二，很多探索型工作本来就需要模型展开讲、提出备选方案、做权衡。如果你把它压得过于简短，省下来的可能不是废话，而是有用的思考过程。
第三，如果你追求的是“绝对稳定、绝对可解析”，那应该优先用结构化输出、schema 和工具调用，而不是指望 prompt 约束永远听话。
所以这套方法的正确定位不是“万能优化”，而是：
当你的主要问题是冗余输出时，它很好用；当你的主要问题是正确性、稳定性和复杂推理时，它不是主解法。
真正有启发的地方
那 9 行规则提醒了我们一件很容易被忽略的事：模型成本不只取决于你问什么，也取决于你允许它怎么回答。
很多团队在优化 LLM 成本时，会盯着模型价格、上下文窗口、RAG 命中率、缓存命中率这些“大头”。这些当然重要。
但输出风格其实也是成本控制的一部分，而且是最容易被忽略的那一部分。
尤其是写代码这种任务，很多默认语言习惯根本不创造价值：
- “这是一个很棒的问题”
- “你说得很对”
- “另外我建议你顺手再重构一下”
- “希望这些内容对你有帮助”
它们在人类对话里可能是润滑剂，在自动化工作流里却更像噪音。
如果你的系统本来就追求短、稳、可预测，那这些噪音越早被消掉越好。
我会怎么做
我不会把这个仓库原封不动地当“圣经”抄过去，但我会照着它的思路做三件事。
第一，把通用偏好写得极短。
比如：
- Think before acting. Read existing files before writing code.
- Be concise in output but thorough in reasoning.
- Prefer editing over rewriting whole files.
- Test before declaring done.
- No sycophantic openers or closing fluff.
第二，只写自己真实遇到过的失败模式。
如果模型经常不读文件就开始改，那就写“先读再写”。如果模型经常乱提需求外建议，那就明确禁止。不要为了“看起来完整”塞一堆泛化规则，因为每一条都会变成长期输入成本。
第三，按层级拆分规则，而不是把所有要求都塞进一个文件。
这个项目在 README 里提到，CLAUDE.md 可以有全局、项目、子目录多个层级。我很认同这个思路：
- 全局层放表达风格和通用偏好
- 项目层放安全边界和仓库约束
- 子目录层放局部任务的特殊规则
这样既能保持规则短，也能把约束放在最需要它们的地方。
一点想法
claude-token-efficient 的价值，不在于那组 63% 的 headline，也不在于“9 行规则”这种传播友好的包装。
它真正提醒我们的，是一个更实在的工程问题：
你是不是正在用昂贵的输出 token，购买一堆自己其实并不需要的礼貌、复述和自我发挥？
如果你的答案是“是，而且量很大”，那这种做法值得认真试一次。
如果你的答案是“不是，我本来就只偶尔问几句”，那它大概率不会替你省钱。
说到底，这不是魔法，也不是 prompt 黑科技。
它只是一次很朴素的成本优化：把该省的废话先省掉，再把预算留给真正有信息量的回答。
