i-have-adhd：3.4 万 Star 的提示词插件，治 AI 编程助手的「把答案埋在第三段」

Claude开源AI提示词工程

9 月 10 日的 GitHub Trending 榜单上，一个名为 i-have-adhd 的仓库排在第一：总星数 34,440，单日新增 4,624。它的全部核心内容是一个 6.8 KB 的 Markdown 文件，里面写着 10 条规则，第一条是「第一行必须是读者可以执行的动作」。装上它之后，Claude Code 这类编程助手的回答会变成这样：先给命令，再给编号步骤，最后一句是「下一步：运行测试，把第一行报错贴给我」——不再有「好问题！让我们来看看你的认证流程」这类开场白，也不再有为凑字数而写的结尾。

仓库的作者把它定位成「阻止你的编程助手把答案埋起来」的技能。这个名字里带着 ADHD（注意缺陷多动障碍），但 README 第一行就写明：不需要 ADHD 诊断。它真正的用户是所有被 AI 编程助手的长篇大论消耗过耐心的人。

i-have-adhd 仓库卡片：34k Stars

它解决什么问题

编程助手有一个共同的行为模式：收到问题后先复述问题，再铺垫背景，把真正的命令或结论放在第三、第四段，结尾还要加一句「希望这有帮助！如果需要深入探讨，随时告诉我」。对扫描式阅读的人来说，这些内容全是噪音——真正要找的只是那一行命令、那一个文件路径。

i-have-adhd 的 README 里给了一个改写前后的对照。同一个 verifyToken 函数报错的问题，改写前的回答用了五段话讲「认证流程有几个组成部分」「中间件、token 验证、cookie 处理」，最后才不痛不痒地说「一个思路是更新这个包」。改写后的回答只有三行：

text
运行 npm install jsonwebtoken@latest，然后编辑 src/auth.ts:42
1. 打开 src/auth.ts
2. 用下面的代码替换 verifyToken（第 42-58 行）
3. 运行 npm test -- auth.spec.ts
下一步：如果有测试失败，把第一行报错贴出来。

这个对照不是文学修辞。它背后的 10 条规则每一条都指向 LLM 输出的具体病灶，而且每条都写了「坏例子」和「好例子」。

10 条规则的完整拆解

技能本体在 skills/i-have-adhd/SKILL.md，140 行，MIT 协议。10 条规则如下：

1. 第一行给动作。 不是背景，不是计划，是读者此刻能执行的事。命令、路径、代码片段排最前，散文放后面——如果没有散文更好。

2. 多步任务必须编号。 每步是一个有边界的动作，一个步骤里不允许出现两次「然后再」。规则还要求用最少的步骤完成任务：「一条能走完的短路径，胜过一条会被放弃的完整路径。」

3. 结尾必须是一个两分钟内能做的具体动作。 替代「希望有帮助，随时问我」。哪怕是「先打开那个文件」也算数。

4. 压制跑题。 发现已知问题（比如依赖过期）时，先完成当前任务，再把它作为独立问题提出来，而不是顺手展开。

5. 每一轮都重述进度。 「完成。继续下一部分？」是坏例子；「5 步中的第 3 步完成：数据库表已更新。下一步：回填新列」是好例子。这条针对的是跨轮次的工作记忆问题——读者不需要「记住我们到哪了」。

6. 时间估计必须具体。 「有点工作量」和「几个小时」在大脑里的权重是一样的，模糊估计等于没有估计。好例子：「如果测试已经覆盖，大约 15 分钟；没覆盖的话，一个下午。」

7. 让完成的事可见。 不要说「我对认证流程做了一些修改」，要说「登录现在支持魔法链接了。运行 npm run dev，打开 /login 就能试」。

8. 错误陈述不带情绪。 禁止「哦不，测试好像出了点问题」，只写「测试在 auth.spec.ts:42 失败：期望 200，实际 401。原因：缺少认证头。修复：在请求里加 Authorization: Bearer ${token}」。原因、位置、修复，三件事说完就停。

9. 列表不超过 5 项。 超过就拆成「现在做」和「以后做」，或者「必须」和「最好有」。排序后的 5 项胜过不排序的 10 项。

