我们要振作精神，下苦功学习。下苦功，三个字，一个叫下，一个叫苦，一个叫功，一定要振作精神，下苦功。——毛泽东

https://github.com/ayghri/i-have-adhd

i-have-adhd：给编码代理装上一颗“不许绕弯子”的脑子

有些工具不是为了增加功能，而是为了纠正一种让人抓狂的习惯。i-have-adhd 就很像这样一个项目。它不负责写更多代码，不负责接更多接口，也不负责替代理上天入地。它盯上的，是另一件看似小、其实每天都在消耗人的事：回答明明可以一句话说清，却偏偏要先铺三层垫子，再绕五个弯，最后把真正有用的动作埋在中间。

这个仓库把自己的 description 写得异常干脆：A skill for your coding agent to stop it from burying the answer. ADHD-friendly output.
它的目标不是含糊的“优化表达”，而是非常具体地阻止编码代理把答案埋起来。

项目地址：https://github.com/ayghri/i-have-adhd

它不是一个新模型，也不是一套复杂系统，而是一种回答方式的矫正器

README 的一句话已经把它说透了：ADHD-friendly outputs. No ADHD diagnosis needed!

这句话很轻，却很有穿透力。它并没有把自己包装成某种严肃沉重的心理标签工具，也没有设置额外门槛，而是直接把重点放回输出体验本身：让回答更容易抓住重点，更容易执行，更不容易让人读到一半就失去线头。

这意味着 i-have-adhd 本质上是一种skill，用来约束编码助手的表达方式。它不改变助手知道什么，而是改变助手怎么说、先说什么、说到什么程度就该停。

它要解决的问题，其实很多人都太熟了

README 在 “What it does” 里写得很直白：

A skill for your coding assistant that stops it from burying the answer. Action first. Steps numbered. No “Hope this helps!”

这三句几乎像三记精准落点：

  • stops it from burying the answer
  • Action first
  • Steps numbered

最后再补一刀：

  • No “Hope this helps!”

光看这几句，就能立刻明白作者在对抗什么。那种“先热情寒暄、再长篇铺垫、最后含糊收尾”的代理式表达，在这个 skill 面前几乎没有藏身之处。它要的不是更客气，而是更可执行；不是更圆润，而是更快把人送到下一步。

最精彩的地方，是它把“前后对比”摆得一清二楚

README 里有一个非常生动的对照表，分别展示了 Before 和 After。

Before

是那种很多人一看就头皮发麻的回答方式：
先来一句“Great question! Let me think about this.”，然后开始解释“你的 auth flow 有几个 moving pieces”，再继续展开 middleware、token verification、cookie handling……真正该做的动作迟迟不落地。

After

它变成了这种样子：

Run npm install jsonwebtoken@latest, then edit src/auth.ts:42.

  1. Open src/auth.ts
  2. Replace verifyToken (lines 42–58) with the snippet below
  3. Run npm test -- auth.spec.ts

Next: paste the first failing line if any test fails.

这个对比非常有力，因为它没有抽象讨论“输出风格优化”，而是直接让你看见差别：以前是一团云，后来是一把梯子。以前回答像把你推到信息堆里自己找出口，后来则像一只手直接把第一块落脚石放到你脚下。

它最核心的，是那 10 条规则

README 里把规则压缩成了 10 条，并说明完整内容在 SKILL.md 中。仅凭这 10 条，已经足以看出整个 skill 的精神内核。

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

时间预估要具体，用“几分钟”而不是“很快”“一会儿”“稍后”。这让任务感变得可感知。

7. Make wins visible

要让进展可见。哪怕只是完成一小步，也要让“做成了什么”看得见。

8. Matter-of-fact errors

错误提示要就事论事，别情绪化、别戏剧化、别兜圈子。

9. Cap lists at 5 items

列表最多 5 项。这个限制本身就很有风格：不是不能多说，而是不准一口气倾倒太多东西。

10. No preamble. No recap. No closers.

没有前言，没有复述，没有收尾客套。不要“Great question”，不要“总结一下”，也不要“希望这对你有帮助”。

这十条组合起来，几乎像是给代理立了一套沟通军规。它们的共同目标只有一个：把可执行性从语言废雾里救出来。

它的安装方式也非常简洁，和项目气质高度一致

Claude Code

README 给出的安装命令是：

1
2
claude plugin marketplace add ayghri/i-have-adhd
claude plugin install i-have-adhd@i-have-adhd

之后输入：

1
/i-have-adhd

