i-have-adhd Claude Code 技能为什么走红？2026 开发者要不要迁移工作流

你遇到的症状：Claude Code 经常先讲背景、重复复述，真正能执行的下一步反而埋在最后。

最快解法：先把 i-have-adhd 当成“输出与交互规则”低风险试用；它不会直接提升模型的代码能力，团队迁移前必须验证规则冲突、上下文、权限和任务复现，云端工作区也不能替代工作流设计。

谁该看这篇： Claude Code 用户，想判断“答案优先、少废话”是否适合自己的编码方式。AI Coding 内容读者，想理解一个热门技能为什么引发关注，而不是只看安装命令。小型团队负责人，正在考虑把个人技能规则推广到共享工作区或团队规范。

最后更新于 2026 年 9 月 23 日，本文核实了 ayghri/i-have-adhd 公开仓库、安装说明、SKILL.md、AGENTS.md 以及 Anthropic 与 GitHub 的相关文档。公开资料中存在多个同名或相似项目，本文只讨论 ayghri/i-have-adhd，不把其它仓库的功能混在一起。

i-have-adhd Claude Code 技能的真实定位

i-have-adhd 的核心不是新增工具、数据库、浏览器控制或多 Agent 编排，而是改变编码 Agent 的回答组织方式。它在仓库中以 SKILL.md 规则为中心，公开描述包括：先给行动、为多步骤任务编号、减少旁枝、说明当前状态、给出一个具体下一步等。仓库 README 展示的规则数量是 10 条，但这代表规则条目数量，不代表代码质量提升幅度或开发效率提升比例。具体规则可以在 项目 README 与示例 中核对。

这一区分非常重要：

Anthropic 对 Skills 的定义是：由说明、脚本和资源组成的可复用能力单元，模型会在任务相关时动态加载。换句话说，Skill 更像“如何完成某类任务的操作说明”，而不是重新训练模型或替换底层推理能力。你可以参考 Anthropic 对 Agent Skills 的介绍 了解这种机制。

这项技能具体改变了哪一层？
它主要改变 Claude Code 的“表达协议”：先告诉你改什么、改哪里、下一步做什么，再补充原因和限制。它可能减少你在长答案中寻找命令、文件路径和验收动作的时间，但不会凭空增加测试覆盖率、架构判断力、依赖分析能力或安全审查能力。

社区走红原因也应保持为社区观察，而不是官方认可。公开讨论集中在“AI Coding Agent 说得太多、行动太晚”这一普遍摩擦上；这解释了传播性，却不能证明它适合所有团队。

个人开发者：交互摩擦

对单人开发者来说，i-have-adhd 最适合处理三类问题：

• ✅ 你经常需要从一大段解释中寻找第一条可执行命令；
• ✅ 你在调试过程中容易被延伸建议带偏；
• ✅ 你希望每轮回答都明确当前状态和下一个动作。

例如，你让 Claude Code 修复一个测试失败。普通输出可能先总结错误背景、列出几种猜测，再给修改建议。启用规则后，回答更可能先指向文件、命令和验证步骤。这个变化对频繁复制命令、快速切换任务的个人开发者比较直观。

但它也有三个边界。

第一，少废话不等于少错误。如果仓库缺少测试、依赖版本不明确，答案变短后，错误信息可能也被压缩。你仍然需要让 Claude Code 执行测试、查看差异，并说明没有验证的部分。Anthropic 的 Claude Code 团队也把“让 Claude 验证自己的输出”列为重要工作方式，可参考 Claude Code 的验证与工作流建议。

第二，答案优先不等于任务拆解。如果你真正缺的是需求拆分、任务依赖、长期记忆或终端会话管理，换一个输出风格只能缓解表面摩擦。你可能得到更清楚的第一步，却仍然不知道一个跨文件重构应该如何分阶段完成。

第三，个人偏好不一定适合所有任务。写技术方案、做安全审查、排查线上故障时，背景、假设和证据链本身就是答案的一部分。此时过度压缩可能让你错过风险条件。

建议你用下面的 5 步试用法，不要一上来把它设置为所有项目永久生效：

1. 选择一个非核心仓库，避免影响正在发布的项目。
2. 记录 3 类原始任务：修复测试、解释代码、执行小型重构。
3. 分别比较启用前后的第一屏输出，重点看文件路径、命令、风险和下一步是否更清楚。
4. 强制执行验证动作，例如测试、类型检查、git diff 和人工审阅。
5. 试用结束后删除或停用技能，再处理一次相似任务，确认变化来自规则，而不是任务本身更简单。