10. 无开场白，无总结，无客套收尾。 禁用开头包括「好问题」「让我」「我看了一下你的」；禁用结尾包括「有需要随时说」「希望这有帮助」。

文件末尾还有一段「发送前检查」：删掉宣布自己要做什么的第一句，删掉问「还有别的吗」的最后一句，删掉「顺便说一句」插入的旁支，删掉不携带信息的模糊副词，把比喻换成字面动作。最后的验收标准只有一句：如果读者只看第一行和最后一行，能知道接下来做什么、刚发生了什么，就可以发送。

约束不是越紧越好：六条例外

这份技能没有把规则写成绝对命令，SKILL.md 里专门有一节「什么时候可以打破规则」，列了六种情况：

  1. 用户要求「解释」或「带我走一遍」时，正文可以随主题展开，只保留无开场白、无收尾的形态。
  2. 遇到 rm -rf、强制推送、删表这类破坏性操作，先确认再执行，安全优先于简洁。
  3. 调试进入死循环——连续三轮「还是不行」时，停下来，说出可能错误的假设，问一个诊断性问题，而不是继续改代码。
  4. 请求真的含糊时，问一个简短的澄清问题，好过猜错后重写。
  5. 规则和任务冲突时任务赢：「我的选项有哪些」这类问题，答案就是 2 到 4 个带取舍的选项本身，此时列表形态服从内容。
  6. 规则和宿主 harness 冲突时系统提示词赢：harness 要求播报工具调用就播报。

这个设计直接回应了一个真实风险：无差别的简洁指令会压掉必要的确认和解释，让模型在破坏性操作上抢跑。例外条款把「输出风格」和「安全边界」拆成了两套逻辑。

交付形态：从 6.8 KB 到六种运行时

i-have-adhd 的仓库共 54 个代码和文档文件、约 8,600 行，但真正进上下文的只有 SKILL.md 的正文。其余文件全是适配层：

  • Claude Code：作为 plugin 安装（claude plugin marketplace add ayghri/i-have-adhd 后 claude plugin install），用 /i-have-adhd 手动激活；
  • Gemini CLI：一份自包含的 TOML 命令文件，复制到 ~/.gemini/commands/ 后用同样的斜杠命令触发；
  • OpenAI 系工具：一份 YAML 接口描述，声明显示名和默认提示词，并设置 allow_implicit_invocation: false（不允许模型自动触发，只能用户手动调）；
  • pi 等可编程 harness：一个 240 行的 TypeScript 扩展，把规则作为持久消息注入会话，并用状态消息记录开关，支持「stop adhd mode」退出；
  • 常开模式：一个 SessionStart hook（Node 版、shell 版、PowerShell 版三份实现），用户创建 ~/.claude/.i-have-adhd-always 标记文件后，每次会话启动自动注入完整规则集；hook 里专门做了 YAML frontmatter 剥离和「任何失败都以 exit 0 退出、绝不阻塞会话启动」的兜底。

INSTALL.md 写了 774 行，覆盖每个平台的安装、验证、更新、卸载四步。这种「一个核心文件 + N 个薄适配层」的结构，正好演示了 agent skill 这个生态该有的样子：规则与分发分离，规则本身保持单文件、可 fork、可 diff。

作者自己做了评测，然后把自己评了个「不通过」

这个项目最不寻常的部分是 evals/ 目录。作者没有停留在「我用了感觉不错」，而是写了一套配对评测框架：

  • 14 个测试用例（cases.jsonl），覆盖直接回答、多步进度汇报、错误报告、破坏性操作、医疗边界、含糊请求等场景，每个用例带验收标准和风险等级；
  • 5 维加权评分表（rubric.md）：正确性 35%、自主性 25%、可执行性 20%、安全性 10%、简洁性 10%，由盲评裁判在不暴露条件名的情况下打 1-5 分；
  • 2026 年 8 月 2 日的一次完整运行（RESULTS.md）：用固定的 claude-opus-4-8 模型，基线和注入技能的候选各跑 14 用例 × 3 轮，共 84 行结果，报告生成成本 2.67 美元、裁判成本 0.92 美元。

