當硬核傳產工程遇上數位花園：我如何用 LLM Wiki 打造「傳統產業管理 × 新媒體副業」的高效雙軌知識庫

Wed, 15 Jul 2026 16:53:00 +0800

當硬核傳產工程遇上數位花園：我如何用 LLM Wiki 打造「傳統產業管理 × 新媒體副業」的高效雙軌知識庫

想像一下，你的白天與夜晚分別是這樣度過的：

白天（作為傳統產業現場工程師）：你需要盯著廠區內的大型重型機械設備，處理突然發生的控制系統自動降速保護跳脫故障；你要和現場主管、值班技術員、外部代理商開會，排查輔助設備冷卻器大洞焊補或起重搬運設備的排纜器鋼絲磨損，並應付繁瑣的國際合規證照申辦與管理。
夜晚（作為 YouTuber 與部落客）：你坐在電腦前經營著個人部落格 Digital Vineyard，思考著在 AI 時代下「書籍導讀與電影哲學」頻道的定位與生存策略，或是為了節省幾分鐘而折騰 Obsidian 結合 GitHub Actions 的自動化部署（CI/CD）流程。

這是我真實的雙軌生活。一個是鐵鏽、潤滑油、重型動力主機與嚴格安全法規的傳統硬核工業；另一個是代碼、演算法、個人品牌與自動化工具的數位新媒體。

這兩個看似風馬牛不相及的平行宇宙，每天都會產生海量的非結構化資訊（會議記錄、排障報告、影片腳本草稿、技術文檔）。過去，我嘗試過各種筆記方法，但面臨高強度工作時，分類繁瑣與維護連結的「整理摩擦力」總是會讓知識庫迅速荒廢。

直到我讀到了 Andrej Karpathy 提出的 LLM Wiki 模式，並在自己的 Obsidian 庫中實作了這套架構，這兩個世界的知識終於在同一個數位花園裡，找到了有機融合的完美秩序。

什麼是 LLM Wiki 模式？

Andrej Karpathy（前 Tesla AI 總監、OpenAI 創辦成員）提出了一種面向 AI 時代的個人知識庫管理模式。它的核心思想非常簡單，卻徹底解決了傳統知識庫的痛點：

讀寫分離（Immutable Sources vs. Synthesized Wiki）：
- sources/ 存放原始、零碎的輸入（如現場隨手記下的聊天記錄、原始故障報告、會議大綱、靈感草稿）。這些檔案對 AI 助理是唯讀的，人類只管把原始資料丟進去。
- wiki/ 是經由 AI 助理彙整編譯後的結構化知識庫，包含實體頁（Entities，如特定設備、廠商、專案）與概念頁（Concepts，如特定排障方法、技術工法）。
人機協同的 Ingest 流程：
- 當我有新的原始檔案進入 sources/ 時，我不需要自己去建立連結、打標籤、分資料夾。
- 我只需要呼叫 AI 助理執行 ingest 指令，AI 會徹底閱讀這份原始資料，提取關鍵資訊。
- 如果涉及已有的設備或技術概念，AI 會自動更新舊的 Wiki 頁面；如果是一個新概念，AI 會自動建立新頁面，並在整個 Wiki 中建立交叉引用（Wikilinks [[page]]）。
- 最後，AI 會自動在 wiki/index.md（地圖索引）與 wiki/log.md（變更日誌，採 append-only 追加）中留下足跡。

這意味著，人類負責輸入粗糙的原材料，AI 助理負責繁瑣的圖書館整理工作。知識庫的維護摩擦力降到了零。

實戰案例一：在傳統產業（設備管理）的落地

在極度依賴經驗與歷史故障紀錄的傳統重工業設備管理中，這套系統展現了驚人的威力。

以我最近處理的 K 號重型設備 故障為例：

1. 原始日誌的輸入 (`sources/`)

當設備在運作中發生自動降速跳脫時，我把現場人員對話、拆檢報告丟進 sources/。這是一堆非結構化的文本，記錄著「液壓氣缸控制單元 (HCU) 漏油」、「更換三組高壓管路後復原」、「空調加熱系統應急割管修復以備合規檢查」等零碎資訊。

2. AI 助理的彙整與沉澱 (`wiki/`)

當執行 ingest 之後，AI 助理在 wiki/ 下為我自動更新與建立了幾種類型的知識：

實體頁 [[EquipmentK]]（設備K）：自動記錄了該設備的基本規格（高壓控制系統、排氣與動力配置）以及該設備的維修歷史。
概念頁 [[HCUOilLeakage]]（控制單元漏油）：AI 將零散的報告提煉成高度專業的技術卡。它定義了重型動力系統中液壓氣缸控制單元與高壓管路的配置關係，分析了雙層高壓管洩漏觸發警報的原理，甚至提煉出了一條珍貴的排障決策指引：

