Tôi đã tìm thấy hơn 30 kho lưu trữ GitHub hữu ích và không còn bị mất dấu chúng nữa (Claude + Obsidian, Hướng dẫn đầy đủ)

@gippp69
TIẾNG ANH2 ngày trước · 20 thg 7, 2026
148K
149
13
30
235

TL;DR

Hướng dẫn này trình bày chi tiết quy trình làm việc được hỗ trợ bởi AI, sử dụng Claude và Obsidian để sắp xếp các kho lưu trữ GitHub đã sao chép, tự động theo dõi việc sử dụng, xác định các bản sao và gắn cờ các phụ thuộc không còn được duy trì.

Tôi star một repo, clone nó, làm cho nó chạy được một nửa, rồi chuyển sang vấn đề tiếp theo. Ba tháng sau, tôi lại tìm thấy cùng một thư mục đó và không thể nhớ nổi tại sao mình đã lấy nó, liệu tôi đã từng thực sự sử dụng nó chưa, hay tôi đã clone cùng một loại công cụ hai lần dưới một tên khác. Khi đã có hơn 30 repo, điều đó không còn là chuyện đùa nữa mà bắt đầu tiêu tốn thời gian thực sự.

Tại sao một README cho mỗi repo là chưa đủ?

Một README cho bạn biết tác giả đã xây dựng nó để làm gì. Nó không nói gì về lý do bạn lấy nó, liệu bạn có thực sự đang sử dụng nó hay không, hoặc liệu bạn đã có ba công cụ khác làm cùng một công việc hay chưa.

Đó là phần mà không ai ghi lại, bởi vì không ai ghi lại điều đó cho những repo không phải của họ. Bạn clone một thứ hữu ích, chạy nó một lần, và bối cảnh về lý do tại sao biến mất ngay khi bạn đóng terminal. Nhân lên điều đó với 30 repo nằm trong cùng một thư mục và bạn sẽ có một nghĩa địa mà bạn sợ phải dọn dẹp, bởi vì bạn không chắc cái nào là quan trọng và cái nào là gánh nặng vô ích.

Không điều nào trong số đó hiện ra trong bất kỳ README riêng lẻ nào. Nó chỉ hiện ra khi có thứ gì đó đọc xuyên suốt tất cả những gì bạn đã thu thập, theo một lịch trình, mà không cần bạn nhớ phải kiểm tra.

Bạn sẽ có được gì?

Một vault, hai thư mục:

text
1found-tools-vault/
2├── notes/ # một ghi chú markdown cho mỗi repo bạn đã lấy
3│ ├── some-scraper-tool.md
4│ ├── some-telegram-lib.md
5│ └── ...
6└── memory/
7 └── PORTFOLIO.md # bốn lần chạy xuyên repo sẽ ghi vào đây

Markdown thuần trên đĩa. Mở nó trong Obsidian, hoặc dùng cat từ terminal. Không có cơ sở dữ liệu, không có thứ gì bạn không thể tự đọc được.

Thiết lập nó?

Trên Mac hoặc Linux:

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

Trên Windows, PowerShell:

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

Trỏ Loop 1 và Loop 2, bên dưới, vào thư mục này và việc thiết lập đã hoàn tất. Mọi thứ từ đây trở đi là những gì bạn bảo Claude làm bên trong nó.

Bộ công cụ: vẫn ba phần giống nhau, chỉ khác là hướng đến mã nguồn của người khác?

Vault. Một thư mục Obsidian, một ghi chú cho mỗi công cụ bạn đã clone, cộng với một thư mục cho các lần chạy xuyên repo.

Nguồn. Mọi repo nằm trong thư mục clone của bạn, cho dù bạn sử dụng nó hàng ngày hay đã quên mất nó tồn tại.

Bộ não. Claude, được chia theo công việc. Mô hình rẻ đọc repo và README của nó. Sonnet thực hiện các phán đoán: cái này có phải là bản sao của một thứ khác bạn đã lấy hay không, và nó có thực sự đáng để chiếm dung lượng đĩa hay không.