如果你试用时发现“答案变短了，但需要反复追问更多细节”，就不要把它当作效率提升。你需要的是更好的项目上下文或任务模板，而不只是 i-have-adhd。

小型团队：规则边界

放进团队规范前，先看哪些条件？
可以试点，但不适合未经审查就变成强制团队标准。个人技能通常包含对“什么算冗余”“应该先做哪一步”“什么时候停止解释”的主观判断。一个人的高效交互方式，可能与另一个人的审查、教学或故障处理方式冲突。

Claude Code 的规则来源不是单一文件。Anthropic 将 CLAUDE.md、Rules、Skills、Subagents、Hooks、Output Styles 和系统提示等列为不同的控制方式，并强调它们在加载时机、持续时间和指令权重上存在差异。可参考 Anthropic 关于 CLAUDE.md、Skills、Hooks 和 Subagents 的决策说明。

团队最容易遇到的冲突包括：

• 个人技能与项目规则冲突：技能要求“只给一个下一步”，项目 CLAUDE.md 却要求每次修改都报告风险、测试和回滚计划。
• 全局规则与项目规则冲突：个人目录中的偏好可能影响所有仓库，而项目目录中的规则只应服务当前代码库。
• 技能与其他 Skills 叠加：另一个技能可能要求详细解释、生成审查报告或保留完整推理依据。
• 输出风格与权限边界混淆：技能可以建议执行动作，但不应替代权限确认、命令白名单和人工批准。
• 不同 Agent 上下文不一致：主会话、子 Agent 和云端任务未必读取完全相同的指令文件。

GitHub 对 AGENTS.md、仓库级指令、路径级指令和 Skills 也进行了区分：持续性的仓库规则与按任务调用的 Skill 不是同一层。你可以查看 GitHub 关于 Agent 指令与 Skills 分工的文档。

小团队应采用“试点—审查—回滚”流程：

1. 指定一个项目和 1-2 名试用者，不要立即覆盖整个组织。
2. 把规则副本固定在版本库或内部配置仓库中，记录来源、版本和修改原因。
3. 准备相同的 5-10 个代表性任务，包含编码、测试、代码解释和错误排查。
4. 让另一名成员审查输出，重点检查遗漏的假设、错误命令和权限请求。
5. 如果出现规则冲突，先撤回团队默认配置，再保留个人范围试用。

团队推广的验收标准不应是“大家都觉得回答更爽”，而应是：任务是否更容易复现、提交是否更容易审查、错误是否更容易定位、成员是否知道哪些规则优先级更高。

它与项目规则可能发生哪些冲突？
会，而且冲突不一定表现为明显报错。更常见的情况是 Claude Code 同时遵守两套要求，输出变得不完整：例如它按照 i-have-adhd 压缩说明，却漏掉项目要求的迁移风险；或者它按照项目规则提供完整报告，却违背了个人技能的简洁格式。

处理方式是把规则分层：

• 项目架构、构建命令、测试要求，放进项目级 CLAUDE.md；
• 个人表达偏好，放在个人范围；
• 可复用的代码审查、发布、迁移流程，单独做成任务型 Skill；
• 权限和危险操作，通过权限配置与人工确认控制，不写成模糊的风格要求。

关于 CLAUDE.md 的作用范围，可以参考 Claude 官方上下文文件说明。该文档明确区分了用户级和项目级上下文；这正是团队不能把个人偏好直接复制成项目规范的原因。

如果你准备把个人规则纳入共享配置，建议先查看 Kvmjet 帮助中心的工作流与配置说明，把技能文件、项目规则和权限配置分别记录，避免后续无法定位冲突来源。

平台管理员：云端迁移

平台管理员关注的不是“回答是否更短”，而是工作区能否持续运行、远程访问、统一环境、留存日志并隔离权限。对于需要长时间运行的 AI Coding 任务、跨成员接力或固定工具链的团队，云端工作区确实可能有价值。

但要先拆开 5 个概念：

什么情况下值得把 AI Coding 工作流放到云端？
如果你的主要问题是“Claude Code 输出太绕”，不需要。云端工作区不会自动让输出更可执行，也不会替你解决 CLAUDE.md、Skills 和代码审查之间的优先级问题。

