llm-wiki-compiler：把原始資料編譯成可審查的 Markdown 知識庫
The knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.
秒懂
- 它是什麼？
- 它用兩階段 LLM 流程把論文、筆記、逐字稿編譯成互相連結、可追溯引用的 wiki 頁面，並用 profile.json 把領域規則變成執行期強制檢查。適合願意為知識建立長期資產的團隊，不適合拿來當靜態網站產生器或即時日誌搜尋。
- 適合誰用？
- 如果你手上有一批值得反覆查閱的來源（論文、逐字稿、內部筆記），而且需要引用可追溯、可人工審查的產出，llmwiki 的編譯模型比每次查詢都重新檢索更划算。若你的資料每天翻新、查完就丟，或你只是想找一個 Markdown 靜態網站產生器，這個專案會多出不必要的生命週期與審查負擔。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 5 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「重複發現」而不是「搜尋」
RAG 的典型做法是查詢當下才從原始檔案裡重新找出答案，同一個問題問十次，代價就付十次，而且每次抓到的片段可能不同。llmwiki 把這個順序倒過來：先把原始材料編譯成耐久頁面，之後的查詢、瀏覽、匯出都建立在編譯結果上。README 引述 Karpathy 的 LLM Wiki 模式，說法是「compile it once into durable pages that accumulate structure, provenance, review state, and retrieval metadata over time」。
所以它的目標讀者不是想隨手問答的人，而是需要一份會累積的知識資產的人。README 列出的適用情境包括把論文、筆記、README、逐字稿、PDF、圖片或網頁編譯成有型別的 wiki 頁面，以及給 agent 一份穩定、帶引用的 context pack。同一段也明講不該拿它當通用靜態網站產生器、重量級 ontology 資料庫，或取代對快速變動原始日誌的即時搜尋。這條界線畫得很清楚：來源知識值得編譯、審查、重複使用，才值得付出編譯成本。
兩階段編譯與四種頁面型別
預設流程分成兩階段：第一階段用 LLM 抽取概念，第二階段生成有型別的頁面。README 點名四種型別：concept、entity、comparison、overview。這個切法意味著產出不是一堆等長的摘要，而是有結構差異的節點，comparison 與 overview 的生成邏輯顯然與單一概念頁不同。
頁面的價值在於它們互相連結。輸出是 Markdown，wikilink 構成圖，段落與主張會標註來源檔案與行號範圍，lint 負責驗證這些連結。檢索端則採混合策略：語意 chunk 搜尋、BM25 重排、wikilink 圖展開，三者組出精簡的 evidence pack，供查詢與 agent 使用。這不是單純的向量檢索，圖結構被當成召回的一部分。
真正讓它與一般文件產生器分開的是 Configurable Lifecycle Profiles。一份經過驗證的 .llmwiki/profile.json 是唯一契約，宣告有型別的實體與有向關係、生命週期狀態與轉移證據、多階段 workflow、以雜湊鎖定的 artifact 與 connector 綁定、內容分層與檢索行為。README 的說法是這些規則「enforced by the runtime, not left as prompt conventions」，無效的 profile 與繞過 gate 的寫入會 fail closed。CLI、SDK、MCP server、viewer、context builder、lint、status、export 與 OKF 交換都讀同一份契約，這是它避免領域分支滲進編譯器核心的做法。
從 profile 到 wiki 的實際指令順序
安裝細節不在提供的材料裡，README 只給了 npm 套件名 llm-wiki-compiler 與官網文件連結，實際安裝指令請以官方文件為準。可以確定的是三條起步路徑，README 直接給了範例。
第一條是自己寫 profile，一次加一種實體型別：
llmwiki profile init research --entity paper
第二條是安裝內建或本機的宣告式模板：
llmwiki template list llmwiki template inspect autosci llmwiki template init autosci
第三條是從受信任的 tap 安裝簽章模板，README 提到 publisher 可用 llmwiki template publish 產出以 Ed25519 簽章的離線發行包，但這段的敘述在提供的材料中被截斷，簽章驗證的完整流程無法從現有內容確認。
建好之後用 llmwiki profile validate 檢查契約，llmwiki workflow list 看可用流程。編譯完成後的操作面包括 llmwiki view 開本機唯讀瀏覽介面（含搜尋、頁面 metadata、圖探索、來源新鮮度標記與引用 chip）、llmwiki lint 找過期或孤立的頁面、llmwiki refresh --stale 只修有變動的知識而不重編無關的新來源、llmwiki eval 產出健康分數與逐頁分布、引用覆蓋率與精確度、語料統計與回歸差異。要接 agent 就用 llmwiki serve 開 MCP server，或在 TypeScript 裡用 createWiki({ root }) 直接驅動 ingest、compile、query、context、status、export、eval 與 OKF 匯入匯出。
一個容易忽略的相容性設計：沒有 .llmwiki/profile.json 的專案會走內建的 concepts-and-queries 預設 profile，保留 1.0 之前的行為。舊專案不會因為升級而被強迫改寫設定。
autosci 與 newsroom 示範的是同一套機械
內建模板不是範例資料，而是同一套 CLP 機械的兩種配置。autosci 是一套研究系統，包含 papers、ideas、experiments、manuscripts、evidence artifacts、workflows 與 Crossref 匯入。newsroom 把同樣的機制套到 articles、desks、bylines 與編輯流程上。README 強調兩者「deliberately different」，用意應該是證明領域差異可以完全落在配置層。
這裡有個值得注意的邊界：README 明講模板只含配置與範例，「never executable plugin code」。這限制了模板能做的事，也移除了安裝模板時執行第三方程式碼的風險。代價是任何需要自訂邏輯的流程，只能靠 profile 已宣告的動作與 workflow 表達，超出範圍就得改編譯器本身或走 SDK。
信任 gate 的設計也值得拆開看。relation、evidence、artifact 與 human/agent gate 由寫入路徑強制執行，standing lint 則在事後偵測漂移。這個前後分工合理：寫入時擋掉不合規的變更，事後用 lint 抓語意上的鬆動。但 gate 的嚴格程度直接決定人力成本，human gate 開得多，編譯就不再是自動化流程，而是一條待審佇列。
編譯式知識庫不適用的三種情況
第一種是來源變動速度高於編譯速度。README 自己把「replacement for ad-hoc search over fast-changing raw logs」列為不該使用的場景。如果你的資料是每天翻新的日誌，編譯出來的頁面在你讀之前就過期了，refresh --stale 只是把成本往後推。
第二種是把它當知識圖譜資料庫用。README 直接寫明不要當 heavy ontology database。它有實體與有向關係，也有 GraphML 匯出，但那是為了檢索與瀏覽，不是為了 SPARQL 式的複雜推論查詢。
第三種是 LLM 供應商的選擇受限。README 列出的 provider 相當廣，涵蓋 Anthropic、Claude Agent SDK 本機登入、OpenAI Codex CLI 本機登入、OpenAI 相容伺服器、Ollama、GitHub Copilot、Atlas Cloud、OrcaRouter 與本機 OpenAI 相容執行環境。清單很長，但編譯品質與 citation coverage 直接取決於模型能力，用小型本機模型跑兩階段抽取，產出的頁面與引用精確度會落在哪個水位，材料裡沒有任何數據可以回答。
另外，eval 回報的 health score 與 citation coverage 是相對指標，不是絕對正確性保證。它能告訴你哪幾頁最差，不能告訴你那些頁面錯在哪裡。
與 Obsidian、一般 RAG 堆疊的差異
llmwiki 的輸出是 Markdown 加 wikilink，topics 裡也放了 obsidian，所以最直覺的比較對象是 Obsidian 加外掛的知識管理流程。差別在於誰做連結。Obsidian 假設連結由人建立，外掛負責呈現與查詢；llmwiki 由編譯器產生頁面與連結，人退到審查與 gate 的位置。這代表你換到的是規模，失去的是每一條連結背後的人為判斷。
與常見的 RAG 堆疊相比，差異在檢索發生的時間點。RAG 在查詢時切 chunk、算相似度、組 context；llmwiki 在編譯時就把結構、provenance 與檢索 metadata 寫進頁面，查詢時做的是語意搜尋加 BM25 重排再加 wikilink 圖展開。前者對來源更新反應快，後者對重複查詢與跨頁推理更省。兩者不是取代關係，但同時維護會產生兩份真相。
OKF（Open Knowledge Format）匯出匯入是它保留退路的方式。README 說明外部 OKF 匯入預設會進 review queue，受信任的 bundle 才能明確地直接寫入。這個預設值選得保守，也讓 llmwiki 可以當成更大知識流程中的一環，而不是終點。其他可攜匯出還包括 JSON、JSON-LD、GraphML、Marp 投影片與 llms.txt。
維護成本與 MIT 授權的實際含義
版本節奏可以從 release 看出輪廓：v1.0.0 在 2026-07-11，v1.1.0 在 2026-07-16，v1.2.0 在 2026-09-10。1.0 之後兩個月內出了兩個次版本，且 1.0 本身就是加入 Configurable Lifecycle Profiles 的大改版。CLP 宣告為 backward-compatible by construction，沒有 profile.json 的專案沿用預設行為，這降低了升級的破壞性，但不代表 profile 的 schema 在次版本之間不會擴充。
日常維護成本主要落在三處。編譯本身要付 LLM 呼叫費用，來源越多越明顯。審查佇列要有人清，review policy 會在 confidence、contradiction、schema 或 provenance 規則觸發時自動把頁面扣下。lint 與 eval 要進 CI 才有意義，否則漂移只會累積。這三項都是持續性的，不是一次性安裝成本。
授權是 MIT，寬鬆，允許商用與修改，沒有 copyleft 傳染問題。要注意的是這只涵蓋 llmwiki 本身：你送進去的來源、編譯出來的頁面、以及你選用的 LLM 供應商條款，各自受不同條件約束；模板若來自第三方 tap，其簽章與來源可信度也需要自行判斷。這些都不構成法律意見，實際採用前請依自身情況確認。
判斷是否採用的順序建議是：先用 llmwiki template inspect autosci 讀一份完整 profile，確認 gate 與 workflow 的粒度是否符合團隊實際流程；再用自己的少量來源跑一次編譯與 llmwiki eval，看 citation coverage 落在哪裡；最後才決定要不要把 lint 接進 CI。反過來做，通常會在 profile 設計階段就卡住。
編輯結論
如果你手上有一批值得反覆查閱的來源（論文、逐字稿、內部筆記），而且需要引用可追溯、可人工審查的產出，llmwiki 的編譯模型比每次查詢都重新檢索更划算。若你的資料每天翻新、查完就丟，或你只是想找一個 Markdown 靜態網站產生器，這個專案會多出不必要的生命週期與審查負擔。動手前先確認三件事：你的 LLM 供應商是否在支援清單內、.llmwiki/profile.json 的 gate 是否符合團隊流程、以及 lint 回報的 citation coverage 是否達到你能接受的水位。
社群筆記