你问Claude一个bug为什么反复出现,它不会直接说"因为超时没重试",它会说"这里有个耐人寻味的地方",然后列三条发现,郑重宣布"第三条最有启发性"。开发者adnanakil受够了,写了个叫nobuzz的Claude Code插件,核心命令是/debuzz:把Claude刚才的回答原样喂给Gemini CLI,让另一个模型把它翻译成正常人说话的样子。
Claude到底在说什么"黑话"
before/after对比很直观。翻译前,Claude会说重试逻辑"不只是锦上添花——它是整个同步管道的承重假设",三件事跳出来,第三件"最有启发性",最后甩出一个"关键点":去重键包含时间戳,所以重试从未真正去重。
翻译后(/debuzz默认的colleague模式):同步管道有三个bug。文件142行吞掉了超时错误没重新入队,退避上限太低,去重键带时间戳导致重试形同虚设。修复方案三句话说完。
/debuzz还分三档:colleague模式保留全部代码细节;manager模式砍到三分之一长度,讲清楚发生了什么、为什么重要、下一步做什么;director模式压到三到五句话,只留结果、影响、诉求,假设对方只有三十秒注意力。规则很简单:Gemini翻译什么,Claude就原样打印什么,不许自己再"润色"一遍——不然等于让制造问题的模型给自己擦屁股。
这不是个人抱怨,是被系统归纳过的词汇表
Hacker News上有专门一贴,标题就是"怎么让Claude别再说load-bearing",网友凑出了一整套可辨认的Claude腔词典:load-bearing、gate、blast radius、"这里有个耐人寻味的地方"、"这不只是X,更是Y"。Reddit的写作社区也早就在归纳这套固定句式,并且发现一个更麻烦的规律:你明确禁止某个词,Claude不会改掉习惯,只会换一个邻近的陈词滥调接着用。
有人做过一次非正式统计:在约六万条对话轮次里,"load-bearing"出现了188次,分布在151个轮次中。样本量不代表整体频率,但足以说明这不是错觉,是一种可辨认、可复现的写作癖好。
反转:解药本身只有18颗星
读到这里,nobuzz听起来像个对症的社区方案。但翻回它的GitHub主页,现实很朴素:18个star,1个fork,主分支只有两次提交,没有发布过任何Release。第一次提交叫"Introducing Claudette",第二次才是加上/debuzz功能——这更像是两个人一个周末的手痒之作,而不是被广泛验证的工程工具。
- 提醒.一个18星、无版本发布的仓库,离"解决行业痛点"还差得远,它目前更接近一份写得很好的段子
更值得追问的是,这条弯路是不是根本没必要绕。Claude Code在同期版本里已经内置了Concise输出风格,用户直接在配置里开启就能砍掉大量前言废话;Gemini CLI自己也支持全局配置文件和Stop/AfterAgent钩子,可以在系统提示层面强制拒绝啰嗦输出。这些都是持久生效的原生机制,不需要每次调用都临时拉一个模型来"翻译"。
禁词没用,具体才有用
社区讨论里有个共识值得记下来:黑名单式禁词几乎无效。你禁掉"load-bearing",Claude换成"关键前提"照样绕弯子。真正管用的指令不是"别说这个词",而是要求它把话说具体——谁依赖谁、坏了会怎样、修复动作是什么。Before/after那个例子已经证明了这一点:去掉修辞脚手架之后剩下的,是文件名、行号和三句修复方案,信息量反而更大。
这背后还有个更绕的循环:开发者在issue和commit里开始模仿AI的措辞,写下"load-bearing assumption"这种句子,这些文本又会成为下一代模型的训练或上下文材料。人学AI说话,AI再从人的文本里学回去,风格趋同可能会越滚越紧,而不是随时间自然消退。
修辞可以喊停,惯性喊不停
这也是为什么/debuzz这类插件更像临时补丁而不是解法:它治的是输出端的症状,没碰训练和对齐层面的成因。Anthropic自己已经动手在Claude Code里做原生的简洁风格,这条路径更可能笑到最后。值得盯的不是nobuzz的star数会不会涨,而是Concise风格会不会在后续版本里变成默认选项——那才是真正把"TED腔"焊死的时刻,而不是靠开发者手动拉一次Gemini来救场。