LLM-as-Compiler 知識庫

資料來源#

• An open-source spec for Codex orchestration: Symphony.
• LLM Knowledge Bases
• llm-wiki
• The New Physics of Business — Garry Tan, Y Combinator

摘要#

這是一種由 Andrej Karpathy 發起的架構模式，其中 LLM 扮演編譯器：讀取原始來源文件，逐步產生結構化、彼此連結的 markdown wiki。不同於依賴嵌入與向量資料庫的傳統 RAG 系統，這種方法使用 wiki 自身的索引檔案與 LLM 的 context window 進行檢索；在個人知識庫規模（約 100 篇文章、400K 字）下已經足夠。

詳情#

四階段 Pipeline#

系統以持續循環的方式運作：

1. Ingest — 原始內容（透過 Obsidian Web Clipper 收集的網頁文章、論文、repo 筆記）以 markdown 檔案形式進入 raw/ staging 目錄。
2. Compile — LLM 讀取 raw/，建立索引檔案（所有文件的摘要）、概念文章（依主題整理，包含反向連結與交叉引用），以及衍生輸出（投影片、圖表、歸檔的查詢答案）。LLM 會自動維護概念之間的連結圖。
3. Query & Enhance — 使用者在 Obsidian 中瀏覽 wiki、透過 Q&A agent 提出研究問題，或使用 CLI／網頁工具搜尋。關鍵在於，查詢產生的所有輸出都會回存至 wiki，因此每次探索都會累積價值。
4. Lint & Maintain — LLM 稽核不一致之處、透過網路搜尋補足遺漏資訊、發現新的概念間連結，並提出後續問題。完成 lint 後，循環回到 compile。

關鍵設計決策#

• 不使用向量資料庫 — 在個人規模下，索引檔案加上 LLM context window 已足以進行檢索，因此可消除 embedding pipeline 的複雜度。規模更大時，可使用像 qmd 這樣的本機搜尋引擎（結合 BM25／向量搜尋與 LLM 重新排序，可作為 CLI 與 MCP server）來補強索引。
• 增量編譯 — 新的原始文件會整合進現有 wiki 結構；已建立索引的文件絕不重新處理。
• 探索永遠會累積 — 每個查詢答案、圖表與衍生產物都會回存至 wiki。這是它相較於 RAG 的核心差異：知識只需編譯一次並持續更新，而不是每次查詢都重新推導。
• 由 LLM 負責寫作 — 人類很少直接編輯 wiki；LLM 負責編譯、連結與維護。人類的工作是尋找來源、探索，以及提出正確問題。
• Wiki 是持久且會複利的產物 — 交叉引用已經存在、矛盾已被標記、綜合結果已反映所有讀過的內容。每加入一個來源、每提出一個問題，wiki 都會更加豐富。

三層架構（來自 Karpathy 的 Gist）#

Karpathy 的原始設計文件明確說明了這套架構：

1. Raw sources — 經過策展且不可變的來源文件（文章、論文、圖片、資料）。LLM 會讀取但不修改它們，這是事實來源。
2. The wiki — LLM 產生的 markdown 檔案：摘要、實體頁面、概念頁面、比較與綜合整理。LLM 完全負責這一層：建立、更新、交叉引用並維持一致性；人類則閱讀它。
3. The schema — 設定文件（CLAUDE.md／AGENTS.md），告訴 LLM wiki 的結構、應遵循的慣例，以及要執行的工作流程。人類與 LLM 會隨時間共同演進這套 schema。

索引與導覽#

兩個特殊檔案有助於在大規模 wiki 中導覽：

• index.md — 以內容為導向的目錄，列出每個頁面的一行摘要，並按類別整理。LLM 回答查詢時會先讀取它，再深入相關頁面。在中等規模（約 100 個來源、數百個頁面）下運作良好。
• log.md — 按時間排列、只能追加的操作紀錄（匯入、查詢、lint pass）。如果使用一致的前綴（例如 ## [2026-04-02] ingest | Article Title），就能用 unix 工具解析。

使用情境#

這種模式適用範圍廣泛：

• 個人：目標、健康、心理學——歸檔日誌、文章與 podcast 筆記
• 研究：用數週／數月閱讀論文，建立具備演進中論點的完整 wiki
• 閱讀書籍：按章節建立伴讀 wiki，整理角色、主題與情節線索（像個人的粉絲 wiki）
• 企業／團隊：由 Slack 討論串、會議逐字稿與客戶通話餵入內部 wiki，再由人類審查更新
• 任何知識累積：競爭分析、盡職調查、旅程規劃、課程筆記

為什麼有效#

知識庫的瓶頸不是閱讀或思考，而是簿記：更新交叉引用、保持摘要最新、記錄矛盾，以及維持數十個頁面之間的一致性。人類會放棄 wiki，因為維護負擔增長得比價值更快。LLM 不會感到厭倦、不會忘記更新交叉引用，還能一次處理 15 個檔案。

思想脈絡#

