用过 Claude Code 的人几乎都撞过同一堵墙：问了半小时，答案埋在第三段；改完一个 bug，它还要用两段话回顾自己做了什么，最后来一句”希望这有帮助”。
i-have-adhd 就干一件事——把 AI 的回答从”报告”改成”下一步做什么”。它用 10 条规则把输出重新塑形，上线 122 天拿到 43,456 颗星，是 2026 年增速最快的输出风格 skill 之一。更有意思的是：这个项目自带一套评测框架，而它自己公布的评测结果，发布闸门是失败。
它不是 CLI，是一份 142 行的规则文件
整个技能的本体，就是 skills/i-have-adhd/SKILL.md：7,207 字节、142 行，MIT 许可。没有模型、没有 API、没有依赖，任何 harness 都能装。
它的出发点是五条关于 ADHD 读者的判断：工作记忆小（不在屏幕上就等于忘掉）、知道答案不等于做完、启动是最难的一步、模糊的时间估计等于没有估计、进展必须看得见。十条规则全部由这五条推出来。
| 规则 | 治的毛病 | 我的一行判断 |
|---|---|---|
| 1 先说下一步动作 | 答案埋在下文 | 最有价值的一条，直接改变回答的第一行 |
| 2 多步骤写编号 | 步骤糊成一段话 | 要求”能少一步就少一步，别写完整路线” |
| 3 结尾给一个 2 分钟内能做的动作 | “还需要什么随时说” | 把开放式结尾换成封闭动作 |
| 4 抑制跑题 | 顺手塞三条无关建议 | 自己查得到的先自己查，留到最后的只有一条 |
| 5 每轮重述状态 | “第 3 步做到哪了”要靠翻记录 | “第 3/5 步完成，下一步回填列” |
| 6 给具体时间估计 | “这需要一些工作” | 明确要求用分钟，不许用”一会儿” |
| 7 让成果可见 | 改动藏在总结里 | “登录现在能用魔法链接了，跑 npm run dev 试” |
| 8 错误只讲事实 | “哎呀，测试好像失败了” | 位置 + 原因 + 修复，不演情绪 |
| 9 列表控制在 5 项 | 一屏 30 条的清单 | 争论最多的一条，见下文 |
| 10 不写开场白、不写回顾、不写客套 | “好问题！让我想想” | 直接禁止清单里点名了这些话术 |
关键的反直觉在于：它不追求短。规则 9 的原文明确写了”这条只塑形，不能限制分析、检索、工具结果、候选项生成”；技能里还专门留了一节”什么时候可以破例”，六种情况包括：用户要求解释就尽管展开、破坏性操作先确认、连续三次修不好就停下来质疑假设、”规则和任务打架时任务赢，形状不变”。最后一条的例子写得很清楚——用户问”我有哪些选项”，答案就该是 2 到 4 个带取舍排序的选项，而不是一条路径。
它的安装面铺得极广：仓库里的安装文档有 14 个章节，覆盖 Claude Code、Codex、Cursor、OpenCode、Gemini CLI、Kimi Code CLI、Qwen Code、Copilot、Pi、OMP、Zed、Antigravity、AstronClaw 等 13 个具名平台，外加一个通用 agent-skills 方式。但它没有发过任何 release，也没有 git tag，package.json 里的版本号停在 0.3.0——43k 星的仓库，走的还是”直接追 main 分支”的路线。
实测：自带评测框架跑得通，但它自己的闸门过不去
这个仓库最特别的地方，是它为了回答”这个 skill 到底有没有用”专门造了一套评测框架：14 条用例 × 3 轮 × 基线/候选两组 = 84 个回答，再用同一个模型盲评打分。
我把这套框架在沙盒里跑了一遍，是可以复现的：
python3 scripts/run_evals.py validate通过，14 条用例格式合法；
plan --trials 3能输出完整的运行矩阵（84 行生成 + 42 次评判）；
- 仓库自带的 51 个单元测试，6.77 秒全过。
作者公布的结果确实漂亮：加权分从 4.045 涨到 4.473。拆开看，简洁度维度涨得最猛（3.429 → 4.571），而权重最高的正确性（+0.190）和安全性（+0.024）也没掉——README 里那句“不是拿准确度换简洁”，在数字上站得住。
但同一份 RESULTS.md 往下读三行，写着 Release gate: FAILED。失败原因是闸门的第一条规则：”候选中不能有任何阻断性发现”。候选有 3 个，基线有 7 个，翻了一倍还多，照样不算过。
我把这个闸门单独复现了三次，结论很干净：
- 按公布的每用例均分重建（加权分 4.045 对 4.473，与我复现出的算数完全一致）、候选仍带 3 个阻断 → 不通过；
- 候选全维度满分 5.0、只保留 1 个阻断 → 不通过；
- 候选全维度 5.0、0 个阻断、基线 4.0 → 通过。
也就是说，规则 1 是一条绝对条款：只要用例集里还剩任何一个阻断性发现，再优秀的候选也过不了。RESULTS.md 自己把这层写透了——”按现在的写法，任何候选都不可能在还有阻断留存时通过，无论它改进了多少”。
更麻烦的是，14 条用例里有一条结构上不可能通过。agent-owned-edit 问的是”我让你改 README 的错别字，你有仓库权限，接下来怎么做”，评分要求”直接动手改，然后报告验证结果”。但两个 runner 的配置一个是 --tools ""，另一个是 --sandbox read-only——谁都没有工具。作者在 issue #98 里承认：这是”在一个没有行动能力的配置里要求智能体行动”，而且基线在这种不可能的任务上退化成了”我现在去读文件，让我用一下工具”这种自言自语。
真正的坏消息只有一条：partial-success 用例上候选回归了 −0.63 分（三轮分别是 +0.05 / −0.70 / −1.25）。机制被指得很准——规则 8 要求”先说原因，再给修复”，当证据不足以确定原因时，这个模板会推着模型去编一个原因。评判模型的批注原文是：”把『缺少认证头』当成确定原因并给出修复，没有任何证据支撑。”作者没有辩解，把它标成了”唯一值得加试验轮次的方向”。
顺带说，它的盲评机制不是口号：42 组（用例、轮次）的 A/B 标签由组名的 sha256 派生，我算出来 A/B 分布是 23:19，同一组重跑标签不变——结构上确实没给评委留下位置信息。
两个真实的坑：常开钩子会静默复活，中文文档缺两节
坑一：你说”关掉”，一次上下文压缩就给你打开。
Claude Code 上有个常开模式：把 flag 文件写到 ~/.claude/.i-have-adhd-always，之后每次会话启动由 SessionStart 钩子把整套规则注进去。我实测了：flag 不在时零输出，flag 在时每次注入 6,986 字节，而且 sh 版和 Node 版两个实现的输出逐字节一致。
问题出在匹配条件上。hooks.json 写的是 startup|resume|clear|compact——resume 和 compact 都是接着旧会话继续，但钩子本身只检查 flag 文件是否存在，全程不读 stdin（我把 hooks/ 目录全部文件 grep 了一遍，没有任何 stdin 或 source 字段的读取）。
于是我把 {"source":"compact"} 喂进去，输出和 startup 逐字节相同。意思是：你在会话里说了”停掉 ADHD 模式”，压缩一次之后规则会带着”ADHD 模式已激活，适用于每一条回复”的横幅重新注入，而钩子输出在界面上默认不可见。
这条不是我发现的——仓库有个叫 AI Agora 的讨论区（issue #127），专门让 AI agent 之间讨论规则措辞，提这条的 agent 在结尾署了 provenance：由 Claude Code（claude-opus-5）起草并验证。同一讨论区的另一条提案（opencode 配 GLM-5.3 起草）指向的正是规则 8 的编原因问题，和评测里的回归对上了。这些提案目前都还没被合并。
坑二：中文安装文档比英文少两节。
.github/install/INSTALL.zh-CN.md 有 12 个平台章节，英文版有 14 个：OMP（Oh My Pi）整节缺失，OpenCode 被并进”其他运行环境”的通用段落里。另外规则的缩写版散落在 13 个文件里，光 INSTALL.md 一个文件就复制了 6 份规则清单——想改一条规则，得同时改十几个地方。
同类项目里，规则 9 至今还在改。15 条评论的 issue #96 里，用户反馈”控制在 5 项”被模型字面执行成”砍掉第 6 项之后的全部”，作者前后给了三版措辞，当前版本的解法是加一句”多余的条目内部保留，只是不显示”。
和同类比，它站在哪个位置
| 项目 | 星数 | 层次 | 核心手段 |
|---|---|---|---|
| i-have-adhd | 43,456 | 结构层 | 10 条规则重排回答形状：先动作、编号、重述状态 |
| Caveman | 105,244 | 语言层 | 用洞穴人语体压缩输出，宣称省 65% token |
| stop-slop-zh | 47 | 语言层（中文） | 禁词表 + 标点规范 + 四层质检，专治中文 AI 味 |
Caveman 和历史榜首那批项目在同一条赛道上：压语言、省 token。i-have-adhd 换了个层面——它几乎不省字，改的是信息的顺序和可见性。issue #4 里就有人问能不能把两者合体，作者的回答是”这个仓库只做 ADHD 相关规则，想合请自己 fork”。
stop-slop-zh 的对比尤其值得看一眼：它的作者跑到 issue #42 里问”把结构收紧，模型会不会把冗余转移到句子层面”，i-have-adhd 的作者直接承认”结构本身不够，句级清理放在发送前检查那一步”，并说”塑完形状，填充物会跑进句子里，然后你追着它跑”。两个作者都确认：严格规则能抬高下限，也会削平上限，所以两边都加了”默认而非绝对”的逃生舱。
适合谁：日常在 Claude Code / Codex / Cursor 里跟 Agent 来回拉锯、经常要翻半天找结论的人；团队里要让 AI 输出变成可执行步骤的负责人。不适合谁：主要用 AI 做长文写作和头脑风暴的人（它专门为”解释模式”开了豁免，但你本来也不需要它）；指望它省 token 的人（要省 token，去看 Caveman）。
值得装，但要知道它的三处短板
我的判断是：装，但要把它当一个需要维护的规则集，而不是一个装完就忘的插件。三条注意事项——第一，Claude Code / Codex / Qwen Code 上它默认不自动生效，必须显式调用 /i-have-adhd；第二，上下文压缩或分叉会话会让它掉线或静默复活，觉得输出漂回老样子，重新调用一次是最省事的解法；第三，别把它当成”AI 输出质量的保证”——它有一份诚实到罕见的自评报告，评的是回答形状，不是回答对不对。
顺带一个可以偷师的点：这个仓库把”我怎么证明自己有用”写成了可复现的代码（14 条用例、盲评、发布闸门、成本上限），还允许 AI agent 在专门议题里提交带模型署名的提案。做开源项目的人比做 skill 的人更该抄这套东西，因为它把”我改进了多少”从口嗨变成了能被别人跑出来的数字。
关注 AI 商业快讯，每天一篇 AI 热点深度解读。
相关阅读：
本文数据于 2026-09-13 抓取：仓库 star 数、fork 数、提交时间来自 GitHub API；仓库结构与评测运行结果来自本机 Alpine aarch64 沙盒实测（run_evals.py validate / plan、pytest 51 项、闸门三场景复现、always-on 钩子两种实现对比）。评测框架中的模型打分沿用作者 2026-08-02 公布的数据，非本人重跑，已如实标注。