AB
AB
AiBoss

すべてのカテゴリ

チュートリアル

i-have-adhd 技能使用指南：让 AI 回答变成结论、编号步骤与下一步

チュートリアル

i-have-adhd 技能使用指南：让 AI 回答变成结论、编号步骤与下一步

i-have-adhd 是一个 Agent Skill，用来把 AI 的回答整理成「结论 → 编号步骤 → 下一步行动」的结构。它不会让回答单纯变短，而是让回答里明确写出先做什么、按什么顺序做、哪些事暂时搁置。本文介绍它的作用、在 Codex 与 Claude Code 中的安装方式、调用与退出方法，并给出一个排查 500 错误的完整对照示例。

i-have-adhd 是一个 Agent Skill，作用是把 AI 的回答重新组织成便于立刻动手的形式：先给结论，再给编号步骤，最后落到一个具体的下一步动作。它适合那些经常在读完一长段回答之后仍然想问「所以我到底该先做什么」的人。它并不是一个单纯压缩字数的技能——回答里会明确写出第一步做什么、按什么顺序推进、哪些事情现在先放一放。本文介绍它的规则要点、安装与调用方式，并用一个排查 500 错误的例子展示使用前后的差别。

准备工作

在开始之前，需要先确认几件事。

  • 可用的 AI 编程工具：i-have-adhd 以插件形式提供，支持 Codex 与 Claude Code 两种客户端。你需要先有一个能正常工作的对应客户端。
  • 命令行环境：安装通过命令行完成，需要能在终端里执行 codex 或 claude 命令。
  • 网络与插件市场访问：安装命令会从插件市场拉取内容，需要能访问对应的插件市场。
  • 一个待处理的具体任务：这个技能的价值在于把回答收敛到可执行动作上，所以最好带着一个真实的、有明确时间要求的任务去用，而不是泛泛地聊天。

另外需要说明的是，插件的版本、可用命令、市场名称等都可能随时间变化，安装前建议以官方仓库当前给出的说明为准。

操作步骤

第一步：在 Codex 中安装

Codex 侧需要先添加插件市场，再安装插件本体。两条命令依次执行：

codex plugin marketplace add ayghri/i-have-adhd --ref main
codex plugin add i-have-adhd@i-have-adhd

第一条命令把该仓库注册为一个插件市场来源，并指定使用 main 分支；第二条命令从该市场安装名为 i-have-adhd 的插件。

第二步：在 Codex 中调用

安装完成后，在聊天中直接以如下形式调用：

$i-have-adhd

调用之后，该会话中的回答就会按这个技能定义的规则来组织。

第三步：在 Claude Code 中安装

Claude Code 侧的安装同样是两步，命令形式略有不同：

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

第一条命令添加插件市场，第二条命令安装插件。

第四步：在 Claude Code 中调用与退出

在会话内执行斜杠命令即可启用：

/i-have-adhd

启用后，该会话中规则会持续生效。如果想回到普通的输出方式，可以在会话中说出退出指令：

stop adhd mode

或者：

normal mode

这两者都会让输出恢复到常规风格。

第五步：理解它到底改变了什么

该技能的 SKILL.md 中定义了 10 条规则，核心内容可以归纳为以下几点：

  • 把下一步行动写在最前面，而不是先铺垫背景。
  • 给多个待办事项编号，让顺序一目了然。
  • 把时间具体化：不写「稍微花点时间」，而写「15 分钟」这类明确量级。
  • 不展开与主线无关的话题，避免把注意力引到旁支上。
  • 以一个有界的、具体的行动收尾，而不是以开放式提问收尾。

换句话说，回答里会包含「现在先做什么」「按什么顺序做」「什么暂时不做」这三类信息。它解决的是「读完回答之后还要自己决定从哪一条开始」这个问题。

一个完整示例

下面用一个接近实际工作的场景来对比使用前后的差别。场景设定是：一个用 Next.js 与 FastAPI 搭建的内部工具，打开用户列表时出现 500 错误，需要在当天 17 点之前修好。浏览器显示 Internal Server Error，FastAPI 日志里出现 ResponseValidationError，并提示 UserSummary 的 department_name 为 Field required。前一天刚把列表 API 的响应类型从 User 改成了 UserSummary。此外 README 已经过时，CI 也比较慢。

为了做对照，两次运行使用同一个提示词，各自在新会话中执行一次。对照时关闭了日常配置的干扰，只让启用技能的那一次加载 i-have-adhd 的 SKILL.md。

未启用技能时的回答形态

