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:
1found-tools-vault/2├── notes/ # một ghi chú markdown cho mỗi repo bạn đã lấy3│ ├── some-scraper-tool.md4│ ├── some-telegram-lib.md5│ └── ...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:
1mkdir -p ~/found-tools-vault/notes ~/found-tools-vault/memory
Trên Windows, PowerShell:
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:
unclearthay vì bỏ qua nó.

1KÍCH HOẠT: repo mới được clone vào thư mục, hoặc mỗi ngày một lần2CÁC BƯỚC:3 1. Đọc repo: README, package.json / requirements.txt, ngày4 commit thượng nguồn cuối cùng, và kiểm tra xem nó có được tham chiếu5 ở 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 | unclear14 ---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ông18KIỂ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ả định20DỪ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ú:
- github.com/author/scrape-lite - đang sử dụng, commit thượng nguồn cuối 2 ngày trước, được tham chiếu trong: dự án feed-reader
- github.com/author/tg-bot-kit - đang sử dụng, commit thượng nguồn cuối 5 ngày trước, được tham chiếu trong: hai bot của tôi
- github.com/author/quick-scheduler - tạm gác, commit thượng nguồn cuối 41 ngày trước, được tham chiếu trong: không
- github.com/author/api-wrapper-x - đang sử dụng, commit thượng nguồn cuối 1 ngày trước, được tham chiếu trong: một dự án
- github.com/author/rss-to-json - trùng lặp, commit thượng nguồn cuối 3 ngày trước, được tham chiếu trong: không (cùng công việc với scrape-lite)
- github.com/author/cheap-queue - đang sử dụng, commit thượng nguồn cuối 6 giờ trước, được tham chiếu trong: hai dự án
- github.com/author/webhook-relay-lib - tạm gác, commit thượng nguồn cuối 96 ngày trước, được tham chiếu trong: không
- github.com/author/simple-cache - đang sử dụng, commit thượng nguồn cuối 2 ngày trước, được tham chiếu trong: ba dự án
- github.com/author/old-scraper - thượng nguồn bị bỏ rơi, commit thượng nguồn cuối 340 ngày trước, được tham chiếu trong: không
- github.com/author/notify-me - không rõ, commit thượng nguồn cuối 12 ngày trước, được tham chiếu trong: không chắc
- github.com/author/token-utils - đang sử dụng, commit thượng nguồn cuối 1 ngày trước, được tham chiếu trong: một dự án
- github.com/author/quick-parser - trùng lặp, commit thượng nguồn cuối 8 ngày trước, được tham chiếu trong: không (cùng công việc với rss-to-json)
- github.com/author/tiny-orm - tạm gác, commit thượng nguồn cuối 55 ngày trước, được tham chiếu trong: không
- github.com/author/rate-limiter - đang sử dụng, commit thượng nguồn cuối 3 ngày trước, được tham chiếu trong: hai dự án
- github.com/author/config-loader - đang sử dụng, commit thượng nguồn cuối 4 ngày trước, được tham chiếu trong: hầu hết các dự án của tôi
- github.com/author/legacy-fetch - thượng nguồn bị bỏ rơi, commit thượng nguồn cuối 400+ ngày trước, được tham chiếu trong: không
- github.com/author/env-check - đang sử dụng, commit thượng nguồn cuối 9 ngày trước, được tham chiếu trong: một dự án
- github.com/author/pretty-logs - tạm gác, commit thượng nguồn cuối 70 ngày trước, được tham chiếu trong: không
- github.com/author/proxy-list - không rõ, commit thượng nguồn cuối 20 ngày trước, được tham chiếu trong: không chắc
- github.com/author/backoff-lib - đang sử dụng, commit thượng nguồn cuối 6 ngày trước, được tham chiếu trong: hai dự án
- github.com/author/dead-simple-db - tạm gác, commit thượng nguồn cuối 88 ngày trước, được tham chiếu trong: không
- github.com/author/quick-hash - đang sử dụng, commit thượng nguồn cuối 1 ngày trước, được tham chiếu trong: một dự án
- github.com/author/retry-wrapper - trùng lặp, commit thượng nguồn cuối 14 ngày trước, được tham chiếu trong: không (cùng công việc với backoff-lib)
- github.com/author/format-time - đang sử dụng, commit thượng nguồn cuối 2 ngày trước, được tham chiếu trong: hầu hết các dự án của tôi
- github.com/author/quick-mailer - tạm gác, commit thượng nguồn cuối 50 ngày trước, được tham chiếu trong: không
- github.com/author/health-check-lib - đang sử dụng, commit thượng nguồn cuối 5 ngày trước, được tham chiếu trong: hai dự án
- github.com/author/dotenv-plus - đang sử dụng, commit thượng nguồn cuối 3 ngày trước, được tham chiếu trong: hầu hết các dự án của tôi
- github.com/author/simple-lock - không rõ, commit thượng nguồn cuối 30 ngày trước, được tham chiếu trong: không chắc
- github.com/author/old-notify - thượng nguồn bị bỏ rơi, commit thượng nguồn cuối 500+ ngày trước, được tham chiếu trong: không
- github.com/author/tiny-scheduler - trùng lặp, commit thượng nguồn cuối 18 ngày trước, được tham chiếu trong: không (cùng công việc với quick-scheduler)

(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ể.
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ếu5 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 repo6 của riêng bạn để biết cách sử dụng thực tế, không phải giả định7 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àm10 hoặc khớp mục đích, không chỉ là các mô tả nghe có vẻ giống nhau11 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ồn13 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áo15 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 đi18KIỂM TRA: mỗi lần chạy ghi vào memory/PORTFOLIO.md, các nhóm của Lần chạy 219 đượ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.

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.
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.23NHIỆ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ụng6nó 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ộc8vào mà đã im lặng ở thượng nguồn.910TIÊ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 nhau13- 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ạn15- rủi ro thượng nguồn dựa trên ngày commit thực tế, không phải giả định1617GIAO 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ất192. THỰC HIỆN - tạo ra hoặc cải thiện đầu ra203. KIỂM TRA - chấm điểm 1-10 cho mỗi tiêu chí, hãy hoàn toàn trung thực214. QUYẾT ĐỊNH - nếu mọi tiêu chí đều từ 8 trở lên, in "FINAL" và dừng lại2223QUY TẮC:24- Đừng bao giờ coi là xong cho đến khi mọi tiêu chí đều từ 8 trở lên25- Đừng hỏi tôi câu hỏi, hãy đưa ra giả định hợp lý và tiếp tục2627Bắ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í.
Telegram - https://t.me/GipArcAI