如果你的主要问题是本地电脑无法持续运行、团队需要同一套依赖、成员需要远程接入，云端迁移才有明确价值。此时应迁移的是经过审查的工作流，而不是简单上传整个 ~/.claude 目录。

还要特别注意权限。Claude Code 的 CLI 文档列出了跳过权限提示的高风险选项，并明确要求谨慎使用；平台管理员不应把“无人值守”理解成“可以取消边界”。相关限制可参考 Claude Code CLI 官方参数说明。

在云端迁移前，至少完成以下检查：

1. 删除环境变量、配置文件和脚本中的真实密钥。
2. 为代码读取、文件修改、命令执行和网络访问分别设定权限。
3. 将 i-have-adhd 与项目规则分开部署，避免无法判断冲突来源。
4. 记录每次技能版本、配置变更和会话恢复结果。
5. 用一组固定任务验证新工作区是否能复现本地结果。
6. 为失败任务保留人工接管和回滚路径。

Skills 本身也不能被当成完全可信的文本附件。Anthropic 的 Skills 帮助文档提醒用户注意技能中可能要求连接不受信任外部网络的指令；相关说明见 Claude Skills 使用安全建议。更广泛的研究也指出，公开 Agent Skills 的结构、来源和维护质量差异很大，可参考 GitSkills 关于公开技能生态的研究数据。

如果你要评估远程运行、环境一致性和权限隔离，可以先阅读 Kvmjet 的基础设施说明，再决定是否需要云端工作区。这个顺序比先复制技能文件更稳妥，因为它会迫使你先明确代码、密钥、日志和会话状态分别如何处理。

试用、保留还是放弃：决策条件

先不要用社区热度替代生产证据。你可以按下面的条件分支做决定：

• 若你主要受输出冗余困扰，且项目规则简单，选择个人范围试用 i-have-adhd。
• 若你需要持续记忆、任务依赖或多终端管理，回退到项目上下文、任务管理或终端方案，不要把问题归因于输出风格。
• 若团队已经有多套 CLAUDE.md、Skills 和审查模板，先做规则冲突测试，再考虑共享部署。
• 若任务涉及生产权限、敏感代码或自动提交，先保留人工审批，不因回答更简洁而放宽权限。
• 若云端只解决“电脑不能一直开着”，可以迁移运行环境，但不要声称工作流已经完成迁移。
• 若同一任务在不同成员或不同会话中无法复现，暂停推广，先固定版本、输入、上下文和验收标准。
• 若维护成本高于节省的追问时间，停止使用，保留项目级规则和代码审查流程。

下面 3 张表用于快速判断，不是对代码质量或开发速度的承诺。

如果你要把试点推进到团队工作流，建议先查阅 Kvmjet 帮助中心中关于 Skills 版本管理、项目规则和云端工作区的说明，再单独核对权限、日志和验收要求。最终上线前，还应把规则冲突、权限、日志、测试和人工接管写进 AI Coding 工作流验收清单中，而不是只记录“回答变短了”。

从热点技能到可持续 AI Coding 工作流

i-have-adhd 的价值在于降低交互摩擦：你更快看到动作、文件和下一步。项目规则解决的是“这个仓库应该如何工作”；任务型 Skills 解决的是“这类任务应该按什么流程完成”；云端工作区解决的是“环境如何持续运行和被多人访问”；代码审查解决的是“结果是否真的可以合并”。

这 4 层不能互相替代。

当前方案如果只是本地 Claude Code 加个人技能，常见缺点是：环境依赖难以统一、会话状态难以交接、权限与日志容易依赖个人习惯。直接把技能文件搬到云端，又会出现另一组问题：密钥和项目数据不会因为文件上传而自动安全迁移，规则冲突不会因为工作区集中化而消失，缺少验收标准的 Agent 仍然可能生成不可合并的代码。

因此，若你只是想让个人编码对话更直接，先在本地低风险试用 i-have-adhd；若你需要持续运行、固定环境和远程接力，再考虑使用 Kvmjet 的 Mac 云端工作区，但应先完成技能版本管理、权限隔离和验收测试。对于长期稳定重负载、必须接触物理接口或已经拥有成熟本地设备的场景，租赁并不一定是最佳选择；它更适合临时算力、隔离测试环境和需要远程访问的 AI Coding 试点。

把热点技能变成可持续工作流，真正的顺序应是：先验证输出是否适合你，再固定项目规则，接着测试团队复现，最后才决定是否迁移云端。