我整理了 30 多個實用的 GitHub 儲存庫,從此不再遺失(Claude + Obsidian 完整指南)

@gippp69
英語2 天前 · 2026年7月20日
148K
149
13
30
235

TL;DR

本指南詳細介紹了一套由 AI 驅動的工作流程,利用 Claude 與 Obsidian 來整理已複製的 GitHub 儲存庫,包含自動追蹤使用狀況、識別重複項目以及標記未維護的相依套件。

我收藏一個 repo,把它 clone 下來,弄到半能用之後就跑去處理下一個問題。三個月後我又找到同一個資料夾,卻記不起當初為什麼要抓它、到底有沒有用過,或者是不是用不同名字把同類工具 clone 了兩次。當 repo 數量超過三十個,這就不再是玩笑,而是真的在浪費時間。

為什麼每個 repo 的 README 不夠用?

README 告訴你作者當初為什麼寫它,但完全沒提你為什麼要抓它、你現在到底有沒有在用,或者你手上是不是已經有三個做同樣事情的工具了。

這才是沒有人會寫下來的部分,因為沒有人會為不屬於自己的 repo 寫這些筆記。你 clone 了一個有用的東西,成功跑了一次,然後關掉終端機的那一刻,所有關於「為什麼」的脈絡就消失了。當同一個資料夾裡躺著三十個 repo,你就會得到一個不敢清理的墳場——因為你不確定哪些是支撐結構、哪些是多餘的累贅。

這些東西沒有任何一個 README 能告訴你。只有當某個東西能夠跨過你收集的所有東西去讀取、而且定時執行、不需要你記住去檢查的時候,這些資訊才會浮現出來。

你會得到什麼?

一個 vault,兩個資料夾:

text
1found-tools-vault/
2├── notes/ # 每個你抓過的 repo 一篇 markdown 筆記
3│ ├── some-scraper-tool.md
4│ ├── some-telegram-lib.md
5│ └── ...
6└── memory/
7 └── PORTFOLIO.md # 四個跨 repo 掃描的結果寫在這裡

就是純文字 markdown 放在硬碟上。用 Obsidian 打開,或者直接在終端機裡用 cat 看。沒有資料庫,沒有你不能自己讀的東西。

怎麼設定?

在 Mac 或 Linux 上:

bash
1mkdir -p ~/found-tools-vault/notes ~/found-tools-vault/memory

在 Windows 上,用 PowerShell:

text
1New-Item -ItemType Directory -Force -Path "$HOME\found-tools-vault\notes","$HOME\found-tools-vault\memory"

把下面的 Loop 1 和 Loop 2 指向這個資料夾,設定就完成了。接下來的內容,就是你讓 Claude 在這個資料夾裡做的事情。

核心配置:同樣的三個角色,只是把目標指向別人的程式碼?

Vault。 一個 Obsidian 資料夾,每個你 clone 下來的工具一篇筆記,再加上一個用來放跨 repo 掃描結果的資料夾。

來源。 你 clone 資料夾裡的每一個 repo,不管你是每天在用還是已經忘了它的存在。

大腦。 Claude,按工作分開。便宜的模型負責讀 repo 和它的 README。Sonnet 負責做判斷:這個工具是不是你已經抓過的某個東西的重複品?它到底值不值得佔用硬碟空間?

Loop 1:每個工具一篇筆記,由 Claude 寫,而不是由你寫?

重要提醒:在對真實資料執行之前,請注意:

  • 絕對不要讓這個 loop 去 push 程式碼、安裝依賴、或執行工具本身的任何東西。永遠保持唯讀。
  • why_i_grabbed_it 應該根據你自己的筆記、commit 記錄、或在你其他專案中的使用情況來填寫,而不是從 repo 自己的 README 猜測。
  • 如果你不確定自己到底有沒有在用某個工具,就寫上 status: unclear,而不是直接跳過。
