i-have-adhd：让 AI 编程助手先给答案，再讲过程
你有没有遇到过这种情况：AI 编程助手明明知道怎么修，却先写三段背景、两种备选方案和一句 “这是个好问题”，真正要执行的命令藏在页面中间？
代码没有更难，答案也没有更聪明，只是读取成本被拉高了。你必须从礼貌开场、重复上下文和旁支建议里捞出下一步，再判断它究竟希望你改哪个文件、跑哪条测试。
今天 GitHub Trending 上的 ayghri/i-have-adhd 专门处理这个小而真实的问题。它是一套面向 AI 编程助手的输出 Skill，不要求使用者真的被诊断为 ADHD，也不修改模型能力。它只规定回答顺序：行动在前、步骤编号、限制岔题，并以一个明确的下一步收尾。
项目当前约 8.3k Stars，当天新增约 1.7k Stars，采用 MIT 协议，主分支已有 90 多次提交。仓库同时提供 Claude Code、Codex、Cursor、Gemini 等工具所需的插件或 Skill 目录，不只是一个贴在 README 里的提示词。
它解决的不是 “回答质量”，而是行动摩擦
大模型偏爱生成完整、礼貌、上下文充足的文字。这在解释概念时很有用，放进调试过程却容易出问题。
假设认证测试失败，普通回答可能先介绍中间件、Token 校验和 Cookie 的关系，再提出升级依赖、重写函数、检查全局版本等建议。内容大体正确，开发者仍要自己重组执行顺序。
i-have-adhd 希望把同一答案压成下面这种形态：
运行
npm install jsonwebtoken@latest，然后修改src/auth.ts:42。
- 打开
src/auth.ts- 替换第 42 到 58 行的
verifyToken- 运行
npm test -- auth.spec.ts下一步：如果失败，贴出第一行错误。
它没有让模型少做事，而是把 “你现在该做什么” 从说明文中提到第一屏。对频繁往返终端、编辑器和测试输出的开发者来说，这个调整比再多一段原理说明更直接。
十条规则如何约束编程 Agent
项目的核心只有十条规则，但覆盖了日常 Agent 对话最常见的摩擦点。
1. 下一步必须排在最前面
回答先给命令、文件位置或决策，不用 “我来分析一下” 热身。需要解释时，解释放在行动之后。这样一眼就能判断 Agent 是否理解了任务。
2. 多步骤任务必须编号
散落在段落中的命令很容易漏掉。编号后，安装依赖、修改代码、运行测试各自成为独立检查点，也方便你回复 “第 2 步失败了”。
3. 每轮只留下一个明确的下一步
传统助手常在结尾同时追问日志、环境、配置和复现步骤。这个 Skill 要求收口为一个动作，例如 “贴出第一个失败断言”，降低继续对话时的决策负担。
4. 压住旁支建议
修认证错误时顺手建议重构整个依赖树，通常只会扩大范围。规则要求 Agent 把无关建议藏起来，除非它们直接阻塞当前目标。
5. 每轮重述当前状态
长任务中最危险的不是回答短，而是忘记已经完成什么。Skill 要求每轮恢复任务状态，让中途接回会话时不用重新阅读几十条消息。
6. 时间估计必须具体
“很快”“稍等一下” 没有操作价值。它要求使用 “约 5 分钟”“还剩两个测试” 这类可判断的信息。模型无法精确预测时，也应说明估计依据，而不是制造虚假的确定性。
剩余四条分别是：让完成项可见、用平静事实描述错误、列表最多五项，以及禁止开场白、重复总结和客套结尾。组合起来的效果不是粗暴删字，而是把回答改造成一个轻量任务面板。
五分钟安装与使用
Claude Code 可以直接从插件市场安装：
1 | claude plugin marketplace add ayghri/i-have-adhd |
进入会话后执行：
1 | /i-have-adhd |
如果希望每次会话都启用，项目提供了一个标记文件方案：
1 | touch ~/.claude/.i-have-adhd-always |
Codex 的安装方式类似：
1 | codex plugin marketplace add ayghri/i-have-adhd --ref main |
显式调用时输入：
1 | $i-have-adhd |
Codex 也可以在识别到合适任务时隐式使用它。仓库还包含 .cursor/skills/i-have-adhd、gemini-extension.json、通用 .agents/plugins 目录以及独立的 INSTALL.md，便于把同一套输出规范带到不同 Agent。
安装后可以用一个真实任务验证效果：
1 | 修复支付接口的 3 个失败测试。每完成一个测试就更新状态； |
理想回复应该先报当前失败点，再给文件和命令，修复后显示 1/3、2/3、3/3，而不是先写一篇支付模块架构说明。
为什么不直接写进 CLAUDE.md
当然可以。把 “回答简洁一点”“先说结论” 写进项目规则，几分钟就能完成。i-have-adhd 的价值不在于这些句子难以发明，而在于它把零散偏好变成了可安装、可更新、可测试的产品。
与一段临时提示词相比，它有四个实际差异：
- 同一套规则可跨 Claude Code、Codex、Cursor 和 Gemini 复用；
- 有固定的十条约束，团队成员不必各自解释 “简洁” 的含义；
- 仓库包含
evals/、tests/、hooks 和 CI，而非只有一个 Markdown 文件； - 可以 Fork 后修改
skills/i-have-adhd/SKILL.md，形成团队自己的输出契约。
它和 Superpowers、Everything Claude Code 这类工作流框架也不同。后两者会规定如何规划、测试、调试和交付，影响 Agent 做事的方法；i-have-adhd 主要管理答案如何呈现。两者可以叠加：工作流 Skill 决定 “该做什么”，它负责 “怎么把下一步告诉你”。
适合哪些场景
它最适合高频、短反馈循环的工作：修测试、排查构建失败、逐步部署、处理代码审查意见，以及同时开多个 Agent 会话时快速确认每个任务的状态。
对团队来说，还可以把它当作输出规范的起点。比如要求所有 Agent 回答固定包含 “状态、动作、验证、下一步” 四项，再按团队习惯增加风险提示或回滚命令。
它也适合不喜欢长回答的人。项目名称突出 ADHD，但 README 明确写着 “不需要 ADHD 诊断”。本质上，这是一套降低信息检索成本的界面规范。
限制：短不等于对
这套 Skill 不会提升模型的代码能力，也不能保证命令安全。错误答案即使写得很短，仍然是错误答案。涉及删除数据、修改生产环境或迁移数据库时，开发者仍要检查 diff、备份和回滚路径。
严格限制列表最多五项，也不适合所有任务。架构评审、事故复盘、协议设计和教学文章需要保留推理背景。如果把每个问题都压缩成三行命令，重要的权衡和隐含条件可能被一起删掉。
“具体时间估计” 同样只能作为估算。Agent 无法预知下载速度、CI 队列或遗留代码复杂度，不应把 “约 10 分钟” 当成承诺。
还有一个边界：规则控制的是输出，不是执行。它可以要求 Agent 每轮重述状态，但真正的持久记忆、任务恢复和多 Agent 调度仍需专门工具负责。
总结
i-have-adhd 没有造一个更大的 Agent 框架，而是抓住了人与 Agent 协作里经常被忽略的一层：答案本身也是用户界面。
行动先行、步骤编号、压住岔题、显示进度、一次只给一个下一步，这些规则看起来朴素，却能把 “读完一篇说明再开始” 变成 “看第一行就能动手”。如果你每天都在 Claude Code 或 Codex 里处理短任务，安装它的成本只有几条命令，效果也最容易当场判断。