结果：候选加权分 4.473 对基线 4.045，14 个维度全线不降，其中可执行性 +0.714、简洁性 +1.143。提升集中在「进度汇报」类用例——multi-step-progress +2.53、error-report +2.40；而带明确输出契约的用例（代码题、长文写作）完全不变，说明例外条款在起作用，技能没有侵蚀任务本身的形态。

然后是这份评测最值得读的部分：按作者自己定的发布门槛，这次结果是 FAILED。 门槛第一条是「零阻断性发现」，候选组出现了 3 次。作者把这笔账算得很清楚：其中 2 次来自一个任何运行都不可能通过的用例（该用例要求 agent「直接操作仓库」，但评测框架为了让基线干净，把所有工具都禁用了——用例设计与运行环境互相矛盾），即便剔除这个坏用例，剩余 1 次阻断仍然触发绝对条款，结果还是不通过。

作者没有改门槛迁就结果，而是把「绝对规则会吞掉一切改进」写成了评测报告里的一个待决事项：一个候选哪怕把阻断从 7 降到 3，也永远过不了一票否决。这实际上是所有 LLM 评测框架都会撞上的问题——比较性指标和绝对性指标混在同一个门槛里时，门槛会退化成「零容忍」，而零容忍在概率性系统上永远达不到。

评测里还有一条带机制的回归发现：partial-success 用例掉了 0.63 分，三次试验方向一致。裁判的批注是，候选回答「在没有证据的情况下断言『缺少认证头』就是确定原因」。作者给出的解释是：规则 8 要求错误必须按「原因，然后修复」的格式陈述，当证据不足以定位原因时，格式压力会逼模型编一个说得通的原因填进去。这个发现对所有写提示词的人都有参考价值——强制格式的规则，会在证据缺失的位置制造幻觉的压力。作者的建议是三个样本不足以定论，但方向和机制都值得加跑试验确认。

为什么一个提示词文件能拿到 34,000 星

HN 相关讨论串 12 小时拿到 324 分和 256 条评论（据 aiweekly.co 的统计口径），评论区吵的其实是一个问题：这不就是把「回答简短点，我有 ADHD」写进提示词吗？

持这个观点的人给出了更简单的替代方案：一句话写进 CLAUDE.md，或者每次说「I have adhd」就能压住啰嗦。反对的实验结果同样来自评论区：有人试过各种「简洁」指令，模型几轮之后就回退到默认风格；而给规则加上「为什么要这样」的理由（比如规则 6 背后是「ADHD 的时间盲区」），遵循的稳定性明显更好。这与提示词工程里的普遍经验一致：对齐过的理由比命令更抗上下文漂移。

更有意思的一层是命名的贡献。这个技能解决的核心问题——先给答案，还是先铺陈——和 ADHD 没有必然关系，任何扫描式阅读的人都受益。但「i-have-adhd」这个.repo 名提供了一个具体的、可共情的语境，让 10 条抽象规则有了靶子。评论区里 ADHD 人群对「把医疗状况当生产力梗」的批评真实存在，作者用「No ADHD diagnosis needed!」的副标题和一条中立副标题做了切割，最终是实用主义者赢了：一个名字带来的传播力，撑起了 34,000 次安装。

对普通开发者的实操结论有三条。第一，如果你在用 Claude Code、Gemini CLI 或兼容 skill 机制的工具，两条命令就能装上，试错成本接近零；嫌每次手动激活麻烦，就创建 ~/.claude/.i-have-adhd-always 开常开模式。第二，它不是万能的——评论区多位 Opus 5 用户报告技能「帮助有限」，模型本身的啰嗦倾向（比如 Claude 系的「反驳癖」）不是一层提示词能完全压住的，版本选择的影响可能比技能更大。第三，如果你自己维护任何 agent 规则文件，这个仓库的结构值得抄：规则正文件 + 六条例外 + 适配层分离 + 自建评测，尤其是「给自己定的门槛不过就不发布」这一步，是整个项目最硬核的部分。

仓库地址：ayghri/i-have-adhd（MIT 协议）。

来源：