2026-04-25 活動快照 snapshot · 數字為當時狀態，最新統計見 BIM_MCP 知識站
The Physics of Insight · Revit MCP

什麼知識，值得變成 Wiki

讀 Karpathy 的 LLM Wiki，與我們這 18 週來的黑暗摸索。

CORE ARCHITECTURE
Wiki is the product, Chat is ephemeral.
我們不是在優化 Prompt，是在編寫一套會自行演化的 BIM 專業 DNA。
SCROLL TO BEGIN
✉️
INTRODUCTION

前言 · 給老師的一封信

讀完 Karpathy 的 gist 時，我感到的不是新奇，而是戰慄。原來我們爭論已久的架構，正是矽谷最頂尖工程師眼中的標準路徑。

上篇 · 讀 Karpathy

CHAPTER 01

一、他說的不是教學

Instruction 是死的手冊，Idea File 是活的基因。這份 gist 描述的是如何建立一套讓 AI 自我維護知識的 Schema。

CHAPTER 02

二、三層架構：Raw／Wiki／Schema

你不直接編寫 Wiki，你定義的是 DNA (Schema)。當規則對了，知識庫就會在每次與 AI 的互動中自動重編與演化。

CHAPTER 03

三、三種動作：Ingest／Query／Lint

動作的基元。特別是不分片 (No Chunk) 的全量讀取，讓 AI 具備了真正的跨頁推理與摘要能力。

CHAPTER 04

四、index 與 log：小規模的反叛

拋棄複雜的向量搜尋。在 100 份文件內，清晰的索引地圖與時序日誌，才是知識庫最穩固的座標。

中篇 · 一個更重要的問題

CHAPTER 05

五、真的都要變 Wiki 嗎？

過度的維護是浪費，缺失的維護是負債。我們必須定義知識的邊界與「活性知識」的範疇。

→
CHAPTER 06

六、四條判準：決策模型

以 BIM 生命週期數據分鏡為例。為什麼營造現場讀設計 Wiki 是一種「數據負債」？我們如何決定知識的流向。

下篇 · 照鏡子

90% MATCH
CHAPTER 07

七、REVIT_MCP 是同一張地圖

逐條對照 Karpathy 的模式。我們在 18 週前埋下的種子，如今開出了與矽谷頂尖架構完全一致的花朵。

CHAPTER 08

八、我們刻意不一樣的
三個地方

為了 BIM 的專業權威性。我們堅持「人類是作者」，並增加了驅動模型操作的「工具執行層」。

CHAPTER 09

九、可以偷回來的四個成果

已落地至 main 的四項資產：三層 Log、/handoff 協議、Nested Metadata 與 AI-agnostic 保底設計。

🌙
CONCLUSION

你的專業，
就是下一個按鈕

這是一場跨越時空的對話。我們寫下的每一行，都是在減少未來的焦慮。讓我們用「放大」來放大你的潛力。

KARPATHY GIST 原文 繁體中文深度譯本
QR
五月小聚 2026.05.23 (Sat)
💰 線上 500 / 現場 200 / 首次 4,800（含歷次回放）
📝 分享筆記到社群即免費　｜　⏰ 5/20 23:59 截止

前言 · 一封給老師的信

親愛的老師：

這 18 週來，我們在黑暗中摸索出的路，原來與 Karpathy 的思考殊途同歸。

讀完 Karpathy 的 gist 時，我感到的不是新奇，而是戰慄。原來這三個月我們不斷爭論的「Domain 為什麼要獨立」、「Log 為什麼要 session 級」，在最頂尖的 AI 工程師眼裡，正是通往 AGI 知識管理的標準路徑。

這不是一篇筆記，是我們架構的「認證書」。它告訴我們，在 BIM 這個極度碎片化、法律權威至上的領域，我們選擇的路徑是正確的。我們不再只是在用工具，我們是在建立「知識的自愈系統」。

HOW將知識從易逝的對話 (Chat) 中剝離，存入持久化的 Wiki (Codebase)。
TRANSFORM從「AI 使用者」晉升為「AI 專業直覺的 DNA 編寫者」。

一、他說的不是教學：Idea File

大多數人要求 AI 摘要，把牛排打成肉泥。Karpathy 要求 AI 寫代碼來管理知識庫。

核心哲學：Obsidian 是 IDE，LLM 是 Programmer

Karpathy 的觀點非常明確：Wiki 就是 Codebase。Instruction 是死的手冊，而 Idea File 是活的基因。它不告訴 AI 具體步驟，而是告訴 AI「如果你是我，你會怎麼建立這套維護系統」。