Karpathy 將這套方法連結到 Vannevar Bush 的 Memex（1945）——一個在文件之間建立聯想路徑的個人策展知識儲存庫。Bush 的願景比後來的網路更接近這種模式：私有、持續策展，且文件之間的連結與文件本身同樣有價值。Bush 無法解決的部分，是誰來維護它；這部分由 LLM 負責。

變體#

Elvis Saravia 描述了一種自動化匯入的變體：經過調整的 Skill agent 每日策展研究論文，使用 qmd CLI tool 為它們建立索引，再將已索引的知識庫餵給以 MCP tools 建構的互動式 artifact generator。這會在數百篇論文之間產生可探索的互動式視覺化。

未來方向#

Karpathy 提到，可以使用 wiki 產生合成訓練資料，並對 LLM 進行 fine-tune，讓它在權重中「知道」這些資料——將個人知識庫轉變為個人化模型。

公司大腦：組織規模的模式（Garry Tan 的 GBrain）#

這套架構在野外最突出的姊妹版本（2026 年 7 月，practitioner-opinion）是 Garry Tan 的公司大腦——他採 MIT 授權的開源 GBrain，「實際上就是 agents 的 Postgres」。他的表述是**「圖書館加上圖書管理員」**：組織的完整紀錄（電子郵件、會議、決策及其推理、事後檢討）是圖書館，而承擔關鍵作用的是圖書管理員——檢索層會依每項任務決定哪些「三本書」要放進 agent 的 context（他以工作記憶作比喻：agent 能容納約 1M tokens ≈ 三本 Harry Potter，相對於人類的 7±2；「決定你的 agents 是天才還是金魚的問題，是誰決定桌上打開哪三本書」）。他的個人實例約有 220,000 頁，主要由 agents 從 20 年的電子郵件、會議與筆記編譯而成。

Tan 預先回應了「這不就只是 RAG 嗎」的質疑，方式與本頁完全一致——「retrieval 是基本原語，就像 Postgres 只是 B-trees……Retrieval 很容易。真正值得檢索的內容才是產品。」值得從他的說法保留的是衛生準則，這與本 vault 自身的設計獨立趨同：

Tan 的失效模式／處方	本 vault 的機制
「每個事實都要有 Provenance」	evidence: 分級＋逐來源引用（Non-Malleable Memory Authority (TMA-NM) 證明，在對抗性情境下，不綁定來源的內容信任是不健全的）
「新資訊與舊資訊衝突時進行矛盾檢查」	明確標記矛盾的 compile rule
「一位人類加 agent 組成的圖書管理員，其實際工作是修剪」	lint pass
「沒有人策展的大腦會變成搜尋功能很棒的垃圾場」	這正是 compile／lint 存在的原因——未經策展的儲存庫進行檢索時，會「帶著十足信心」呈現過時事實

他的總結——「把大腦當成 production infrastructure，它就會複利；把它當成傾倒場，你會得到一個非常有自信、卻以無人能追溯的方式犯錯的 agent」——是本頁「探索永遠會累積」的作業版本，並明確呈現失效分支。他的經濟觀點也值得記錄：「模型品質是租來的，但如果你建立自己的大腦，你就擁有那個大腦」（Compounding Data Moat：知識儲存庫層級的資料護城河）。

作為編譯來源的 Spec（Symphony 的跨語言 Fuzz）#

目前在野外最具體的 LLM-as-compiler 延伸：OpenAI 的 Symphony 團隊將 SPEC.md 視為來源，請 Codex 以 Elixir、TypeScript、Go、Rust、Java 與 Python 實作。他們接著利用各實作之間的差異找出 spec 中的模糊處，並加以簡化。

這項技術真正新穎之處在於：

• LLM 就是編譯器（markdown → N 種目標語言中的可運作 orchestrator）。
• 多個實作是 spec-fuzzing 訊號——凡是實作出現差異的地方，都代表 spec 的約束不足。這類似於編譯器驗證中的 differential fuzzing，但來源語言變成英文／markdown。
• Spec 才是持久產物，而非編譯輸出。OpenAI 明確表示，他們不打算將 Symphony 維護為獨立產品——它是一個參考實作，使用者可以讓自己的 coding agent 依此執行。

對本 vault 的啟示：

• _system/compiler-prompt.md 在結構上類似 Symphony 的 SPEC.md——兩者都定義 agent 應如何將一類產物（原始文件／Linear tickets）轉換為另一類產物（wiki 文章／運作中的 orchestrator）。
• 對知識庫而言，透過多語言進行 spec-fuzzing 是過度設計，但這個想法可以泛化：如果 compiler-prompt.md 由不同模型家族（Claude、GPT、本機模型）執行時產生意義不同的 wiki，差異就會指出規格不足之處。
• Schema 層（Karpathy 的用語）與 SPEC.md／WORKFLOW.md 屬於同一類產物——由 repo 版本控管、定義 agent 行為的 markdown。參見 Claude Code Best Practices（CLAUDE.md）、Hermes Agent（AGENTS.md／SOUL.md）、Symphony（WORKFLOW.md）的交叉連結。

