Bộ não thứ hai tự bảo trì: Claude Fable 5 + Obsidian

Hàng trăm bookmark bạn sẽ không bao giờ mở lại. Hàng chục cuộc trò chuyện với AI đã trôi mất. Đó không phải là tích luỹ tri thức — đó là tích luỹ chỗ chứa.

Khác biệt nằm ở chỗ có thứ gì được biên dịch ngay lúc nạp vào hay không. Một thư mục chỉ giữ đúng thứ bạn bỏ vào. Một wiki thì mỗi lúc một dày hơn: mỗi nguồn mới đều phải được đối chiếu với những gì đã có — mà đó đúng là việc chẳng ai chịu làm vào tối Chủ nhật.

Đây là cách giao phần đối chiếu đó cho một agent: một vault Obsidian mà tầng wiki/ do Claude Fable 5 viết và bảo trì hoàn toàn, theo mô hình LLM Wiki mà Andrej Karpathy công bố dưới dạng một "idea file" — viết ra để dán thẳng vào agent.

Vì sao không dùng luôn RAG

Cách đặt vấn đề của Karpathy là phần sắc nhất, và nên nói trước khi bàn tới cơ chế.

Tải file lên, truy xuất các đoạn liên quan lúc hỏi, rồi sinh câu trả lời — phần lớn các hệ thống tài liệu hoạt động như vậy, và không có gì được tích luỹ. Hỏi một câu cần tổng hợp năm tài liệu thì mô hình phải đi tìm và ghép lại từng mảnh đó lại từ đầu, mỗi lần hỏi.

Wiki đảo ngược thời điểm. Phần tổng hợp diễn ra một lần, ngay lúc nạp vào: liên kết chéo đã được viết sẵn, mâu thuẫn đã được đánh dấu sẵn. Mọi câu hỏi về sau đọc một cấu trúc mỗi lúc một dày lên theo từng nguồn, thay vì phải dựng lại cấu trúc đó từ văn bản thô.

Cách làm việc của chính ông cũng là cách dùng ở đây — agent một bên, Obsidian một bên, vừa làm vừa nhìn graph vẽ lại:

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

— Andrej Karpathy, LLM Wiki

Về bài viết này

Viết từ chính vault của mình chứ không phải từ lý thuyết — số lượng thư mục, bản hợp đồng và các dòng log trích dưới đây đều là file thật. Chỗ nào hệ thống có giới hạn, mình nói rõ.

Ý tưởng duy nhất khiến nó chạy được

Phần lớn các setup "bộ não thứ hai bằng AI" đều hỏng theo cùng một kiểu: agent cứ viết thêm trang mới, không có gì được gộp lại, và sáu tháng sau bạn có bốn trang nói về cùng một công cụ dưới bốn cái tên khác nhau.

Cách chữa không phải là một prompt hay hơn. Mà là quyền sở hữu, được viết ra thành văn bản.

Đây là bản viết của video, nơi vault được dựng từ một thư mục rỗng và hai nguồn đầu tiên được nạp từ đầu đến cuối — kể cả cảnh graph view tự vẽ lại.

Muốn xem thẳng trên YouTube?

Xem trên YouTube — hoặc đăng ký kênh để đón video tiếp theo.

Chính sự phân chia này giữ cho vault đáng tin: agent muốn viết bao nhiêu trong wiki/ cũng được, nhưng không thể đụng vào bằng chứng trong raw/ mà mọi khẳng định đều phải trích dẫn.

Ba tầng, và ranh giới giữa chúng được cưỡng chế bằng một file hợp đồng mà agent đọc trước mỗi lần làm việc:

Đường dẫn	Chủ sở hữu	Quy tắc
inbox/	bạn	nơi thả tài liệu chưa xử lý
raw/	bạn	tài liệu gốc bất biến — agent chỉ được đọc
wiki/	agent	mọi trang do agent sinh ra; agent sở hữu trọn tầng này

Việc raw/ nằm ngoài tầm với chính là mấu chốt. Agent muốn viết bao nhiêu cũng được, nhưng không thể sửa đổi cái bằng chứng mà mọi khẳng định của nó buộc phải trích dẫn.

Năm quy tắc gánh phần việc chính

Bản hợp đồng khá dài, nhưng năm quy tắc dưới đây gánh gần hết.

Xuất xứ — không nguồn thì không viết. Mọi câu khẳng định đều kèm một wiki-link tới file trong raw/ mà nó lấy ra. "Nếu không truy được câu đó về một file trong raw/, thì đừng viết." Agent vẫn được phép tự tổng hợp, nhưng phải ghi rõ đó là tổng hợp.

Nén — gộp lại, đừng nhân bản. Một nguồn mới có chỗ đứng bằng cách hoà vào cái đã có, chứ không phải bằng cách chất thêm trang. Sửa trang cũ và viết lại những mục bị ảnh hưởng, để nó luôn là "một bản tổng hợp tốt nhất ở hiện tại, không phải một cuốn sổ chép theo thời gian."

