巨人之肩 (Giants' Shoulders) 是做什麼的？
「如果說我看得比別人更遠，那是因為我站在巨人的肩膀上。」——艾薩克·牛頓，1675
概述
在開始建構新東西之前，先找出誰已經建構過類似的東西。 大多數的想法都已經被嘗試過：有些解決得很好，有些解決得很差，有些因為具有啟發性的原因而被放棄，少數則真正是空白的領域。目標不是抄襲——而是從當前的邊界開始，而不是從空白頁開始：重用經過驗證的方法，避開已知的死胡同，並清楚地看到任務實際上與現有方案有何不同。
此技能與代理無關：適用於任何能夠搜索網路的代理（Claude Code、Codex、Cursor、TRAE 或其他）。使用主機提供的任何網路搜尋/獲取工具。請在任務開始時、設計或編碼之前執行此技能，並保持比例——這是一次簡短的掃描，而不是文獻回顧。
何時執行 vs. 跳過
執行：當任務需要創建新東西或選擇方法時：建構工具/腳本/函式庫/CLI/技能/插件/代理/工作流程/整合/原型/產品，設計架構，或選擇框架、函式庫或演算法。
跳過：對於瑣碎的任務（翻譯一行文字、重新命名一個變數、查看時間）或沒有外部前車之鑑的任務（編輯使用者自己的私有檔案/資料）。如果不確定是否值得，可以問一句：「要不要我先花一兩分鐘看看有沒有現成方案？」
工作流程
1. 用一句話重新陳述問題
將任務簡化為核心問題，用白話描述——而不是使用者選擇的解決方案。例如：「建立一個腳本對我的 CSV 去重」→ 核心問題 = 「表格資料中的行去重」。如果問題框架過於寬泛，以至與整個工具類別匹配，則在搜索前提出剛好一個澄清問題（提供最多 3 個範例維度作為提示，而不是一份問卷）。
2. 在搜索前生成詞彙表
不同的社群使用不同的詞彙來描述同一件事。在執行任何查詢之前，從不同的視角寫出6–10 個問題框架，並將每個搜索查詢映射到一個框架。這可以防止最常見的失敗模式：五次查詢都落在同一個語義區域。至少涵蓋：
- 建構者框架 — 使用者自己的用語
- 工具使用者框架 — 搜尋此工具的人會輸入的詞彙
- 學術/研究框架 — 如果適用
- 基礎設施/實作框架 — 低層級的名稱
- 相鄰社群框架 — 很可能先解決此問題的鄰近領域
至少包含一個英文框架——大多數前車之鑑和倉庫用英文搜索效果更好。
3. 在開發者實際發表的地方搜索
使用主機的網路工具（先搜尋，然後獲取有希望的結果）。針對不同的框架和來源執行3–6 次有針對性的查詢——不要只執行一個通用查詢就停止。
| 來源 | 找到的內容 | 方法 |
|---|---|---|
| 網頁搜尋 | 產品、比較、「最佳 X 用於 Y」、部落格文章 | 主機搜索工具 |
| 程式碼託管平台 | 實際實現、函式庫、「awesome-*」列表 | site:github.com <問題>、GitLab；如果 gh CLI 存在則使用 gh search repos/code "<關鍵詞>" |
| 套件註冊表 | 現有函式庫 | npm、PyPI、crates.io、pkg.go.dev、Hugging Face (ML) |
| 產品/社群 | 已發布的產品、實戰經驗談 | Product Hunt、Hacker News "Show HN"、相關子版塊 |
| 問答/論壇 | 陷阱、方法失敗的原因 | Stack Overflow、HN 討論串 |
| 領域場所 | 標準做法 | 官方文件、RFC/標準、arXiv、模型卡片 |
優先使用主要來源（倉庫、Show HN 討論串、專案首頁）而不是彙整性的列表文章。一個有 200 顆星的 GitHub 倉庫勝過一篇 Medium 列表文章。
4. 對每個直接匹配項向下追踪一層
這是掃描最常失敗的地方——因為提早一層就停止了。當一個專案的文件說「基於 X 建構」、「包裝了 Y」、「Z 的官方框架」或「通過 W 運行」時，這個被提及的東西往往是真正的現有霸主，而你找到的專案只是一個薄薄的包裝。將直接匹配項中的每個命名依賴視為搜索線索：在得出結論之前，用專門的查詢追蹤它。不要讓第一個（可能很小的）專案錨定你的答案。
5. 將發現歸類為四個桶
不要傾倒原始結果。將它們分組：
- 直接匹配 — 相同的問題，相同的方法
- 相鄰方案 — 相同的問題，不同的方法
- 部分方案 — 解決了子集
- 已廢棄/過時 — 曾經存在，現在已死（記錄最後提交日期，如果找得到，記錄原因——這通常是最有啟發性的前車之鑑）
6. 提取標準模式
在所有匹配項中，哪些模式反覆出現？常見的架構、函式庫、設計決策、命名、定價模式。這就是任務在構建或競爭時所依據的默認劇本。
7. 誠實地衡量任務的切入角度
用一段話，將使用者的特定框架與現有方案進行比較。說出真正的差異化優勢，或者承認沒有差異化優勢。不要為了友善而製造新意，也不要為了看起來詳盡而虛構競爭對手。
8. 給出裁決，然後繼續
選擇一個裁決並以此開頭（確切的輸出格式請參見 references/report-template.md）：
- 使用現有方案 — 已經解決得很好；指出最佳選項
- 擴充分支 — 最近的專案 + 具體要添加的內容
- 向上游貢獻 — 該功能屬於上游；建議在哪裡貢獻
- 從頭建構 — 真正的空白領域；差異化優勢清晰且可防禦
- 先進行調查 — 有人嘗試過但放棄了；先了解原因再花時間
然後，將任務交給實際的工作，並以你的發現為基礎。除非某個發現從根本上改變了範圍（例如，一個成熟的工具已經完全實現了這個功能）——在這種情況下，請提出來並詢問——否則不要為了獲得批准而停滯。
預算與護欄
- 設定時間盒。 目標是 ≤10 次總查詢；如果在 3-4 次查詢後情況已經明朗，並且至少有一個追蹤了依賴項向下一層（步驟 4），則可以更早停止。這是在實際工作之前進行的準備工作；它不應該佔據主導地位。
- 誠實報告。 「未找到直接的前車之鑑」是一個有效且有價值的結果——說明你在哪裡搜索過，而不是用弱匹配或虛假的競爭對手來湊數。
- 當有好的東西存在時，不要建議「建構」。 自定義建構會帶來持續的維護成本，而這個成本往往被低估。除非沒有合適的方案，否則默認使用/改編/貢獻。
- 檢查維護狀態，而不僅僅是星數。 近期的提交、問題回應、發布週期和公車指數比星數更能說明問題。一個穩定的 500 星工具可能勝過一個 trending 的 50k 星工具。
- 尊重授權條款。 在建議重用時，請註明專案的授權條款。
- 引用來源。 每個命名的項目都應附上連結，以便發現可驗證。
- 沒有網路？ 請說明情況，並註明掃描已被跳過，然後依賴你所知道的知識——標記其為記憶推導的，可能已過時——然後繼續前進。
- 綜合總結，而不是單純列出。 價值在於比較（重用 vs. 空白），而不是一堆連結。
參考文件
references/report-template.md— 確切的輸出結構和一個實際範例。在撰寫簡報時請閱讀它。
可選：將其設為默認規則
默認情況下，此技能僅在其描述與任務匹配時觸發。要讓它在每個從頭建構的任務之前自動運行，請在主機代理的指令檔案中添加一條規則。執行一次（選擇加入、冪等、可安全重新執行）：
scripts/install.sh
它會詢問是否將「巨人之肩」設為默認規則，如果選擇是，則會在其找到的代理指令檔案（Codex/TRAE/Cursor 的 AGENTS.md，Claude Code 的 CLAUDE.md）中附加一個由標記包裹的規則區塊。拒絕則不寫入任何內容。設置 GIANTS_SHOULDERS_ASSUME_YES=1 以非互動方式安裝。