問「幫我解說這個專案的任務系統設計」，比較 base、ponytail、i-have-adhd 與兩個同開。這次答案真的變短了——短在少講了三分之一的概念，不是少講廢話。
六個維度各 0–10 分，總分 60。每個維度最高分標色，並列則同時標。答案先去識別化成 A–D 才評分，評完才揭曉對應。
| 維度 | base無客製化 | ponytail少寫程式碼 | i-have-adhd輸出排版 | 兩個同開pony + adhd |
|---|---|---|---|---|
| 正確性 | 10 |
9 |
9 |
10 |
| 完整度 | 10 |
9 |
8 |
9 |
| 簡潔度 | 7 |
8 |
7 |
8 |
| 可掃描性 | 9 |
8 |
7 |
10 |
| 資訊密度 | 10 |
9 |
8 |
8 |
| 可執行性 | 8 |
7 |
8 |
10 |
| 總分 | 54 / 60 |
50 / 60 |
47 / 60 |
55 / 60 |
這個排序不可靠，別拿它做決定。我只評了每組的第一次。而同一組跑三次，答案長度能差 30%、概念數能差 17 個——單次判讀的變異很可能大於 47 與 55 的差距。要讓排序站得住，得 12 次全評再算組內雜訊底線。
這張表能講的只有一件事：四組都寫得很好，base 沒有比較差。
把每份答案裡提到的函式、檔案、常數抽出來去重，就是它實際覆蓋了多少個知識點。一個點＝一個概念，空心表示比 base 少講的量。
base 自己跑三次，概念數只在 56 到 65 之間擺盪——全距 9 個。ponytail 少 18、兩個同開少 19，都是這條線的兩倍。這不是雜訊，是真的少講了。
數字是三次的中位數。這是計數比較，不是集合比較——不代表少講的正好是 base 講過的那 18 個。
四組差距最大 864，而 base 自己三次就能差 2,348。跟上一輪的結論一樣：output tokens 完全在雜訊裡。原因是這些 token 的大宗是 26–29 輪工具呼叫的推理，不是最終那份答案。答案砍掉四分之一，總花費不動。
兩個數字幾乎一樣，而組內本身就在 32% 到 54% 之間擺盪。沒有任何一組讓內容系統性地換方向。把這件事跟上面的概念數合起來讀，結論很精確：從同一個概念池裡挑，只是挑得更少。
相加應該接近 −48%，實際上兩個同開 ≈ ponytail 單開。壓縮由 ponytail 主導，adhd 的效果被吸收。
不過兩個同開有個單獨的好處：它是四組裡最穩的，三次概念數全距只有 5 個（base 9、adhd 11、ponytail 17）。要可預期的產出，這組最好。
最精準。資料模型表多一欄關鍵欄位。獨家講到「重算失敗不覆寫，避免把 0 蓋掉既有進度」，也是唯一分辨 runProcessBundleTx 把連線池錯誤（P2024／P2028）往上拋、業務錯誤才降級的一份。
收尾一句話最好：「用 partial unique index 換掉大部分的鎖，用冪等重算換掉精確的事件消費」。獨家點出 avatarHashTag 以現值判定、與規格 §10.7 有已知偏差。
最會給起點與終點。開場直接指向兩份權威設計文件，結尾指到文件第 27–33 行。獨家有一節講「為什麼讀路徑不能發獎」，把 justGranted → false → 獎勵被靜默吞掉 的因果鏈走完。
教學裝置最強。把三個白名單常數提煉成「理解全系統的鑰匙」，並觀察到這個 codebase 的註解記的幾乎都是「為什麼不那樣做」。結尾指向 processBundle:224-272：「30 行內有四個決策」。
事實查證方面，我抽查了約 25 處引用——schema.prisma 的七個 model 行號、task-assignment.service.ts 的七個函式定義行、三個白名單常數位置、configs/user-task.ts:10 的上限 500、以及三處註解位置。四組全部命中，沒有任何捏造。
想要完整就別開。base 的完整度與資訊密度都是最高分，而且概念覆蓋最廣。研究一個沒碰過的模組時，多出來的那 18 個知識點值得那 1,600 字。
想要快速掌握輪廓就開 ponytail，或兩個同開。少三分之一的概念換來短四分之一的篇幅，而且骨架不會少。
要穩定就兩個同開。三次概念數全距只有 5，是四組裡最可預期的。
別為了省 token 開任何一個。output tokens 三輪實驗都在雜訊裡。真要省該往 rtk、codegraph、subagent 隔離去找。
claude-opus-5，基線 --safe-mode（關掉全部客製化），工具只給 Read／Grep／Glob，四組交錯執行各 3 次。