未启用技能时，回答会先指出工作目录是空的、找不到代码，并请求提供仓库位置。随后它仍然根据症状给出了推断：把 response_model 改成 list[UserSummary] 之后，端点返回的对象（例如 ORM 的 User）里没有 department_name，FastAPI 用 UserSummary 校验响应时找不到该字段，于是抛出 ResponseValidationError 并变成 500。

接着它列出三个确认点：

  1. UserSummary 的定义里 department_name: str 是否为必填。
  2. 列表 API 返回的数据里是否包含 department_name，是否存在通过 user.department.name 这类关系取值却没有做转换的情况。
  3. 是否存在 department 为 NULL 的用户——如果有，而字段类型仍是 str，校验就会失败。

再给出三个修改方向：在列表查询里 JOIN 或使用 selectinload 加载部门，并显式构造 UserSummary(..., department_name=u.department.name if u.department else None)；如果允许没有部门，就把字段改成 department_name: str | None = None；如果前端用到了 department_name，TypeScript 侧的类型定义也要同步更新。

关于 README 和 CI，它建议等 17 点的修复完成之后再作为单独的工作处理，先修 500 错误，之后再给改进方案。最后它请求提供仓库路径或对应的路由、schema 代码。

这类回答内容是正确的，但确认点有三个、修改方向也有三个，先看哪一个需要读者自己判断。

启用技能后的回答形态

启用技能后，回答同样先说明该目录下只有 AGENTS.md、找不到应用代码，并请求告知代码位置。区别在于，它紧接着就给出了在拿到代码之前可以先做的事。

最初要做的事：打开列表 API 的路由函数和 UserSummary，确认 department_name 的来源。并直接给出可执行的命令：

grep -rn "UserSummary\|department_name" backend/

原因判断：response_model=UserSummary 要求 department_name 必填，但返回的对象里没有这个值。常见情况有三种：

  1. User 模型本身没有 department_name，也没有从 department.name 构造它的处理。
  2. 存在未设置部门的用户，取值为 None，无法通过 str 类型的必填项校验。
  3. 查询没有取到 department，即缺少 join 或 selectinload。

修改方式（每项约 5 到 15 分钟）：如果允许部门为空的用户存在，就把 UserSummary 改成 department_name: str | None = None。如果要从 User 构造该值，就在列表查询里加上 selectinload(User.department)，并补上返回 department_name 的处理，例如：

@computed_field
@property
def department_name(self) -> str | None:
    return self.department.name if self.department else None

如果还没有构造该值的处理，也可以在路由侧直接组装：

UserSummary(..., department_name=u.department.name if u.department else None)

验证方式：修改后用 curl 请求列表 API，确认返回 200。

明确搁置的事项：README 和 CI 先放一放，17 点之前只专注 500 错误，修好之后再作为另一件事处理。

下一步（2 分钟）：把上面 grep 的结果和列表 API 的路由函数贴出来，以便定位原因并给出修改方案。

两次回答的差别对照

对比项未启用技能启用技能后
开头说明找不到代码指定最先打开的位置
第一个操作从三个确认点里自己挑给出可直接执行的 grep 命令
时间量级未提及修改每项 5 到 15 分钟，下一步 2 分钟
README 与 CI17 点修复之后另作处理明确写出 17 点前只做 500 错误
回答结尾请求提供仓库或相关代码收窄到 grep 结果与路由函数

两次回答在技术内容上并没有本质差别，未启用时同样能指出原因和修改方向。真正的差别在于：未启用时是「广泛地告诉你可能的原因和修法」，启用后是「推动当前这一步往前走」。后者不仅给出了先打开哪个文件，还给出了要执行的命令，并且以一个两分钟内能完成的动作收尾。

需要提醒的是，这只是一次同题对照的结果。模型的输出本身存在波动，启用技能并不保证每次生成的文字完全一致。

注意事项

  • 它不等于「回答变短」：这个技能的着力点是把行动、顺序、时间量级和搁置项写清楚，而不是单纯压缩篇幅。如果期待的是极简回复，它未必符合预期。
  • 规则在会话内持续生效：在 Claude Code 中启用后，该会话会一直沿用这套输出规则，需要显式退出才会恢复常规风格。
  • 退出指令有两种写法：stop adhd mode 与 normal mode 都可以让输出回到普通模式。
  • 输出存在随机性：同题对照只能反映一次运行的结果，不能当作稳定可复现的基准。
  • 安装信息可能变化：插件市场名称、安装命令、支持的客户端等细节，请以官方仓库当前说明为准。
  • 它不替代判断：技能只是改变回答的组织方式，给出的原因判断和修改方案仍然需要结合自己的代码去验证。
戻る