先看一眼那条让全球开发者集体破防的原文。别急，我把它完整贴在这，你盯着读三秒，看看有没有被冒犯到的感觉：
- UI descriptions: Do not add subtitles, helper text, or descriptive copy beneath
headings, labels, cards, or settings by default. Prefer one concise, self-explanatory heading
or label. Only add supporting copy when the user explicitly asks for it or when it is
necessary to prevent misunderstanding or error, and never use it to restate the heading.
就这六行英文，没有感叹号，没有威胁，连个“please”都没用。但就是这堆单词，在推特上炸出几百条“偷了”“马上用”“终于有人说了”。
它到底在说什么？
翻译成中文就一句话：别特么往标题底下加废话。但把它拆开，每一小句都是一个耳光，扇在AI最顽固的本能上。
我们一句一句剖，看看它到底怎么把AI从“话痨”训成“哑巴”的。
第一刀：默认禁止，而不是默认允许
这一句是整条规则的死刑判决书：“Do not add subtitles, helper text, or descriptive copy beneath headings, labels, cards, or settings by default.” 它用了三个并列名词——subtitles、helper text、descriptive copy——把你能想到的所有辅助文字类型一网打尽。然后一个“by default”把整个逻辑翻了过来。正常人的思维是“需要的时候才加”，但AI的统计本能是“有标题就有描述”。这条规则直接反转了默认值：不加是正常态，加是例外。
这个反转的背后是认知经济原则。用户打开一个设置页面，眼睛扫描的是开关、输入框、下拉菜单这些可操作元素。标题只是给这些元素贴个名字，让人知道“这是在调什么”。如果每个名字下面都跟一行灰色小字，用户的眼睛就要多扫一行，大脑就要多判断一次“这行字有没有用”。绝大多数情况下，判断结果是“没用”，但那个判断动作本身已经消耗了注意力。这就是为什么界面越“贴心”越让人烦躁——它强迫你做了一堆无效的过滤工作。
更狠的是，规则没有说“尽量少加”或者“谨慎添加”，它直接用了“do not add”。这是一个绝对的起始立场。AI接到这条指令后，生成任何UI组件之前都要先过一道闸门：我准备加的那行字，符不符合后面那两个例外条件？如果不符合，连想都不要想。这种“禁止优先”的措辞在prompt engineering里属于硬约束，比“请简洁”这种软性建议有效一百倍。因为AI对“do not”的响应权重远远高于“prefer”。
第二刀：一个标题就够了，别把它当填空题
第二句是整条规则的精髓：“Prefer one concise, self-explanatory heading or label.” 八个单词，没有从句，没有修饰。它不是在教你写标题，它是在告诉你：标题的任务是独立完成表意。什么叫“self-explanatory”？就是任何正常人看到这个标题，不需要第二眼就能明白这个控件是干嘛的。如果标题做不到这一点，你应该改标题，而不是在底下补一行解释。
这个原则直接砍断了AI最常用的偷懒路径。大语言模型生成UI时，经常先丢一个模糊的标题，比如“配置选项”，然后底下跟一行“在这里调整应用的各项参数”。它以为自己在做“标题+描述”的标准组件，实际上标题本身就没写明白。“配置选项”是什么？哪些配置？调整什么参数？如果标题改成“调整字体大小和主题颜色”，底下那行字根本就不需要了。AI之所以不这么做，是因为它训练数据里充斥着大量泛化标题加通用描述的模板，它觉得“标题+描述”是固定搭配，而不是“标题没写清才需要描述”的补救措施。
这条规则还隐含了一个反直觉的设计哲学：辅助文字是对标题失败的承认。如果你需要靠底下的灰色小字才能让人看懂这个开关是干嘛的，说明你的标题文案是失败的。好的设计不需要道歉，好的标题也不需要补丁。所以规则说的是“prefer one”，强调单一性。一个控件只有一个核心标识符，那就是标题本身。底下任何附加文本都在稀释那个标识符的权重。
第三刀：例外条件比死刑还苛刻
第三句开始松动，但松动的幅度极其有限：“Only add supporting copy when the user explicitly asks for it or when it is necessary to prevent misunderstanding or error.” 两个例外条件，一个比一个严。
第一个条件“用户明确要求”——注意是“explicitly asks”，不是“might need”或“could benefit”。也就是说，AI不能自作主张判断“用户可能需要解释”，必须等用户在对话里白纸黑字说“给我加个说明”或者“这里写个提示”。这个条件把决策权完全交还给人类，AI的角色从“主动提供信息”降级为“被动响应指令”。
第二个条件“为了防止误解或错误”——这是唯一的自主空间，但判定标准极高。“misunderstanding”指标题本身有歧义，比如一个按钮叫“提交”，但下面有两个不同的提交对象，用户可能不知道点完是提交哪个。“error”指操作有不可逆风险，比如“删除账户”底下必须加“此操作不可撤销”。这两个情况有一个共同点：不加辅助文字会导致用户做出错误决策。如果只是“用户可能想知道更多细节”，那不属于这个条件。AI要评估的是“如果不加这行字，用户会点错吗”，而不是“加了这行字，用户会更明白吗”。
这两个条件的设计逻辑是“风险驱动”而非“信息驱动”。加辅助文字不是为了传递信息，是为了规避风险。一旦风险不存在，任何额外文字都是噪音。这个框架把AI从“信息提供者”扭转为“风险预警器”，它的输出标准从“多”变成了“准”。
第四刀：复述是死罪，绝对禁止
最后收尾的那句是整条规则的绞索：“and never use it to restate the heading.” 前面说了两个例外条件，但这里又加了一个绝对禁止项——即使你满足了例外条件，你也不能用辅助文字去复述标题。这是什么意思？假设你有一个标题叫“自动保存”，你判断这里可能造成误解（用户不知道自动保存的频率），于是你想加一行“开启后系统将自动保存您的更改”。这行字符合“防止误解”的条件吗？不，它没有提供任何新信息，它只是把“自动保存”四个字扩写成一个句子。这就是“restate”——重新说一遍，没有增加频率、范围、后果等任何实质性内容。这种复述型文字，即使满足了例外条件，也是被明令禁止的。
这个“never”是整条规则里唯一的大写级否定。前面用的是“do not”和“only”，语气还算克制，到了这里直接上“never”。因为复述是AI最隐蔽也最顽固的毛病——它写代码时爱加注释说“// 这是为了处理XXX”，生成UI时爱加“此设置用于YYY”。它觉得这是在解释，其实只是在镜像复制标题的意思。这种废话不仅不增加信息，还会让界面变得啰嗦，让用户产生“这个软件不信任我的理解力”的隐性反感。
从认知心理学看，复述型文字会造成双重加工负担。用户先读标题，获取一个概念；然后读到辅助文字，发现它传达的是同一个概念，但表述不同。大脑会自动比对这两个表述是否一致，这个比对过程消耗额外资源，而且完全多余。用户最终记住的还是那个标题，辅助文字被遗忘，但浪费掉的认知时间回不来了。所以规则用“never”彻底堵死这条路——你可以加辅助文字，但必须增加新信息，比如“每30秒自动保存一次”或者“仅保存至本地，不同步云端”。如果你加的文字只是标题的翻版，那就闭嘴。
第五刀：整条规则自己就是它的活体证据
现在退后一步看整段英文，你会发现一个精妙的自指结构。规则的标题是“UI descriptions”，正文第一句禁止加描述性文字，第二句要求标题自解释，第三句给出例外，第四句禁止复述。整段文字本身就是一个UI说明——它放在CLAUDE.md里，标题是“UI descriptions”，正文是它的描述。但它没有在正文里加任何辅助文字来解释自己，也没有复述标题。它用行动证明了一个自解释的标题可以独立完成全部表意工作。
这个自指结构在修辞学里叫“践行式陈述”，它说的和做的是同一件事。如果这条规则在自己身上加了一行“本条规则用于规范UI描述”，那就违反了它自己。但它没有，它干净利落地只写了一个标题和一段正文，正文里没有废话，没有概括，没有重述。你读完标题就知道它要讲UI描述，读完正文就知道具体怎么操作。整段不需要任何额外注释，这就是“one concise, self-explanatory heading”的完美示范。
从语言运作机制看，这段英文的词汇密度极高。核心词“heading”出现两次，“label”一次，“subtitles”“helper text”“descriptive copy”“supporting copy”各一次——所有词都指向同一语义场：附着在主标识符之下的次级文本。而对立面的关键词“concise”和“self-explanatory”只出现一次，但它们承担了整条规则的价值观支点。这种“大量负向列举+少量正向锚定”的分布策略，在读者脑中制造了一个清晰的禁区地图：所有那些词都是你不该加的东西，只有这两个形容词描述的东西才是你该追求的。
句式上，四个分句的长度分别是15词、8词、23词、9词，形成长短长段的节奏。第一句用长列举制造压迫感，第二句用极短句释放压力并给出方向，第三句用长复合句引入复杂条件，第四句用短句加“never”收尾，像一记重锤砸实禁令。这种节奏切换会让读者在“紧张-放松-再紧张-彻底定音”的情绪曲线上走一圈，最终牢牢记住那个“never”。
第六刀：为什么全世界的开发者都在偷这条规则
X评论区里的反应已经说明了一切。
Nick Dobos说“GPT和Claude都爱加我根本没要过的标签”，Sawyer Hood说“我才发现Opus 5一直这么干”，Brendan Falk说“立刻加到我们内部的agents.md”。这些人不是在转发一条UI规范，他们是在签署一份对AI废话本能的血泪控诉。
问题根源在于大语言模型的训练机制。它吃进去的UI模板绝大多数都包含“标题+描述”的双层结构，它学到的不是“描述是可选的”，而是“描述是标准配置”。模型不具备设计判断力，它只有统计学上的模式复制能力。当你让它生成一个设置页面，它会把它见过的所有组件结构都复制一遍，包括那些它根本不理解为什么要存在的辅助文字。它不知道那个描述可能是设计师为了凑布局加的，也不知道那个眉题可能是原型工具自动生成的。它只管输出概率最高的组合——标题下面一定有段灰字，卡片里面一定有行小说明。
这种本能在代码生成场景里尤其顽固。因为代码本身需要注释，AI习惯了在函数上面写一段描述，于是它把这种习惯迁移到UI文案上。但它没意识到UI文案是用户界面的一部分，不是开发文档。用户不会感谢你给他看的每个开关都配一段说明书，他只会觉得你把他当傻子。那条规则的本质，就是告诉AI：用户界面不是代码注释区，你的解释欲请留在代码文件里。
另一个隐藏的痛点是“eyebrow header”那个鬼东西。就是标题上面那行更小更淡的类别标签，比如在“通知”上面加一个“偏好设置”。这玩意儿在UI组件库里经常出现，AI学了一肚子，于是疯狂往生成的界面里塞。但用户根本不关心“这是偏好设置区”这种宏观分类，他只想找到“通知”那个开关。眉题不仅不帮忙，还增加了一行扫描障碍。所以评论区里好几个人专门点名“尤其是眉题”，因为这东西比底下的辅助文字更阴险——它放在标题上面，你一眼扫过去先看到它，然后才找到标题，多了一道跳转工序。
最后一刀：这条规则教会AI的不是“不加”，是“什么时候才加”
回到那条英文文本，你会发现它真正的训练目标不是“别加文字”，而是建立一套“加文字的审批流程”。AI接到指令后，每次生成UI都要走这个流程：
第一步：我要不要加辅助文字？默认答案是不加，直接跳过。
第二步：如果我想加，用户有没有明确要求？有就加，没有就进入下一步。
第三步：如果不加，会不会导致用户误解或操作错误？如果会，我再检查一下我准备加的文字是不是在复述标题。如果是复述，放弃；如果不是复述，而是补充了新的关键信息（比如后果、频率、范围），那就可以加。
这个流程把“加辅助文字”从“本能行为”变成了“理性决策”。AI不再是无脑输出模板，而是被迫在每个生成点进行风险评估和信息增量判断。这恰恰是当前所有大模型最缺的能力——它们擅长生成连贯文本，但不擅长判定“这个文本是否真的有必要存在”。CLAUDE.md里的这条规则，就是在弥补模型的这个缺陷，用硬编码的规则对冲统计学习的盲目性。
Guido Pettinari在评论里提出了一个更极致的做法：“我让我的代理把辅助文字藏在tooltip里。”这其实就是把“用户明确要求”这个条件工程化——用户悬停时才触发，平时不占视觉空间。这个方案完全符合那条规则的精神：默认不加，需要时通过交互手段暴露。如果所有AI生成的UI都能默认走这个逻辑，那条规则可能根本不需要写出来。
但现实是，模型还没学会。所以开发者们只能像Charlie Holtz那样，在配置文件中写一行“Do not add”，然后看着AI乖乖闭嘴。这不是胜利，这是停战协议。真正的胜利要等到模型在训练阶段就把“简洁优先”内化成生成偏好，到那天，这条规则就可以从CLAUDE.md里删掉了。但今天，它还得继续待在那，像一张贴在AI额头上的便利贴，提醒它：你不是设计师，别替我拿主意。
总结：这条六行英文的规则，实质上是一份AI本能纠正手册。它把“加文字”从默认动作改为例外动作，把“解释”降级为“风险预警”，把“复述”列为死罪。开发者们集体偷它，是因为AI的废话病已经到了忍无可忍的地步。
闭嘴不是AI的天性，是它需要反复背诵才能掌握的技能——而这条规则，就是那张写满标准答案的作弊纸条。
原文期刊: Twitter / 发表日期: 2026年8月4日 / 原文标题: Added this to CLAUDE md today / 作者单位背景: Charlie Holtz，独立开发者，编程教育领域创作者