有些工具不是为了增加功能，而是为了纠正一种让人抓狂的习惯。`i-have-adhd` 就很像这样一个项目。它不负责写更多代码，不负责接更多接口，也不负责替代理上天入地。它盯上的，是另一件看似小、其实每天都在消耗人的事：**回答明明可以一句话说清，却偏偏要先铺三层垫子，再绕五个弯，最后把真正有用的动作埋在中间。**

这个仓库把自己的 description 写得异常干脆：**A skill for your coding agent to stop it from burying the answer. ADHD-friendly output.**  
它的目标不是含糊的“优化表达”，而是非常具体地阻止编码代理**把答案埋起来**。

项目地址：/ayghri/i-have-adhd

## 它不是一个新模型，也不是一套复杂系统，而是一种回答方式的矫正器

README 的一句话已经把它说透了：**ADHD-friendly outputs. No ADHD diagnosis needed!**

这句话很轻，却很有穿透力。它并没有把自己包装成某种严肃沉重的心理标签工具，也没有设置额外门槛，而是直接把重点放回输出体验本身：让回答更容易抓住重点，更容易执行，更不容易让人读到一半就失去线头。

这意味着 `i-have-adhd` 本质上是一种**skill**，用来约束编码助手的表达方式。它不改变助手知道什么，而是改变助手**怎么说、先说什么、说到什么程度就该停**。

## 它要解决的问题，其实很多人都太熟了

README 在 “What it does” 里写得很直白：

**A skill for your coding assistant that stops it from burying the answer. Action first. Steps numbered. No "Hope this helps!"**

这三句几乎像三记精准落点：

- **stops it from burying the answer**
- **Action first**
- **Steps numbered**

最后再补一刀：

- **No "Hope this helps!"**

光看这几句，就能立刻明白作者在对抗什么。那种“先热情寒暄、再长篇铺垫、最后含糊收尾”的代理式表达，在这个 skill 面前几乎没有藏身之处。它要的不是更客气，而是更可执行；不是更圆润，而是更快把人送到下一步。

## 最精彩的地方，是它把“前后对比”摆得一清二楚

README 里有一个非常生动的对照表，分别展示了 **Before** 和 **After**。

### Before

是那种很多人一看就头皮发麻的回答方式：  
先来一句“Great question! Let me think about this.”，然后开始解释“你的 auth flow 有几个 moving pieces”，再继续展开 middleware、token verification、cookie handling……真正该做的动作迟迟不落地。

### After

它变成了这种样子：

> Run `npm install jsonwebtoken@latest`, then edit `src/auth.ts:42`.
>
> 1. Open `src/auth.ts`
> 2. Replace `verifyToken` (lines 42–58) with the snippet below
> 3. Run `npm test -- auth.spec.ts`
>
> Next: paste the first failing line if any test fails.

这个对比非常有力，因为它没有抽象讨论“输出风格优化”，而是直接让你看见差别：以前是一团云，后来是一把梯子。以前回答像把你推到信息堆里自己找出口，后来则像一只手直接把第一块落脚石放到你脚下。

## 它最核心的，是那 10 条规则

README 里把规则压缩成了 10 条，并说明完整内容在 `SKILL.md` 中。仅凭这 10 条，已经足以看出整个 skill 的精神内核。

### 1. Lead with the next action

先说下一步动作。不是先说背景，不是先说赞叹，也不是先说“让我想想”，而是先把人最需要做的事放出来。

### 2. Number multi-step tasks

多步骤任务必须编号。因为一旦没有编号，信息就会糊成一团；一旦编号出现，执行感就会立刻变强。

### 3. End with one concrete next step

结尾只留一个具体的下一步。这一点很妙，因为它能防止回答在最后又分叉出三个建议、五个可能和八个“你也可以”。

### 4. Suppress tangents

压制跑题。很多回答的问题不是没内容，而是支线比主线还粗，最后把读者带丢了。

### 5. Restate state every turn

每一轮都重新说明当前状态。这样对话不会因为上下文堆积变得越来越混乱。

### 6. Specific time estimates

时间预估要具体，用“几分钟”而不是“很快”“一会儿”“稍后”。这让任务感变得可感知。

### 7. Make wins visible

要让进展可见。哪怕只是完成一小步，也要让“做成了什么”看得见。

### 8. Matter-of-fact errors

错误提示要就事论事，别情绪化、别戏剧化、别兜圈子。

### 9. Cap lists at 5 items

列表最多 5 项。这个限制本身就很有风格：不是不能多说，而是不准一口气倾倒太多东西。

### 10. No preamble. No recap. No closers.

没有前言，没有复述，没有收尾客套。不要“Great question”，不要“总结一下”，也不要“希望这对你有帮助”。

这十条组合起来，几乎像是给代理立了一套沟通军规。它们的共同目标只有一个：**把可执行性从语言废雾里救出来。**

## 它的安装方式也非常简洁，和项目气质高度一致

### Claude Code

README 给出的安装命令是：

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

之后输入：

```bash
/i-have-adhd
```

就可以启用这套输出风格。README 还特别说明：**不需要本地 clone**，Claude Code 会获取这个仓库并保持更新。

### Codex

Codex 的安装方式是：

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

启用时使用：

```bash
$i-have-adhd
```

README 同时说明，这个 skill 也可能在 Codex 识别到适合的任务时被**隐式调用**。

这两个安装过程都很短，也很符合项目本身的性格：不铺陈，不冗长，直奔主题。

## 它甚至允许你自己把这套“说话纪律”改造成私人口味

