ADHD：把發散思維拆成獨立推理行程的 agent skill
ADHD — a skill for coding agents. Tree-of-thought with pruning, built on the Claude & Codex Agent SDK. Fans out parallel divergent thoughts under different cognitive frames, scores, prunes traps, deepens the survivors. The no-brainer skill for creative and interdisciplinary work.
秒懂
- 它是什麼？
- ADHD 是掛在 Claude Code、Codex 等 coding agent 上的一個 skill，用平行、彼此隔離的認知框架產生想法，再交給獨立的評審階段評分、剪枝、深化。以下整理它實際解決的問題、機制、安裝方式，以及文件沒有交代清楚的地方。
- 適合誰用？
- 如果你面對的是設計取捨、命名、API 介面規劃、模糊除錯這類「給我幾種做法」的題目，而且願意付多次平行推論的 token 成本，ADHD 值得在一個真實題目上跑一次再決定是否納入日常工作流。若你的任務是單一正解的重構、效能調校或已有明確規格的實作，平行發散只會製造需要人工過濾的雜訊，不適合採用。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 3 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它針對的是線性推理的錨定效應
自迴歸模型產出推理鏈時，前面講過的話會變成後面推理的前提。README 把這個現象稱為 premature convergence：線性 Chain-of-Thought 會錨定在它最先說出的那個答案上。Tree-of-Thought 雖然把搜尋面打開，但 README 指出它仍然走同一份共享 context，所以錨定會沿著分支延續下去。ADHD 的立場是把這件事當成架構問題而非提示詞問題，解法是在發散階段完全不共享 context。這個判斷決定了它適合什麼題目：需要跳出第一個合理答案的場合，例如設計取捨、模糊除錯、命名、API 介面規劃、策略擬定。它不處理需要唯一正解的任務，那類題目平行發散只會產生要人工收拾的雜訊。
發散、評分、剪枝、深化四個階段
README 描述的做法是 spawn N 個彼此隔離的推理行程，每個掛在不同的認知框架下，發散期間零共享 context。接著跑一個獨立的 critic pass，負責評分、分群、標記陷阱、深化存活下來的想法。README 的 side-by-side 範例用的是 6 個框架，產出 30 多個想法，標記 20 個陷阱。範例題目是「CLI 呼叫 LLM 有時卡住 90 秒，設計重試、逾時與 UX 策略」，ADHD 給出的非顯而易見選項是即時中止並改走更便宜更快的模型，理由是慢的那個模型可能根本不適合這個 prompt。這是整個機制裡最值得注意的一點：它產出的價值不在想法數量，而在於它會明確標出哪些方向是陷阱以及原因。至於 critic pass 用什麼模型、評分尺度如何定義、框架清單是否可自訂，README 沒有交代，需要看 documentation 目錄。
安裝與執行環境
官方給的安裝指令是 npx skills add UditAkhourii/adhd，README 說它會自動偵測你的 agent，涵蓋 Claude Code、Cursor、Antigravity、Codex、Cline、Gemini CLI、Windsurf 等。npm 套件名稱是 adhd-agent，Node 版本要求 >=18。裝好之後以 /ad 這個斜線指令顯式呼叫，README 的範例在此處被截斷，完整用法要看 documentation/install.md 與 adhd.mintlify.site。專案以 TypeScript 撰寫，MIT 授權，預設分支 main。v0.1.4 的 release note 提到 Codex 相容性與第一個 OSS 採用者，也就是說跨 agent 支援是近期才補上的，早期版本應以 Claude Code 為主。
評估數據來自專案方自己的測試
README 引用的獨立 LLM 評審結果是 breadth 9 對 6、novelty 8 對 3、trap detection 約 8 對約 2，方法論放在 documentation/evals.md，完整逐字稿在 bench/results.json。這組數字的解讀需要保留：它來自單一題目、單一模型，而且 README 自己也說評審是 LLM。換一個題目、換一個模型，差距是否維持同樣幅度，從現有材料無法確認。真正可查的是那份逐字稿，判斷這個 skill 值不值得用，應該先讀 bench/results.json 裡 20 個被標記的陷阱是否合理，而不是看那三個分數。
成本與失敗模式
平行發散本質上是用 token 換廣度。6 個隔離框架加上一輪 critic pass，推論次數遠高於單次生成，這在長 context 或高單價模型上會直接反映在帳單。第二個限制是收斂責任回到人身上：README 的範例裡 30 多個想法最後只留下一個主選與三條短清單，中間的篩選由 critic 完成，但 critic 的判斷品質決定了整個流程的產出品質。第三個限制與題型有關，當任務本身有明確規格或唯一正解時，隔離框架產生的多樣性沒有價值，反而增加閱讀負擔。文件沒有說明平行框架的併發上限、失敗重試行為，也沒有說明單次執行的 token 預算，這些在導入前都是未知數。
與 Tree-of-Thought 實作的差異
同樣是樹狀搜尋，Tree-of-Thought 的典型實作讓分支共享同一份對話 context，分支之間互相可見，錨定因此延續。ADHD 的差異在於發散階段刻意切斷共享 context，並且讓每個分支處在不同的認知框架下，README 列出的框架類型包括 economic-incentive、async-control-surface、gamification、perceptual-distortion、collective-intelligence、redundancy-race。這是方法論上的分歧，不是參數調整。代價是分支之間無法互相啟發，好處是不會全部收斂到同一個起點。另一條路是自己寫多輪提示詞迴圈，彈性更大但沒有內建的評分與剪枝階段，你得自己實作 critic 那一層。
採用前該確認的事
這個專案在 2026 年 5 月發布 v0.1.4，距今約三個月，版本號仍在 0.x。README 提到 17 個以上專案採用或整合，包括 repowire、mstack、zk-flow-oss、han、wtfismyrepo、awesome-prompts，完整清單在 ADOPTERS.md。其中 repowire 的整合以 PR #313 合併，是把 ADHD 移植到它自己的 mesh-orchestrator 原語上，這代表 skill 的邊界是可以被拆開重組的。如果你要的是開箱即用，先確認 npx skills add 對你的 agent 實際寫入了哪些檔案與指令；如果你要的是嵌進既有流程，repowire 那個 PR 比 README 更值得讀。MIT 授權允許商用與修改，但移植到自家系統後的維護責任落在你這邊，上游 0.x 的介面變動沒有穩定性承諾。
編輯結論
如果你面對的是設計取捨、命名、API 介面規劃、模糊除錯這類「給我幾種做法」的題目，而且願意付多次平行推論的 token 成本，ADHD 值得在一個真實題目上跑一次再決定是否納入日常工作流。若你的任務是單一正解的重構、效能調校或已有明確規格的實作，平行發散只會製造需要人工過濾的雜訊，不適合採用。採用前請先查證三件事：bench/results.json 裡那組評分是否由專案方自行執行、documentation/evals.md 的評審方法是否可重現、以及 npx skills add 對你的 agent 實際寫入了哪些檔案。
社群筆記