技术 · 2026-09-13
I-have-ADHD 上线:Claude Code Skill 协议让 Agent 不再把答案埋进日志,以及企业 Coding Agent 输出层的新基线
技术
2026-09-13
阅读 22 分钟
8,572 字
# I-have-ADHD 上线:Claude Code Skill 协议让 Agent 不再把答案埋进日志,以及企业 Coding Agent 输出层的新基线 2026 年 9 月 8 日,一个名叫 `i-have-adhd` 的开源项目在 Hacker News 上炸出了 537 个 upvotes 和 371 条评论——这是 Show HN 历史上少见的"非工具、非框架、纯 prompt 规
# I-have-ADHD 上线:Claude Code Skill 协议让 Agent 不再把答案埋进日志,以及企业 Coding Agent 输出层的新基线
2026 年 9 月 8 日,一个名叫 `i-have-adhd` 的开源项目在 Hacker News 上炸出了 537 个 upvotes 和 371 条评论——这是 Show HN 历史上少见的"非工具、非框架、纯 prompt 规约"项目能拿到这种量级的关注。项目本身非常简单:它就是一个 MIT 许可的 Claude Code skill 文件,装上之后,coding agent 的每一条回复都会按"行动先行、编号步骤、不啰嗦开头、不总结回顾"的格式重新排版。配合官方的 install 一行命令(几秒钟接入),这个 skill 在 GitHub 上累计到 31K+ stars,被官方技能市场(claudemarketplaces、skillselion、skills.sh)同时收录,变成今天 Claude Code、Cursor、Codex、Gemini CLI、OpenCode 这些主流 coding agent 几乎默认会装的一个 skill。
本文把 Hacker News 上 49610631 这条原帖(2026-09-08)里的真实工程讨论、官方 SKILL.md 的核心条款、官方落地页(skillselion 等)公布的安装量/兼容矩阵,合并改写成一篇"为什么这件事对 coding agent 落地如此重要、它解决了什么企业级问题、又留下了什么没解决的边界"的分析。
## 一、coding agent 的"日志式输出"是怎么变成问题的
Claude Code、Cursor、Codex 这一代 coding agent,本质上是个对话式的"工具调用循环":用户发消息,Agent 思考要不要调工具,调完工具再想下一步,直到自认为答完用户的问题。这套机制在底层会让 Agent 倾向于"长输出 + 重复确认 + 大量中间日志",理由很简单:模型被 RLHF 训练出来的"礼貌"和"详尽"偏好,加上多步 tool call 的中间过程本来就需要可见。但这条默认偏好对开发者来说几乎是一场灾难——打开 Claude Code 的回放,你会看到 Agent 在做了一件小事之后,先复述问题、再列出三个备选、再权衡利弊、再给出最终答案、再补充一句"如果你需要我可以……",真正干活的一句话被埋在几百个 token 的"前奏"里。
Hacker News 上 49610631 这条帖子下面被顶最多的几条评论,基本都集中在同一个工程体感上:"Agent 知道答案,但就是不肯先把答案说出口。"一位用户说"我只要 /i-have-adhd 之后,Claude Code 就会立刻告诉我下一步该做什么";另一位说"现在我直接跟 Agent 说'I have adhd, explain like I'm 5',也能拿到差不多的效果";还有人指出"很多时候一句'Be concise'就够了"。这些评论合并起来的工程含义是:**Agent 的输出格式是产品的一部分,而不只是装饰**——同一个模型、同一个 prompt、同一个工具链,因为输出格式不同,开发者能拿到的实际产出质量差几个量级。
i-have-adhd 之所以能拿到 537 个 upvotes,是因为它做对了一件小事:把开发者已经知道但懒得每次都敲的 prompt 模板,固化成一个 MIT 协议、几秒钟安装、所有主流 coding agent 都兼容的 skill 文件。这条路线的成功把"输出格式"这件事正式拉到了 coding agent 落地讨论的中心。
## 二、SKILL.md 的 10 条规则到底写了什么
i-have-adhd 项目的核心是 `skills/i-have-adhd/SKILL.md` 这份说明文件,GitHub 仓库全文加起来大约 8700 行(包含插件/适配器),但 SKILL.md 本身只有 140 行。skill 的全部"行为合约"都在这 140 行里。它给 Agent 的指令浓缩下来有十条核心规则。
第一条:**Action First**——每条回复的第一句话必须是当前可以采取的下一步具体动作,不要先讲背景、不要先复述用户问题、不要先列三个备选。
第二条:**编号步骤**——所有多步操作必须用 1/2/3/4 编号,每一步只说一件事,不要把三步并成一段。
第三条:**显式进度**——每完成一步要在下一条消息开头重新声明当前进度("已完成 X,正在做 Y,接下来 Z"),让读者随时知道 Agent 在哪。
第四条:**不啰嗦开头**——不要"Great question!""Sure thing!""Of course!"这种客套;不要"I'm happy to help";不要"Hmm, let me think about that";不要任何形式的"我正在思考"占位。
第五条:**不总结回顾**——Agent 完成之后不要写"In summary, I did…",直接说任务完成 + 下一步动作;用户问的如果是要总结,才总结。
第六条:**保持开启**——一旦用户激活了 /i-have-adhd,这个模式一直保持,直到用户明确说 "stop adhd mode"。
第七条:**失败直说**——做不到的事直接说做不到,不要"虽然我可以尝试…";不要"也许可以…";不要把失败包装成"探索"。
第八条:**遵守 Agent 自身的工具调用约定**——如果 Agent harness(比如 Claude Code)要求先声明 tool call 才能调工具,那就先声明;但声明之后的内容仍然按前 7 条规则排版。SKILL.md 原话:"Inside an agent harness, the system prompt outranks this skill: announce a tool call when the harness requires it, do the work instead of explaining, then drop the result."——这条契约的本质是"skill 在 system prompt 之下,在 user 输出之上"。
第九条:**不发散**——不在 coding 任务里突然给用户讲历史、讲哲学、讲"为什么这样设计";只回答和当前任务直接相关的事。
第十条:**发消息前自检删除**——Agent 在 send message 之前,要主动检查有没有违反前面任何一条,有就删掉。这条规则的存在让 Agent 不能"先写一长段再删前缀",必须从一开始就按格式生成。
这十条规则合并起来的工程效果是:Agent 的输出从"对话式聊天体"变成"任务式简报体"——读者打开 Claude Code 看到的第一行永远是"下一步该做什么",而不是"让我先想一下"。
## 三、Skill 协议为什么是 Claude Code 的"输出层新基线"
i-have-adhd 的成功实际上揭示了一个比 skill 本身更重要的趋势——Claude Code 在 2026 年逐渐稳定下来的 **Skill 协议**,正在变成 coding agent 落地的"输出层新基线"。
Skill 协议的工程定义是:每个 Skill 是一个放在 `.claude/skills/
/SKILL.md` 或者 `.agents/skills//SKILL.md` 下的 Markdown 文件,Agent 在启动时会扫描这些文件,把它们的内容当成 system prompt 的一部分。Skill 文件的格式是 OpenAI/Anthropic/Cursor 等厂商在过去半年里陆续对齐的一个轻量约定:一个 frontmatter(YAML 描述 metadata),一个 body(自然语言指令)。
i-have-adhd 这种 Skill 之所以能"装上就生效",依赖的就是这条协议的几条隐含约定:Skill 是声明性的、不是程序性的(只是 prompt,不是代码);Skill 文件人类可读、可 git diff、可 code review;Skill 在 agent 启动时被静态加载,运行时不再读取新文件;多个 Skill 之间通过"system prompt 里按顺序拼接"的方式组合,优先级由加载顺序决定。
把这套协议放到企业 coding agent 落地的语境里,它的工程价值立刻显现。
第一,**输出规范不再需要改模型权重**。过去你如果想让 Agent 给出某种格式的输出,你只能 fine-tune 或者做 prompt engineering,而且 prompt 写在 CLAUDE.md 里很容易被淹没。现在你可以让"输出规范"以 Skill 的形式独立维护、独立版本管理、独立回滚——一行 git checkout 就能切回上周的输出格式。
第二,**团队输出规范可以复用**。一个企业的所有开发者可以用同一个 i-have-adhd skill、同一个"代码评审规范"skill、同一个"测试用例格式"skill,这意味着 Agent 的输出在团队内部是可预测、可比较的——这对"AI 编码助手"在企业里被审计、被评估、被纳入 KPI 体系,是基础设施级的前提。
第三,**Skill 文件可被合规审计**。一行 Markdown 的 diff 在 git blame 里清清楚楚,"我们上周把输出规范改了哪几条"是工程问题,不是 prompt 工程的黑盒。这条性质对金融、医疗、政企这类对"AI 决策可追溯"有强需求的场景尤其重要。
第四,**Skill 协议是跨 Agent 兼容的**。i-have-adhd 同时支持 Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Kimi、Qwen,这件事的关键不是"它支持得多",而是"Skill 协议本身正在被不同 Agent 厂商同步采纳"。这意味着企业今天为 Claude Code 写的 Skill 资产,明天 Cursor、Codex 都能直接复用——切换 coding agent 框架的迁移成本被进一步压低。
## 四、企业 Coding Agent 输出层的真实需求
把 i-have-adhd 的成功抽象一下,会发现企业里 coding agent 的输出层其实有四类硬需求,i-have-adhd 解决了其中一类,剩下三类还等着被工程化。
第一类需求是**结论先行**——i-have-adhd 已经覆盖。企业里的开发者打开 Claude Code,经常只是想确认"这个函数该不该这么写"、"这个 PR 能不能合并"、"这个 bug 在哪一行"。Agent 上来先讲三段背景再给答案,开发者直接关掉。
第二类需求是**审计可追溯**——目前没有标准方案。企业安全团队最常问的问题之一是"Agent 上个月做的所有改动,有几行被审计过?"这件事如果靠 review Agent 的输出文本,等于人工审计;如果靠 Agent 自己声明"我做了什么",等于 Agent 自证。现在需要的是"Agent 的每一条结论都附带可追溯的 evidence":文件路径、行号、commit hash、测试报告,这些都是 Skill 协议可以承载的规约,但目前没有形成统一标准。
第三类需求是**多角色差异化输出**——目前没有标准方案。同一段 Agent 输出,给开发者看应该是"代码 + 行号",给产品经理看应该是"影响范围 + 时间",给合规看应该是"风险点 + 政策条款"。i-have-adhd 的 "no preamble" 规则对开发者好用,但对产品经理可能太干。这件事需要 Skill 协议扩展"按接收者适配"的能力,但目前没有任何 Skill 协议设计在朝这个方向走。
第四类需求是**输出和模型解耦**——目前在朝这个方向走。Skill 协议最大的价值是它把"输出规范"和"模型选择"分开了——你可以换 Claude、换 GPT、换 Gemini、换本地 Qwen,但 Skill 文件可以原样复用。这对企业的模型供应链管理是巨大的利好,不再被"想换模型但 prompt 全部要重写"卡住。
## 五、Skill 文件本身的工程风险
i-have-adhd 在 Hacker News 上拿到 371 条评论,讨论热度极高,也引出了几个工程社区对 Skill 协议本身的担忧。
第一个担忧是**Skill 数量膨胀**。Claude Code 的 Skill 协议允许无限多个 Skill 同时加载,但每个 Skill 都会占 system prompt 的 token 预算。当一个团队的 Skill 数量从 5 个膨胀到 50 个,system prompt 会被撑爆,真正的对话上下文反而被挤压。这条问题目前没有官方解法,工程社区的临时建议是"按项目场景分组,每个项目只加载相关 Skill"。
第二个担忧是**Skill 之间的优先级冲突**。当两个 Skill 都对"输出格式"有要求,比如 i-have-adhd 要求"no preamble",另一个 Skill 要求"always greet user",Agent 怎么选?目前 Claude Code 的策略是"按加载顺序拼接,后加载的覆盖前加载的",但这个策略不是 Skill 协议规范明文规定的,各家 Agent 的实现细节不一。
第三个担忧是**Skill 本身的供应链安全**。Skill 是 Markdown 文件,可以直接通过 git 安装、URL 安装,甚至有人开始搞 "Skill marketplace"。这意味着任何攻击者只要能让一个 Skill 文件被加载,就能在 system prompt 里塞任意指令——典型的 prompt injection 攻击面。一个 HN 用户在评论区直接指出,i-have-adhd 仓库自己的 AGENTS.md 里塞了让 Agent 去某个 GitHub Issue 发评论的指令,他拒绝执行——这是 Skill 协议被滥用的第一个公开案例。
## 六、对国内企业 Coding Agent 落地的启示
把 i-have-adhd 折射出的趋势合并起来,对国内企业把 coding agent 落到生产里有四条启示。
第一条启示:**Skill 协议不是工程玩具,是企业级基础设施**。一条 140 行的 Markdown 文件能让 31K+ 开发者主动采用,这件事本身就说明 Agent 的"输出层"在工程上是一等公民,不是装饰。企业应该把"输出规范"这件事从 PR 描述、code review 规范里抽出来,做成 Skill 文件,纳入代码仓库一起管理。
第二条启示:**Skill 协议让"AI 编码规范"可被版本管理**。一个企业的所有 Skill 文件应该和代码同仓库、同 CI、同 review。任何一条"Agent 必须按这个格式输出"的规则,都应该有 git commit、git blame、code review 的全流程追溯——这是 Skill 协议相对 CLAUDE.md 这种"写在仓库根目录的提示"最大的工程优势。
第三条启示:**Skill 协议要配套审计机制**。Skill 文件本身是 Markdown,可以塞任意 prompt 指令,所以加载任何外部 Skill 都应该走"和 npm 包一样的供应链审计"——有源、有签名、有 code review。国内企业落地 coding agent 时,建议建立内部的 Skill 仓库(类比内部 npm),不允许直接从 GitHub 加载未审核 Skill。
第四条启示:**Skill 协议要支持按角色输出适配**。企业里开发者、产品、合规对同一段 Agent 输出的需求完全不同。Skill 协议目前没有原生支持这件事,但企业可以自己扩展——比如定义一个 `audience: developer|product|compliance` 的 frontmatter 字段,Agent 根据上下文选择加载哪个版本的 Skill。这是一个值得提前布局的能力,等 Agent 框架层面原生支持可能还要一年。
## 七、Skill 协议还没解决的问题
把 i-have-adhd 夸完,也必须指出 Skill 协议本身在工程上还有几条没解的边界。
第一个边界是 **Skill 没办法做到严格的"行为契约"**。Skill 文件本质是自然语言 prompt,Agent 在压力下可能不遵守。比如用户问"请帮我详细解释一下",i-have-adhd 规则要求"no preamble",但用户明确要 preamble 时,Agent 该听 Skill 还是听用户?目前 i-have-adhd 的做法是"用户明确要求时例外",但这条优先级规则是隐式的,不是协议层面的硬约束。
第二个边界是 **Skill 没办法做条件分支**。Skill 是静态文本,不能写"如果用户在金融部门就加载 X,如果在客服部门就加载 Y"。这件事目前靠 Agent 启动时通过 CLAUDE.md 或者 settings.json 决定加载哪些 Skill,但加载逻辑本身没有 Skill 协议层的标准。
第三个边界是 **Skill 的可观测性**。Skill 文件改了之后,Agent 的实际输出格式到底有没有跟着改,这件事目前没有任何官方工具能告诉你。企业要落地 Skill 协议,必须自己写"Skill 改动 → Agent 输出 diff"的可观测链路。
## 八、结论:Skill 协议是 coding agent 输出的新基线
回到标题那个问题:i-have-adhd 只是一个 31K stars 的开源 skill,但它折射出的工程趋势远比 skill 本身重要——**Claude Code 的 Skill 协议正在变成 coding agent 输出层的事实标准**。这条协议的成功在于它做到了三件最难的事:用 Markdown 而不是代码,让 skill 可读、可 review、可版本管理;用声明式而不是程序式,让 skill 的作者不需要是程序员;用 Anthropic/OpenAI/Cursor 同步采纳的轻量约定,让 skill 资产可以跨 Agent 框架复用。
对企业来说,Skill 协议的真正价值不在"装 i-have-adhd 让 Agent 说话简洁",而在于把"Agent 的输出规范"从 prompt 工程的暗箱,推到了工程治理的明面。下次再有人跟你说"我们要给 coding agent 做输出规范",你可以反问一句:**"你的规范是 Skill 文件吗?进 git 了吗?有 review 吗?有可观测吗?有跨 Agent 兼容吗?"**——这五个问题的答案,就是判断一家企业有没有把 coding agent 落到工程基线上的最低门槛。
参考资料:
- domhudson, *Show HN: I-have-ADHD: A skill to stop coding agents from burying the answer*, 2026-09-08, news.ycombinator.com/item?id=49610631
- ayghri/i-have-adhd, 源码仓库, github.com/ayghri/i-have-adhd, MIT License
- ayghri, *SKILL.md 全文*, github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md
- Skillselion Catalog, *I Have ADHD Skill for Claude Code*, 2026-09-07, skillselion.com/skills/ayghri/i-have-adhd
- Explainx.ai, *i-have-adhd: The 31K-Star Skill That Stops Claude Code Burying the Answer*, 2026-09-09
- Anthropic, *Claude Code Skills Documentation*, 2026
