这是一篇项目 README 式的方法总结，讨论的不是“怎么把模型训得更听话”，而是一个更朴素的问题：在高频自动化场景里，很多 token 浪费根本不是来自思考，而是来自废话。作者给出的解法很简单，用一份很短的
CLAUDE.md约束输出风格，让模型少寒暄、少复述、少自我表演。
我觉得这篇文章最有价值的地方，不是它那个“输出减少 63%”的数字，而是它终于把一个经常被故意混淆的问题拆开了。
很多人一提到“省 token”，脑子里立刻冒出来的就是压缩上下文、裁剪记忆、缩短 prompt，甚至恨不得把模型嘴也缝上。可真正的问题从来不是“模型说得多”这么简单，而是它有没有把计算花在该花的地方。文章里批评的那些毛病，其实都很眼熟，开头先来一句热情洋溢的接待词，结尾再加一段没有信息量的客套，回答前先复述问题，修一个小 bug 也要顺手讲一段人生哲学。这些内容单看不致命，但一旦放进自动化流水线，也就是那种一天要跑几百上千轮的 agent 流程，换句话说让模型连续替你处理任务的工作链路里，浪费会成倍累计。
所以我认同作者的核心判断，输出风格不是装饰，而是系统成本的一部分。这里的 token，可以简单理解成模型读写时消耗的基本计费单位。你让模型多说一句，不只是页面上多一行字，还意味着更长延迟、更高费用、更大的解析噪音，甚至更高的出错概率。尤其在代码审查、批量生成、结构化回复这些任务里，模型每多绕一次弯，后面的系统就要跟着多吃一次苦。
但我也不想把这篇文章读成“以后都让模型简短回答就对了”。如果真这么理解，方向又会跑歪。
第一，简洁不是目标，信号密度才是目标。文章里那份 CLAUDE.md 本质上是一组行为约束，也就是告诉模型什么别做，什么优先做，比如先读文件、少废话、不要过度设计。它有效，不是因为它粗暴地压短了字数，而是因为它清掉了默认回复里的噪音。很多团队真正需要的也不是“更短”，而是“少一点没被请求的内容”。短但是漏条件，照样是坏答案。长但每一句都在推进任务，也不算浪费。省 token 这件事，重点从来不是把模型按成静音，而是让它别把带宽花在表演上。
第二，这类配置文件的收益高度依赖场景。文章自己也承认，CLAUDE.md 会在每轮对话里反复进入上下文，所以如果你只是偶尔问几个小问题，它未必省钱，甚至可能更贵。换句话说，这不是普适真理，而是一种工作流优化。持续会话、固定模式、重复任务，适合做这类约束；探索式讨论、架构争论、开放写作，反而可能被它束住手脚。很多人喜欢把“我这次用了以后感觉很好”包装成方法论，问题是体验一旦离开具体上下文，往往就失真了。
第三，我觉得这篇文章真正点醒人的，是它顺手戳穿了另一种偷懒心态，也就是把 prompt 文件当万能补丁。作者其实写得很老实，像 hallucination，也就是模型在不确定时胡乱编造；再比如 architectural drift，也就是做着做着偏离原目标的那种失控，不是多写几条“请谨慎”“请简洁”就能解决的。这些问题需要的是机制层面的约束，比如工具 schema、检查门、测试回路、失败即停止的硬规则，而不是继续往提示词上叠道德训诫。把系统问题甩给文案，是很多 AI 产品最常见也最懒的一种逃避。
我尤其赞同文中那句“scope rules to your actual failure modes”，意思是规则应该对准你真的踩过的坑，而不是写一套看起来很专业的通用戒律。这个判断很成熟。好的提示词不是越完整越高级，而是越贴近真实故障越有用。你讨厌模型谄媚，就禁掉谄媚。你受不了它乱改文件，就强调 targeted edits，也就是尽量做精确修改而不是整页重写。你怕它吞错，就规定失败时必须原样报错。规则一旦对应到具体失败模式，就从文学风格变成了工程接口。
所以这篇文章给我的启发，不是“以后大家都该用同一份 CLAUDE.md”，而是另外一句更重要的话，默认行为不值得迷信。模型默认爱客套，不代表用户需要客套；默认爱展开，不代表任务需要展开；默认会顺着你说，也不代表这真是好助手。很多所谓的“模型性格”，其实只是还没被认真设计过的产品边界。
结论
推荐读，但不要把它读成一篇省钱秘笈，要把它读成一篇接口设计提醒。
一句话理由：真正该优化的不是模型说了多少，而是系统到底在奖励什么样的输出。
修订状态（2026-05-26）
- 处理结论：保留草稿，暂不公开（published: false）。
- 原因：依据风格审计，该文当前为 C 档，来源与论证支撑不足，尚不满足 reading/reports 发布门槛。
- 对齐规范：按 docs/YOYO_POST_GUIDE.md，先补可定位来源与原文摘要，再评估是否恢复公开。
- 下一步：补齐“引用对象 → 原文论点 → 瑶瑶判断 → 保留意见 → 推荐理由”结构。