就可以启用这套输出风格。README 还特别说明：不需要本地 clone，Claude Code 会获取这个仓库并保持更新。

Codex

Codex 的安装方式是：

1
2
codex plugin marketplace add ayghri/i-have-adhd --ref main
codex plugin add i-have-adhd@i-have-adhd

启用时使用：

1
$i-have-adhd

README 同时说明，这个 skill 也可能在 Codex 识别到适合的任务时被隐式调用。

这两个安装过程都很短，也很符合项目本身的性格：不铺陈，不冗长，直奔主题。

它甚至允许你自己把这套“说话纪律”改造成私人口味

README 在 “Tune it” 里给出了一条很直接的路径：如果你想调整它，就 fork 仓库，编辑 skills/i-have-adhd/SKILL.md，然后安装你自己的 fork。

示例方式是：

claude plugin marketplace add <your-username>/i-have-adhd

这个设计很讨喜。因为沟通风格这件事，本来就很个人。有人想更冷静一点，有人想更强硬一点，有人想更简洁，有人想保留一点温度。项目没有把规则变成不可碰触的圣经，而是留出了定制空间。

它不是凭空长出来的，README 也交代了灵感来源

在 Credits 里，README 写得很明白：它loosely based on The Adult ADHD Tool Kit，作者是 J. Russell Ramsay 和 Anthony L. Rostain。
但同时也特别指出：这里的改编针对的是LLM 应该如何回应，而不是人类应该如何安排自己的一天。

这个界限划得很清楚。它不是把一本书生硬地搬进插件里，而是借用了其中的某些思路，重新转译成适合代理输出风格的规则集。

它的价值，不在“懂 ADHD”，而在“懂拖沓的伤害”

这个项目最容易让人误解的一点，可能恰恰在名字上。i-have-adhd 看起来像一个面向某类特定人群的工具，但 README 其实已经说得很清楚：No ADHD diagnosis needed。

这句话背后的真正意思是：它并不要求某种身份认同，它处理的是一种广泛存在的阅读与执行困境——回答太松散、重点太晚出现、动作不够明确、任务边界不清晰、支线太多、客套太重。

这些问题不只会困扰某一类人，几乎任何在高密度信息环境里工作的人，都很容易被这种表达方式消耗。尤其在编码场景里，很多时候人并不是不懂，而是没有精力穿过一大段语言泡沫，去捞那颗真正有用的钉子。

而 i-have-adhd 做的，就是逼代理先把那颗钉子递出来。

它像一张贴在代理额头上的便签：先说人该做什么

如果把这个项目拟人化，它不像一个功能庞大的工程师，更像一个站在旁边、时不时敲桌子提醒的编辑：

  • 先说结论
  • 先说动作
  • 步骤编号
  • 别岔开
  • 别啰嗦
  • 别客套
  • 最后只留一个下一步

它不负责替你解决一切，但它负责确保当代理已经知道答案时，不会再把答案藏进一团友好、完整、圆润、却令人分神的语言里。

为什么这样的小项目反而很容易让人记住

因为它解决的是一个每天都会发生、却常常被忽视的摩擦点。

很多项目在扩展代理的能力边界：让它会搜索、会写代码、会调试、会部署。i-have-adhd 则做了另一件同样关键的事：让代理在已经会的前提下，别把人拖累得更累。

它没有复杂架构，没有夸张功能树，也没有大段技术术语。它只做一件事：给编码代理加上一套更利落的输出纪律。可也正因为它做得这么聚焦，所以显得格外锋利。

你几乎可以把它理解成一种反本能训练。因为大多数模型天然倾向于解释、铺垫、补充、安抚、总结，而这个 skill 则像一把剪刀，专门去剪掉那些会把人注意力拖散的枝蔓。

它真正改造的，也许不是回答本身，而是协作节奏

一个回答如果总是把关键动作藏在中间，你每次都得读、找、筛、再决定下一步；久而久之，节奏就断了。
而一个回答如果能直接给出动作、编号步骤、交代状态、控制列表长度、只留一个下一步，你和代理之间的配合会变得更像接力，而不是像拆谜语。

这正是 i-have-adhd 最耐人寻味的地方。它看似只是在调整措辞，实际上是在调整一种协作节拍。它逼代理说话更像工具，也更像搭档：不抢戏，不绕路，不在你最需要迈步的时候递来一盆背景知识。

于是这个项目最终给人的感觉就像一句安静但很有力量的话：

别再埋答案了。先把路指出来。