ผมเจอ GitHub repo เจ๋งๆ กว่า 30 รายการ และเลิกทำหายสักที (Claude + Obsidian, คู่มือฉบับเต็ม)

ฉัน star repo, clone มัน, ทำให้มันทำงานได้ครึ่งๆ กลางๆ แล้วก็ไปแก้ปัญหาต่อไป สามเดือนต่อมาเจอโฟลเดอร์เดิมอีกครั้งแต่จำไม่ได้ว่าทำไมถึงเอามา เคยใช้จริงๆ หรือเปล่า หรือว่าผม clone เครื่องมือแบบเดียวกันซ้ำสองตัวภายใต้ชื่อคนละชื่อ เมื่อมี repo เกิน 30 ตัว สิ่งนี้ไม่ใช่เรื่องตลกอีกต่อไป แต่เริ่มเสียเวลาไปจริงๆ

ทำไม README ต่อ repo ถึงไม่พอ?

README บอกคุณว่าผู้เขียนสร้างมันมาเพื่ออะไร แต่มันไม่ได้บอกอะไรเลยว่าทำไมคุณถึงเอามา คุณใช้มันจริงไหม หรือว่าคุณมีเครื่องมืออื่นอีกสามตัวที่ทำงานแบบเดียวกันอยู่แล้ว

นั่นคือส่วนที่ไม่มีใครเขียนลงไป เพราะว่าไม่มีใครเขียนมันสำหรับ repo ที่ไม่ใช่ของตัวเอง คุณ clone อะไรที่มีประโยชน์มา ทำให้มันทำงานได้ครั้งหนึ่ง แล้วบริบทว่าทำไมถึงเอามันมาก็หายไปทันทีที่คุณปิด terminal ลองคูณด้วย 30 repos ที่อยู่ในโฟลเดอร์เดียวกัน คุณจะได้สุสานที่คุณกลัวที่จะทำความสะอาด เพราะคุณไม่แน่ใจว่าอันไหนสำคัญและอันไหนไร้ค่า

ไม่มีอะไรในนั้นที่ปรากฏใน README ตัวเดียว มันจะปรากฏก็ต่อเมื่อมีอะไรบางอย่างที่อ่าน ข้าม ทุกอย่างที่คุณรวบรวมไว้ ตามกำหนดเวลา โดยที่คุณไม่ต้องจำว่าจะต้องตรวจสอบ

คุณจะได้อะไร?

คลังเดียว สองโฟลเดอร์:

1found-tools-vault/
2├── notes/                  # โน้ต Markdown หนึ่งอันต่อ repo ที่คุณดึงมา
3│   ├── some-scraper-tool.md
4│   ├── some-telegram-lib.md
5│   └── ...
6└── memory/
7    └── PORTFOLIO.md         # การรันข้าม repo สี่ครั้งจะเขียนที่นี่

Markdown ธรรมดาบนดิสก์ เปิดใน Obsidian หรือ cat จาก terminal ไม่มีฐานข้อมูล ไม่มีอะไรที่คุณอ่านเองไม่ได้

ตั้งค่าอย่างไร?

บน Mac หรือ Linux:

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

บน Windows, PowerShell:

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

ชี้ Loop 1 และ Loop 2 ด้านล่างไปที่โฟลเดอร์นี้ แล้วก็ตั้งค่าเสร็จ ทุกอย่างหลังจากนี้คือสิ่งที่คุณบอก Claude ให้ทำภายในนั้น

สแต็ค: สามชิ้นส่วนเดิม แต่ชี้ไปที่โค้ดของคนอื่น?

คลัง. โฟลเดอร์ Obsidian หนึ่งอัน, โน้ตหนึ่งอันต่อเครื่องมือหนึ่งตัวที่คุณ clone, บวกกับโฟลเดอร์สำหรับการรันข้าม repo

แหล่งที่มา. ทุก repo ที่อยู่ในโฟลเดอร์ clone ของคุณ ไม่ว่าจะใช้ทุกวันหรือลืมไปแล้วว่ามันมีอยู่

สมอง. Claude, แบ่งตามงาน โมเดลราคาถูกอ่าน repo และ README ของมัน Sonnet ทำหน้าที่ตัดสิน: นี่ซ้ำกับอันอื่นที่คุณเอามาแล้วหรือเปล่า และมันคุ้มค่ากับพื้นที่ดิสก์ไหม

Loop 1: หนึ่งโน้ตต่อเครื่องมือ, เขียนโดย Claude, ไม่ใช่โดยคุณ?