Loop 1: một ghi chú cho mỗi công cụ, do Claude viết chứ không phải bạn?

Quan trọng, trước khi bạn chạy cái này trên bất cứ thứ gì thực tế:

  • Đừng bao giờ để vòng lặp này push code, cài đặt dependencies, hoặc chạy bất cứ thứ gì từ chính công cụ đó. Chỉ đọc, luôn luôn.
  • why_i_grabbed_it được điền từ ghi chú, commit hoặc cách sử dụng của riêng bạn trong các dự án khác của bạn, không phải đoán từ README của repo.
  • Nếu bạn không thể biết liệu mình có đang sử dụng một công cụ hay không, hãy viết ghi chú với trạng thái: unclear thay vì bỏ qua nó.
Gipp 🦅 - inline image
text
1KÍCH HOẠT: repo mới được clone vào thư mục, hoặc mỗi ngày một lần
2CÁC BƯỚC:
3 1. Đọc repo: README, package.json / requirements.txt, ngày
4 commit thượng nguồn cuối cùng, và kiểm tra xem nó có được tham chiếu
5 ở bất kỳ đâu trong các dự án khác của bạn không (import, config, script)
6 2. Viết hoặc cập nhật notes/<tên-repo>.md với:
7 ---
8 repo:
9 what_it_does:
10 why_i_grabbed_it:
11 last_upstream_commit:
12 referenced_in_my_projects: []
13 status: in-use | shelved | duplicate | unclear
14 ---
15 ## Nó thực sự làm gì
16 ## Tại sao tôi lấy nó
17 ## Tôi có thực sự đang sử dụng nó không
18KIỂM TRA: mọi trường đều được điền, "referenced_in_my_projects"
19 được kiểm tra dựa trên cách sử dụng thực tế, không phải giả định
20DỪNG: kiểm tra đạt, hoặc 2 lần thử lại, sau đó đánh dấu để xem xét thủ công

Chỉ riêng điều này thôi đã đáng để xây dựng ngay cả khi không có Loop 2. Lần đầu tiên bạn đọc 30 cái này liên tiếp, một nửa trong số chúng sẽ làm bạn ngạc nhiên, hoặc vì bạn quên rằng mình đang sử dụng công cụ đó, hoặc vì bạn chưa bao giờ thực sự sử dụng nó.

Một ghi chú công cụ được tạo ra, nằm cạnh thư mục clone thực tế mà nó mô tả. Đây là bối cảnh mà nếu không bạn sẽ không bao giờ ghi lại.

30 repo tìm thấy thực sự trông như thế nào sau khi Loop 1 chạy?

Một danh sách Claude tạo lại mỗi khi bạn clone một thứ gì đó mới, được lấy trực tiếp từ các ghi chú:

Gipp 🦅 - inline image

(các tên trên là placeholder, minh họa hình dạng của danh sách, không phải các công cụ thực tế)

Ba mươi dòng là chẳng là gì để đọc thủ công. Nhưng nó cũng đủ để bạn nhận ra bạn có ba thư viện retry-logic riêng biệt làm cùng một công việc, và một trong những repo bạn thực sự phụ thuộc vào đã không có commit thượng nguồn trong hơn một năm.

Chế độ xem đồ thị của vault khi tất cả 30 ghi chú tồn tại: mỗi công cụ là một nút, các bản sao và repo có mục đích chung được kéo thành các cụm có thể nhìn thấy.

Loop 2: các lần chạy chỉ hoạt động khi bạn đã thu thập hơn 30 công cụ?

README của một công cụ duy nhất không thể cho bạn biết điều này. Chỉ có thứ gì đó đọc xuyên suốt tất cả những gì bạn đã lấy mới có thể.

