一份 CLAUDE.md，真能让 AI 少说废话吗？GitHub 上这个小项目戳中了生成式 AI 的老毛病
AI 不贵在思考，贵在碎碎念
最近 GitHub 上有个项目火得很像一个段子：不给模型升级参数，不接入新 API，不改代码逻辑，只往项目里塞一个 CLAUDE.md，就声称能把 Claude 的输出 token 压下去大约 63%。项目名也很直白，叫 claude-token-efficient。它的卖点几乎带着点“反 AI 套话”的情绪：别再说“Great question!”、别再复述问题、别再在结尾加“希望这对你有帮助”，更别动不动就端出一套过度设计的抽象代码。
这件事之所以有趣，不是因为它有多复杂，恰恰是因为它太朴素了。今天的大模型应用行业，一边在卷更长上下文、更强推理、更复杂 agent，一边又被用户吐槽“废话太多”“格式太花”“过分迎合”。很多团队花大钱做 AI 自动化，最后卡住流程的，不一定是模型不会做事，而是模型太爱表现自己。它像一个热情过度的实习生，你问一句“这段循环有 bug 吗”，它先夸你代码写得认真，再给你一段人生建议，最后才告诉你 <= 写错了。
claude-token-efficient针对的，就是这种“低级但高频”的烦人体验。项目作者 Drona Gangarapu 的思路很明确：既然 Claude Code 会自动读取项目根目录里的 CLAUDE.md，那就把一套行为规则预先塞进去，让模型默认变得更克制、更干脆、更像一个工具，而不是一个不停点头寒暄的客服。
它不是省钱神器，更像“去油腻补丁”
从项目给出的 benchmark 看，同样几组问题，加入这份 CLAUDE.md 后，解释 async/await 的回答从 180 个词降到 65 个词，代码 review 从 120 个词压到 30 个词，总体输出字数减少约 63%。看上去很唬人，但项目自己倒是挺诚实：这不是严格统计学意义上的实验，没有做重复跑、没有控制方差，更多是一个“方向性信号”。
更关键的是，作者没有把它包装成“成本核武器”。他反而反复提醒用户，AI 成本的大头很多时候在输入 token，不在输出 token。CLAUDE.md 本身每轮对话都要占用上下文，所以如果你只是偶尔问几个短问题，它可能反而更费 token。真正适合它的，是那种高频、批量、结构化输出的场景，比如自动化流水线、简历筛选 bot、多轮 agent 循环、代码生成和审查这些重复劳动。
这一点我很认同。过去一年，提示词工程有个常见误区：动不动就宣传“一个 prompt 提升 80% 效率”。但现实是，大模型优化从来不是玄学，它讲究投入产出比。一个额外的上下文文件，到底值不值，取决于你是不是每天要跑几百上千次同类任务。对企业团队来说，这种账很好算；对个人用户来说，很多时候你省下的不是钱，而是耐心。
说白了，这个项目真正解决的，可能不是“钱包疼”，而是“眼睛疼”。那种被套话、格式噪音和无关建议塞满的回答，会迅速稀释有效信息密度。你不是看不懂，而是不想看。AI 输出像白开水兑了三遍，杯子很满，信息却很淡。
它其实暴露了一个更大的行业问题：模型默认人格，正在影响生产力
这个项目最值得玩味的地方，在于它并不是在修一个 bug，而是在对抗一种产品哲学。今天主流大模型普遍被训练得“友好”“积极”“不冒犯”，这当然有商业和安全上的合理性。但副作用也越来越明显：模型容易过度谄媚，容易先认同再纠正，容易在不确定时绕着说，甚至把“像人类交流”误解成“像话多的人类交流”。
Anthropic 的 Claude、OpenAI 的 ChatGPT、Google 的 Gemini，在不同阶段都被用户抱怨过类似问题。有人嫌它们太会道歉，有人嫌它们总爱总结，还有人嫌它们动不动就补充一堆没被要求的背景知识。对普通聊天用户来说，这也许只是风格问题；但在开发、数据处理、自动化调用这些严肃场景里，风格会直接变成成本、稳定性和可解析性的问题。
claude-token-efficient里最“工程师思维”的部分，不是简洁本身，而是那套具体约束：禁止复述问题，禁止 Unicode 花活，禁止“作为一个 AI”，禁止没必要的免责声明，不知道就直接说不知道，不要重复读取同一个文件，不要碰请求范围之外的代码。这些规则听起来像在训模型，其实更像在定义一个更适合机器协作的协议。
这也是为什么它会引起开发者共鸣。大家越来越发现，所谓 AI 编程助手的竞争，已经不只是“会不会写代码”，而是“能不能少添乱”。能生成一段函数不难，难的是生成恰到好处的函数，不自作聪明，不顺手改一串别的文件，不把一个 if 判断升级成三层抽象工厂。很多团队现在防的，不是模型太笨，而是模型太积极。
一份提示词文件的边界，也很清楚
当然，这个项目并不是银弹。作者自己说得很清楚：如果你要解决的是幻觉、架构跑偏、复杂任务下的失控，这种基于提示词的约束远远不够。你还是得上更硬的机制，比如 schema、JSON 输出、工具调用、校验器、hook、审批闸门。这些才是企业级可靠性的基础设施。
这里有个很现实的分界线：当你只是想让模型“别那么烦”，提示词很好用；当你需要模型“绝不能出错”，提示词就显得太软了。很多 AI 产品团队吃过这个亏，前期靠 prompt patch 一路缝缝补补，到了规模化阶段才发现，真正决定系统稳定性的不是语言，而是约束结构。claude-token-efficient更像一张创可贴，贴得准、贴得爽，但它不是骨科手术。
另一个值得讨论的问题是，这种“压缩输出”的思路，会不会让模型失去必要的解释性？毕竟不少用户喜欢 Claude，恰恰是因为它说话完整、语气温和、愿意给上下文。项目里也预留了“覆盖规则”：只要用户明确要求详细解释，模型依然会展开。这是个不错的设计，说明作者并不是盲目崇拜简短，而是在强调默认状态应该更利落，把啰嗦当作一种显式选项，而不是出厂设置。
我觉得这背后其实反映了一种成熟：AI 工具终于开始从“会说话”转向“会闭嘴”。这是产品进化里很少被歌颂、却极其重要的一步。真正好用的工具，不一定总在表达自己，而是在你需要的时候刚好出现，在你不需要的时候尽量安静。
从这个小项目往外看，2025 年的 AI 正在进入“精装修”阶段
如果把时间拉长看，这类项目流行并不意外。过去两年，大模型行业主要在比“毛坯房”能力：上下文多长、参数多大、推理多强、能不能写完整应用。到了现在，越来越多用户开始关心“精装修”问题：输出格式稳不稳、团队协作顺不顺、长会话会不会越聊越散、自动化流程里会不会冒出一句多余的废话把 parser 干崩。
你会发现，开发者社区的抱怨也发生了变化。早期大家吐槽“模型太笨”，现在更多吐槽“模型太会来事”。这其实是好事，说明底层能力已经过了及格线，用户开始较真细节了。每一次技术产品真正走向普及，都是从拼大功能，走到抠小摩擦。浏览器曾经如此，智能手机如此，今天的 AI 编程工具也一样。
所以别小看这份 CLAUDE.md。它虽然只是个 GitHub 仓库，却像一面镜子，照出了生成式 AI 当前最真实的使用现场：人们不再满足于“能用”，而开始要求“顺手”；不再只盯着模型有多聪明，也开始在意它有没有边界感。一个成熟的 AI 助手，不该像一个情绪饱满的演讲者，而该像一个靠谱的同事，知道什么时候回答，什么时候闭嘴，什么时候承认“我不知道”。
如果说这份文件有什么更大的意义，我会把它理解为一种用户反向塑造模型的尝试。平台厂商给出的默认人格，不一定适合每个团队；真正的工作流，最终要靠用户社区一点点磨出来。今天是一份 CLAUDE.md，明天可能就是一套更系统的“AI 行为配置层”。谁能先把这层做好，谁就更有机会拿下企业场景里最值钱的那部分使用时长。
而这，也许比省下那几百个 token 更重要。