README 在 “Tune it” 里给出了一条很直接的路径：如果你想调整它，就 fork 仓库，编辑 `skills/i-have-adhd/SKILL.md`，然后安装你自己的 fork。

示例方式是：

`claude plugin marketplace add <your-username>/i-have-adhd`

这个设计很讨喜。因为沟通风格这件事，本来就很个人。有人想更冷静一点，有人想更强硬一点，有人想更简洁，有人想保留一点温度。项目没有把规则变成不可碰触的圣经，而是留出了定制空间。

## 它不是凭空长出来的，README 也交代了灵感来源

在 Credits 里，README 写得很明白：它**loosely based on** *The Adult ADHD Tool Kit*，作者是 J. Russell Ramsay 和 Anthony L. Rostain。  
但同时也特别指出：这里的改编针对的是**LLM 应该如何回应**，而不是人类应该如何安排自己的一天。

这个界限划得很清楚。它不是把一本书生硬地搬进插件里，而是借用了其中的某些思路，重新转译成适合代理输出风格的规则集。

## 它的价值，不在“懂 ADHD”，而在“懂拖沓的伤害”

这个项目最容易让人误解的一点，可能恰恰在名字上。`i-have-adhd` 看起来像一个面向某类特定人群的工具，但 README 其实已经说得很清楚：**No ADHD diagnosis needed**。

这句话背后的真正意思是：它并不要求某种身份认同，它处理的是一种广泛存在的阅读与执行困境——回答太松散、重点太晚出现、动作不够明确、任务边界不清晰、支线太多、客套太重。

这些问题不只会困扰某一类人，几乎任何在高密度信息环境里工作的人，都很容易被这种表达方式消耗。尤其在编码场景里，很多时候人并不是不懂，而是**没有精力穿过一大段语言泡沫，去捞那颗真正有用的钉子**。

而 `i-have-adhd` 做的，就是逼代理先把那颗钉子递出来。

## 它像一张贴在代理额头上的便签：先说人该做什么

如果把这个项目拟人化，它不像一个功能庞大的工程师，更像一个站在旁边、时不时敲桌子提醒的编辑：

- 先说结论  
- 先说动作  
- 步骤编号  
- 别岔开  
- 别啰嗦  
- 别客套  
- 最后只留一个下一步

它不负责替你解决一切，但它负责确保当代理已经知道答案时，**不会再把答案藏进一团友好、完整、圆润、却令人分神的语言里**。

## 为什么这样的小项目反而很容易让人记住

因为它解决的是一个每天都会发生、却常常被忽视的摩擦点。

很多项目在扩展代理的能力边界：让它会搜索、会写代码、会调试、会部署。`i-have-adhd` 则做了另一件同样关键的事：**让代理在已经会的前提下，别把人拖累得更累。**

它没有复杂架构，没有夸张功能树，也没有大段技术术语。它只做一件事：给编码代理加上一套更利落的输出纪律。可也正因为它做得这么聚焦，所以显得格外锋利。

你几乎可以把它理解成一种反本能训练。因为大多数模型天然倾向于解释、铺垫、补充、安抚、总结，而这个 skill 则像一把剪刀，专门去剪掉那些会把人注意力拖散的枝蔓。

## 它真正改造的，也许不是回答本身，而是协作节奏

一个回答如果总是把关键动作藏在中间，你每次都得读、找、筛、再决定下一步；久而久之，节奏就断了。  
而一个回答如果能直接给出动作、编号步骤、交代状态、控制列表长度、只留一个下一步，你和代理之间的配合会变得更像接力，而不是像拆谜语。

这正是 `i-have-adhd` 最耐人寻味的地方。它看似只是在调整措辞，实际上是在调整一种协作节拍。它逼代理说话更像工具，也更像搭档：不抢戏，不绕路，不在你最需要迈步的时候递来一盆背景知识。

于是这个项目最终给人的感觉就像一句安静但很有力量的话：

**别再埋答案了。先把路指出来。**

有些工具不是为了增加功能，而是为了纠正一种让人抓狂的习惯。i-have-adhd 就很像这样一个项目。它不负责写更多代码，不负责接更多接口，也不负责替代理上天入地。它盯上的，是另一件看似小、其实每天都在消耗人的事：回答明明可以一句话说清，却偏偏要先铺三层垫子，再绕五个弯，最后把真正有用的动作埋在中间。

i-have-adhd：给编码代理装上一颗“不许绕弯子”的脑子

技术副总监/联合创始人

人工智能

i-have-adhd项目为编码助手设计了一套简洁高效的输出规则，专注于解决"答案被埋没"的问题。它要求AI直接给出可执行步骤，避免冗长铺垫，确保回答更清晰、更易执行。项目提供10条核心规则，如"先说下一步动作"、"多步骤任务必须编号"等，帮助开发者快速获取关键信息。安装简单，支持自定义调整，适用于任何需要高效沟通的编程场景。

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

i-have-adhd项目为编码助手设计了一套简洁高效的输出规则，专注于解决"答案被埋没"的问题。它要求AI直接给出可执行步骤，避免冗长铺垫，确保回答更清晰、更易执行。项目提供10条核心规则，如"先说下一步动作"、"多步骤任务必须编号"等，帮助开发者快速获取关键信息。安装简单，支持自定义调整，适用于任何需要高效沟通的编...

i-have-adhd：给编码代理装上一颗“不许绕弯子”的脑子-腾讯云开发者社区-腾讯云

i-have-adhd：给编码代理装上一颗“不许绕弯子”的脑子

i-have-adhd：给编码代理装上一颗“不许绕弯子”的脑子

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