「高壓管路逐一排查 vs. 一次性更換」的決策指引：當發生高壓燃油/液壓管路洩漏警報時，由於單一單元包含多組分支油管，逐一拆卸極其耗時。在急需恢復動力與運作時，應果斷採行「一次性更換整組管路新品」的策略，以配件成本換取寶貴的停機時間。

當下一次有另一處廠區（例如 S 號設備 [[EquipmentS]]）遇到類似警報時，我不需要再去檔案櫃或群組裡翻找「那時候設備 K 是怎麼修的」，只要在 Obsidian 輸入 [[HCUOil，當年的排障精華與決策指引就立刻呈現在眼前。

同樣的，當遇到起重設備鋼絲繩磨損斷股事件時，AI 自動幫我建立了 [[起重設備排纜維護]] 概念頁，記錄了「排纜滾筒表面局部凸起」的根本原因，防止未來發生類似事件。

實戰案例二：在數位副業 (YouTuber) 的自我迭代

而在我經營 YouTube 頻道與個人部落格的副業維度中，這套系統則扮演了「理性決策的煞車皮」。

在 YTB 知識庫中，我記錄了部落格 [[DigitalVineyard]] 作為服務頻道的核心定位，以及針對 AI 時代下，思考書籍導讀與電影哲學等選題方向的 [[頻道定位]] 筆記。

最有趣的一個例子，是我在 src-260709-obsidian-hugo-github-actions-automation 中記錄的「Obsidian 一鍵自動部署 Hugo」的技術嘗試。我寫好了詳細的 GitHub Actions 工作流 (YAML)，希望實現一鍵發布。

但在實際測試後，我在筆記中記錄了這段決策：

「在安裝相關 Git 同步插件後，發現很多自動化運作細節不會在前端顯示，導致查找部署錯誤時非常麻煩。評估後，決定維持現有的 IDE 手動 Git 工作流程，暫不配置自動化，因此已將該文章轉回為草稿 (draft: true) 狀態。」

這段看似「失敗」的技術折騰，被 LLM Wiki 忠實地沉澱在知識庫中。它不是沒用的垃圾資訊，而是我個人技術演進的決策歷史。

跨領域的化學反應：當鋼鐵與代碼相遇

當我用統一的 LLM Wiki 架構來整理這兩個領域時，我發現了一些意想不到的收穫：

重工業與新媒體的工程邏輯互通：處理廠區輔助設備（如冷卻系統壓力錶座裂開、緊急焊補）的現場調度，其本質上與定位 YouTube 頻道的流量瓶頸是高度一致的——都是「觀察異常 -> 尋找邊界條件 -> 做出最小成本的應急決策 -> 根本原因分析 (RCA)」。這種心智模型在知識庫中互相參照，讓我面對複雜問題時更加游刃有餘。
消除了「整理筆記」的心智負擔：前人種樹，後人乘涼。維護一個精美的 Wiki 是非常累人的。你需要手動更新 index 頁面，還要在 log 檔裡自己寫下變更。現在，我只要把原始的 Daily Log（如安全防護裝備檢修、合規證照申辦、頻道選題思考）隨手寫成一份 sources 檔案，AI 助理就會幫我做完剩下的一切。

結語：讓 AI 成為你的圖書館管理員

很多人使用 AI，只是把它當作一個隨問隨答的聊天機器人。但實際上，AI 最強大的能力在於理解非結構化文本，並將其關聯到已有的結構化知識體系中。

透過 Andrej Karpathy 的 LLM Wiki 模式，我的 Obsidian 數位花園不再只是一堆靜態的資料夾，而是一個有生命力、會隨著我的工作與副業同步增長、主動為我沉澱排障經驗與決策歷史的「第二大腦」。

如果你也深受資訊割裂、筆記整理摩擦力過大之苦，不妨也嘗試在你的數位花園中引入這位「AI 圖書館員」吧！

本文同步發表於個人部落格 Digital Vineyard。若你對傳統產業設備維護或 AI 輔助個人知識庫建構有興趣，歡迎在下方留言交流！

Engineer on Digital Vineyard

當硬核傳產工程遇上數位花園：我如何用 LLM Wiki 打造「傳統產業管理 × 新媒體副業」的高效雙軌知識庫

當硬核傳產工程遇上數位花園：我如何用 LLM Wiki 打造「傳統產業管理 × 新媒體副業」的高效雙軌知識庫

什麼是 LLM Wiki 模式？

實戰案例一：在傳統產業（設備管理）的落地

1. 原始日誌的輸入 (sources/)

2. AI 助理的彙整與沉澱 (wiki/)

實戰案例二：在數位副業 (YouTuber) 的自我迭代

跨領域的化學反應：當鋼鐵與代碼相遇

結語：讓 AI 成為你的圖書館管理員

1. 原始日誌的輸入 (`sources/`)

2. AI 助理的彙整與沉澱 (`wiki/`)