抄 awesome 清單不難，難的是決定不抄什麼
現在社群上各種 awesome 清單滿天飛，隨便滑過去都是幾十甚至上百個資源。面對這種策展包，就我看到的，反應大概就兩種：要嘛挑兩三個看起來順眼的隨手裝一下，要嘛整包照單全收直接塞進自己的環境裡。
先說立場：少裝點東西
先把話講在前面：這篇是立場文，不是中性方法論。我主張少裝點東西。
整包裝上去，對環境還空空如也的人來說完全合理，畢竟從零開始先求有再求好。但如果你手上已經有一套天天在跑的工作流，事情就完全不是這麼回事：既有的東西越多，隨便塞一大包進來跟現有設定打架的機率就越高。這跟第十二篇〈你已經有的越多，新工具能給的越少〉是同一條線——能給的越少，還越容易撞。
問題是，如果不想整包裝，要怎麼把整份清單看完，而且確定自己沒有漏掉真正有用的東西？我的答案是逐條判決。清單真正的價值，不在它推薦了什麼，在你決定不抄什麼。
2026 年 7 月的時候，我拿當時全量 118 條的 hesreallyhim/awesome-claude-code 開源清單來試。我給自己的目標很簡單：不挑著看，但也不整包搬，而是把 118 條全部看完，逐條做出判決。
每一條都要拿到判決，而且加總要對得上
做法其實很單純：每一條資源都必須拿到三種判決之一。
- 借鑑落地：概念很好，但我不裝它的本體（工具程式本身），只把裡面的規則、數字或判準抽出來，接回自己的流程。
- 引入候選：現有環境真的缺這個能力，值得列進「要不要裝」的討論名單，另外找時間評估。
- 跳過：明確判定不需要，並且當場寫下一句具體的否決理由。
這個流程的完成標準不是「我覺得看完了」，而是分批處理的每一批加總起來必須剛好等於 118：每一條都有判決、一條都不准漏。每筆至少記資源名稱、判決、理由；進候選的再多一欄重新評估條件。判決按條計數，但「借鑑落地」那欄記的是抽出來的碎片，兩者不是一對一；硬列三類總數反而誤導，所以下一節只報「引入候選」這一類的數字，驗算就停在「118 條都有判決」。
這樣做的目的，是把「不抄」從一種漫不經心的略過，變成一個寫在紀錄裡的明確決定。
代價也擺在這裡：每一條都得拿自己手上已有的東西對一遍，燒 token 也燒腦。
118 條判完，只有 6 條進到安裝討論
把 118 條全部判完之後，真正進入「要不要裝」討論的候選名單，其實只有 6 條。
118 個看起來能讓工作流起飛的酷東西，拿自己的現有環境一條一條對過之後，有 112 條連「要不要裝」的討論都沒進，將近九成五根本不需要出現在你的終端機裡。
而且這 6 條候選最後也沒有全上，真的收下的只有兩個。一個是設定檔檢查工具 agent-sh/agnix。另一個嚴格說收的不是清單上的條目，而是「我缺一道危險指令的攔截」這個位置：清單裡的同類候選我都沒選，最後裝上的是自己另外帶進來的工具，細節在第二十八篇〈防得了失誤，防不住意圖：給 AI 的 shell 裝一把鎖〉。其餘 4 個候選在後續評估中全數否決。
事後回頭看還有個小巧合：被否決的 4 個裡，有 2 個後來被清單維護者自己標成不再活躍。這只能算個順向的小旁證（當時否決的理由是停更、跟既有工具重疊，跟上游後來對維護狀態的判斷方向一致），不是什麼判準。
真正帶得走的，幾乎都是碎片而不是本體
整份清單留下來的東西，幾乎都不是可以執行的套件，而是零散的碎片：像是一個「快取活多久才划算」的成本模型、一組誤報排除表。
這種「偷概念不搬本體」的狀況，在我後來消化其他包（不限清單，任何一整包外部資源）時也是一模一樣的形狀：
- 看到 openai/codex-security 這個資安外掛包，95 件全部走完判決，一個本體都沒裝，最後只抽出一張嚴重度評級表，拿來當資安審查的參考依據。
- 看到 lopopolo/harness-engineering 這份方法論知識包，整套架構完全不搬，只抽了幾個窄機制，接回我既有的工具試用流程。
- 看到 VoltAgent/awesome-claude-code-subagents 裡上百個 agent 人格範本，本體全部跳過，反倒拿它的分類方式回頭對照我過去一個月派 agent 做事的紀錄，照出我自己的系統裡缺了哪些角色。
清單裡那些包裝精美的巨大框架，拆開來看往往只有一兩塊核心邏輯剛好打中我手上的問題。把那一塊切下來帶走就好，剩下的外殼留在原地。
否決紀錄不是垃圾，它在下一次評估會複利
逐條寫下否決理由看似很花時間，但這些紀錄會累積成資產。
最明顯的例子是「多代理協作框架」。這類主打自動分工、多角色開會的工具，在不同作者的包裝下反覆出現。在我自己歷來的評估紀錄裡（不只這份清單），同類型的否決理由已經累積了十次以上，全是我個人紀錄的流水帳，不是外部統計。
先例累積起來的效果，是評估可以整類整類地做。這次的 118 條裡，檢視器與儀表板類、記憶管理類這兩個類別，就是整類被各自的既有否決標準掃掉的：看一眼確認它踩在同一個老問題上，直接套結論封存，不用逐條重新研究。
這是純粹的主觀感受，我自己沒精確量過耗時，但從「每次都要燒一輪腦力去想」，變成「對照先例就能迅速歸檔」，速度差距非常有感。
當然，否決不是判無期徒刑。這些否決先例的紀錄裡都寫著重新評估的條件，例如「等官方原生支援某個 API」或「等自己真的長出那個規模的需求」。只要條件沒成立，它就繼續安靜躺著。到目前為止，當時 118 條的判決裡，還沒有任何一條事後需要翻案。
這套方法有上限：有些坑只有跑進去才量得到
不過這套事前判決的方法也有極限。它解決的是「漏掉」：不會有任何一條默默滑過去。它防不住的是反方向的「看走眼」：判它有用、裝了才發現沒有。
有些問題你在紙上推演、看文件結構完全抓不出來，非得真的裝上去、接進真實工作流跑過一陣子才會發現。
同期有一條跟這份清單無關、獨立評估後引入的工具：oraios/serena，一個把程式庫按函式與類別建索引、讓 AI 查得到「誰呼叫了誰」的檢索工具。看架構和文件都非常合理，我也真的把它接進程式碼審查流程。結果在前後約兩週、兩輪的觀察裡，安裝當下預先登記的關鍵指標「它有沒有找出我原本做法漏掉的受影響位置」，次數是零。最後整包拆除，環境完全還原。
這不代表這個工具在所有地方都沒用，只能證明在我的工作情境與那段觀察窗內，它沒有找出任何我原本做法會漏掉的位置。
這種裝了才量得到的錯位，事前判決防不住，但可以讓它變便宜。serena 能乾淨退場、不留殘骸，正是因為安裝那天就先寫好了失敗條件與檢查日期，時間到、沒達標，照著寫好的條件拆掉就好。停損不是事後補救，是安裝當天就寫好的。這套「裝之前先寫好怎麼退場」的做法，其實是我整套工具試用制度的一角，之後有機會再寫。
從評單一工具到消化整包
把這次的整包消化放回我過去幾篇工具評估，正好補上缺的最後一個尺度：
- 第十二篇〈你已經有的越多，新工具能給的越少〉談的是怎麼評估單一工具與現有環境的競合；
- 第十四篇〈嘴上說想要，但 agent 根本沒在用〉談的是如何用真實行為資料量化工具的採用率；
- 第十五篇〈偷確定性層：否決整套 AI 工具後，還能帶走什麼〉談的是否決整套工具後如何抽取概念；
- 本篇則是把尺度拉大，示範面對百條等級的資源清單時，如何整包消化而不被牽著走。
這套消化流程固化成了一支自用的 skill，叫 absorb-pack；消化這份 118 條的清單，就是它的第一次出勤。到寫這篇為止，它被真實呼叫過 8 次，每一次都對應一個具名的包，本文出現過的那幾包都在裡面。skill 還沒公開、沒有連結可給，但 8 次是翻執行紀錄數出來的行為證據，不是宣稱。
面對滿滿的工具清單，心態上不用抗拒，把它當成挖寶就好。就算最後只挖出一兩個能用的判準或碎片，這趟也已經賺到了。真正重要的從來不是別人推薦了什麼，而是你看完之後，清清楚楚地決定了不抄什麼。