Xung đột — không bao giờ ghi đè lặng lẽ. Khi nguồn mới mâu thuẫn với trang cũ, giữ cả hai, mỗi bên kèm trích dẫn, đặt trong một callout ⚠️ CONFLICT, rồi đẩy cho con người quyết.

Tiết kiệm token — đọc index, đừng đọc cả vault. Bắt đầu từ index.md, dùng các dòng tóm tắt một câu để chọn trang cần mở, và chỉ mở đúng những trang đó. Quét toàn vault chỉ dành cho lint.

Sửa mang tính xoá thì phải xin phép. Việc thêm thì cứ mạnh dạn làm; còn gộp trang có xoá và các thao tác xoá thì luôn phải chờ con người duyệt.

Ba quy trình

INGEST — mỗi lần một nguồn. Đọc nguồn, bàn về ý chính trước khi viết, tra index.md và sổ thuật ngữ xem có trùng lặp không, quyết định tạo trang mới hay gộp cho từng chủ đề và nói rõ vì sao, rồi mới viết, cập nhật index và ghi vào log.

QUERY — trả lời từ wiki, có trích dẫn những trang đã dùng. Nếu wiki mỏng về chủ đề đó thì nói thẳng thay vì đoán. Trang nào có updated quá 90 ngày thì cảnh báo là có thể đã cũ. Đáng chú ý: nó không ra internet — câu trả lời chỉ dựa trên thứ bạn đã thật sự nạp vào.

LINT — được đề nghị sau mỗi 10 lần nạp. Quét tìm trang gần trùng, link gãy, trang mồ côi, mâu thuẫn giữa các trang, trang cụt, trang cũ, và lỗ hổng: những chủ đề lặp đi lặp lại qua nhiều nguồn mà chưa có trang riêng.

Hai nguồn đã tạo ra được gì

Tại thời điểm viết bài, vault mới nạp đúng hai thứ: một bài web so sánh các AI coding agent, và một cuốn PDF 93 trang về xây dựng agent.

Nguồn trong raw/	2
wiki/concepts/	11 trang
wiki/entities/	12 trang
wiki/summaries/	2 trang

Một bài viết và một cuốn sách thành 25 trang liên kết với nhau — và lần nạp thứ hai không chỉ nối thêm vào. Log ghi lại rằng nó đã hoà vào lần nạp đầu: ai-coding-agents được gắn thêm một concept cha, và hai trang cũ được thêm liên kết chéo sang các trang mới về đánh giá và framework.

Chính hành vi gộp đó là thứ đáng kiểm tra trên vault của bạn. Nó là ranh giới giữa một wiki và một thư mục.

Phần mình không ngờ tới: file log

log.md chỉ ghi thêm, mới nhất lên đầu, không bao giờ sửa cái cũ. Nó là một sổ ghi kiểm toán — và các dòng ghi tự nêu ra điểm yếu của chính mình:

Flagged: vendor source (Galileo) and ~late-2024 vintage — framework verdicts likely stale.

…noted Firecrawl marketing bias and a gap (no dedicated MCP source yet).

Một lần nạp mà tự ghi lại "nguồn này là của hãng đang bán hàng, và nó đã cũ" là đang làm đúng việc của một trợ lý nghiên cứu tử tế. Cùng một tinh thần với lập luận về quality gate trong loạt bài SDLC: một kết quả xanh chỉ có giá trị bằng đúng bằng chứng đứng sau nó — mà bằng chứng ở đây là một trang tiếp thị.

Lượt lint cũng thẳng thắn tương tự: báo 0 link gãy, 0 trang mồ côi, 0 trang cũ, rồi chỉ ra một file rỗng bị bỏ quên ở thư mục gốc và hai chủ đề lặp lại ở cả hai nguồn mà chưa có trang riêng.

Toàn văn bản hợp đồng

Đây là file mà cả hệ thống chạy dựa trên nó. Nó nằm ở gốc vault và agent đọc nó đầu tiên, mỗi lần. Copy về, đổi phần lĩnh vực và tên thư mục cho hợp với bạn, rồi trỏ một agent vào vault rỗng.

`CLAUDE.md` — toàn bộ schema và hợp đồng (bấm để mở)

File có bảng markdown và khối code lồng bên trong, nên mình để nguyên trạng thay vì bẻ dòng — bẻ dòng sẽ làm hỏng bảng. Cứ copy trọn khối.

# Second Brain Wiki — Schema & Contract

This vault is a personal knowledge base on **IT, AI, DevOps, and Software Engineering**,
maintained by an LLM agent (you) on the three-layer pattern: raw sources → wiki → this schema.
The human curates sources and asks questions; you do all writing, filing, and maintenance.
All wiki content is written in **English**.