สำคัญ, ก่อนที่คุณจะรันสิ่งนี้กับของจริง:

• อย่าให้ loop นี้ push โค้ด, ติดตั้ง dependencies, หรือรันอะไรก็ตามจากตัวเครื่องมือเอง อ่านอย่างเดียวเสมอ
• why_i_grabbed_it จะถูกเติมจากโน้ตของคุณเอง, commits, หรือการใช้งานในโปรเจกต์อื่นๆ ของคุณ, ไม่ใช่เดาจาก README ของ repo เอง
• ถ้าคุณบอกไม่ได้ว่าคุณใช้เครื่องมือหรือไม่ ให้เขียนโน้ตด้วยสถานะ: unclear แทนที่จะข้ามไป

1TRIGGER:   เจอ repo ใหม่ที่ clone ลงในโฟลเดอร์, หรือวันละครั้ง
2STEPS:
3  1. อ่าน repo: README, package.json / requirements.txt, วันที่ commit
4     upstream ล่าสุด, และตรวจสอบว่ามีการอ้างถึงในโปรเจกต์อื่นๆ ของคุณหรือไม่
5     (imports, configs, scripts)
6  2. เขียนหรืออัปเดต notes/<repo-name>.md ด้วย:
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       ## มันทำอะไรจริงๆ
16       ## ทำไมถึงเอามันมา
17       ## ฉันใช้มันจริงหรือเปล่า
18VERIFY:    ทุกช่องถูกกรอก, "referenced_in_my_projects" ตรวจสอบกับ
19           การใช้งานจริง, ไม่ใช่สมมติฐาน
20STOP:      ผ่านการตรวจสอบ, หรือลองอีก 2 ครั้ง, แล้วตั้งธงให้ตรวจสอบด้วยตนเอง

แค่นี้ก็คุ้มที่จะสร้างแล้วแม้ไม่มี Loop 2 ครั้งแรกที่คุณอ่าน 30 ตัวนี้ติดๆ กัน ครึ่งหนึ่งจะทำให้คุณแปลกใจ ไม่ว่าจะเป็นเพราะคุณลืมไปว่ากำลังใช้เครื่องมือนั้น หรือเพราะคุณไม่เคยใช้มันเลย

โน้ตเครื่องมือที่สร้างขึ้นหนึ่งอัน, ถัดจากโฟลเดอร์ clone จริงที่มันอธิบาย นี่คือบริบทที่คุณจะไม่มีวันเขียนลงไป

30 found repos ที่มีลักษณะอย่างไรเมื่อ Loop 1 ทำงานแล้ว?

รายการที่ Claude สร้างใหม่ทุกครั้งที่คุณ clone อะไรใหม่, ดึงมาจากโน้ตโดยตรง:

