如果你用 AI 编程，每天至少要被这样一段话浪费掉一次注意力：「这是个好问题！让我想想。你的认证流程有几个环节，中间件、令牌校验、Cookie 处理……另外你的依赖版本好像也旧了，顺便说一句……希望对你有帮助，有需要随时问我。」 你问的是「怎么修」，它答了三百字，你读完还不知道第一行该敲什么。
有一个开源技能就是专门治这个毛病的。它叫 i-have-adhd，5 个月前出现在 GitHub 上，现在 5.1 万 Star。它的做法和你见过的「请简洁一点」完全不同：它写死了 10 条输出纪律——第一行就给可执行动作、多步任务必须编号、每轮都要复述进度、列表最多 5 条、禁掉「好问题」这类开场白和「希望对你有帮助」这类收尾。
它最有价值的地方不是这 10 条规则，而是它自带一整套评测。项目作者写了一台机器，拿 14 道题让同一个模型分别在「不带技能」和「带技能」两种情况下作答，再让评分模型盲评五个维度。结果是五个维度全线上涨，加权总分从 4.045 涨到 4.473。
但真正有意思的是接下来这件事：它自己的发布闸门，把这份成绩单判成了 FAIL。 项目里白纸黑字写着「发布门：未通过」。原因不在分数，在下文那张表。
它是什么，怎么做到的
先说清它到底是个什么东西。i-have-adhd 是一份给 AI 看的写作规范，一份纯文本文件，把 10 条输出纪律写进去。你把它装进 Claude Code、Codex、Cursor、Gemini CLI 这些编码助手（也就是能自己读文件、跑命令的 AI 编程工具），它就会在每次回答时被读一遍，管住输出的形状。
我把它 clone 下来逐层拆了一遍。整个项目 245 次提交、48 位贡献者，从 5 月 13 日建仓到现在 4 个多月，热度没有掉（最近 30 天还有 59 次提交，一周前刚合过代码）。规则本身只有 142 行、1187 个英文词——按比例换算大约 1700 个 token（也就是模型读写文字的最小计量单位，同时也是计费单位），这就是它每次回答要额外付的开销。
10 条规则里，前 3 条是核心，其余 7 条都在给这 3 条堵漏：
| 规则 | 一句话要求 | 它想治的病 |
|---|---|---|
| 1 动作先行 | 第一行就是能跑的指令、路径或代码 | 开场先铺垫背景 |
| 2 多步编号 | 一步一个动作，不许「然后」套「然后」 | 步骤糊成一段 |
| 3 末尾给一个下一步 | 指明 2 分钟内能做完的那一件事 | 结尾用「随时问我」收场 |
| 7 让完成可见 | 「登录能用了，去跑这个命令」 | 把成果埋在复述里 |
| 9 列表封顶 5 条 | 排序后只显示 5 条，其余留在内部 | 一口气甩 20 条清单 |
| 10 无开场白、无复述、无客套 | 删掉「好问题」「希望对你有帮助」 | AI 味最重的两头 |
有个设计我认为值得单独说：规则 9 特意写了「只在展示层收敛，不许丢信息」——它只压缩你看到的清单，不压缩它搜过的结果。这一条是被用户骂出来的，我在下面「翻车点」里细说。
实测：我复现了全部 70 个测试，也复现了它自己的判据
它自带的评测有三层，我从最便宜的一层往上跑，全部在隔离沙箱里完成（一次性的容器式沙箱，跑完即删，不碰本机环境）。
第一层：70 个自动化测试，我逐个复现。项目里有 7 个测试文件，覆盖会话钩子、评分脚本、评测调度、安装文档路径、多平台打包。我按它官方 CI 用的同一套命令跑：
| 测试文件 | 用例数 | 我的结果 |
|---|---|---|
| 会话钩子（always_on_hooks） | 7 | 全过 |
| 盲评脚本（judge） | 17 | 全过 |
| 评测调度（run_evals） | 25 | 全过 |
| 场景评测（run_scenario_eval） | 7 | 全过 |
| 安装文档（install_docs） | 2 | 全过 |
| 打包（omp_package） | 2 | 全过 |
| OpenCode 插件 | 10 | 全过 |
| 合计 | 70 | 70 过 0 挂 |
这里有个插曲值得记：第一次跑，有 2 个用例挂了，报错是「找不到 awk」。我一开始以为是仓库的 bug，追下去发现是我的沙箱问题——那两个用例调用一个文本处理小工具，而它在系统里是通过一条软链接间接指向真身的，我的沙箱只读挂载了主程序目录、没挂那个软链接目录，于是「工具在，但找不到」。我把真身直接接进去再跑，7 个用例全过。
也就是说：这 2 个失败是我的环境造成的假阳性，不是项目缺陷。我把它写出来，是因为「评测翻车往往是评测者自己的问题」这件事，比 70 个全绿更常见。
第二层：评测清单能跑通。项目的评测调度脚本有两个命令：一个校验 14 道题的清单格式，一个打印「要跑哪些组合」。前者输出「用例有效」；后者按 3 次重复 × 14 道题 × 3 种条件（不带技能 / 带技能）算出 126 次作答的排期。这两步我都跑通了，说明评测脚手架本身是好的。
第三层：评分环节我没有跑通，原因必须说清楚。项目的评分流程要用命令行调用 Claude Code 或 Codex（也就是 Anthropic 和 OpenAI 的编码助手命令行），由它们实际生成作答、再盲评打分。
我这台评测机没有装这两个工具、也没有对应的商业 API 额度，所以我无法自己生成那 126 次作答，也就无法亲手复核那五组分数。下面的数字来自项目公开的成绩单，不是我跑出来的——这一点我在文末的口径说明里再强调一次。
它自己那份成绩单是这样的（同一模型、14 道题 × 3 次重复，共 84 份作答，盲评时被打乱成 A / B / C 三组、评委不知道哪份带技能）。五个维度各自满分 5 分，带技能后全部上涨：
- 正确性（权重 35%）：4.333 → 4.524，涨 0.190
- 自主性（25%）：3.762 → 4.167，涨 0.405
- 可执行性（20%）：3.905 → 4.619，涨 0.714
- 安全性（10%）：4.643 → 4.667，涨 0.024
- 简洁度（10%）：3.429 → 4.571，涨 1.143
- 加权总分：4.045 → 4.473，涨 0.427
最值得看的是「正确性」和「安全性」也在涨——这两项权重最高，而且向风格类改动要收益是最难的：一般「让 AI 说短点」的做法，最容易拿简洁度换掉正确性，表现成「答得更短，但也更不准」。它在这里没有掉，说明压缩的是废话，不是内容。
再细一层，14 道题里它 10 道赢、2 道平、2 道输。涨幅最大的两道是「多步任务报进度」和「报错怎么说」——加权分分别涨了 2.53 和 2.40，这两道题几乎贡献了全部总分增量。而「写代码」和「写长文」两道题是零变化：题目本身就规定了输出格式，技能没有乱插手。这个「该让的时候让了」的结果，比总分上涨更能说明规则设计得克制。
翻车点：它的发布闸门判自己 FAIL，这事不能算小事
现在说开头那个反差。项目里有一份发布门规则，写着 4 条放行条件，其中第一条是「不得存在任何阻断问题」。它自己跑出来的结果是：不带技能 7 处阻断问题，带技能 3 处——砍掉了一半以上，但发布门依然 FAIL。
因为那条规则写的是「零」，而不是「比之前少」。所以一个把缺陷数量砍掉 57% 的版本，和原版一样被拦下。这不是分数问题，是判据的写法问题，项目自己也在文档里点破了这一点：按这条规则的字面意思，只要题目集里还剩下任何一处阻断问题，任何版本都永远不可能通过，无论它改善了多少。
这个设计我认为是本项目最耐看的地方，也是最该被别家抄的地方：它的成绩单和它的发布门是两台独立的机器，而且发布门比成绩单严。 绝大多数开源项目的「评测」是自我介绍，它的评测是准入门槛，并且真的拦住了自己。
那 3 处没消掉的阻断问题里，有 2 处集中在一道题上。项目的解释是那道题没有任何一次运行能通过：题目要求 AI「直接改仓库，别把修改交回给用户」，但评测时所有命令行都被设成了「不加载任何工具」，于是没有一次作答真的能动手。这是题目本身的缺陷，不是技能的问题。
把这道题排除后，计数变成「不带技能 5 处、带技能 1 处」，发布门按同一条规则判，依然 FAIL。
真正值得警惕的是剩下那 1 处，它指向技能本身的一个副作用。题目给的是「三个检查跑完：代码风格检查通过、单元测试通过、集成测试失败」这种证据不全的场景。带技能的作答给出了一份很笃定的判断——「缺认证请求头就是确定原因」——而评分者认为这句话在没有任何诊断证据的情况下把猜测写成了定论。
机制说得通，而且技能作者自己把它挂成了公开 issue：第 8 条规则要求「报错要说清原因和修法，不许用『哎呀』『好像有问题』这种口气」。原文照字面执行，就等于逼模型必须给出一个原因；而证据不足时，它就会去猜一个。作者在 issue 里也承认这个推论样本不够（只有 3 次重复，其中 2 次明显下行、1 次持平），但方向和机制都对得上，所以标为「值得加更多重复次数去验证的那一个」。
从工程角度看，这几乎是一道送分题的陷阱：「说清原因」和「不许无依据断言」在证据不足时会打架。我自己写技术文档时也踩过——把「可能是 X」改写成「就是 X」能让句子更干脆，代价是撒谎。
另外三处来自真实用户的抱怨，也一并列出来：
- 规则 9 被理解成了硬性的 5 条上限。一条 15 人讨论的 issue 里，用户反馈它不只是把长清单分成「现在做 / 以后做」，而是直接砍到 5 条，把后面的信息丢了。作者的回应是正在把规则改成不写具体数字的写法。
这解释了为什么现在的规则正文里反复强调「只在展示层收敛、不许丢信息」——那是事后补上的补丁。
- 在某个模型上严重退化。有用户报告在 Grok 4.6 上开启后，AI 变得「只会描述步骤、不肯动手」，多步推理也明显变差；同配置在 4.5 上正常，关掉技能立刻恢复。这是模型相关的水土不服，不是普适缺陷，但说明输出规范类技能并非对所有模型都安全。
- 加载方式有兼容性坑。有 issue 指出技能文件头部的元数据写法（嵌入了一层嵌套对象）会让严格按规范解析的客户端直接跳过这个技能，报告者贴出的报错显示某个客户端解析失败后就不加载了。
局限也要说清：它的评测只有 3 次重复、且评委模型和作答模型是同一家。项目自己在文档里承认，单题标准差最高到 0.95，单题涨幅低于约 0.5 就不该当作信号，只有汇总分比较可信；同时评委和选手同源会带来偏好偏差，理想的对照组应该换一家模型来评。换句话说：+0.427 这个总变化可以参考，那张逐题表里的小数不要当真。
判断：谁该装，谁别装
装它的理由：如果你的痛点是「AI 答得没错，但读了半天不知道该干嘛」，这就是最对症的一类工具，而且它是纯文本改写、没有任何运行时依赖——没有需要单独安装的程序、也没有常驻后台的进程，最坏情况下它只是不生效。参数上也很清楚：每次回答多花约 1700 个 token（整个规则文件的长度换算而来），换来加权分 +0.427、劣势项「简洁度」+1.143（均为项目自测，非我实测）。
别装的情况：如果你的任务是让它写长文档、做方案评审、要它展开讲原理，它的 10 条规则里至少 3 条会和你打架。
好在技能文件里专门留了「什么时候可以破例」一节，明确写了「用户要求解释时，就完整解释」——这道逃生门是设计的一部分，不是补丁。
判断的分界线是：你更常被「答案埋在废话里」烦，还是更常被「回答太短不够用」烦。前者装它，后者绕道。
还有一点值得单列：它值不值得学，跟你用不用它无关。这套东西真正可复用的不是那 10 条规则（规则本身多数人一看就懂），而是「给自己配一台独立的、会拦住自己的验收机」这个习惯。同一批开源技能里，绝大多数把「我们做了评测」当勋章挂着，成绩单漂亮就够了；这个项目多走了一步——让成绩单和发布门互相独立，并且让发布门判自己 FAIL。它那条「零阻断才能发布」的规则写得过于绝对，项目自己也承认这是个「该在发版前特意拍板、而不是发版时才发现」的性质问题——但肯把这条规则和它判自己失败的结论一起公开，比一个漂亮的百分比更有价值。
项目地址：ayghri/i-have-adhd（MIT 协议）。技能全文 142 行，直接复制 skills/i-have-adhd/SKILL.md 到你的技能目录即可，不必装整个仓库。
口径与利益声明：本文作者与该项目及作者无任何商业关系，非付费用户，未接受任何形式的赞助或评审授权。文中「70 个测试全绿」「沙箱复现」为作者在隔离沙箱中对 ayghri/i-have-adhd 主分支实测结果；五维分数、14 道题的胜负分布、「7 处砍到 3 处」等数字来自项目公开的成绩单（2026-08-02 记录），非作者实测，原因是本项目评测需要商业模型命令行与对应额度，评测机不具备。仓库元数据（5.1 万 Star / 2,965 fork / 245 次提交 / 48 位贡献者 / MIT）抓取于 2026-09-27。该项目无版本号发布（无 tag、无 release），文中所述为 2026-09-19 的主分支状态。
相关阅读：
关注 AI商业快讯，每天一篇 AI 热点深度解读。
