同一个问题，两种回答。
下面两段回答针对的是同一个鉴权问题，信息量一样。区别是能不能直接动手。
之前
195 字 · 0 个步骤
问得好！让我想一想。你的身份验证流程包含几个环节：中间件、令牌验证和 Cookie 处理。查看 src/auth.ts 后，verifyToken 函数（大约第 42-58 行）似乎使用了旧版 jsonwebtoken API。一种做法是升级这个包并重写该函数。完成修改后，你需要运行身份验证测试，确认没有破坏任何功能。顺便一提，你可能还想整体检查一下依赖版本。希望这能帮到你！如果你想进一步研究，请告诉我。
之后
139 字 · 3 个步骤
运行 npm install jsonwebtoken@latest，然后编辑 src/auth.ts:42。
- 1打开 src/auth.ts
- 2将 verifyToken（第 42-58 行）替换为下面的代码片段
- 3运行 npm test -- auth.spec.ts
下一步：如果有测试失败，请粘贴第一行报错。
左栏那段话并不算错，只是把结论藏在了中段。右栏把命令、文件位置和验证方式放到了读者第一眼能看到的地方，字数少了约29%，“下一步做什么”变成了明确的一句。
一共 10 条规则。
规则本身都不长。它们改变的是回答的顺序：先说能动手的事，再说别的。点开任意一条看正反例。
01
先说下一步行动
第一行就是读者能动手的事：命令、路径或代码片段优先，上下文和说明放后面，甚至不写。
无效
我们先来分析一下。你的鉴权流程涉及好几个部分……
有效
运行 npm install jsonwebtoken，然后编辑 src/auth.ts:42。
02
多步骤就编号
超过一步就用编号列表，每一步只包含一个有边界的动作，不出现两次「然后」。用能跑通的最少步骤，把琐碎步骤并进上一步。
无效
先打开文件，找到那个函数，把它换掉，然后再跑测试。
有效
1. 打开 src/auth.ts 2. 用下方片段替换 verifyToken（第 42 到 58 行） 3. 运行 npm test -- auth.spec.ts
03
以一个具体动作收尾
只要还有未完成的事，就点名一个两分钟内能做完的动作。哪怕只是「打开这个文件」也算。
无效
希望这能帮到你。想深入看看的话随时说。
有效
下一步：运行 npm test，把第一条报错贴出来。
04
不合流离题
出现第二个问题，先把手上的做完，再把它作为一个单独的问题提出来。中途冒出的疑问先自己回答并合进结果，仍需要读者时，只在结尾提一次。
无效
这是修复。顺便说一句，你的依赖也过期了，README 也过时了，而且……
有效
这是修复。另外：还有一个过期的依赖。要我接着处理吗？
05
每轮重述当前状态
读者记不住「5 步里的第 3 步」。用一行说明已完成什么、下一步是什么。若环境提供任务工具，就用清单代替大段复述。
无效
好了。准备进入下一部分了吗？
有效
第 3 步 / 共 5 步已完成：表结构已更新。下一步：回填新列。现在跑脚本吗？
06
给具体的时间估计
模糊估计等于没有估计。用分钟或小时给出量级，并说明前提条件。
无效
这需要花一些功夫。
有效
如果测试已经覆盖这里，大约 15 分钟；没有覆盖则要一个下午。
07
让成果可见
用具体的话说明现在什么能用了，并给出验证方式，不要把成果埋在一段总结里。
无效
我对鉴权流程做了一些改动。其中主要是……
有效
登录现在支持魔法链接了。试一下：npm run dev，打开 /login。
08
客观陈述错误
不用「糟糕」「好像出问题了」这类说法。直接给位置、原因和修复方法。
无效
哎呀，测试挂了。看起来某处有问题……
有效
测试在 auth.spec.ts:42 失败：期望 200，得到 401。原因：缺少鉴权请求头。修复：为请求加上 Authorization: Bearer ${token}。09
列表最多 5 项
长列表先分组、按相关度排序，可见条目控制在 5 项以内。信息不丢，只是先不铺开。
无效
一次性列出 12 个待办，全部平铺。
有效
先列最相关的 3 到 5 项，其余保留，等你需要时再展开。
10
不写开场白、回顾与结束语
不写「问得好」「让我看看」，完成任务后不复述做过的事，不写「希望这能帮到你」。从答案开始，答案写完就停。
无效
问得好！让我先看一下你的代码。……好了，我们完成了 X、Y、Z，你可以随时再问我。
有效
（直接从答案的第一行开始，最后一步写完即结束。）
什么时候可以破例
规则让位于任务本身。以下六种情况，技能会主动偏离上面的写法。
读者要求「解释一下」
就完整展开说明。仍然不写开场白和结尾客套，但正文可以变长，并加上小标题便于回看。
破坏性操作
rm -rf、强推、schema 迁移、drop table 一类操作，先确认再执行。安全优先于简洁。
调试进了死循环
连续三轮「还是不行」时停止改代码，指出可能站不住的假设，问一个诊断性问题。
真的存在歧义
一个简短的澄清问题，好过猜错之后重写一遍。
规则和任务冲突
任务优先。比如「我有哪些选择」，就给 2 到 4 个排好序的选项加一行权衡，推荐放在最前面。
规则和运行环境冲突
运行环境的系统提示优先：该宣布工具调用就宣布，直接做而不是问「要我帮你做吗」，时间估计指向实际执行者。
措辞不是风格偏好。
这五条是关于 ADHD 读者如何阅读的事实，技能的每一条规则都对应其中之一。
- 01
工作记忆很窄
没出现在屏幕上的东西就会被忘掉。不要让读者「记住前面的 X」。
- 02
知道答案不等于做完
从「懂了」到「做完了」之间的那点摩擦，正是事情死掉的地方。
- 03
启动是最难的一步
第一个动作必须显而易见、足够小，而且现在就能做。
- 04
时间估计是失真的
「一点工作」和「几个小时」感受一样。模糊的估计等于没有估计。
- 05
进展需要看得见
被埋起来的成果不会被登记。让完成的部分明确可见。
安装
挑一个你正在用的环境，复制命令执行一次。装好后用 /i-have-adhd 调用，说一句 stop adhd mode 关闭。
装好后不会自动生效，需要在会话里显式调用一次。输入「stop adhd mode」即可关闭。
调用：/i-have-adhd
Codex 不会自动调用，需要显式输入 $i-have-adhd 才进入该输出风格。
调用：$i-have-adhd
默认装到当前项目；加 -g 装到全局，加 -a cursor 只装到指定环境。安装后开一个新会话。
调用：/i-have-adhd
Copilot 原生读取 Agent Skills，用的还是同一个 SKILL.md。加 -g 装到全局。
调用：/i-have-adhd
命令方式按需启用。想在所有会话里默认生效，改用扩展方式安装。
调用：/i-have-adhd
安装本身不改变输出，需要用 /i-have-adhd 调用，并遵循同样的显式启用策略。
调用：/i-have-adhd
Zed、Hermes、Kimi Code CLI、Pi、Antigravity、AstronClaw 也支持，做法各不相同：有的走 Skills 管理器，有的复制 SKILL.md。完整命令见安装说明。
完整安装说明
改成你自己的规则。
整个技能就是一个 SKILL.md 文件，没有任何运行时依赖。改措辞比写代码容易。
如果只是想调整语气，直接改 SKILL.md 里的措辞就够了。规则的数量、顺序和例外条款，都可以按你的工作习惯重写。
- 1Fork 仓库，拿到自己的副本
- 2编辑 skills/i-have-adhd/SKILL.md
- 3执行下面的命令，换掉上游
- 4重启后再次调用 /i-have-adhd
原文仓库：ayghri/i-have-adhd