一个给 Claude、Codex、Cursor 用的「ADHD 友好型输出技能」，在 GitHub 上拿了 49.2k stars。这个数字什么概念——比绝大多数正经的开发者工具、CI 插件、甚至不少小语言模型项目都高。而且它的 README 自己说了：你不需要真的被诊断有 ADHD 也能用。这句话基本上就把这个项目的真实定位给戳破了。
它火的理由不是 ADHD。它火是因为它替每一个被 AI 助手气过的人，把那条憋了很久的话说了出来：别铺垫，给我能跑的东西。
我第一次翻这个 repo 的时候心里其实挺不屑的——这不就是个 prompt 吗？包了个「技能/插件」的壳子，10 条规则全是大白话，没有一行代码，没有任何技术含量。翻完 SKILL.md 我花了不到三分钟，觉得这玩意儿也配 49.2k 星？但后来我越琢磨越觉得不对。恰恰是它没有任何技术含量，它才传播得动。因为它的全部价值都在「输出侧」：它不碰模型怎么推理，只碰模型怎么把自己已经算出来的答案交给你。而这一层，恰恰是现在所有 AI 编程助手做得最烂、又最没人愿意承认的一层。
你八成有这种经历。问「这个依赖装不上」，它先回一句「看到你遇到了一个问题」，然后开始解释错误的可能原因，然后给你三个「可能的修复方向」，最后用「希望这有帮助」收尾。你其实只想要那个命令。你滚动了两次，才在一堆解释的夹缝里找到它。这就是那个 repo 名字里梗的真正来源：不是用户注意力有问题，是输出格式在制造注意力的摩擦。给一个本来就被 bug 搞得焦头烂额的人再雪上加霜。
这 10 条规则我翻了一遍，没有一条是新技术，但每一条都在治一个具体的病。我挑几条承重墙级别的讲，剩下的你自己去看 SKILL.md——完整规则就躺在那儿，没人拦着你。
第一条是「优先给下一步行动」。这条等于把 AI 输出的默认结构整个倒过来：不先解释为什么，先给那个能执行的动作。它对抗的是模型在训练过程中被灌输的那套「先共情、再解释、后建议」的客服话术——那套话术在陪聊场景也许成立，在改 bug 的场景里就是在浪费带宽。行动前置，解释后置；行动本身就够用的话，解释可以整个砍掉。这条是全部规则的骨架，其他九条基本都是在给这条打配合。
第二条是「多步任务编号，且列表不超过五条」。编号这个动作看着琐碎，但它实际上是在给工作记忆减负——用户不需要自己去解析一段连贯文字里到底藏着几个步骤，每个步骤的边界在哪。编号等于把步骤的边界直接画出来。而「不超过五条」是个很粗暴但有效的上限：多出来的每一条，都是在跟用户的工作记忆抢 slot。五个以上，人就开始丢上下文了。这不是什么认知科学的前沿结论，就是个工程上的经验数字，但它被写成了硬规则，这就比一百句「请简洁回答」都管用。
第三条是「用分钟而不是模糊说法给时间估计」。这条最容易被当小事，但它实际上把「感觉」换成了「可证伪的承诺」。「很快」没有可证伪性，说错了你也没法追究；「两分钟」有。模糊的时间词是 AI 输出里最常见的防御性措辞——它保护的是模型，不是用户。把这条写成规则，等于要求模型对用户的时间负责。
第四条是「以平实方式报错」。这条直接砍掉 AI 输出错误时那种过度道歉和委婉包装。报错的时候绕弯子，浪费的是修复时间。错误本身就是信息，把它用最直接的方式递出来，然后给出下一步，别在「抱歉给你带来了不便」上浪费一个字。这条规则对很多人反直觉，因为我们都习惯了「有礼貌的 AI」；但礼貌的代价是信息密度下降，在 debug 场景里信息密度就是一切。
第五条，也是我觉得最聪明的一条：「每轮回答中重述当前状态」。这条表面上像在对抗多轮对话里的状态丢失——但它对抗的主要不是模型记不住，是人记不住。你让 AI 改一个文件，它改了，然后你又问了两个别的问题，再回来问第三个改动的状态，你自己可能都已经忘了前面的上下文。强制重述等于每次回答前先同步一次心智模型，把「人」这个最容易丢状态的环节也纳入了系统。这条在所有规则里最不像「ADHD 专用」，它其实是多轮 agent 对话里一个通用的可靠性设计。
我画个简单的对比，把改进前后的输出结构差异说清楚，这张图本身就是这个 repo 核心 idea 的视觉化：
改进前：
用户：这个依赖怎么装不上
AI：看起来你遇到了一个问题。这可能是因为版本冲突，
也可能是缓存没刷新。有一种常见做法是清理缓存，
另外你也可以试试升级 pip。希望这有帮助！
（用户滚动两次才找到那个命令）
改进后：
用户：这个依赖怎么装不上
AI：1. 运行 pip install --upgrade pip
2. 重新执行 pip install <你那个包名>
3. 如果仍失败，贴出完整报错
下一步：先跑第 1 条。
前后差别不是模型变聪明了，是同样的信息被重新排了序、砍了废话、加了编号。这个 repo 的全部技术含量，就在这个重排里。示意图到这儿就够用了，再往下类比就失真了，因为它根本没碰任何「推理」层面的东西。
拆到这儿我得诚实地补一刀：这套东西不提升模型能力，只改变模型表达。它是 prompt 层的输出侧约束，不是能力侧的升级。你的底层模型要是本来不会修那个 bug，那这 10 条规则只会让它错得更干脆——以前它还会用一大段委婉的解释把「我其实不会」糊弄过去，现在它会直接给你一个错的下一步。这对用户未必是坏事，因为它把模型的真实能力边界暴露出来了；但你得知道这一点，别指望装了这个技能之后模型就变强了。它不会。
还有一个更隐蔽的风险。这套规则正在被当成某种「最佳实践」到处贴。我看到它的时候，脑子里冒出的第一个念头也是「这不就是一段写得很好的 system prompt 吗，我直接抄进我的 agent 里不就完了」。但无脑套用会翻车。「重述当前状态」在单轮问答里就是废话；「列表不超过五条」在需要完整清单的场景会漏信息；「优先给下一步行动」在用户只是想讨论方案、还没准备执行的时候会显得很冲。规则是治病的，不是供起来拜的。每条规则背后对应一个具体的失败模式，你得先判断那个失败模式在你的场景里存不存在，再决定要不要用那条规则。这跟用药一个道理——别因为别人吃了有效就整瓶吞。
把论文拉回地面，或者说把这个 repo 拉回地面。它对一线开发者的真正价值不在于「帮 ADHD 用户」，而在于它把「输出应该怎么组织」从一种隐式的审美偏好，变成了显式的、可复制、可版本化的约束条款。你在写 agent 的 system prompt、给内部 CLI 工具写输出格式规范、或者调一个代码修复类 agent 的时候，这 10 条规则是一个可以直接抄的模板。你不需要同意每一条，但把它们一条条过一遍，问问自己「这条在我的场景里治什么病、有没有必要」，这件事本身就比大多数人写 prompt 时拍脑袋想的那几句「请用简洁的方式回答」要有价值得多。后者的毛病是太模糊，模糊到模型根本没法执行；这个 repo 的贡献，是把「简洁」拆成了十条具体的、可执行的、彼此不重叠的规则。这个拆解动作，才是它值 49.2k 星的全部原因。
说到底这堵墙很矮，矮到你可能觉得它不值得拆。它没有公式，没有推导，没有架构图，就一个 SKILL.md 里躺着十条大白话。但正因为它矮，它才暴露了一件被我们选择性忽视的事情——过去这两年，所有人都在卷模型能力、卷上下文长度、卷 agent 框架，几乎没人认真卷「输出格式」。这个 repo 用 49.2k 颗星投了张反对票，票面上写着：输出格式也是承重墙，别等模型聪明到不需要你了才想起来补。这堵墙我替你拆了，剩下那十条规则，你最好自己打开 SKILL.md 读一遍——它总共也没多长，别让摘要替你下结论。