Gipp 🦅 - inline image
text
1TRIGGER: 新的 repo 被 clone 進資料夾時,或每天一次
2STEPS:
3 1. 讀取 repo:README、package.json / requirements.txt、最後一次上游 commit 日期,並檢查它是否在你的其他專案中被引用(import、config、script)
4 2. 寫入或更新 notes/<repo-name>.md,內容包含:
5 ---
6 repo:
7 what_it_does:
8 why_i_grabbed_it:
9 last_upstream_commit:
10 referenced_in_my_projects: []
11 status: in-use | shelved | duplicate | unclear
12 ---
13 ## 它實際做什麼
14 ## 我為什麼抓它
15 ## 我到底有沒有在用
16VERIFY: 每個欄位都填寫完成,"referenced_in_my_projects" 必須根據實際使用情況檢查,而不是假設
17STOP: 驗證通過,或重試 2 次後仍失敗,則標記為需要人工審查

光是這個 loop,就算沒有 Loop 2 也值得建。當你第一次一口氣讀完三十篇這樣的筆記,至少有一半會讓你驚訝——要嘛是你忘了自己正在用這個工具,要嘛是你根本從來沒用過。

一篇產生的工具筆記,就放在它所描述的實際 clone 資料夾旁邊。這就是你原本永遠不會寫下來的脈絡。

Loop 1 執行完之後,30 個被找到的 repo 實際上看起來像什麼?

每次你 clone 新東西時,Claude 就會重新產生這份清單,直接從筆記中拉取:

Gipp 🦅 - inline image

(上面的名稱都是佔位符,只是為了展示清單的樣貌,不是實際的工具)

三十行文字手動讀起來一點也不費力。但也足夠讓你注意到你居然有三個做同樣工作的 retry-logic 函式庫,而且其中一個你實際依賴的 repo 已經超過一年沒有上游 commit 了。

當全部 30 篇筆記都存在時,vault 的圖形視圖:每個工具都是一個節點,重複的和共用目的的 repo 被拉進可見的叢集中。

Loop 2:只有當你收集了 30 個以上的工具時才有效的掃描?

單一工具的 README 無法告訴你這些。只有能跨過你抓取的所有東西去讀取的東西才能做到。

text
1TRIGGER: 每 12 小時一次
2STEPS:
3 Pass 1,實際擱置的:
4 標記任何狀態為 in-use 但在你的專案中超過 30 天未被引用的 repo,
5 並與你自己的 repo 交叉比對實際使用情況,不要只靠假設
6 Pass 2,重複工具:
7 比較所有筆記中的 "what it actually does",
8 將任何解決相同問題的工具分組,
9 必須以匹配的函式名稱或匹配的目的為依據,不只是聽起來相似的描述
10 Pass 3,上游風險:
11 標記任何你依賴的工具,其最後上游 commit 距今超過 120 天,
12 這樣你就能知道哪些依賴可能會無預警地過時
13 Pass 4,誠實評估:
14 每個工具一行,判斷它是否值得佔用硬碟空間和記住它存在的心理負擔,不修飾
15VERIFY: 每個 pass 都要寫入 memory/PORTFOLIO.md,Pass 2 的分組必須有實際的共享函式或目的匹配作為依據
16STOP: 所有四個 pass 都完成,或者某個 pass 失敗並被記錄下來,絕不能默默地跳過

Pass 3 是真正會改變你工作方式的那個。你直到它列成清單擺在你面前,才會意識到你依賴的三個工具,它們的維護者已經一年沒動靜了。

Pass 3 產生的風險表:你正在使用的工具,依照上游最後一次更新的時間排序。

Gipp 🦅 - inline image

先試試手動版本?

跟往常一樣的規則:不要排程任何你還沒親手驗證過的東西。

