AI-MEN
AboutBlogGrowth KitAI BOSS CLUBConcierge

Workflow

從 LLM Wiki 到 iMe LLM Wiki：如何把原始素材編譯成可持續運作的 AI 知識系統

這篇文章示範如何把 LLM Wiki 的概念改編成 iMe LLM Wiki，並透過 raw、opcwiki、operation 三層結構，把原始素材編譯成可持續運作的 AI business memory。

Workflow

Editorial cover fallback

April 14, 2026

一、總覽：這件事是否可行？

答案是可行，而且比大多數人現在使用 AI 的方式更適合長期經營。

多數人使用 LLM 的方式是：

  • 上傳一批文件

  • 在需要時提問

  • 讓模型即時檢索、即時拼湊答案

這種方式可以快速得到回應，但也有明顯限制：

  • 每次提問都像重新開機

  • 前一次的整理不會自然沉澱成長期知識

  • 跨文件、跨主題的細緻綜合容易反覆重做

LLM Wiki 提出的關鍵觀點是另一種模式：不要把 AI 當成只會臨時回答問題的介面，而要讓它持續維護一套 wiki，作為原始資料與實際輸出之間的中介記憶層。

而 iMe LLM Wiki 則是在這個基礎上再往前一步，把它從「知識整理系統」改造成「One Person Company 的營運系統」。

可達成的結果是：

  • 將原始素材累積成可重用的 business memory

  • 將知識整理與市場輸出接起來

  • 讓每次發布後的回饋再回寫進系統

限制條件也很明確：

  • 需要一套固定的資料夾與命名規則

  • 需要讓 AI 有明確的 ingest、generate、observe workflow

  • 需要人持續提供素材與判斷優先級

二、核心模組地圖

模組 1 — Raw Sources

功能：

  • 保存原始輸入材料

  • 作為不可隨意改寫的 source of truth

前置需求：

  • 你要先有來源，例如文章、筆記、PDF、研究資料、創作草稿

在 iMe LLM Wiki 裡，這一層放在 raw/。

模組 2 — Compiled Wiki Memory

功能：

  • 把原始材料編譯成可持續更新的 wiki 條目

  • 保存當前信念、決策、流程、洞察與狀態

這一層不只是筆記區，而是系統真正的 operating memory。 在 iMe LLM Wiki 裡，這一層放在 opcwiki/。

模組 3 — Market-Facing Operation

功能：

  • 生成網站文章、頁面、社群內容

  • 承接 opcwiki 的記憶，對外輸出具體內容

這一層對應 operation/。

它的重要性在於：內容不是從零開始瞎寫，而是從已經整理過的 business memory 生成。

三、完整工作流程

完整流程如下：

  1. 原始輸入進入 raw

  2. Codex 先 ingest 並整理意思

  3. 將可持久的條目寫入 opcwiki

  4. 從 opcwiki 生成網站或社群內容到 operation

  5. 對外發布

  6. 觀察市場回饋，再回寫到 opcwiki

這條 pipeline 是 LLM Wiki 到 iMe LLM Wiki 最大的改編點。

原始 LLM Wiki 重點在於：

  • 持久化 wiki

  • 持續 ingest

  • 查詢結果也能回寫

iMe LLM Wiki 則加上：

  • 當前目標狀態

  • 營運決策頁

  • 市場輸出層

  • 發布後回寫閉環

也就是從 knowledge system 變成 execution system。

四、逐步建構

第 1 步 — 先定義三層結構

第一步不是叫 AI 直接生成內容，而是先把系統拆成三層：

  • raw/：原始素材

  • opcwiki/：編譯後的記憶

  • operation/：對市場輸出的內容

這樣做的好處是，你不會把「資料」、「理解」、「輸出」混在一起。

例如一篇原始文章進來後，不應該直接變成首頁文案；它應該先變成：

  • 一條新的 system belief

  • 一個 decision

  • 或一個 reusable playbook

