企业官网建设流程全解析

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不是万能的，它有明确的适用边界。我按场景整理了一下：

我的做法是按任务类型切换。写代码、查错、快速验证想法时开着；学新东西、做方案对比时关掉。技能包的价值在于它给了你一个"档位"，而不是逼你一直用同一个档位。

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的约束太狠，可以自己改指令文档，把"每段不超过三行"放宽到五行，或者允许在复杂问题上展开。技能文档是纯文本，改起来没有门槛。找到适合自己节奏的那个档位，比照搬别人的配置更重要。