在 BIM 應用中，不要寫「如何標註磁磚」，而要寫「磁磚標註的幾何邏輯與偏移規則」。讓 AI 學會「思考」標註與牆體的關係，而非模仿畫線動作。

HOW利用 Entropy Control 抑制 LLM 的「過度泛化」天性，強制保留原始語義的顆粒感。
TECHNIQUEIdea-driven Schema Projection & Recursive Context Alignment.

二、三層架構：DNA 的演化邏輯

你不直接編寫 Wiki，你編寫的是「Wiki 怎麼寫」的規則。DNA 對了，Wiki 自己就會長對。

這就像參數化設計：你定義的是「參數關係」，而不是「最終幾何」。當法規更新時，你只需要修改 Schema (CLAUDE.md)，整個 Wiki 知識庫會自動完成「知識重編 (Refactoring)」。

HOW將 CLAUDE.md 定義為系統的 DNA，規定所有 domain 文件的生命週期與交叉引用規則。
LAYERSRaw (地基) → Wiki (建物) → Schema (設計規範)。

三、三種動作：不 Chunk 的全量推理

傳統 RAG 每次都在拼湊碎片，像是在垃圾堆裡找零件。Karpathy 主張全量讀取 (No Chunk)。

在 BIM 領域，一條走廊寬度的判準可能跟防火區劃、建蔽率有關。如果進行分片 (Chunk)，AI 會失去跨章節的邏輯鏈結。我們追求的是「全量關係的交叉引用」。

HOW利用長上下文建立全量語義圖譜，讓 AI 能在 100 份文件內進行無損推理。
TECHNIQUEFull-context Semantic Mapping & Zero-Omission Ingestion.

四、index 與 log：空間與時序的座標

index.md 是空間性的地圖。log.md 是時序性的日誌。這兩者結合，構成了知識庫的完整座標系。

Karpathy 的小規模反叛：當文件在 100 份以內時，一個清晰的人類可讀 index.md 比任何 Embedding 系統都更可靠。Log 不是流水帳，是 append-only 的時間線保險。

HOW回歸結構化的索引與結構化日誌，放棄黑盒子的語義搜尋。
TECHNIQUEDeterministic Retrieval via Manual Indexing.

五、真的，什麼都要變成 Wiki 嗎？

過度的維護是浪費，缺失的維護是負債。Wiki 應承載的是「活性知識」：那些會隨專案演化，但具備長期價值的專業 SOP。

如果資訊能指導下一個專案，它就該進 Wiki；如果只是解決當下的 Bug，它該進 Chat 或 Log。

六、四條判準：BIM 生命週期的數據分鏡

BIM 的全生命週期陷阱： 為了所謂的延續，我們總是將前階段所有數據塞進模型，結果造成數據肥大且充斥垃圾邏輯。

設計 Wiki vs. 營造 Wiki 的衝突

如果營造現場還在讀設計 Wiki，那是負債。這就是為什麼我們需要 Purpose-driven Wiki Forking。知識必須與當前的執行階段「接面」對接。

判準 1權威性：是否涉及法律條文或執業權威？
判準 2頻率：是否為本月被問超過 3 次的痛點？
判準 3穩定性：這項共識是否能維持超過一個月？
判準 4跨度：是否需要跨多個 Skill 共享知識？

七、REVIT_MCP 是同一張地圖

我們與 Karpathy 的重合度高達 90%。這證明了我們這 18 週來的黑暗摸索，是知識工程演化的必然路徑。

DNACLAUDE.md 完美對應其 Schema 層。
WIKIdomain/ 目錄對應其 Wiki 層。
OPS/lessons 與 /qaqc 對應 Ingest 與 Lint。

八、我們刻意不一樣的三個地方

為了 BIM 實戰而生的特化設計：

1. 人類作者權威

法律裁量權不可交給 LLM 盲目萃取，避免產生公安幻覺。我們堅持「人類是作者」。

2. 增加工具執行層 (Skills & Tools)

知識必須驅動 86 個 MCP Tools（snapshot 2026-05-12，4/25 為 76 個）在 Revit 裡劃出那道牆。不轉化為動作的知識，對我們而言沒有價值。

3. 團隊共用架構

多入口保底設計，跨 client (Claude/Gemini) 共享一套 Wiki。

九、可以偷回來的四個小東西

尾聲 · 給下一個月的自己

親愛的自己：當你在未來重新打開這個專案，看到當初留下的每一個 domain/ 與 log 摘要時，你會感謝現在的自己。

我們不僅是在蓋房子，我們在建立智慧系統。我們寫下的每一行，都是在減少未來的焦慮。

要有意識地去理解：省掉的每一個字元，伴隨著怎樣的惋惜。

⚠ 3 個不要踩的雷