text
1KÍCH HOẠT: mỗi 12 giờ
2CÁC BƯỚC:
3 Lần chạy 1, thực sự tạm gác:
4 đánh dấu bất kỳ repo nào có trạng thái: in-use nhưng không được tham chiếu
5 trong bất kỳ dự án nào của bạn trong 30+ ngày, kiểm tra chéo với các repo
6 của riêng bạn để biết cách sử dụng thực tế, không phải giả định
7 Lần chạy 2, công cụ trùng lặp:
8 so sánh "nó thực sự làm gì" trên tất cả các ghi chú, nhóm bất cứ thứ gì
9 giải quyết cùng một vấn đề, được xác nhận bằng cách khớp tên hàm
10 hoặc khớp mục đích, không chỉ là các mô tả nghe có vẻ giống nhau
11 Lần chạy 3, rủi ro thượng nguồn:
12 đánh dấu bất kỳ công cụ nào bạn phụ thuộc vào mà commit thượng nguồn
13 cuối cùng đã 120+ ngày trước, để bạn biết dependencies nào có thể
14 trở nên lỗi thời mà không có cảnh báo
15 Lần chạy 4, đánh giá trung thực:
16 một dòng cho mỗi công cụ về việc nó có xứng đáng với dung lượng đĩa và
17 gánh nặng tinh thần khi nhớ rằng nó tồn tại hay không, không làm dịu đi
18KIỂM TRA: mỗi lần chạy ghi vào memory/PORTFOLIO.md, các nhóm của Lần chạy 2
19 được hỗ trợ bởi một hàm hoặc mục đích dùng chung thực tế
20DỪNG: tất cả bốn lần chạy hoàn thành, hoặc một lần chạy thất bại và được ghi lại,
21 không bao giờ bị bỏ qua một cách im lặng

Lần chạy 3 là lần thực sự thay đổi cách bạn làm việc. Bạn không nhận ra mình đang phụ thuộc vào ba công cụ mà người bảo trì đã im lặng từ một năm trước cho đến khi nó nằm trong một danh sách trước mặt bạn.

Một bảng rủi ro được tạo ra từ Lần chạy 3: các công cụ bạn thực sự đang sử dụng, được sắp xếp theo thời gian kể từ lần cuối cùng dự án thượng nguồn của chúng có động thái.

Gipp 🦅 - inline image

Hãy thử phiên bản thủ công trước?

Cùng một quy tắc như mọi khi. Đừng lên lịch bất cứ thứ gì bạn chưa chứng minh được bằng tay.

text
1Bạn sẽ làm việc trong một vòng lặp cho đến khi nhiệm vụ đáp ứng được tiêu chuẩn.
2
3NHIỆM VỤ:
4Đọc mọi thư mục repo trong [đường dẫn]. Với mỗi repo, hãy ghi lại nó làm gì,
5tại sao ban đầu bạn lấy nó, liệu bạn có còn thực sự đang sử dụng
6nó hay không, và đã bao lâu kể từ lần commit cuối cùng của dự án thượng nguồn. Sau đó
7so sánh trên tất cả các repo: tìm các bản sao và bất cứ thứ gì bạn phụ thuộc
8vào mà đã im lặng ở thượng nguồn.
9
10TIÊU CHÍ THÀNH CÔNG (nghiêm ngặt, không có điểm đạt mềm):
11- mọi "trùng lặp" đều được hỗ trợ bởi một hàm hoặc mục đích khớp thực tế,
12 không chỉ là các mô tả nghe có vẻ giống nhau
13- mọi repo "tạm gác" đều bao gồm số ngày kể từ lần cuối bạn tham chiếu nó
14 ở bất kỳ đâu trong các dự án của riêng bạn
15- rủi ro thượng nguồn dựa trên ngày commit thực tế, không phải giả định
16
17GIAO THỨC VÒNG LẶP, lặp lại mỗi lượt:
181. LẬP KẾ HOẠCH - nêu bước tiếp theo duy nhất
192. THỰC HIỆN - tạo ra hoặc cải thiện đầu ra
203. KIỂM TRA - chấm điểm 1-10 cho mỗi tiêu chí, hãy hoàn toàn trung thực
214. QUYẾT ĐỊNH - nếu mọi tiêu chí đều từ 8 trở lên, in "FINAL" và dừng lại
22
23QUY TẮC:
24- Đừng bao giờ coi là xong cho đến khi mọi tiêu chí đều từ 8 trở lên
25- Đừng hỏi tôi câu hỏi, hãy đưa ra giả định hợp lý và tiếp tục
26
27Bắt đầu. Chạy vòng lặp cho đến khi FINAL.