然後再被用來生成網站內容。

第 2 步 — 把 source 匯入成 wiki 條目

這一步是整個系統最重要的地方。

以這次實驗為例，我們把 LLM Wiki.md 放進 sources，然後讓 Codex 執行 ingest。 但 ingest 的目標不是產出一份摘要，而是回答四件事：

  • 這份 source 帶來了什麼新的觀點？

  • 這個觀點應該落在哪一類 wiki 頁？

  • 它會改變哪些現有信念或流程？

  • 它接下來會影響什麼行動？

結果不是一頁 summary，而是三頁不同功能的條目：

  1. wiki-operating-model.md

把「wiki 是 compiled memory」寫成 foundation。

  1. adopt-compiled-wiki-memory

把這個方法寫成 decision。

  1. source-ingest-playbook.md

把這種處理方式寫成可重複執行的 SOP。

這就是「AI 編譯」的意思： 不是轉述來源，而是把來源拆成可運作的系統部件。

第 3 步 — 再把 wiki memory 生成成市場內容

當 opcwiki/ 已經有穩定條目後，網站文章、社群貼文、首頁文案都可以從這些頁面生成，而不是每次重讀原始來源。

這樣的優勢有三個：

  • 內容輸出更一致

  • 重複性的思考成本更低

  • 每一篇文章都能追溯到來源與決策

這篇文章本身就是這個流程的示範：

  • source 來自 LLM Wiki.md

  • wiki memory 已經被編譯進 opcwiki/

  • 現在再由 Codex 從這些條目生成 blog 草稿

這等於證明了 iMe LLM Wiki 不是理論，而是已經可以實作的工作流。

五、風險與限制

  • 系統一開始過度設計 嚴重度：中。若分類太複雜，維護成本會快速上升。

  • AI 只做摘要，不做編譯 嚴重度：高。這會讓 wiki 退化成普通筆記庫。

  • 發布後沒有回寫 嚴重度：高。沒有市場回饋，系統就不會真正進化。

  • foundation 與 state 混在一起 嚴重度：中。長期信念與短期任務不分，容易造成混亂。

  • 路徑與命名不一致 嚴重度：中。Obsidian 和 agent 容易迷路。

六、成本估算

  • 系統骨架建立：低到中

  • 初期規則整理：中

  • 單次 source ingest：低

  • 長期維護成本：低於人工維護 wiki

  • 最大成本：founder 必須持續提供高品質素材與判斷

七、最佳實踐

建議：

  • 一次 ingest 一份重要 source，先讓 wiki 成長得乾淨

  • 強迫每次 ingest 至少更新一個 durable page

  • 把好的回答、比較、分析也寫回 wiki

  • 每次發布後都補 log、timeline、insight 或 experience

避免：

  • 把 raw source 直接當最終文案

  • 把所有東西都塞進同一頁 summary

  • 只生成內容，不維護 wiki

  • 讓 decision、insight、playbook 沒有明確邊界

八、快速起步

  1. 建立三層結構：raw / opcwiki / operation

  2. 把第一份重要 source 放進 raw/data/sources/

  3. 叫 Codex 執行 ingest，不只摘要，而是更新 foundation、decision、playbook、log 與 next-actions

九、結論

真正重要的不是讓 AI 幫你回答更多問題， 而是讓 AI 幫你把知識持續編譯成可以運作的系統。

LLM Wiki 提供了 persistent wiki 的核心觀念。 iMe LLM Wiki 則把這個觀念推進到更具體的商業現場：從原始素材、到操作記憶、到市場輸出，再到回寫學習，形成一個真正會成長的閉環。

如果你想讓 Codex 不只是幫你寫字，而是幫你經營一套會累積、會進化的 AI-native business memory，那麼這套方法值得你現在就開始實作。

從 LLM Wiki 到 iMe LLM Wiki：把 AI 知識系統變成可運作的 OPC 工作流 | AI-Men