• github.com/author/scrape-lite - กำลังใช้, commit upstream ล่าสุด 2 วันที่แล้ว, อ้างถึงใน: โปรเจกต์ feed-reader
• github.com/author/tg-bot-kit - กำลังใช้, commit upstream ล่าสุด 5 วันที่แล้ว, อ้างถึงใน: bot สองตัวของฉัน
• github.com/author/quick-scheduler - เก็บไว้, commit upstream ล่าสุด 41 วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/api-wrapper-x - กำลังใช้, commit upstream ล่าสุด 1 วันที่แล้ว, อ้างถึงใน: หนึ่งโปรเจกต์
• github.com/author/rss-to-json - ซ้ำ, commit upstream ล่าสุด 3 วันที่แล้ว, อ้างถึงใน: ไม่มี (งานเดียวกับ scrape-lite)
• github.com/author/cheap-queue - กำลังใช้, commit upstream ล่าสุด 6 ชั่วโมงที่แล้ว, อ้างถึงใน: สองโปรเจกต์
• github.com/author/webhook-relay-lib - เก็บไว้, commit upstream ล่าสุด 96 วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/simple-cache - กำลังใช้, commit upstream ล่าสุด 2 วันที่แล้ว, อ้างถึงใน: สามโปรเจกต์
• github.com/author/old-scraper - upstream ถูกทิ้ง, commit upstream ล่าสุด 340 วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/notify-me - ไม่ชัดเจน, commit upstream ล่าสุด 12 วันที่แล้ว, อ้างถึงใน: ไม่แน่ใจ
• github.com/author/token-utils - กำลังใช้, commit upstream ล่าสุด 1 วันที่แล้ว, อ้างถึงใน: หนึ่งโปรเจกต์
• github.com/author/quick-parser - ซ้ำ, commit upstream ล่าสุด 8 วันที่แล้ว, อ้างถึงใน: ไม่มี (งานเดียวกับ rss-to-json)
• github.com/author/tiny-orm - เก็บไว้, commit upstream ล่าสุด 55 วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/rate-limiter - กำลังใช้, commit upstream ล่าสุด 3 วันที่แล้ว, อ้างถึงใน: สองโปรเจกต์
• github.com/author/config-loader - กำลังใช้, commit upstream ล่าสุด 4 วันที่แล้ว, อ้างถึงใน: โปรเจกต์ส่วนใหญ่ของฉัน
• github.com/author/legacy-fetch - upstream ถูกทิ้ง, commit upstream ล่าสุด 400+ วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/env-check - กำลังใช้, commit upstream ล่าสุด 9 วันที่แล้ว, อ้างถึงใน: หนึ่งโปรเจกต์
• github.com/author/pretty-logs - เก็บไว้, commit upstream ล่าสุด 70 วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/proxy-list - ไม่ชัดเจน, commit upstream ล่าสุด 20 วันที่แล้ว, อ้างถึงใน: ไม่แน่ใจ
• github.com/author/backoff-lib - กำลังใช้, commit upstream ล่าสุด 6 วันที่แล้ว, อ้างถึงใน: สองโปรเจกต์
• github.com/author/dead-simple-db - เก็บไว้, commit upstream ล่าสุด 88 วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/quick-hash - กำลังใช้, commit upstream ล่าสุด 1 วันที่แล้ว, อ้างถึงใน: หนึ่งโปรเจกต์
• github.com/author/retry-wrapper - ซ้ำ, commit upstream ล่าสุด 14 วันที่แล้ว, อ้างถึงใน: ไม่มี (งานเดียวกับ backoff-lib)
• github.com/author/format-time - กำลังใช้, commit upstream ล่าสุด 2 วันที่แล้ว, อ้างถึงใน: โปรเจกต์ส่วนใหญ่ของฉัน
• github.com/author/quick-mailer - เก็บไว้, commit upstream ล่าสุด 50 วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/health-check-lib - กำลังใช้, commit upstream ล่าสุด 5 วันที่แล้ว, อ้างถึงใน: สองโปรเจกต์
• github.com/author/dotenv-plus - กำลังใช้, commit upstream ล่าสุด 3 วันที่แล้ว, อ้างถึงใน: โปรเจกต์ส่วนใหญ่ของฉัน
• github.com/author/simple-lock - ไม่ชัดเจน, commit upstream ล่าสุด 30 วันที่แล้ว, อ้างถึงใน: ไม่แน่ใจ
• github.com/author/old-notify - upstream ถูกทิ้ง, commit upstream ล่าสุด 500+ วันที่แล้ว, อ้างถึงใน: ไม่มี
• github.com/author/tiny-scheduler - ซ้ำ, commit upstream ล่าสุด 18 วันที่แล้ว, อ้างถึงใน: ไม่มี (งานเดียวกับ quick-scheduler)

(ชื่อด้านบนเป็นตัวยึด, แสดงลักษณะของรายการ, ไม่ใช่เครื่องมือจริง)

สามสิบบรรทัดไม่ใช่เรื่องยากที่จะอ่านด้วยตัวเอง แต่มันก็เพียงพอที่จะสังเกตว่าคุณมีไลบรารี retry-logic แยกกันสามตัวที่ทำงานเหมือนกัน และหนึ่งใน repo ที่คุณพึ่งพาจริงๆ ไม่มี commit upstream มานานกว่าหนึ่งปีแล้ว

มุมมองกราฟของคลังเมื่อมีโน้ตครบ 30 อัน: ทุกเครื่องมือเป็นโหนด, ตัวที่ซ้ำและ repo ที่มีวัตถุประสงค์ร่วมกันถูกดึงเป็นกลุ่มที่มองเห็นได้

Loop 2: การรันที่ทำงานได้ก็ต่อเมื่อคุณรวบรวมเครื่องมือครบ 30+ ตัว?

README ของเครื่องมือตัวเดียวไม่สามารถบอกคุณได้ มีเพียงสิ่งที่อ่านข้ามทุกอย่างที่คุณดึงมาเท่านั้นที่ทำได้