Nếu danh sách trùng lặp hoặc danh sách rủi ro thượng nguồn làm bạn ngạc nhiên, thì nó xứng đáng để lên lịch. Nếu nó chỉ xác nhận những gì bạn đã biết, thì đừng tự động hóa nó vội.

Thứ tự thực sự hiệu quả?

Hãy chạy Loop 1 cho đến khi mọi repo đã clone đều có một ghi chú thực sự, không phải là placeholder.

Hãy để nó yên trong một hoặc hai tuần. Mọi công cụ mới bạn lấy sẽ tự động có một ghi chú kể từ đó.

Chỉ sau đó mới bật Loop 2. Các lần chạy trùng lặp và rủi ro thượng nguồn cần đủ ghi chú để thực sự va chạm với nhau.

Lên lịch cho nó cuối cùng, sau khi bạn đã xem nó chạy sạch bằng tay ít nhất hai lần.

Chi phí là bao nhiêu?

Loop 1 chạy mỗi khi có bản clone mới, vì vậy nó mở rộng quy mô theo lượng bạn thực sự lấy, không phải theo một lịch trình cố định. Hầu hết các tuần, đó chỉ là một vài cuộc gọi mô hình rẻ.

Loop 2 chạy hai lần một ngày trên hơn 30 ghi chú. Chuyển Lần chạy 1 và Lần chạy 3 sang mô hình rẻ, chúng là các tra cứu, không phải phán đoán. Giữ Lần chạy 2 và Lần chạy 4 trên Sonnet, vì phát hiện một bản sao thực sự và đưa ra đánh giá trung thực đều cần một mô hình có thể thực sự suy luận về những gì nó đang so sánh. Chia theo cách đó, hai lần chạy mỗi ngày trên một bộ sưu tập 30 repo có chi phí thấp hơn thời gian bạn dành để tự kiểm tra thủ công một lần.

Điều duy nhất cần nhớ?

Một README cho bạn biết một công cụ làm gì. Cái này cho bạn biết bạn thực sự đang sử dụng công cụ nào trong số 30 công cụ bạn đã tìm thấy, cái nào đang lặng lẽ trùng lặp với nhau, và cái nào bạn đang phụ thuộc vào mà không còn ai bảo trì nữa.

Giá trị không bao giờ nằm trong bất kỳ ghi chú công cụ đơn lẻ nào. Nó nằm ở thực tế là không có thứ gì bạn đã thu thập có thể âm thầm mục nát, âm thầm trùng lặp, hoặc âm thầm không được bảo trì mà không có thứ gì đó ghi lại điều đó ở nơi bạn thực sự sẽ thấy nó.

Xây dựng Loop 1 trước. Hãy để nó chạy trong hai hoặc ba tuần trước khi bạn động đến Loop 2. Các lần chạy trùng lặp và rủi ro thượng nguồn là vô dụng với năm repo. Chúng bắt đầu tự trả tiền ở đâu đó sau hai mươi.

Nếu bạn muốn nhiều bài phân tích như thế này, tôi đăng một bài sau mỗi vài ngày trên Telegram và X. Cả hai đều miễn phí.

X - https://x.com/gippp69

Telegram - https://t.me/GipArcAI

Viết lại trong YouMind

Turn one viral article into a full content workflow

Collect the source, decode the pattern, create assets, draft the story, and distribute from one AI workspace.

Explore YouMind
Dành cho nhà sáng tạo

Biến Markdown của bạn thành bài viết 𝕏 gọn gàng

Khi bạn đăng bài viết dài của riêng mình, việc định dạng hình ảnh, bảng và khối mã cho 𝕏 rất mệt mỏi. YouMind biến cả bản nháp Markdown thành một bài viết 𝕏 gọn gàng, sẵn sàng để đăng.

Thử Markdown sang 𝕏

Thêm pattern để giải mã

Bài viết viral gần đây

Khám phá thêm bài viết viral