## Layers & folders

| Path | Owner | Purpose |
|---|---|---|
| `raw/` | Human | Immutable source documents. **Read-only for you — never edit, move, rename, or delete anything here.** |
| `raw/assets/` | Human | Images/attachments belonging to raw sources. Also immutable. |
| `inbox/` | Human | Landing zone for not-yet-ingested material. After ingest, the human (or you, with permission) moves the file to `raw/`. |
| `wiki/` | You | All LLM-generated pages. You own this layer entirely. |
| `wiki/summaries/` | You | One page per ingested source. |
| `wiki/entities/` | You | Proper nouns: tools, products, models, companies, people, platforms (e.g. `claude-code.md`, `kubernetes.md`). |
| `wiki/concepts/` | You | Ideas, techniques, practices, patterns (e.g. `prompt-caching.md`, `blue-green-deployment.md`). |
| `wiki/aliases.md` | You | Terminology registry (see below). |
| `index.md` | You | Live map of the whole wiki, grouped by domain. Updated on every change. |
| `log.md` | You | Append-only chronological record. Never edit past entries. |

### Naming rules
- Everything **kebab-case**, `.md` extension.
- `raw/`: `YYYY-MM-DD-<slug>.md` (date = date added, slug from the title). PDFs keep their extension: `YYYY-MM-DD-<slug>.pdf`.
- `wiki/summaries/`: same slug as the raw file it summarizes: `YYYY-MM-DD-<slug>.md`.
- `wiki/entities/` and `wiki/concepts/`: canonical name only, no date: `github-actions.md`, `retrieval-augmented-generation.md`. Check `wiki/aliases.md` before naming.

### Domains
Primary tag taxonomy (extend as needed, record extensions here):
`ai-tools`, `ai-models`, `ai-workflows`, `software-engineering`, `devops`, `cloud`, `containers`, `ci-cd`, `infrastructure`.

## Page schema

Every wiki page has this shape:

```markdown
---
title: Prompt Caching
aliases: [prompt cache, KV cache reuse]
tags: [ai-models, ai-workflows]
status: draft        # stub | draft | stable
sources: [2026-07-05-anthropic-caching-docs]
updated: 2026-07-05
---
**One-line summary of the page, readable on its own.**

<body: sections, claims with citations, wiki-links>

## Related
- [[parent-or-sibling-pages]]
```

- The **first body line** (right after front-matter) is a one-line bold summary. Read this line
  to judge relevance before loading a full page. (It sits after the front-matter, not before,
  because Obsidian only parses YAML at the very top of a file.)
- `status`: `stub` = placeholder, needs content; `draft` = has content, single-source or unreviewed;
  `stable` = multi-source, reviewed by the human.
- **Backlinks:** every concept page links to at least one parent (a broader concept or domain hub
  page). No orphan pages.

## Provenance rule — no source, no claim

Every factual claim cites its raw source inline as a wiki-link to the raw file, e.g.:

> Claude Code supports hooks for intercepting tool calls ([[2026-07-05-claude-code-docs]]).

- Citations link to files in `raw/` so they are clickable in Obsidian.
- If you cannot trace a statement to a file in `raw/`, do not write it. Your own synthesis is
  allowed but must be marked as such (e.g. "Synthesis:") and must reference the pages it draws on.

## Compression rule — merge, don't duplicate

A new source earns its place by **merging** into existing knowledge, not by piling up pages.

- Before writing anything, search `index.md` and `wiki/aliases.md` for overlap.
- If a topic already has a page: **update that page**, and note in its body or the log what
  changed and why. Do not append blindly; rewrite sections so the page stays a coherent
  current-best synthesis, not a chronological scrapbook.
- Never create a near-duplicate page. Two pages about the same thing under different names is
  the failure mode this whole rule exists to prevent.

## Terminology registry — `wiki/aliases.md`

A table mapping every known alias to its one canonical page:

```markdown
| Alias | Canonical page |
|---|---|
| RAG | [[retrieval-augmented-generation]] |
| retrieval augmented generation | [[retrieval-augmented-generation]] |
| K8s | [[kubernetes]] |
```

- **Consult it on every ingest** before creating or linking pages.
- When you coin a canonical page name, register the name and all aliases you've seen.
- Also mirror aliases into each page's `aliases:` front-matter so Obsidian resolves them.

## Conflict rule

When a new source contradicts an existing page, **never silently overwrite**. Instead:

1. Keep both claims on the page, each with its citation, under a `> ⚠️ CONFLICT:` callout
   explaining the disagreement.
2. Flag it to the human in your ingest report and let them resolve it.
3. Record the conflict in `log.md`.

## Token-efficiency rule

