8k星!10条规则让AI编程助手闭嘴说人话,这个「ADHD插件」凭什么刷爆GitHub

一、你有没有遇到过——AI明明知道答案，但每次都要绕三圈才说出来

你有没有遇到过这样的场景——

你问 Claude Code 一个认证问题，它说："Great question! Let me think about this. Your auth flow has a few moving pieces..."

你心想：别铺垫了，直接告诉我改哪行代码。

然后它继续说："One approach would be to update the package and rewrite that function..."

你已经开始焦虑了——你只想让它说「运行这条命令，改这个文件，跑这个测试」，但它偏不。

最后它用一句"Hope this helps! Let me know if you want to dig deeper."收尾，而你已经在心里翻了个白眼。

这不是你的问题。这是 AI 编程助手的默认回答风格的问题。

它们被训练成「热情、细致、面面俱到」——对客服场景来说很好，对编程场景来说，这叫信息噪音。

而这个月，一个叫 i-have-adhd 的 GitHub 项目，用10条规则 + 一个50行的 SKILL.md 文件，在两周内从1100星冲到 8000星，登上了 GitHub Trending 第三名。

它不训练模型，不改推理引擎，不加任何新能力。它只改一件事：AI 怎么说话。

二、这个东西是什么——不训练、不微调，就是一个「输出格式约束文件」

i-have-adhd 的本质简单到让你觉得"这也算项目？"

它是一个 Claude Code / Codex / Cursor / Gemini CLI / GitHub Copilot 的 Skill（技能插件），安装命令只有一行：

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

然后输入 /i-have-adhd，你的 AI 编程助手就变了个人。

核心内容就是一个 SKILL.md 文件，里面定义了 5个 ADHD 认知事实 和 10条输出规则。

先说这5个事实——它们不是随便写的，每一条都来自 ADHD 认知科学：

这五条不是 AI 的问题——这是所有人的问题。只不过 ADHD 人群的体验更极端，而工程师用 AI 编程时，恰恰处在一个类似 ADHD 的状态：频繁切换上下文、注意力碎片化、需要立刻看到可执行的动作。

三、10条规则逐条拆解——每一条都在打AI默认回答的"七寸"

规则1：第一行就是行动

你问「这个依赖怎么升级」，它的第一行必须是 npm install jsonwebtoken@latest，而不是「让我想想，你的认证流程有几个环节...」

被打的七寸：AI 默认回答的「铺垫惯性」。Claude 被训练成先共情、再分析、再建议——但编程场景不需要共情，需要指令。

规则2：多步骤任务必须编号

如果工作超过一步，写成编号列表。每条一步，不出现"然后...然后..."。能砍掉的步骤就砍掉，宁可路径短一点，也比路径完整但读者半路放弃强。

被打的七寸：AI 喜欢把简单的事说成一锅粥，读者需要自己在粥里捞步骤。

规则3：以一个具体的「下一步」收尾

不说"Hope that helps. Let me know if you want to dig deeper." 而是说"Next: run npm test and paste the first failing line."

被打的七寸：AI 的收尾套话——看似礼貌，实则是把「接下来该干什么」的认知负担踢回给用户。

规则4：主动压制跑题

如果代码里顺便发现了另一个问题，先把手头的事做完，再问「另外还有一个问题，要我帮你处理吗？」而不是一口气把所有发现都倒出来。

被打的七寸：AI 的「知无不言」本能——它看到什么都想说，但你的大脑同时处理不了三个独立任务。

规则5：每轮对话重新陈述状态

不说"完成了，下一步？"，而是说"第3步/共5步完成：schema已更新。下一步：回填新列，运行脚本？"

被打的七寸：AI 假设你记得上一轮对话的上下文——但你很可能已经切了三个窗口、回了五条消息了。

规则6：给具体的时间估算

不说"这需要一些工作"，而是说"如果测试已覆盖，约15分钟；如果没覆盖，可能一个下午。"

被打的七寸：AI 默认的模糊时间表达——"一会儿"和"三小时"在工程师的日程表里是完全不同的决策依据。

规则7：让完成的进展可见

不说"我改了一些认证相关的东西"，而是说"登录现在支持 magic link 了。试试：npm run dev，打开 /login。"

被打的七寸：AI 把胜利埋在复盘里——但对 ADHD 大脑来说，可见的进展 = 多巴胺 = 继续工作的动力。

规则8：错误就用就事论事的语气

不说"Uh oh, the test is failing. There seems to be an issue..." 而是说"Test fails at auth.spec.ts:42: expected 200, got 401. Cause: missing auth header. Fix: add Authorization: Bearer ${token}."

被打的七寸：AI 被训练成对错误「友善地表达遗憾」——但工程师不需要情绪安抚，需要「原因 → 修复」的直线。

规则9：列表最多5项

超过5项就拆成「现在做」和「稍后做」，或者「必须」和「最好」。5项排序的列表，比10项无排序的列表有用10倍。

被打的七寸：AI 喜欢穷举所有可能性——但人的工作记忆容量就是 5±2 项。

规则10：禁止开场白、禁止复盘、禁止收尾客套

禁用的开场白："Great question", "Let me...", "I'll...", "Sure!", "Looking at your...", "To answer your question..."

