AI 回答太囉唆，是規格問題，不是智商問題。

這句話值得停一下。我們對 AI 的抱怨裡，有很大一塊其實不是「它答錯了」，而是「它答得太長」。你問一個 token 過期要怎麼修，它先花兩段解釋什麼是 JWT、再花一段說明為什麼會過期，真正要打的那行指令躲在第四段中間，結尾還補一句「希望這對你有幫助！」。你要的是一個動作，它給你一篇導讀。

大部分人碰到這件事的反應是怪模型。換一個更強的、換一家別的、或是在 prompt 尾巴加一句「請簡短回答」。第三種偶爾有用，但只撐一輪，下一個問題它又開始鋪陳。這很奇怪對吧？明明每次都講了，它每次都忘。

因為「簡短一點」根本不是規格。那是形容詞。

一份 Markdown，5.3k star

i-have-adhd 是一個給 Claude Code、Codex、Cursor 用的 skill，GitHub 上已經 5.3k star。名字取得很直白，但它跟診斷無關。作者的意思是把 AI 的輸出改造成注意力友善的樣子：動作放最前面、多步驟編號、砍掉所有開場白和客套結尾。

有趣的是它打開來幾乎沒有程式碼。整個 repo 的核心就是一份 SKILL.md，裡面寫的是一組「你回答時要遵守的規矩」。沒有 parser、沒有 post-processing、沒有把輸出丟給第二個模型重寫。就是一份規矩。

這件事本身就是重點。一個拿到五千顆星的專案，交付物是一份文件，這說明大家缺的從來不是技術，是有人把「我要的交付長什麼樣」認真寫下來一次。

為什麼寫成規則就有用

想像你請一個很熱心的同事幫你查東西。你說「幫我查一下這個 API 怎麼用」，他回你一封八百字的信，從歷史沿革講到最佳實踐。他沒做錯任何事，因為你沒說你要什麼形式。

換個場景。你說「幫我查一下這個 API 怎麼用，用便利貼寫給我，只寫我現在要打的那行」。他就寫一張便利貼給你。

同一個人、同一個問題，差別只在你有沒有指定容器。模型也是一樣。它預設要交出一份「說明文」，因為它的訓練資料裡，回答問題長那個樣子。你不改掉那個預設，它就一直交說明文給你。

i-have-adhd 做的事，就是幫你把那張便利貼的規格寫死。

全部功力就這 10 條

# 規則 白話
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, recap, or closers 不要開場白、不要複述、不要客套

看過就懂，難的是讓 AI 每一次都真的做到。

我自己覺得最被低估的是第 5 條和第 6 條。前面幾條都在做減法，這兩條在做加法——它要求 AI 每一輪主動報告「現在到哪了」「大概還要多久」。跟一個會自己跑二十分鐘的 agent 合作時，這兩條的價值遠高於「少講廢話」。你不用一直問它做完沒。

第 8 條也很有感。AI 出錯時很愛演，先道歉三句再說發生什麼事。平鋪直敘講「這步失敗了，錯誤是 X，我改用 Y」，你的處理速度會快很多。

差別長這樣

README 給了一組對照。沒裝之前你會拿到落落長的說明，中間夾各種「你可能也想知道」，最後 Hope this helps! 收尾。

裝了之後，同一個問題變成：

Run npm install jsonwebtoken@latest, then edit src/auth.ts:42.

  1. Open src/auth.ts…

第一句就是要打的指令。你不用讀完整段就能動手。

裝起來兩行

它走各家 coding agent 的 plugin marketplace。Claude Code：

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

裝完打 /i-have-adhd 套用。Codex 那邊是：

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

用 $i-have-adhd 觸發。更完整的步驟在 repo 的 INSTALL.md。

因為核心就是一份 SKILL.md，客製化也很簡單：fork 回自己帳號，打開 skills/i-have-adhd/SKILL.md 改成你要的規矩，再裝回來。覺得「清單最多 5 項」太少，或想保留多一點推理過程，改一行就好。這其實是我覺得它比較聰明的設計——它沒有把規則寫死在程式裡，所以你不喜歡的部分改得動。

什麼場合最有感

寫 code 寫到一半問它東西的時候差最多。你在心流裡，只想知道下一步打什麼、改哪個檔，動作優先的輸出掃一眼就能接著做，不會把你的節奏撞斷。

無人值守的排程 agent 是另一個。自動化流程裡 AI 的輸出常常要被下一段程式或人快速判讀，編號步驟、狀態明確、沒有廢話，比一堆散文好接太多。

還有一個很實際的：把 AI 的回答貼進 issue 或 PR。少了客套開場跟結尾，貼進去剛好就是一份乾淨的 checklist，同事不用自己再刪一遍。

代價要先知道

它改的是講話方式，不是答案正確率。回答會變簡潔，但一樣可能答錯。講得篤定又有條理的東西最容易讓人放鬆查證，這點要自己盯住。

精簡本身也有代價。砍掉鋪陳的同時，可能砍掉你需要的脈絡。碰到要它攤開好幾個方案做取捨的任務，這種風格反而礙事。你要的正是那些它被規定不能講的推理過程。這種時候就把它關掉。

另外它本質是一組 prompt 規則，模型願不願意乖乖遵守、遵守得多徹底，會因模型而異。安裝也需要支援 plugin marketplace 的較新版本 Claude Code 或 Codex。

順帶一提，這 10 條規則不是憑空發明的，是從《The Adult ADHD Tool Kit》改編過來的。原本是給人的溝通建議，作者把它翻譯成給 LLM 的規矩。原本要幫助的是注意力容易分散的人，結果拿來管 AI 也成立，這個轉譯本身滿有意思。

真正該帶走的

那個問題可以再問得更廣一點：你對 AI 的不滿裡，有多少其實是沒開規格？

「回答太長」是一個。「格式每次都不一樣」是一個。「一直忘記我的專案慣例」也是一個。這些聽起來像模型能力問題，但它們的共同點是：你心裡有一份驗收標準，而你從來沒把它寫下來過。

寫下來，就是一份 SKILL.md。五千顆星證明的不是這套規則多高明，是「原來可以這樣做」這件事，多數人還沒想到。

相關連結

  • GitHub：ayghri/i-have-adhd（MIT license，約 5.3k star）
  • 原著：《The Adult ADHD Tool Kit》 by J. Russell Ramsay & Anthony L. Rostain