相關連結#

• Code as Source of Truth — 將 specs／skills 納入 repo，是套用於程式碼的 compiler-wiki 模式
• 這個概念是本 Obsidian vault 的基礎架構（參見 _system/compiler-prompt.md）
• Agent Harness Engineering — 共用 repo-local knowledge 作為 system of record 的模式；OpenAI 的 AGENTS.md-as-table-of-contents 對應了本 wiki 的 schema 層
• Claude Code Best Practices — CLAUDE.md 檔案在 Claude Code 對此模式的實作中充當 schema 層
• LLM-Driven Vulnerability Research — vulnerability research scaffold 使用 SHA-3 cryptographic commitments 作為可驗證知識編譯的形式；Claude Code 的 agentic capabilities 驅動 discovery pipeline
• Client-Side Agent Optimization — wiki 的 compile／query／lint 階段本身就是 agent pipeline；不同階段可以分配給不同模型（便宜模型負責 index drift checks，強模型負責 cross-reference synthesis），再將組合最佳化
• Symphony — LLM-as-compiler 超越知識庫的最具體延伸：OpenAI 將 SPEC.md 編譯成 6 種語言的實作，並利用差異作為 spec-fuzzer 來消除模糊性
• Ticket-Driven Agent Orchestration — Symphony 的 WORKFLOW.md 在結構上與此處的 schema 層屬於同一類產物；兩者都是由 repo 版本控管的 markdown，讓 LLM 將其「編譯」成行動
• Agent Context Files — spec-as-document 模式是將 LLM-as-compiler 套用至 context file；Symphony 將 SPEC 編譯成 6 種語言的 spec-fuzzing 是最清楚的實例
• Design Concept Grilling — Brooks 的「design concept」（任何產物之前的共同理解）是對齊層的類比：wiki 捕捉什麼是真的，grilling session 捕捉我們同意什麼；兩者都把 LLM 視為編譯夥伴，而非一次性輸出的生成器
• Andrej Karpathy — 發起了這個模式（llm-wiki gist），並在 2026 年 5 月的訪談中再次確認這是他的日常實踐——從讀過的文章建立 wiki 並查詢它
• Software 3.0 — Karpathy 對「過去不是程式的新資訊處理任務」的經典例子：將文件重新編譯成 wiki，在 Software 1.0／2.0 中是不可能的
• Outsource Your Thinking, Not Your Understanding — Karpathy 的模式為何有效：「每當我看到資訊投影的不同方式，我就獲得洞見」——wiki 是建立理解的工具，而不只是檢索工具
• Memory and Context Poisoning — 此模式承襲的對抗性威脅面：任何允許 agent 寫入持久記憶的系統，都需要完整性驗證與來源歸因控制，才能讓編譯後的儲存庫維持可信
• LLM-Assisted Grey-Literature Theory Building — 用於研究綜合的相同架構邊界：LLM 將數千份原始文件編譯成結構化、以引文為基礎的產物（因果理論），但詮釋步驟仍由人類負責——自動化 codes→theory synthesis 產生了 15,029 個膚淺且重複的陳述，這是「LLM 負責簿記，而非判斷」的負面結果回聲
• Garry Tan — GBrain 是組織規模的姊妹版本（圖書館＋圖書管理員、記憶加衛生）；與本 vault 的 provenance／矛盾／修剪設計獨立趨同
• AI-Native Organization — 公司大腦是 Tan 的 AI-native 組織的記憶層；組織的 skills 負責路由工作，大腦提供組織已知的內容
• Non-Malleable Memory Authority (TMA-NM) — 「每個事實都要有 provenance」背後的對抗性案例證明：從記憶的內容或 lineage 推導出的 authority 可以被洗白；來源必須在寫入時綁定
• Compounding Data Moat — 「模型品質是租來的，但你擁有自己的大腦」：策展知識儲存庫是超越模型存取權的持久資產
• Latent vs. Deterministic Space — 本 vault 的實作範例：在 latent compiler 周圍配置 deterministic generators／linters（build.py／lint.py）

開放問題#

• 不使用向量資料庫的方法在什麼規模下會失效？Karpathy 的約 100 篇文章能放進 context，但 1,000 篇以上呢？
• 編譯期間，如何處理來源之間互相衝突的資訊？
• 概念文章的最佳粒度是什麼——每篇文章一個概念，還是依主題聚類？
• 合成訓練資料 → fine-tuning pipeline 在實務上有多有效？

衍生內容#

• What Are AI Tools? — 探索本 wiki 涵蓋哪些 AI tools 的查詢

資料來源#

• LLM Knowledge Bases
• llm-wiki
• The New Physics of Business — Garry Tan, Y Combinator — Garry Tan 的 AI Engineer 演講（2026-07-17，practitioner-opinion）：公司大腦章節（GBrain、圖書館＋圖書管理員、記憶加衛生）