1TRIGGER:   ทุก 12 ชั่วโมง
2STEPS:
3  Pass 1, ถูกเก็บไว้จริงๆ:
4    แจ้งเตือน repo ใดๆ ที่มีสถานะ: in-use แต่ไม่มีการอ้างถึงใน
5    โปรเจกต์ของคุณเป็นเวลา 30+ วัน, ตรวจสอบข้ามกับ repo ของคุณเอง
6    สำหรับการใช้งานจริง, ไม่ใช่สมมติฐาน
7  Pass 2, เครื่องมือที่ซ้ำกัน:
8    เปรียบเทียบ "มันทำอะไรจริงๆ" ในทุกโน้ต, จับกลุ่มสิ่งที่
9    แก้ปัญหาเดียวกัน, ยืนยันด้วยชื่อฟังก์ชันที่ตรงกัน
10    หรือวัตถุประสงค์ที่ตรงกัน, ไม่ใช่แค่คำอธิบายที่ฟังดูคล้ายกัน
11  Pass 3, ความเสี่ยง upstream:
12    แจ้งเตือนเครื่องมือใดๆ ที่คุณพึ่งพาซึ่ง commit upstream ล่าสุด
13    เก่ากว่า 120 วัน, เพื่อให้คุณรู้ว่า dependencies ใดบ้างที่อาจ
14    หยุดนิ่งโดยไม่มีการเตือน
15  Pass 4, การอ่านที่ซื่อสัตย์:
16    หนึ่งบรรทัดต่อเครื่องมือว่ามันคุ้มค่ากับพื้นที่ดิสก์และ
17    ภาระทางจิตที่ต้องจำว่ามันมีอยู่หรือไม่, ไม่มีการลดหย่อน
18VERIFY:    แต่ละ pass เขียนไปที่ memory/PORTFOLIO.md, การจัดกลุ่มของ Pass 2
19           สนับสนุนโดยฟังก์ชันหรือวัตถุประสงค์ที่ใช้ร่วมกันจริง
20STOP:      ทั้งสี่ pass เสร็จสมบูรณ์, หรือ pass ใดล้มเหลวและถูกบันทึก,
21           ไม่ถูกข้ามไปอย่างเงียบๆ

Pass 3 คือสิ่งที่เปลี่ยนแปลงวิธีการทำงานของคุณจริงๆ คุณจะไม่รู้ว่าคุณกำลังพึ่งพาเครื่องมือสามตัวที่ผู้ดูแลหยุดเงียบไปเมื่อปีที่แล้ว จนกว่ามันจะอยู่ในรายการต่อหน้าคุณ

ตารางความเสี่ยงที่สร้างจาก Pass 3: เครื่องมือที่คุณใช้จริง, เรียงตามระยะเวลาตั้งแต่โปรเจกต์ upstream เคลื่อนที่ครั้งล่าสุด

ลองใช้รุ่นที่ทำด้วยตนเองก่อน?

กฎเดียวกันเสมอ อย่ากำหนดเวลาสิ่งที่คุณยังไม่ได้พิสูจน์ด้วยตนเอง

1คุณจะทำงานเป็นวงวนจนกว่างานจะเป็นไปตามเกณฑ์
2
3งาน:
4อ่านทุกโฟลเดอร์ repo ใน [path]. สำหรับแต่ละอัน, จดว่ามันทำอะไร,
5ทำไมคุณถึงเอามันมาแต่แรก, คุณยังใช้มันอยู่จริงหรือเปล่า,
6และนานแค่ไหนแล้วตั้งแต่โปรเจกต์ upstream commit ครั้งล่าสุด
7จากนั้นเปรียบเทียบข้ามทุกรูป: หาสิ่งที่ซ้ำกันและอะไรก็ตามที่คุณพึ่งพา
8และที่ upstream เงียบไปแล้ว
9
10เกณฑ์ความสำเร็จ (เข้มงวด, ไม่มีการผ่านแบบอ่อน):
11- ทุก "ซ้ำ" ได้รับการสนับสนุนโดยฟังก์ชันหรือวัตถุประสงค์ที่ตรงกันจริง,
12  ไม่ใช่คำอธิบายที่ฟังดูคล้ายกัน
13- ทุก repo ที่ "ถูกเก็บไว้" รวมถึงจำนวนวันที่ผ่านไปตั้งแต่คุณอ้างถึงมันครั้งล่าสุด
14  ที่ไหนก็ตามในโปรเจกต์ของคุณเอง
15- ความเสี่ยง upstream ขึ้นอยู่กับวันที่ commit จริง, ไม่ใช่สมมติฐาน
16
17โปรโตคอลวงวน, ทำซ้ำทุกเทิร์น:
181. PLAN   - ระบุขั้นตอนถัดไปเพียงขั้นตอนเดียว
192. DO     - สร้างหรือปรับปรุงผลลัพธ์
203. VERIFY - ให้คะแนน 1-10 ในแต่ละเกณฑ์, ซื่อสัตย์อย่างโหดร้าย
214. DECIDE - ถ้าทุกเกณฑ์ได้ 8+, พิมพ์ "FINAL" และหยุด
22
23กฎ:
24- อย่าเรียกมันว่าเสร็จจนกว่าทุกเกณฑ์จะได้ 8+
25- อย่าถามคำถามฉัน, สมมติอย่างมีเหตุผลและดำเนินการต่อ
26
27เริ่มต้น. รันวงวนจนกว่า FINAL.