禁用的复盘："I've now done X, Y, and Z, which means..."

禁用的收尾："Let me know if you need anything else", "Hope this helps", "Happy to clarify", "Feel free to ask."

开始就是答案，结束就是结束。

四、它不只是"让AI说得短一点"——有完整的评测体系

很多人看到 i-have-adhd 的第一反应是："不就是让 AI 别废话吗？我也可以在 system prompt 里写'请简洁回答'。"

你说得对，但这恰恰是这个项目高明的地方——它证明了「请简洁回答」远远不够。

7月22日，项目新增了一套完整的评测体系（evals/ 目录），用14个测试用例、5个维度来评估输出质量：

注意这五个维度的权重设计——正确性只占35%，而自主性+可操作性占了45%。

这反映了一个深刻的认知：对一个编程助手来说，正确但不可操作的回答，比错误但可执行的回答更糟糕。因为前者让你反复追问，后者让你快速发现错误。

评测还设了严格的发布门槛（Release Gate）：

• 无阻断性发现（blocker = false）
• 正确性和安全性在基线 ±0.1 分以内
• 加权总分高于基线
• 所有对比使用相同的测试集、模型和评分标准

这不是一个「作者觉得好用就行」的项目，这是一个有工程严谨性的产品——虽然它的核心代码只有50行。

五、为什么爆火——Skill经济的「第三波」

回顾7月 GitHub AI 趋势，你会发现一个清晰的进化轨迹：

你看，第一波在解决「成本问题」，第二波在解决「质量/数量问题」，第三波在解决「体验问题」。

i-have-adhd 两周内从1000星冲到8000星，不是因为它的技术有多复杂，而是因为它触碰了一个每个人每天都在经历的痛点：AI 写得多但不一定有用，说得多但不一定好懂。

但这种"简单"背后是有代价的——作者自己也明确列出了不适用的场景：

1. 需要安全审计的操作（删库、改权限）——缺少解释可能引发事故
2. 探索性调试（你自己也不知道问题在哪）——推理链条本身有提示价值
3. 非代码类问答（架构比较、概念解释）——过度压缩可能丢失关键差异

这也是为什么 SKILL.md 里专门写了6条「例外规则」，包括「破坏性操作要先确认」、「调试循环3轮后要反思假设」、「真正模糊的需求要做一次简短澄清」。

简洁不是目的，把事儿办成才是目的。

六、给我们的启示：AI编程的下一个战场是「人机交互」

i-have-adhd 给我们三个启示。

第一个启示：AI 编程助手的第一性瓶颈，不是模型能力，是信息消费带宽。

过去两年，所有人都在卷模型：更大的参数量、更长的上下文、更强的推理。但我们忽略了一个简单的事实——如果输出质量很高，但你需要花5分钟在文字里找答案，那输入质量对你来说等于零。

i-have-adhd 的价值不在于让 AI 更聪明，而在于让 AI 更容易被理解。它本质上是一个 「信息压缩协议」：把相同的正确信息，压缩到最小认知负荷的表达形式里。

第二个启示：Skill 正在从「功能插件」进化成「输出范式」。

caveman 压缩 Token，ponytail 压缩代码量，i-have-adhd 压缩表达冗余——这三个项目没有新增任何「能力」，它们改变的都是一种输出范式。

这意味着，AI Agent 的能力天花板，很多时候不是模型决定的，而是提示词工程决定的。一个精心设计的 SKILL.md，可以把同一个模型的表现从「还行」提升到「好用」。

还记得 system_prompts_leaks 告诉我们的吗？ChatGPT 的 system prompt 有 89 条安全规则。Claude Fable 5 的 system prompt 有 24,000 tokens。这些「出厂设置」本质上是产品设计文档——同样的模型，不同的提示词，完全不同的体验。

i-have-adhd 证明了：普通开发者也可以写自己的「出厂设置」，而且社区的投票（8000星）说明，这个需求远比想象中更普遍。

第三个启示：工程化的下一步是「个性化 Agent 交互风格」。

想象一下：未来的编程 Agent 不只支持「模式切换」——简洁模式、解释模式、安全模式——它应该像一个真正的团队成员，了解你的偏好。

你喜欢 Spring Boot 的写法风格还是更贴近底层？你习惯先看到 UML 类图再读代码，还是直接看代码？你的注意力和时间有什么特点？

i-have-adhd 只是一个起点。它打开了一扇门：AI 编程助手的交互体验，是一个可以系统化设计、评测、迭代的产品维度，而不是一个「模型决定了就这样」的既定事实。

七、总结

i-have-adhd 用10条规则 + 一个50行文件做了一件看似微小但极其准确的事：它让 AI 的回答从「我来说给你听」变成了「你去做就行」。8000个开发者用星标投票——在AI越来越会说的时代，「说人话、说短话、说有用的话」是一种稀缺能力。

安装它只需要一行命令：

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

然后说 /i-have-adhd，你的编程助手就会变成一个「不说废话的实干家」。

试试看。如果它帮你少滚动了一次屏幕来找答案，去给项目一个 Star。

项目地址：github.com/ayghri/i-have-adhd^[1] 许可证：MIT 当前数据：8,000+ Stars | 7月23日 GitHub Trending #3

引用链接