1. 一个名字就说明一切的技能包i-have-adhd 到底在解决什么问题第一次看到i-have-adhd这个名字我差点以为是某个自嘲式的个人状态标签。直到把它拉进项目里跑了一遍才反应过来——这是一个专门给 AI 编码助手用的行为约束技能包名字本身就是它的核心指令让 AI 在回答之前先假设提问的人有 ADHD注意力缺陷多动障碍。这个思路乍一听有点整活但用过之后你会发现它精准命中了当下 AI 辅助编程里最让人抓狂的痛点。我们平时让 AI 帮忙写代码、查 bug、解释报错得到的回复往往是这样的先来一段这个问题通常由以下几个原因导致然后列五条可能性每条再展开三段分析最后给一个你可以尝试以下方法的清单。信息量确实大但你真正想要的可能只是——告诉我改哪一行。i-have-adhd干的事情就是把这个默认行为彻底翻转。它通过一套技能skill定义强制 AI 助手在输出时遵循一套极度克制的规则先给答案再给理由能一句话说清就不写一段能直接给代码就不写解释把最重要的行动项放在最前面。说白了它是在给 AI 装一个别废话的开关。这个技能包适合谁我梳理了三类人。第一类是真的被信息过载困扰的开发者尤其是那些在多任务之间频繁切换、需要快速拿到可执行结论的人。第二类是把 AI 编码助手当日常工具的重度用户比如用 Claude Code、Cursor、各类 CLI 助手的人他们每天要问几十上百个问题每次回复多绕三句话一天下来就是巨大的时间损耗。第三类是对 AI 输出风格有明确偏好的人他们不想要教科书式的完整回答只想要同事式的干脆利落。需要提前说明的是这个技能包本身不是什么复杂的软件系统它的本质是一份写给 AI 看的指令文档配合特定工具的技能加载机制生效。所以理解它的关键不在于代码有多难而在于它把如何跟 AI 沟通这件事从模糊的感觉变成了一套可复用的规则。这也是我觉得它值得单独拿出来讲的原因——它代表了一种正在成型的实践用结构化的方式管理 AI 的输出行为。2. 为什么给 AI 加约束这件事突然变得重要了2.1 默认 AI 输出为什么总是太长要理解i-have-adhd的价值得先搞清楚 AI 助手为什么天生话多。这跟模型的训练方式直接相关。大模型在训练阶段被大量完整、礼貌、结构化的文本喂养——教程、问答、文档、论坛回复。这些文本的共同特征是先铺垫背景再分点论述最后总结。模型学到的就是这套模式所以它默认认为好的回答等于全面的回答。再加上一个现实因素AI 产品在早期竞争时普遍把回答详细当作质量指标。用户看到一大段输出会觉得这个 AI 很认真。于是模型被进一步强化了多说的倾向。结果就是你问一个这个报错什么意思它能给你写出一篇小论文。问题在于详细和有用是两回事。在真实的开发场景里你往往已经知道背景你缺的只是那个具体的答案。多余的铺垫对你来说不是帮助是噪音。这就是i-have-adhd要解决的第一个矛盾AI 的默认输出粒度和用户的实际需求粒度不匹配。2.2 ADHD 视角带来的设计启发这个技能包最聪明的地方是它没有用简洁这种模糊的词来约束 AI而是借用了 ADHD 这个具体的人群特征作为设计锚点。ADHD 的典型表现包括注意力容易被打断、难以处理长段落、需要即时反馈、对延迟满足耐受度低。把这些特征翻译成对 AI 输出的要求就得到了一套非常具体的规则答案前置最重要的结论必须出现在第一句不能藏在第三段。短段落每段控制在几行以内避免大块文字墙。行动导向优先给做什么而不是为什么。减少分支不要一次抛五个可能性先给最可能的那一个。视觉锚点用加粗、列表、代码块让关键信息一眼可见。这套规则的好处是它可执行、可检验。你说请简洁一点AI 不知道简洁到什么程度你说假设读者有 ADHD答案前置、每段不超过三行AI 就有了明确的边界。这是我在实际使用中体会最深的一点约束越具体AI 的执行越稳定。2.3 它和普通提示词技巧的区别市面上讲提示词的内容很多但大多是零散的技巧比如加一句请一步步思考或者让它扮演某个角色。i-have-adhd的不同在于它是一份成体系的、可复用的技能定义而不是一次性的提示词。区别体现在三个层面。第一它是持久化的。你不需要每次对话都重新粘贴一遍要求只要技能被加载规则就一直生效。第二它是结构化的。它把输出规范拆成了明确的条目而不是一句笼统的请简洁。第三它是可组合的。你可以把它和其他技能叠加使用比如在需要详细解释的时候临时关掉它在需要快速定位的时候打开它。我个人的判断是这类行为约束技能会越来越普遍。因为 AI 的能力已经足够强瓶颈不再是它能不能做而是它能不能按你要的方式做。i-have-adhd正好卡在这个位置上。3. 核心机制拆解一份技能文档是怎么改变 AI 行为的3.1 技能加载的基本原理在讲具体内容之前先把这个技能包的工作方式说清楚不然容易误解成某种插件或外挂。实际上它的运行机制非常朴素把一份写好的指令文档注入到 AI 助手的上下文里。具体流程大致是这样的。技能包以目录形式存在里面有一个描述文件通常声明技能的名称、用途、触发条件和一份核心指令文档。当 AI 助手启动或检测到相关场景时会把这份指令文档的内容读进上下文作为系统级的行为约束。之后你所有的提问AI 都会在这套约束下回答。这意味着两件事。第一它不改变模型本身的能力只是改变了输出的组织方式。第二它的效果高度依赖指令文档写得够不够清楚。如果文档里全是请尽量简洁这种软性表述效果会很有限如果文档里是第一句必须是结论禁止使用首先/其次/最后这类过渡词效果就会非常明显。提示技能加载的具体路径和触发方式不同工具的实现不一样。有的工具会自动扫描技能目录有的需要手动在配置里声明。用之前先确认你的工具支持哪种方式别想当然。3.2 指令文档里到底写了什么虽然不同版本的i-have-adhd细节会有差异但核心规则是相通的。我把它归纳成几个关键约束这些也是它真正起作用的地方输出顺序约束。要求 AI 把结论、答案、可执行的操作放在最前面。解释、背景、原理放在后面而且必须是读者主动想看才展开。这一条直接对抗了模型先铺垫后结论的默认习惯。长度约束。对段落长度、总长度都设了上限。比如单段不超过三到四行整体回答尽量控制在一个屏幕内。超过这个长度就说明有信息可以砍。格式约束。明确要求用短列表、加粗关键词、代码块来承载信息而不是用长句描述。这一点对 ADHD 视角特别关键——视觉上的结构感能大幅降低阅读负担。语气约束。禁止客套话、禁止希望这对你有帮助这类收尾、禁止重复用户的问题。直接进入正题。分支约束。当存在多个可能原因时先给最可能的一个并说明如果不对再看下一条而不是一次性铺开所有可能性。这几条约束组合起来效果就是 AI 的回答从论文变成了便签。信息密度反而更高因为你不用在废话里淘金。3.3 为什么这些约束能生效有人可能会问AI 真的会老老实实遵守这些规则吗我的实测答案是大部分时候会但不是 100%。这背后的原因值得说清楚。模型对指令的遵循程度取决于指令的具体性和位置。越具体、越靠前、越像硬规则的指令遵循度越高。i-have-adhd的指令文档之所以有效是因为它把要求写成了接近格式规范的东西而不是风格建议。模型对前者的执行力明显更强。但也要承认局限。当问题本身很复杂、需要多步推理时模型有时会忘记约束又滑回详细模式。这时候需要你在提问时再补一句提醒比如按技能规则回答。这不是技能包的问题是当前模型能力的边界。注意不要指望加载了技能就一劳永逸。把它当成默认档位遇到复杂问题时手动加一句强化效果最稳。4. 实操从零把这个技能包用起来4.1 环境准备与获取方式这部分我尽量讲得通用一些因为不同工具的接入方式差别不小但核心步骤是一致的。第一步确认你的 AI 编码助手支持技能skill机制。目前主流的几类 CLI 助手和编辑器插件大多有类似的功能只是叫法不同——有的叫 skill有的叫 rule有的叫 custom instruction。判断标准很简单能不能加载一份外部文档并让它持续影响 AI 的行为。能就说明支持。第二步获取技能包。i-have-adhd通常以开源仓库的形式分发你可以直接克隆到本地也可以手动创建目录结构。目录一般长这样i-have-adhd/ ├── SKILL.md # 技能描述与触发说明 └── instructions.md # 核心行为约束文档第三步把技能目录放到工具约定的位置。常见的位置包括项目根目录下的.skills/、用户配置目录下的skills/或者工具指定的任意路径。具体放哪查你所用工具的文档别猜。第四步在工具的配置里声明这个技能。有的工具是自动扫描有的需要你手动加一行配置指向技能目录。这一步做完重启工具或重新加载配置。4.2 验证技能是否生效加载完别急着用先做个验证。方法很简单问一个你明知道答案的问题看 AI 的输出结构。比如你问Python 里怎么把列表去重。如果技能生效回答应该是类似这样的第一句直接给list(set(my_list))然后补一句这会打乱顺序要保序用dict.fromkeys结束。如果技能没生效你大概率会看到一段关于去重有多种方法的铺垫然后分点列举三四种方案。我一般会准备两三个这样的探针问题每次换环境或更新配置后跑一遍确认技能还在正常工作。这个习惯帮我省了不少以为加载了其实没生效的冤枉时间。提示如果验证发现没生效先检查技能目录路径对不对再检查配置有没有写错最后检查工具版本是否支持。按这个顺序排查基本能定位到问题。4.3 日常使用中的几个关键动作技能生效之后日常使用其实没什么特别的但有几个动作能让它发挥得更好。提问时给足上下文但别啰嗦。技能约束的是 AI 的输出不是你的输入。你该说清楚的背景还是要说清楚比如我在用某个框架的某个版本报了这个错。输入越精准AI 越不需要靠猜来补全输出也就越短。复杂问题主动降级。遇到需要多步分析的问题别硬套简洁模式。你可以先让 AI 用简洁模式给结论再单独追问展开说说第二步。这样既拿到了快速答案又能在需要时深入。定期回看技能文档。如果你觉得 AI 最近又开始话多了很可能是技能文档被更新覆盖了或者工具升级后加载方式变了。花两分钟检查一下比忍受一周的废话划算。5. 效果对比与真实场景拆解5.1 同一问题的两种回答光说原理不够直观我拿一个真实场景对比一下。假设你问 AI我的程序跑起来报KeyError怎么排查没有技能约束时典型回答是这样的先解释KeyError是什么然后说它通常由几种情况导致接着分点列出键不存在键拼写错误数据类型不匹配等等每种情况再给一段说明最后给一个建议你检查以下几点的清单。整段下来三四百字你读完还得自己判断哪个最可能。加载i-have-adhd之后回答会变成第一句先打印出报错那一行的字典看它实际有哪些键然后大概率是键名拼写或大小写不一致再补一句如果是动态键检查生成键的那段逻辑。三句话直接指向行动。这个对比说明的不是哪个更正确而是哪个更适合当下的你。当你正在调试、急着定位问题时第二种明显更省事。5.2 不同场景下的适配策略i-have-adhd不是万能的它有明确的适用边界。我按场景整理了一下场景是否适合开启原因快速查 API 用法适合你要的就是那一行代码调试报错定位适合需要快速缩小范围代码审查建议适合重点问题优先细节可后补学习新概念不太适合需要铺垫和循序渐进架构方案设计不太适合需要权衡和多角度分析写文档/注释看情况取决于文档面向谁我的做法是按任务类型切换。写代码、查错、快速验证想法时开着学新东西、做方案对比时关掉。技能包的价值在于它给了你一个档位而不是逼你一直用同一个档位。5.3 一个完整的实操案例说个我自己的使用场景。有次我在处理一个数据清洗脚本跑出来结果对不上怀疑是某一步的过滤逻辑有问题。我开着i-have-adhd问了一句这个过滤条件为什么把不该过滤的行也滤掉了AI 的回答是第一句你的条件用了and但两个判断里有一个是字符串比较类型不匹配会静默失败然后直接给出修正后的条件最后补一句加个print确认过滤前后的行数。整个过程不到十秒我改完就验证通过了。如果换成默认模式我大概要先读一段关于过滤逻辑常见问题的分析再自己从中挑出可能的原因。这个差距在一天几十次提问的累积下是实打实的时间。6. 常见问题与避坑经验6.1 技能不生效怎么办这是被问得最多的问题。排查顺序我总结成一张表现象可能原因处理方式完全没变化技能没被加载检查目录路径和配置声明时好时坏上下文被其他指令覆盖减少冲突的全局指令复杂问题失效模型推理时忽略约束提问时补一句按技能规则更新后失效工具升级改了加载机制查新版本文档重新配置我踩过最坑的一次是技能目录放对了但配置里路径写的是相对路径而工具的工作目录变了导致加载失败。后来改成绝对路径就稳了。这种问题不报错只是没效果特别容易让人以为是技能本身不行。6.2 过度简洁带来的风险简洁是有代价的。最典型的风险是丢失关键前提。比如 AI 为了简短直接给了一个方案但没说这个方案在某个版本下不适用。你照着做了结果踩坑。我的应对办法是在关键决策点上主动追问。当 AI 给的答案涉及版本、环境、边界条件时我会补一句这个方案有什么前提。这样既保持了整体简洁又在必要的地方补上了安全网。注意简洁不等于省略风险提示。涉及数据删除、生产环境操作、不可逆改动时一定要主动要求 AI 说明后果。6.3 和其他技能的配合i-have-adhd很少单独用。实际项目里我通常还会加载一些领域相关的技能比如特定框架的规范、团队的代码风格约束。这时候要注意技能之间的优先级和冲突。经验是把输出风格类的技能比如i-have-adhd和领域知识类的技能分开管理。风格技能管怎么说领域技能管说什么两者一般不冲突。但如果两个技能都对输出格式提要求就可能打架。遇到这种情况明确告诉 AI 以哪个为准。7. 我对这类行为约束技能的看法用了一段时间之后我越来越觉得i-have-adhd代表的方向比它本身更重要。它证明了一件事AI 的输出质量不只取决于模型能力还取决于你怎么约束它。同一个模型加不加这层约束用起来像两个不同的工具。这也让我重新思考提示词工程这件事。过去大家把精力花在怎么问得更好现在开始有人把精力花在怎么让 AI 稳定地按某种方式回答。后者更像是配置而不是技巧。配置的好处是可复用、可传承、可版本管理。你把一套约束写进技能文档团队里每个人都能用新人不用重新摸索。我个人在实际操作中的体会是别把这类技能当成省字数的工具它真正的价值是降低认知负担。当你不用再在一堆铺垫里找答案你的注意力就能留给真正需要思考的部分。对开发者来说注意力才是最稀缺的资源。最后分享一个小技巧如果你觉得i-have-adhd的约束太狠可以自己改指令文档把每段不超过三行放宽到五行或者允许在复杂问题上展开。技能文档是纯文本改起来没有门槛。找到适合自己节奏的那个档位比照搬别人的配置更重要。