ถ้ารายการซ้ำหรือรายการความเสี่ยง upstream ทำให้คุณประหลาดใจ มันก็สมควรที่จะมีกำหนดการ ถ้ามันแค่ยืนยันสิ่งที่คุณรู้อยู่แล้ว ยังไม่ต้องทำอัตโนมัติ

ลำดับที่ใช้งานได้จริง?

ทำให้ Loop 1 ทำงานจนกว่า repo ที่ clone ทุกตัวจะมีโน้ตจริง ไม่ใช่ตัวยึด

ปล่อยมันไว้สักหนึ่งหรือสองสัปดาห์ ทุกครั้งที่คุณดึงเครื่องมือใหม่มา มันจะได้โน้ตโดยอัตโนมัติต่อจากนั้น

จากนั้นค่อยเปิด Loop 2 การรันหาเครื่องมือซ้ำและความเสี่ยง upstream ต้องการโน้ตที่มากพอที่จะชนกันจริงๆ

กำหนดเวลามันเป็นลำดับสุดท้าย หลังจากที่คุณเห็นมันทำงานสะอาดด้วยตนเองอย่างน้อยสองครั้ง

มันเสียค่าใช้จ่ายเท่าไหร่?

Loop 1 รันต่อการ clone ใหม่ ดังนั้นมันปรับขนาดตามสิ่งที่คุณดึงมาจริงๆ ไม่ใช่ตามกำหนดเวลาที่ตายตัว ส่วนใหญ่ในแต่ละสัปดาห์ก็แค่การเรียกใช้โมเดลราคาถูกไม่กี่ครั้ง

Loop 2 รันวันละสองครั้งข้ามโน้ต 30+ อัน ย้าย Pass 1 และ Pass 3 ไปที่โมเดลราคาถูก เพราะมันเป็นการค้นหา ไม่ใช่การตัดสิน เก็บ Pass 2 และ Pass 4 ไว้ที่ Sonnet เพราะการหาของซ้ำจริงๆ และการอ่านที่ซื่อสัตย์ต้องใช้โมเดลที่สามารถให้เหตุผลเกี่ยวกับสิ่งที่มันเปรียบเทียบได้จริงๆ เมื่อแบ่งแบบนั้นแล้ว การรันวันละสองครั้งข้ามชุด repo 30 ตัวมีค่าใช้จ่ายน้อยกว่าเวลาที่คุณจะใช้ทำ audit เดียวกันด้วยตนเองครั้งเดียว

สิ่งเดียวที่ต้องจำ?

README บอกคุณว่าเครื่องมือทำอะไร อันนี้บอกคุณว่าใน 30 เครื่องมือที่คุณเจอ คุณใช้ตัวไหนจริง, ตัวไหนที่กำลังซ้ำกันเงียบๆ, และตัวไหนที่คุณพึ่งพาแต่ไม่มีใครดูแลอีกต่อไป

คุณค่าไม่เคยอยู่ในโน้ตเครื่องมือตัวเดียว แต่มันอยู่ในข้อเท็จจริงที่ว่าไม่มีอะไรที่คุณรวบรวมไว้จะเน่าเงียบๆ, ซ้ำกันเงียบๆ, หรือไม่ได้รับการดูแลเงียบๆ โดยไม่มีอะไรเขียนมันลงไปที่คุณจะเห็นได้จริงๆ

สร้าง Loop 1 ก่อน ปล่อยให้มันรันเป็นเวลาสองหรือสามสัปดาห์ก่อนที่คุณจะแตะ Loop 2 การรันหาเครื่องมือซ้ำและความเสี่ยง upstream ไร้ค่าถ้ามีแค่ห้า repos พวกมันเริ่มคุ้มค่าเมื่อมีมากกว่ายี่สิบ

ถ้าคุณต้องการรายละเอียดแบบนี้เพิ่มเติม ผมโพสต์ทุกสองสามวันบน Telegram และ X ทั้งสองฟรี

X - https://x.com/gippp69

Telegram - https://t.me/GipArcAI