text
1你將在一個迴圈中工作,直到任務達到標準。
2
3TASK:
4讀取 [path] 中的每一個 repo 資料夾。針對每一個,記錄它做什麼、
5你當初為什麼抓它、你現在是否還在實際使用它、以及上游最後一次
6commit 距今多久。然後跨所有 repo 進行比較:找出重複的工具,
7以及任何你依賴但上游已經沒動靜的工具。
8
9SUCCESS CRITERIA(嚴格,沒有軟過關):
10- 每一個 "duplicate" 都必須有實際匹配的函式或目的作為依據,
11 不能只是聽起來相似的描述
12- 每一個 "shelved" 的 repo 都必須包含你最後一次在自己的專案中
13 引用它距今的天數
14- 上游風險必須基於實際的 commit 日期,而不是假設
15
16LOOP PROTOCOL,每回合重複:
171. PLAN - 說明下一步要做什麼
182. DO - 產生或改進輸出
193. VERIFY - 對每個標準給出 1-10 分的評分,要毫不留情地誠實
204. DECIDE - 如果每個標準都達到 8 分以上,輸出 "FINAL" 並停止
21
22RULES:
23- 在所有標準都達到 8 分以上之前,絕對不能說完成
24- 不要問我問題,做出合理的假設然後繼續
25
26開始。執行迴圈直到 FINAL。

如果重複清單或上游風險清單讓你感到驚訝,那就值得排程。如果它只是確認了你已經知道的事情,那就先不要自動化。

實際上可行的順序?

先讓 Loop 1 持續運行,直到每個 clone 下來的 repo 都有真正的筆記,而不是佔位符。

讓它跑一兩個星期。從那時起,你每抓一個新工具,它就會自動產生筆記。

然後才開啟 Loop 2。重複工具和上游風險的掃描需要足夠多的筆記才能產生有效的碰撞。

最後才排程,而且必須先親手看著它乾淨地跑完至少兩次。

需要花多少錢?

Loop 1 每次新 clone 時執行,所以它跟你實際抓取的工具數量成正比,而不是固定排程。大多數週只會產生幾次便宜的模型呼叫。

Loop 2 每天執行兩次,橫跨 30 篇以上的筆記。把 Pass 1 和 Pass 3 移到便宜的模型上,它們只是查詢,不是判斷。把 Pass 2 和 Pass 4 留在 Sonnet 上,因為辨識真正的重複工具和誠實評估都需要一個能夠真正推理它正在比較的內容的模型。這樣分開之後,每天跑兩次,橫跨 30 個 repo 的集合,成本比你親手做同樣的審查一次所需的時間還少。

唯一需要記住的事?

README 告訴你一個工具做什麼。而這個系統告訴你,在你找到的 30 個工具中,哪些是你真正在用的、哪些在悄悄地重複彼此、以及哪些是你依賴但已經沒有人維護的。

價值從來不在於任何單一工具筆記本身。而是在於你收集的所有東西中,沒有任何東西可以悄悄地腐爛、悄悄地重複、或悄悄地無人維護,而沒有某個東西把它寫下來,放在你真正會看到的地方。

先建 Loop 1。讓它跑兩三個星期,然後再碰 Loop 2。當你只有五個 repo 時,重複工具和上游風險掃描是沒有用的。它們開始回本大約是在超過二十個的時候。

如果你想要更多像這樣的拆解分析,我每隔一兩天會在 Telegram 和 X 上發布。兩者都是免費的。

X - https://x.com/gippp69

Telegram - https://t.me/GipArcAI

二次創作

使用 YouMind 創作爆款文章

收集素材、拆解爆點、生成視覺資產、撰寫內容,並在一個 AI 工作空間裡完成分發。

了解 YouMind
寫給創作者

把你的 Markdown 變成乾淨的 𝕏 文章

圖片上傳、表格、程式碼區塊,往 𝕏 上手動重排太痛苦。YouMind 把整篇 Markdown 一鍵轉成乾淨、可直接發佈的 𝕏 文章草稿。

試試 Markdown 轉 𝕏

更多可拆解樣本

近期爆款文章

探索更多爆款文章