你有没有过这种体验：问 AI 一个简单问题，它先来一段"这是一个很好的问题！"，再铺垫一段背景，最后才给出答案，结尾还要补一句"希望这能帮到你！"。
答案明明只有一句话，却被埋在 300 字的废话里。
有一个开源项目，就为了解决这一个问题，拿到了数万 Star。
一、痛点：AI 把答案"埋"起来了
用 AI 编程助手的人，几乎都遇到过同一个困扰：AI 太"礼貌"了。
Claude Code、Cursor、Copilot 这些工具在回答问题时，习惯性地堆砌客套话、前言、背景铺垫、总结回顾，以及各种"希望这能帮到你！"式的结束语。真正有用的那一步操作，往往被淹没在长篇大论中间。
对普通用户来说，这最多算"啰嗦"。但对另一群人来说，这是灾难——他们就是 ADHD（注意力缺陷多动障碍）人群。
ADHD 患者的工作记忆有限，注意力容易涣散，启动任务困难。当 AI 把答案埋在废话里时，他们可能读到一半就断了思路，或者根本找不到那个"该做的动作"。
于是，一个叫 i-have-adhd 的开源项目出现了。
二、i-have-adhd 是什么？
一句话概括：这是一个让 AI 编程助手"停止把答案埋起来"的技能（Skill）。
它的本质不是一套复杂的工具，也不是什么框架，而只是一份 142 行的 SKILL.md 文件。里面写死了 10 条"说话规则"，约束 AI 如何组织回答。
项目作者 ayghri 明确表示，这份规则"松散地借鉴了《The Adult ADHD Tool Kit》（J. Russell Ramsay 和 Anthony L. Rostain 著）"，但是针对 LLM 如何回答而改编的，而不是教人类如何规划一天 citation:GitHub - ayghri/i-have-adhd。
换句话说，它把一本写给人类看的"ADHD 自救手册"，翻译成了"AI 应该怎么说话"的说明书。
三、为什么它能火？
这个项目在 GitHub 上经历了持续的病毒式传播。不同时间点的 Star 统计差异很大——从早期的 1.8 万、2.1 万，一路涨到后来的 4.8 万、5.3 万 citation:skills.sh citation:gitstars.io。
它爆火的根本原因在于：戳中了几乎所有 AI 用户的普遍痛点，而不是只有 ADHD 人群。
你不需要有 ADHD 诊断，也能感受到"AI 把答案埋起来"的烦躁。这个项目用最朴素的方式，解决了这个几乎人人都有、但没人系统性解决过的问题。
更妙的是，它证明了在 AI 时代，一份提示词文件本身，就可以是一个开源项目。
四、核心：10 条输出规则
这是项目的灵魂，规则全文保存在 SKILL.md 中 citation:GitHub - ayghri/i-have-adhd：
| # | 规则 | 含义 |
|---|---|---|
| 1 | 先给下一步行动（Lead with the next action） | 第一行必须是读者能直接做的事 |
| 2 | 多步骤任务编号（Number multi-step tasks） | 步骤清晰可循 |
| 3 | 结尾给一个具体的下一步（End with one concrete next step） | 永远留下一个可执行动作 |
| 4 | 抑制跑题（Suppress tangents） | 不扯无关内容 |
| 5 | 每轮都重申当前状态（Restate state every turn） | 让读者知道"现在到哪了" |
| 6 | 给出具体时间估算（Specific time estimates） | 用"5 分钟"，而不是"一会儿" |
| 7 | 让进展可见（Make wins visible） | 明确标出已完成的部分 |
| 8 | 平实陈述错误（Matter-of-fact errors） | 错误就事论事，不渲染 |
| 9 | 列表最多 5 项（Cap lists to 5 items） | 不让人被长列表淹没 |
| 10 | 不要前言、不要总结、不要结束语（No preamble, no recap, no closers） | 砍掉所有客套 |
五、背后的认知科学：为什么是这 10 条？
这 10 条规则不是随便定的。DeepWiki 的技术分析指出，它们实际上是针对 ADHD 的三个核心认知障碍设计的 citation:DeepWiki - The Ten Rules：
- 工作记忆有限（limited working memory）→ 所以要求"每轮重申状态"、列表不超过 5 项，因为工作记忆装不下太多信息。
- 启动任务困难（executive dysfunction in starting tasks）→ 所以要求"先给下一步行动"，因为最难的是"开始"。
- 时间盲区（time blindness）→ 所以要求"用分钟给出具体时间估算"，因为 ADHD 人群对时间流逝的感知是模糊的。
这揭示了一个很关键的设计哲学：它不是让 AI 变得更聪明，而是让 AI 的输出"适配"人类大脑的信息处理方式。
六、怎么安装和使用？
它主要通过 Claude Code 的插件市场机制安装，两条命令即可：
claude plugin marketplace add ayghri/i-have-adhd
claude plugin install i-have-adhd@i-have-adhd
安装后，在 Claude Code 会话中输入 /i-have-adhd 即可启用。
它还支持 fork 后自定义——编辑 skills/i-have-adhd/SKILL.md，就能调整规则，然后把自己的 fork 换进去 citation:GitHub - ayghri/i-have-adhd。
七、深入分析：价值与局限
值得肯定的地方
1. 极简主义的胜利。 整个项目只有一份 SKILL.md，没有代码、没有运行时、没有后端。它证明了"提示词本身就可以是一个开源项目"。这种"一个文件改变 AI 行为"的模式，对开发者极具启发意义。
2. 把 AI 当工具，而不是当同事。 中文社区的分析指出，i-have-adhd 选择了与主流 AI 产品不同的哲学路径：工具不需要礼貌，工具需要精确。 这种"去社交化"的定位。
3. 契合行业趋势。 Cursor、Codex 等工具已经开始原生支持这种"技能"机制，说明行业正在向这个方向演进。
局限与争议
1. 简洁输出并非万能。 有分析指出，在某些需要详细解释、上下文铺垫的场景下，过度追求精简反而会损失信息量。比如复杂架构决策分析、教学场景，这种"冷冰冰"的输出并不总是最优 citation:Botmonster - Ten i-have-adhd rules。
2. 它是"输出风格"而非"能力增强"。 这个 skill 不改变 AI 的能力边界，只改变它的表达方式。它解决的是"沟通效率"问题，不是"任务完成质量"问题。
3. 规则可能过于教条。 强制"列表不超过 5 项"、"不要前言"等规则，在需要完整叙述的场合可能显得僵硬。
八、放进 AI Coding 方法论里：它属于"表达层"
如果你把 AI Coding 的方法论拆开看，会发现它其实有两个正交的维度：
| 维度 | 解决的问题 | 代表 |
|---|---|---|
| 流程层 | Agent 怎么思考、怎么规划、怎么验证 | Spec-Driven Development、obra/superpowers |
| 表达层 | Agent 怎么把话说清楚、怎么呈现结果 | i-have-adhd |
- SDD（Spec-Driven Development） 解决"agent 想清楚"——spec 即契约，先定义清楚再写代码。
- Superpowers 解决"agent 有纪律"——强制走完 brainstorm → plan → TDD → review → wrap-up 的完整流程。
- i-have-adhd 解决"agent 说人话"——输出不埋没答案，让结果可执行。
三者缺一，方法论都不完整。
单独看 i-have-adhd，它只是个"说话技巧"，像是治标。但放进这个框架里，它才显出方法论意义：一个完整的 AI Coding 方法论，必须同时覆盖"怎么做"和"怎么说"两个维度。
九、落地建议：值不值得用？
推荐：值得一试，尤其是如果你用 Claude Code。
- 如果你被 AI 的"客套话"困扰，直接装上，几分钟就能感受到差异。
- 如果你在写 AI Coding 相关的技术文章或方法论，这个案例是"表达层"极好的素材。
- 如果你有自己的 agent 工作流，可以 fork 它的规则，按你的场景裁剪——比如把"列表不超过 5 项"放宽，或增加"复杂决策前先给背景"。
但要注意： 别把它当成万能药。它优化的是"表达效率"，不是"思考质量"。在需要深度解释、教育引导、复杂权衡的场景里，你可能反而需要关掉它。
十、结语
i-have-adhd 的火爆，折射出一个正在发生的趋势：AI 产品正在从"讨好用户"转向"服务用户"。
过去我们习惯了 AI 的客套和冗长，甚至把它当成"AI 味"的一部分。但 i-have-adhd 提醒我们：工具的核心价值是精确，不是礼貌。 当 AI 学会"先说重点"，它才真正开始像一个可靠的工具，而不是一个喋喋不休的同事。
这也许就是它拿到数万 Star 的真正原因——它替我们说出了那句早就想说的话：别废话，说重点。
