用 CLAUDE.md 压缩 Claude Code 输出成本
通过项目级规则减少 Claude Code 的冗余输出，但收益取决于工作流频率与输入成本平衡。
原始内容
Claude Code 用户每天被吃掉的 token 里，有多少是废话？ 有人做了个实验：往项目根目录放一个 9 行的 CLAUDE.md，输出 token 直降 63%。仓库叫 claude-token-efficient，两天 1900 star。 原理极其简单——Claude 默认回复充斥着 "Sure! Great question!" 开头、"I hope this helps!" 结尾、复述你的问题、给你没要求的建议、对明显错误的观点先说一句 "You're absolutely right"。这些「礼貌」全部消耗 token，信息量为零。 这 9 行就是完整的 CLAUDE.md： ``` - Think before acting. Read existing files before writing code. - Be concise in output but thorough in reasoning. - Prefer editing over rewriting whole files. - Do not re-read files you have already read. - Test your code before declaring done. - No sycophantic openers or closing fluff. - Keep solutions simple and direct. - User instructions always override this file. ``` 实测对比： → 代码 review：120 词 → 30 词（-75%） → 概念解释：180 词 → 65 词（-64%） → 纠正错误事实：55 词 → 20 词（-64%） → 信息零损失 第三方独立基准测试验证：编码任务总成本省 17.4%。最极端的 v8 配置只有 7 行规则 + 20 次工具调用预算，逼 Claude 提前规划而不是边试边改。 但作者很坦诚地指出了适用边界：这个文件本身每轮对话都会作为输入 token 加载。只有高频场景——Agent 循环、自动化流水线、日均 100+ prompt——才有净收益。偶尔聊两句反而更贵。 本质上是一个「用输入 token 换输出 token」的游戏。在配额日益紧张的 2026，这个权衡值得认真算一笔账。 https://t.co/gtLoULsJ7t
深度解析
是什么
这是一个以项目根目录 CLAUDE.md 为核心的规则仓库，目标是在 Claude Code 中压缩输出、减少重复劳动；README 称无需改代码即可使用。元数据显示语言为 Python，创建于 2026-03-30，最近提交于 2026-06-16，当前有 5988 stars。
核心设计
它通过自然语言约束模型先读文件再写、优先局部编辑、避免重复读取、测试后再结束，并删除寒暄、复述、奉承和未请求建议。仓库同时提供通用规则、coding/agents/analysis profiles，以及面向不同工具调用预算的版本化配置；本质是提示层策略，不是运行时插件或机械守门。
关键洞察
README 的词数表显示约 63% 的输出下降，但作者强调这是未控方差的方向性指标；可复现基准中，当前最小规则对不同 Claude 模型的输出 token 降幅约为 4%、12% 和 7%，更严格配置才可能接近 63%。外部三项编码挑战的 v8 配置成本较对照组低 17.4%，收益可能来自减少调试循环，而不只是少说话。
边界与风险
规则每轮都会增加输入 token，低频对话可能反而更贵；它也不能替代结构化输出、工具 schema、hooks 或测试门禁来解决解析可靠性、幻觉和架构漂移。README 还说明基准主要针对 Claude，其他模型尚未充分验证；探索式架构讨论若需要反驳与多方案，过度压缩会损失交流空间。
精选追评与案例
指出与系统提示内置指令重叠、并强调 input token 成本，是对原文最实质的边界纠错。
@chenchengpro 1. 对 Claude Code CLI 有效但有限 — Claude Code 的系统提示已内置了 "Go straight to the point"、"Keep your text output brief"等类似指令（你可以翻看本次对话的系统提示）。CLAUDE.md 中的规则与内置行为高度重叠，边际收益远低于裸 API 调用场景。 3. input token 代价被忽视
中文译文 · 机器翻译
@chenchengpro 1. 对 Claude Code CLI 有效，但效果有限——Claude Code 的系统提示里已经内置了「Go straight to the point」「Keep your text output brief」等类似指令（你可以翻看本次对话的系统提示）。CLAUDE.md 里的规则与内置行为高度重叠，边际收益远低于裸 API 调用场景。 3. input token 的代价被忽视了
给出真实踩坑：agent loop 反复读同一文件才是大头，并补充 tool call 上限的可操作做法与省一半 token 的效果。
省 token 这事我也折腾了很久，发现最大的坑不是废话——是重复读文件。 不加 "Do not re-read files" 这条的时候，Claude Code 在一个 agent loop 里会反复 cat 同一个文件三四遍。每次完整读取，几千 input token，它自己完全不觉得有问题。 后来我加了一条更狠的：给每个任务设 tool call 上限。接近上限 agent 就被迫提前规划不能边试边改，token 用量直接砍半。
把「省输出」上升到输入侧上下文管理，给出更根本的优化视角。
@chenchengpro 说到底这是 context engineering 的冰山一角。省 output token 只是第一步，真正的杠杆在 input 端——哪些文件该读、读多少、什么时候丢弃。跑 agent loop 的时候，context window 就是你的 RAM，管理它才是核心竞争力。
中文译文 · 机器翻译
@chenchengpro 说到底，这只是 context engineering（上下文工程）的冰山一角。省 output token 只是第一步，真正的杠杆在 input 端——哪些文件该读、读多少、什么时候丢弃。跑 agent loop 的时候，context window 就是你的内存（RAM），管理它才是核心竞争力。
换了个角度拆解收益来源，提醒读者真实成本在于反复的对齐沟通。
@chenchengpro Strip the token math. That 9-line file isn't saving you compute—it's encoding judgment you already paid for. The real cost isn't API calls; it's repeating the same alignment conversations every sprint.
中文译文 · 机器翻译
@chenchengpro 把 token 的账算清楚就知道：那个 9 行文件并没有替你省算力——它编码的是你早已付过费的判断力。真正的成本不是 API 调用，而是每个 sprint 都要重复一遍的那些「对齐」对话。