👋 Hi，我擅长 AI 大模型应用落地、意识解码与 AI 开发工具链 。 💡 创业路上，用技术换时间，一起把 AI 变成生产力 🚀 >
让 AI 别再“把答案埋在最后一段”：i-have-adhd 入门指南
你有没有过这种体验：问 AI 一个简单的“这个函数为什么报错”，它先给你来一段背景介绍、再列三条注意事项、然后是“当然，具体取决于你的环境”，最后在倒数第二段轻描淡写地写：把第 12 行的分号删掉。
你只想听那个分号的事，但它写了八百字。
ayghri/i-have-adhd 这个项目就是冲着这个毛病来的。它的自我描述很直白：“A skill to stop your coding agent from burying the answer.”——一个让编码智能体别再把答案埋起来的技能，输出面向 ADHD（注意力缺陷多动障碍）读者优化。
① 30 秒结论
- 它是什么：一个“输出风格约束”技能（skill），不是模型、不是 IDE、不是插件市场里的重型工具。它通过一条可安装的指令文件，要求编码智能体改变回答的组织方式。
- 核心主张：先给下一步动作，多步骤要编号，跨轮次重述当前状态，砍掉跑题内容，给出具体时间估计，把“已完成的部分”显性化。
- 适合谁：正在用编码智能体（如命令行 AI 助手）做课程项目、毕业设计、转行练手项目的学生和转行者；尤其是被“长篇大论但抓不到重点”折磨过的人。
- 不适合谁：期待它提升模型推理能力的人（它不改变模型能力，只改变表达结构）；以及团队已有严格输出规范、不允许自定义指令的场景。
- 成本：极低。安装是一条命令或一次斜杠命令，卸载同理，属于“试错成本几乎为零”的那类工具。
② 关键证据
第一，它的设计目标被写死在技能文件里。项目的 SKILL.md 明确列出六条输出准则：面向 ADHD 读者组织输出、以“下一个动作”开头、多步骤工作编号、跨轮次重述状态、抑制跑题、给出具体时间估计、让进展可见。这不是模糊的“友好一点”，而是可检查的清单。
第二，安装路径短到可以当场验证。仓库的 INSTALL.md 给出的方式是在会话里输入 /i-have-adhd，技能会安装到 ~/.hermes/skills/ 目录，并在下一次会话开始时作为斜杠命令暴露出来。另一种方式是把这个仓库添加为技能源（文档里叫 “tap”），再搜索安装。
第三，它解决的是真实存在的协作摩擦。在真实项目里，你和智能体的对话往往跨几十轮，“上一轮改到哪了”这件事本身就是认知负担。技能要求“跨轮次重述状态”，本质上是把上下文管理的一部分外包给了输出格式。
第四，它足够小，小到可以读完全部源码。整个仓库的核心就是一份技能描述文件加安装说明。对学习者来说，这是难得的“可以完整读懂并改写”的样本——你可以照着它写一个自己的“i-prefer-tables”或“i-hate-jargon”。
③ 展开说明：它到底怎么起作用
先解释一个概念。技能（skill） 在这里指的是一份结构化的指令文档，智能体在回答前会读取它，把它当作本次会话的输出规范。你可以把它类比成给新同事的一张便签：“汇报时先说结论，再说过程，超过三步请编号。”便签不会让同事变聪明，但会让沟通顺畅很多。
i-have-adhd 的便签内容，翻译成人话是这几条：
环境准备与第一个可运行结果：
- 做什么：确认你有一个支持技能机制的编码智能体会话环境（项目文档中以 hermes 命令行为例）。
- 输入什么：在会话中输入 /i-have-adhd。
- 看到什么算成功：技能被安装到 ~/.hermes/skills/，并且下一次会话启动时，斜杠命令列表里出现 i-have-adhd。此时你再问一个多步骤问题，回答应当以动作开头、步骤带编号。
如果你想先浏览再安装，文档给出的替代路径是：hermes skills tap add ayghri/i-have-adhd 添加技能源，然后 hermes skills search adhd 搜索，再安装。这条路径的意义在于——你可以先看看这个“技能市场”里还有什么，再决定装不装。
面试/作业里常被追问的点：如果把这个项目写进作品集，面试官很可能问“你怎么评估一个提示词规范是否有效？”诚实的回答是：设计一个对照实验，准备 10 个多步骤任务，分别在有/无该技能下运行，统计“答案出现在前 3 行”的比例和“需要追问次数”。这个项目本身没有提供基准数据，所以你要自己造评估——而这恰恰是加分项。
④ 落地建议：今天就能做的 3 件事
⑤ 风险与反例
它不提升正确性。 输出变短、变清晰，不等于答案变对。一个错误的建议如果被组织得很漂亮，反而更危险。所以它必须和“要求模型给出验证方式”搭配使用。
它可能压制必要的背景。 有些问题（比如涉及并发安全、数据迁移）确实需要先讲清前提。技能里“抑制跑题”的条款如果被机械执行，可能让智能体省略掉关键警告。这时你要主动追问“有没有我没想到的坑”。
它依赖宿主环境支持技能机制。 如果你用的工具不读取这类指令文件，装了也白装。文档以特定命令行工具为例，换到别的环境需要自行确认加载方式。
反例场景：团队协作中，如果每个人装的技能不同，同一份智能体输出在不同人屏幕上结构不一致，反而增加沟通成本。这种时候，团队应该统一一份规范，而不是各自装插件。
最后一句实话：这个项目火起来，不是因为技术多复杂，而是因为它精准命名了一个大家都有过的痛——答案就在那儿，但被埋了。对在校学生和转行者来说，学会“约束工具的输出来匹配自己的注意力”，比学会某个具体框架更耐用。
