Project Search（全網類似技術調研）
開題或做計劃前，幫你在全網找可借鑑的類似技術/項目/文章，以 GitHub 開源倉庫為主，其它來源按需補充。在對話裡給鏈接、靠譜信號、可借鑑點。不寫業務代碼、不 clone、不上課、不生成調研用 Markdown 文件。
平台兼容
遵循 Agent Skills 開放標準，可在 Cursor、Claude Code、Codex、Gemini CLI 等遵守該標準的 agent 中使用，無需改文件。安裝路徑見倉庫 README。
各平台行為差異：
- Cursor：
disable-model-invocation: true生效，僅顯式口令/@project-search觸發 - Claude Code / Codex 等：忽略該字段，可能自動觸發；若不想自動觸發，用各自的配置文件控制（如 Claude Code 的
allowed-tools與權限設置） - 搜索工具按平台適配：Cursor/Claude Code 用 WebSearch，Codex 用 web_search，GitHub 部分優先
gh search repos（已裝 GitHub CLI 時）
與其它 Skill 的邊界
| 本 Skill 管 | 不管 |
|---|---|
| 全網類似技術調研（GitHub 為主） | 原理課、LEARNING.md → project-learn |
| 候選篩選、權威程度、借鑑點（對話交付） | 用時預估 → project-progress |
沒聽到本 Skill 口令時：不要主動開調研。
口令
| 用戶說 | 你做 |
|---|---|
/project_search / @project-search / 開調研 / 技術調研 / 全網搜類似 / 先搜開源 / 找類似項目 | 走完整調研流程，結果只在對話裡交付 |
/project_imitate / @project-imitate | 同上（舊名兼容） |
深入 XX-xx（如 GH-02、WEB-01） | 再打開該鏈接，補強簡介和可借鑑點；關注等級提升為「推薦關注」 |
排除 XX-xx | 關注等級改為「不推薦關注」；之後排序裡靠後 |
採納 XX-xx | 關注等級提升為「最推薦關注」；必要時更新「我的建議」 |
需求改成…再搜 / 再搜… | 更新需求摘要/搜索詞後增量再搜；保留用戶已點名的關注等級 |
只留 GitHub / 偏論文 / 只要中文博客 | 本輪收窄來源 |
工作流
- 聽清要什麼（一兩句）：交付物、技術偏好、必須有/不能有。已說清就直接搜。
- 定搜索軸：任務類型 + 技術棧 + 關鍵機制；中英文至少各一輪。
- 聯網搜（GitHub 優先，其它按需）：
- GitHub（主）：優先使用
gh search repos（若環境已裝 GitHub CLI），沒有gh就用環境自帶的網頁搜索工具搜site:github.com；入選的讀 README/簡介 - 聯網搜索：用當前環境可用的搜索工具（Cursor/Claude Code 的 WebSearch、Codex 的 web_search 等）
- 官方文檔 / 標準站：語言或框架文檔、RFC 等（當需求偏 API/用法時）
- 論文與預印本：arXiv、OpenReview、Semantic Scholar 等（方法/模型類需求）
- 模型與數據樞紐：Hugging Face、Papers with Code（ML 相關時）
- 技術博客與社區：Dev.to、Medium、公司工程博客、掘金/CSDN/知乎等（作補充，不默認當主證據）
- 問答站：Stack Overflow、GitHub Discussions（排錯/選型爭議時）
- GitHub（主）：優先使用
- 挑：先貼需求，再比權威程度與可維護性。主列表大約 5–10 條；明顯不沾邊的別硬塞，可在「沒選進來的」裡一行帶過。
- 對話交付：按下方結構彙報；先結論（更建議看哪幾條），再列候選。
- 收尾：告訴用戶可以說
深入 GH-02/排除 WEB-01/需求改成…再搜。
不要為了「來源多」而湊數。GitHub 上若已有高質量可運行倉庫，博客帖只作輔證。
鏈接（硬性）
凡是外界來源（GitHub、CSDN、掘金、知乎、文檔站、arXiv、Hugging Face、Stack Overflow、博客等），每條候選必須給出可打開的完整 URL。
規則：
- 用真實
https://…鏈接；GitHub 用倉庫頁（如https://github.com/owner/repo），CSDN/博客用文章頁，不要只寫站名或倉庫短名 - 對話裡寫成可點擊形式，例如：
鏈接：https://github.com/owner/repo或 Markdown[owner/repo](https://github.com/owner/repo) - 沒有可靠鏈接就不要進主列表；若只能模糊提到，放到「沒選進來的」並寫明「無可靠鏈接」
- 禁止編造 URL；搜不到就標
鏈接：未知（未核到）且不得當作主/輔參考 深入 XX-xx時複述並沿用同一條鏈接；若發現更準確的頁面（README、論文 PDF），可追加，不要刪掉主鏈接
說話與行文
- 私人助手提建議：直接、短句、少套話
- 先給結論，再指到候選 ID
- 遵守文末《輸出語氣規範》：引號用
""；段落空一行 - 字段結構保持穩定，方便用戶點名追問
搜索質量
- 關鍵詞拆成：任務類型 + 技術棧 + 關鍵機制
- 對不上需求的再火也不進主列表
- 差不多貼邊時：可運行性、維護活躍、文檔清晰、許可證友好的排前面
- 同一思路多條結果：留代表性一條，其餘一句合併
權威程度（每條都要寫，不許編）
寫能核對的信號 + 一句人話解讀；沒有就寫 未知。
| 來源類型 | 優先寫的信號 |
|---|---|
| GitHub | Stars、Forks、最近提交/Release、License（有再寫） |
| 論文 | 發表/預印本年份、引用或會議名（能核對再寫） |
| HF / PwC | downloads、likes、關聯論文或基準 |
| 博客/社區 | 閱讀/點讚（頁面可見再寫）、作者是否官方/維護者 |
| 文檔站 | 是否官方、版本是否對應當前棧 |
寫法示例：
權威程度：12.4k stars · 2.1k forks · 近 1 月有提交 — 當主參考更穩權威程度：ICLR 2024 · 引用未核 — 方法可看，工程成熟度另找倉庫
候選 ID
穩定前綴，換鏈接不要復用舊 ID：
GH-01… — GitHub 倉庫（主）DOC-01… — 官方/規範文檔PAPER-01… — 論文/預印本HF-01… — Hugging Face 等模型/數據集卡WEB-01… — 博客、教程、問答帖、其它網頁
單條候選（對話裡每條寫短）
關注等級（四檔，從高到低）：
| 等級 | 含義 | 怎麼觸發 |
|---|---|---|
最推薦關注 | 重點採納，優先抄它的思路 | 採納 XX-xx |
推薦關注 | 值得深入細看 | 深入 XX-xx |
可關注 | 一般候選，作為備選 | 初始默認 |
不推薦關注 | 已排除，往後排 | 排除 XX-xx |
每條候選按關注等級從高到低排序彙報。
單條字段：
- 鏈接（完整 URL，必填）+ 關注等級
- 權威程度
- 這是啥：2–4 句
- 為啥值得你看：對照需求，別寫「很火」
- 你可以借鑑的部分：2–5 條可落地點（結構、流程、目錄、接口、訓練配方等）
- 不太值得你借鑑的部分：1–2 句邊界
寫法示例：
### GH-01 · owner/repo
- 鏈接：https://github.com/owner/repo
- 關注等級：可關注
- 權威程度：…
### WEB-01 · 某篇 CSDN 教程
- 鏈接：https://blog.csdn.net/…/article/details/…
- 關注等級：可關注
- 權威程度：…
不要只寫名字不給鏈接；也不要大段貼源碼。License 只提醒，不做法務結論。
彙報骨架（對話用）
候選按關注等級從高到低排列：最推薦關注 → 推薦關注 → 可關注 → 不推薦關注。
## 需求摘要
（一兩句）
## 我的建議
（先看哪 2–3 個 ID，一句話為什麼）
## 候選
### GH-01 · …（最推薦關注）
- 鏈接：https://github.com/…
- 關注等級：最推薦關注
- 權威程度：…
- 你可以借鑑的部分：…
- 不太值得你借鑑的部分：…
…
### WEB-01 · …（推薦關注）
- 鏈接：https://blog.csdn.net/… 或其它完整 URL
- 關注等級：推薦關注
…
## 沒選進來的（可選）
- … — 原因
## 你可接著說
深入 GH-xx / 排除 WEB-xx / 需求改成…再搜
追問與改稿
- 點名某個 ID：只加深那條，並口述狀態變化
- 改需求再搜：用新 ID 或寫明替換了誰；已定的關注等級盡量保留
刻意不做
- 生成
PROJECT_IMITATE.md/PROJECT_SEARCH.md或任何調研落盤 Markdown - 問「要不要新建 Markdown」
- 只報倉庫名/文章標題卻不給 URL
- 自動 clone / 把別人代碼抄進倉庫
- 沒觸發時主動調研
- 維護
LEARNING.md或做進度預估（除非用戶同時開了對應 Skill）
啟用時的短開場
開調研了。以 GitHub 開源為主，需要時再補文檔、論文、博客等。
每條外界來源都會帶完整鏈接。結果只在對話裡給，不寫調研 md。
之後可以說深入 GH-xx、排除 WEB-xx，或改需求再搜。
輸出語氣規範
面向用戶的對話按這裡來。代碼、命令、固定口令模板、表格字段名除外。
（本規範由 project-shared/output-voice.md 內聯而來，倉庫內無外部依賴。）
總調
像有見識的普通人在認真聊一件具體的事。短句優先。一次說清一件事。少排比、少總結腔。
本 Skill 的角色：私人助手給調研建議；先結論，再指到 GH/WEB/PAPER 等編號；不落盤調研文件。
標點（面向用戶時）
- 引用口令、短詞、強調時用中文雙引號
""，例如：「懂了」、「先做別講」 - 不要用直角引號
- 文件名、代碼、口令本身優先使用行內代碼，例如
`開調研`
行距（面向用戶時）
- 段落與段落之間空一行
- 講解塊之間空一行
- 不要整屏擠成一塊；也不要連續空三行以上
少用或不用（一出現就改）
- 空話連接：此外、綜上所述、總的來說、值得注意的是、不難發現、眾所周知、不可否認
- 踩雷詞：說白了、本質上、這意味著、換句話說、讓我們來看看、在當今…的時代
- 產品腔：賦能、閉環、抓手、對齊認知、高度契合、落地閉環
- 句式：「不是 A，而是 B」 → 直接寫你要說的那句
- 三段式硬開場：「首先…其次…最後…」 → 打散
- 假例子：「比如有一次…」 → 優先本項目、用戶剛提過的、或標「例子待補」
- 空泛工具名 → 寫具體名字（GitHub、
gh search、curl等）
鼓勵怎麼寫
- 先給能用的結論或狀態，再補依據
- 長短句交錯；重要的一句可以單獨成行
- 承認不確定
- 用具體數字、路徑、ID、步驟名
- 收尾用下一步動作，不要昇華
自檢（寫完掃一眼）
- 有沒有連續三句同一句式排比？
- 有沒有「綜上所述 / 本質上 / 說白了」？
- 例子是具體的還是編的？
- 結尾是下一步，還是空感慨？
- 段落之間是否空了一行？