- Start every task by reading `index.md` (and `wiki/aliases.md` when ingesting).
- Use the one-line summaries in the index to decide which pages are relevant; open only those.
- Never re-read the whole vault by default. Full-vault scans are for lint passes only.

## Workflows

### INGEST (one source at a time, human in the loop)
1. Read the source (from `inbox/` or `raw/`). If it references local images, read the text first,
   then view the images that matter.
2. Discuss key takeaways with the human; let them steer emphasis before writing.
3. Search `index.md` + `wiki/aliases.md` for overlap. Decide new page vs merge for each affected
   topic, and say why.
4. Write the summary page in `wiki/summaries/`; create/update every affected entity and concept
   page (a rich source may touch 10–15 pages). Ensure the file lands in `raw/` with the standard name.
5. Update `index.md` and `wiki/aliases.md`; append to `log.md`.
6. Report in ~3 lines: what was written, what was merged, anything flagged (conflicts, gaps).

### QUERY
- Answer **from the wiki**, citing the pages used (which themselves cite raw sources).
- If the wiki is thin or silent on the topic, say so — flag the gap rather than guessing.
- Flag pages relied on whose `updated` is more than 90 days old as potentially stale.
- If an answer produced durable new synthesis (a comparison, an analysis), offer to file it back
  into the wiki as a page.

### LINT (on request, or offer after every 10th ingest)
Scan the wiki for: near-duplicate pages, broken wiki-links, orphan pages (no inbound links),
contradictions between pages, dead stubs, stale pages, and **gaps** — topics recurring across
multiple raw sources that lack a dedicated page. Propose fixes and new-page candidates;
**apply only after human approval.** Additive fixes may be biased toward action; destructive
edits (merges that delete pages, removals) always require approval first.

### LOG format (newest first, never edit past entries)
```markdown
## [2026-07-05] ingest | Article Title
Pages touched: [[summary-page]], [[entity]], [[concept]] — one-line why.
```
Actions: `ingest` | `update` | `merge` | `lint` | `query-filed` | `schema`.

## Meta

- This schema is co-evolved with the human: when a workflow repeatedly fails or a convention
  proves awkward, propose an amendment here (action `schema` in the log) rather than silently
  deviating.
- Stay quiet about your own mechanics during normal work unless asked.

Các bước cài đặt

1. Tạo vault mới trong Obsidian (Manage vaults → Create), đặt ở chỗ bạn mở được bằng editor.
2. Mở đúng thư mục đó bằng VS Code — bạn cần cây thư mục và một terminal ngay cạnh graph view.
3. Cài Claude Code CLI rồi chạy claude trong terminal đó, với vault làm thư mục làm việc. Chọn model mạnh nhất bạn có.
4. Đưa cho nó mô hình wiki và yêu cầu sinh schema. Nó sẽ hỏi bạn trước — lĩnh vực, loại nguồn, phong cách truy vấn, mức độ bạn muốn tham gia, thói quen dọn dẹp. Hãy trả lời cho nghiêm túc; chính các câu trả lời đó trở thành bản hợp đồng.
5. Để nó viết CLAUDE.md, rồi tới cấu trúc thư mục, index.md và log.md.
6. Thả nguồn đầu tiên vào inbox/ và yêu cầu nạp.

Nhớ đặt vault dưới git. Chạy git status sau mỗi lần nạp là cách nhanh nhất để thấy chính xác agent đã đụng vào những gì — và đó cũng là nút undo duy nhất bạn có.

Những chỗ mình sẽ để mắt

Nó chỉ biết đúng thứ bạn cho nó ăn. Bước QUERY cố ý không ra internet. Đó vừa là điểm mạnh về độ tin cậy, vừa là giới hạn về độ phủ — vault mỏng thì câu trả lời mỏng, và nó sẽ nói thẳng.

Gộp là phần khó nhất, và nó hỏng một cách âm thầm. Hai trang nói về cùng một thứ dưới hai cái tên là đúng cái lỗi mà thiết kế này sinh ra để ngăn, và thứ duy nhất chắn giữa bạn với nó là lượt lint. Hãy chạy lint.

Hai nguồn thì chưa gọi là kiểm chứng. Mọi điều ở trên đúng với một vault 25 trang. Câu hỏi đáng quan tâm là quy tắc nén sẽ hoạt động ra sao ở mức ba trăm trang — và mình chưa có bằng chứng đó.

Liên quan

• Gist LLM Wiki của Karpathy — mô hình gốc, viết ra để dán thẳng vào agent.
• Fable Mode: Bắt model mạnh nhất viết sổ tay vận hành cho model thay thế nó — cùng một nước đi ở quy mô khác: để model mạnh viết ra luật, rồi cho thứ rẻ hơn tuân theo.
• Buổi 4 — Quản trị AI Engineering — vì sao xuất xứ quan trọng hơn sự tự tin, qua một ca hỏng có thật.