Điều gì khiến một second brain còn sống, và điều gì khiến nó mục? Mình soi git history của chính wiki của mình

Method: Primary source is this repo's own git history — git log --oneline -- <file> run against every page in llm-wiki/concepts/, llm-wiki/people/, llm-wiki/frameworks/, read directly this session. AGENTS.md and content-buckets.md read directly. External framing (the "collector's fallacy," the Zettelkasten "write-only" problem) came from WebSearch extracts only — graded SECONDARY, pages not opened directly. Honesty caveat, load-bearing: this repository's recorded git history begins 2026-08-01 — the earliest commit anywhere in the repo, not a per-file artifact. The wiki's own log says the wiki pattern itself was adopted 2026-04-12, months earlier. So every number below covers this repo's ~7-week recorded history, not the wiki's full life. This digest checks something narrower and still real: of the pages that exist right now, how many has anyone gone back to, in the only window there is a record for.

Dạy người khác build second brain thì phải dám soi second brain của mình

Studio này dạy PM tự build một second brain bằng AI. Nên câu hỏi công bằng nhất là: second brain của chính mình có đang sống không?

Mình không đoán. Mình dùng thứ duy nhất không biết nói dối: git history. Với từng trang trong concepts/, people/ và frameworks/ của wiki, chạy git log và đếm số commit.

Một lưu ý trung thực: git history của repo này chỉ bắt đầu từ 2026-08-01, trong khi wiki được lập từ tháng 4. Mọi con số dưới đây chỉ nói về khoảng bảy tuần có ghi chép.

Con số

186 trang. 169 trang (91%) chỉ có đúng một commit — commit tạo ra nó. Mười sáu trang được sửa lần hai. Đúng một trang được sửa lần ba (VERIFIED).

Mình tưởng lý do là một đợt import cũ. Không phải. Những trang tạo ba ngày trước khi làm bài này cũng đã nằm trong cột "chạm một lần", cạnh những trang từ sáu tuần trước. Mới hay cũ không quyết định việc có được xem lại hay không.

Điều này không chứng minh 169 trang kia sai — một trang đúng thì không cần sửa. Nhưng nó chứng minh cơ chế "xem lại" mà chính schema của wiki yêu cầu gần như không bao giờ chạy.

Đoạn đáng xấu hổ nhất

File AGENTS.md — schema của wiki — ghi như một sự thật rằng lần đổi tên folder trước đã để lại "~130 file" có link [[digests/...]] hỏng.

Mình grep lại trực tiếp: 234 (VERIFIED). Nhiều hơn khoảng 80% so với con số trong ghi chú. Có thể ghi chú đúng lúc viết và link hỏng đã tăng thêm; có thể nó đếm thiếu từ đầu. Dù thế nào: chính cái ghi chú về sự mục nát chưa từng được kiểm tra lại. Đúng lỗi mà bài này nói đến, ở tầng cao hơn.

Vì sao nó mục

Không phải vì thiếu quy tắc bảo trì — wiki này có quy tắc đó bằng văn bản ngay từ đầu. Nó mục vì viết một trang và quay lại một trang là hai hành động khác nhau, và chỉ hành động đầu có "cò súng" tự nhiên: mỗi lần nghiên cứu là một trang mới được viết. Còn quay lại thì không có gì kích hoạt.

Giới PKM gọi đây là "collector's fallacy" — sưu tầm thay cho học — và vấn đề ghi chú "write-only" của Zettelkasten (SECONDARY — chỉ đọc qua trích đoạn tìm kiếm).

Thử tuần này

Soi second brain của bạn, không cần git. Notion có page history, Obsidian có ngày sửa file, Confluence có số version. Mở mười ghi chú cũ nhất: bao nhiêu cái từng được sửa lần hai?
Đừng tin ngày "tạo" — xem ngày "chạm lần cuối".
Thêm một cái cò cho việc xem lại. Rẻ nhất: mỗi khi ghi chú mới đụng cùng chủ đề với ghi chú cũ, bỏ 30 giây đọc lại cái cũ và hỏi nó còn nói đúng điều bạn sẽ nói hôm nay không.
Khi đánh dấu thứ gì là "cũ" hay "chưa giải quyết", ghi ngày vào. Một cờ không có ngày trông giống hệt nhau ở ngày thứ nhất và ngày thứ chín mươi.

Lời mờiMở công cụ đang giữ ghi chú của bạn và kiểm tra năm ghi chú cũ nhất: có cái nào từng được sửa lần thứ hai không? Kể mình con số thật — mình đang gom số đếm thật, không phải phỏng đoán.