它今天是 GitHub 全站第一。而它自己的測試報告，第一行大字寫著「Release gate: FAILED」。
一句話結論：i-have-adhd 是一個叫 AI 助手「別把答案埋在廢話裡」的 skill，今天衝上 GitHub 第一（38,245 星、單日 +3,882）；它的實測有效（加權分 4.045→4.473），但它自己的發佈閘沒過，而 README 一次都沒提過這件事。
我沒有讀 README 就寫這篇。我把整個 repo 的 62 個檔案從 GitHub API 拉下來數了一遍，數字全部是自己重算的。結果比 README 有趣得多。
（本文數據截至 2026 年 9 月 11 日 00:17 UTC，全部來自 GitHub REST API 與 git tree API。）
i-have-adhd 到底是什麼？
它是一份給 coding agent 用的輸出規範。你在 Claude Code、Codex 這類工具裡啟用它，AI 回你的話就會變成另一個樣子：第一行直接給你能執行的指令，多步驟自動編號，不再有「希望這對你有幫助！」。
作者 ayghri 在 SKILL.md 裡寫了五條前提，而這五條其實不只對 ADHD 讀者成立：工作記憶很小，沒在螢幕上的東西等於忘了；知道答案不等於做得到答案；開始是最難的一步；模糊的時間估計沒有用；進度看得見才有動力。
然後是八條規則。第一條就是全部：第一行必須是讀者可以做的事，不是背景，不是計劃。
壞的寫法：「我們來想想。你的 auth 流程有幾個環節……」
skills/i-have-adhd/SKILL.md，規則 1
好的寫法：「執行npm install jsonwebtoken，然後編輯src/auth.ts:42。」
它的「技能」只有 7,207 bytes，那另外 98% 是什麼？
這是我數完 62 個檔案之後最意外的一件事。整個 repo 438,630 bytes，真正被 AI 讀進去的那份規範只有 7,207 bytes、142 行，佔 1.64%。
| 項目 | 體積 | 佔 repo | 相對「技能本體」 |
|---|---|---|---|
| SKILL.md（技能本體） | 7,207 bytes | 1.64% | 1× |
| INSTALL 文件（6 種語言） | 147,029 bytes | 33.5% | 20.4× |
| logo.png（一張圖） | 95,884 bytes | 21.9% | 13.3× |
| Python 程式碼 | 88,579 bytes | 20.2% | 12.3× |
| 全部 Markdown | 216,348 bytes | 49.3% | 30.0× |
truncated: false），2026-09-11 自行重算。一個教 AI 精簡的工具，教你怎麼安裝它的文件是它本體的 20 倍。這件事本身不算罪，多語言安裝說明是給人看的，規範是給模型看的，兩者本來就不同用途。但它預示了後面真正的問題。
它做過實測嗎？做過，而且比多數 skill 認真
做過。這點要先講清楚，因為 GitHub 上九成掛著 skill 名號的東西根本沒有任何驗證。
evals/ 裡有一套完整的評測系統：14 個測試 case、每個跑 3 次、對照組與實驗組共 84 筆回應，評分模型是 claude-opus-4-8，執行日期 2026-08-02，作者連成本都寫出來了（生成 $2.67、評分 $0.92）。另外還有 7 個測試檔、88,579 bytes 的 Python。
結果是正向的：
| 評分維度 | 權重 | 對照組 | 裝了 skill | 差值 |
|---|---|---|---|---|
| 正確性 | 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 |
evals/RESULTS.md。14 個 case 中贏 10、平手 2、輸 2。值得注意的是正確性和安全性也往上走。一般來說，逼模型講少一點會犧牲準確度，這次沒有。
那為什麼說它把自己的重點埋了？
因為同一份 RESULTS.md，在漂亮的表格下面兩行，有一個獨立的標題：
Release gate: FAILED
evals/RESULTS.md
沒過的原因是一條絕對規則：「不得有任何 blocking finding」。對照組有 7 個，裝了 skill 之後降到 3 個，砍掉一半以上，還是不過。作者自己在文件裡點破了這條規則的設計問題：它是絕對條件，鄰近的規則卻是比較條件，所以只要案例集裡還有任何一個 blocker，再大的進步都過不了關。
然後他繼續往下拆，把對自己不利的東西一條一條寫出來：
- 有一個 case 根本不可能通過。
agent-owned-edit要求模型「直接動 repo 而不是把工作丟回給使用者」，但所有執行器都帶--tools ""，沒有任何工具可用。三個 blocker 裡有兩個來自這裡。 - 有一個真實退步。
partial-success掉了 0.63 分，三次試驗方向一致。評分者的評語是：回應「在完全沒有證據的情況下，斷言『缺少 auth header』就是確定原因，並直接開藥」。作者甚至推測了機制——規則 8 要求「先講原因再講修法」，這個句式會逼模型在證據不足時硬湊一個原因出來。 - 評分者是自己人。文件原話：「一個評分模型，評自己家族的輸出。」並建議下一步該加跨模型對照。
- 樣本太少。只跑 3 次，單一 case 標準差最高到 0.95，作者明寫「單一 case 差距低於約 0.5 不應視為訊號」。
- 84 筆回應裡有 3 筆有殘留瑕疵（把工具呼叫語法寫成純文字），兩組都有。
這份文件的誠實程度，坦白說高過我今年讀過的大部分 AI 專案。它沒有藏退步、沒有藏壞掉的 case、沒有假裝三次試驗等於科學。
問題在哪？38,245 個人按了星，而這些內容沒有一個字出現在他們按星之前會看到的地方。
我把 README（3,461 bytes）整份抓下來逐字搜，結果是這樣：
| 在 README 搜這個字 | 命中次數 |
|---|---|
eval | 0 |
RESULTS | 0 |
gate | 0 |
FAILED | 0 |
judge | 0 |
blocking | 0 |
regression | 0 |
adhd（陽性對照） | 12 |
README 也沒有任何連結指向 evals/。你要看到那份報告，得自己點進資料夾。
所以這篇文章真正的主角不是那 38,245 顆星。是一個迴圈：一個專門用來阻止 AI 把答案埋起來的工具，把自己最誠實、最有價值的那份文件，埋在了沒人會點開的資料夾裡。
這不是指控作者造假。他寫了，而且寫得很好。他只是沒有套用自己的規則 1：把最重要的那句放第一行。
38,245 顆星只有 125 個 watcher，是不是灌水？
不是。而這一段是我本來準備寫錯、查完對照組之後整段刪掉重寫的。
星數除以 watcher 數是一個常見的「假熱度」判斷法：真正有人在用的專案，會有人訂閱通知。i-have-adhd 是 306:1，看起來很誇張。但我拉了六個對照組之後發現，這個比例根本不是它的異常。
| Repo | Stars | Watchers | 星 : watcher |
|---|---|---|---|
| cathrynlavery/diagram-design | 37,723 | 117 | 322 : 1 |
| ayghri/i-have-adhd | 38,242 | 125 | 306 : 1 |
| vercel-labs/skills | 31,132 | 109 | 286 : 1 |
| obra/superpowers | 284,693 | 1,071 | 266 : 1 |
| THU-MAIC/OpenMAIC | 35,289 | 159 | 222 : 1 |
| pytorch/pytorch | 102,913 | 1,801 | 57 : 1 |
| facebook/react | 250,030 | 6,601 | 38 : 1 |
看出來了嗎？2026 年這批 AI skill 類專案全部落在 222 到 322 之間，經典基礎建設專案落在 38 到 57 之間。這是世代差異，不是造假指紋。
原因不難理解。skill 是一份文字規範，你複製走就完了，不需要訂閱通知等它改版；PyTorch 你要升級、要追 breaking change，所以會 watch。用 2015 年的 heuristic 去判 2026 年的 repo，會把整個類別都冤枉掉。
順帶一提，同一天我還差點在另一個專案上犯類似的錯：Tencent/teamai-cli 的 GitHub API 授權欄回傳 NOASSERTION，看起來像非標準授權。打開 LICENSE 原文，第一段就寫「teamai-cli is licensed under MIT」，只是前面加了一段騰訊抬頭，把 GitHub 的自動偵測器撞散了。API 的授權欄是偵測結果，不是授權事實。
所以到底值不值得裝？
看你用 AI 做什麼。從那份 eval 的逐 case 數據可以直接讀出答案，因為收益完全集中在特定情境。
| 情境 | 分數變化 | 意思 |
|---|---|---|
| 回報多步驟進度 | +2.53 | 收益最大 |
| 回報錯誤 | +2.40 | 收益最大 |
| 解釋概念、寫長文 | 0.00 ~ +0.05 | 沒差，也沒被犧牲 |
| 純寫程式碼 | 0.00 | 沒差 |
| 資訊不足時下判斷 | −0.63 | 會變糟 |
適合你，如果：你常讓 AI 跑多步驟任務、看它回報進度和錯誤，而且受不了它一次丟三百行給你。這兩類正是它加最多分的地方。
先別急，如果：你主要用 AI 做排查和診斷。那個 −0.63 的退步就發生在證據不足的情況，規則會推著模型硬給一個原因。這種時候你要的是「我不確定」，不是一個乾脆俐落的錯答案。
三步驟行動清單
- 先自己讀一次
skills/i-have-adhd/SKILL.md。142 行，五分鐘讀完。就算你不裝，那八條規則本身就是一份不錯的寫作檢查表。 - 裝完之後刻意測一個「資訊不足」的問題，看它會不會硬給你一個原因。這是已知的弱點，你要親眼確認它在你的工作流裡嚴不嚴重。
- 不合用就說
stop adhd mode。它的設計是講這句就關掉，不用反安裝。
有沒有替代方案？
有，而且最便宜的那個不用裝任何東西：直接在你的 system prompt 或專案設定檔裡寫三行——「第一行給指令」「多步驟編號」「不要結尾客套」。這三條就吃掉了 i-have-adhd 大部分的增益，因為加最多分的兩個維度正是可執行性和精簡度。
想要更完整的框架，同一天 GitHub 榜上的 obra/superpowers（284,693 星）走的是整套方法論路線，範圍大得多，學習成本也高得多。
從這件事可以學到什麼？
我這幾個月幾乎每天拆一個上榜的 repo，累積出三條習慣，今天這篇剛好三條全用上：
- 先看資料夾，再看 README。README 是行銷文案，
evals/、logs/、data/才是帳本。今天最值錢的那句話在 README 裡出現 0 次。 - 零命中之前先做陽性對照。我搜
FAILED得到 0，但我同時搜了adhd得到 12，才敢寫那個零是真的。否則你可能只是搜尋壞掉。 - 判異常之前先拉對照組。306:1 單看像鬼，放進同類六個專案裡看就是常態。沒有對照組的比率沒有意義。
至於這個 skill 本身，我的判斷是：東西是真的，數據是真的，作者也是誠實的。它唯一的毛病，剛好就是它自己想解決的那個毛病。
常見問題
i-have-adhd 需要有 ADHD 診斷才能用嗎？
不用。它是一套輸出格式規範，不是醫療工具，README 也寫明「No ADHD diagnosis needed」。它處理的是「AI 話太多、重點被埋」這個所有人都有的問題。
「Release gate: FAILED」是不是代表這個 skill 沒用？
不是。它的加權總分由 4.045 升到 4.473，14 個 case 贏 10 個。閘沒過是因為一條絕對規則（不得有任何 blocking finding），而三個 blocker 裡有兩個來自一個設計上不可能通過的測試案例。
它是免費的嗎？
是，MIT 授權，可自由使用和修改。
星數高的 GitHub 專案就等於可靠嗎？
不等於，但反過來用星數低或 watcher 少判它造假也不可靠。2026 年的 AI skill 類專案普遍在 222:1 到 322:1 的星/watcher 區間，經典基礎建設專案在 38:1 到 57:1。要判斷可靠度，去看 repo 裡有沒有測試、有沒有 eval 結果、以及那些結果敢不敢寫自己的壞消息。
免責聲明：本文所有數據於 2026 年 9 月 11 日 00:17 UTC 自 GitHub REST API 與 git tree API 取得並自行重算，開源專案的星數、檔案結構與評測結果會隨時間變動，請以你閱讀當下的 repo 為準。本文不構成任何投資或採購建議。
發佈留言