我們很容易累積資料，卻不一定容易在需要時找到它。看到值得參考的文章就存起來，研究工具時留下幾份筆記，專案進行中再補上文件與討論紀錄。過一陣子，真正要做決定時，往往只記得「之前看過」，卻想不起來存在哪裡，也不確定不同資料之間的說法是否一致。

LLM Wiki Cloud（簡稱 LWC）想接起這段落差：把分散的來源整理成可以閱讀、搜尋與互相連結的 Wiki，讓你能從一個問題找到相關知識，也能沿著來源回頭查證。這份知識不只放在網頁上供人閱讀，也能透過連線提供給 AI agent，在往後的工作與對話中繼續使用。

收藏之後，還需要一次整理

假設你正在研究某個開發工具，手上有官方文件、自己的安裝筆記，還有一篇分析升級限制的文章。三份資料可能都談到設定方式，但版本、環境與適用條件不完全相同。如果只是收進同一個資料夾，下次問「我們現在這個環境能不能升級？」時，仍得一份一份翻出來比較。

LWC 的做法是保留來源，再由整理流程產生相關的知識條目。一篇來源可以談到多個主題，同一個主題也可以連回不同來源。你可以從問題開始，找到整理後的內容，再決定要深入閱讀哪一份文件，不必先記得原始檔名或文章標題。

這個例子是示意情境。資料裡如果沒有交代版本或環境，整理後也不應把未知的部分當成已確認的條件。

flowchart TB
    accTitle: 從分散資料到可查詢的 Wiki
    accDescr: 使用者把原始資料加入專案，執行整理與編譯後產生來源與知識條目，再由搜尋或問答找到內容並回看來源。
    A["你選擇的文件、筆記與網頁"] --> B["加入一個 LWC 專案"]
    B --> C["執行整理與編譯流程"]
    C --> D["來源：保留內容脈絡"]
    C --> E["條目：整理主題與關聯"]
    D --> F["搜尋知識，或提出問題"]
    E --> F
    F --> G["閱讀結果，沿引用回看來源"]

圖一：上傳只是把資料放進專案。完成整理與發布後，才有新的知識內容可供搜尋，不把「檔案已上傳」當成「知識已經可查」。

用專案區分資料，也區分你想問的問題

LWC 以 Project 管理知識。你可以把一組相關文件放進同一個專案，例如工作上的技術研究、某個產品的操作資料，或長期累積的生活筆記。搜尋與閱讀都在目前選定的專案範圍內進行，避免把不同用途的資料混在一起。

加入資料可以從 Markdown 檔案開始，也能擷取網頁內容，先查看預覽，再決定是否儲存。對於需要登入、付費或受網站限制的頁面，擷取可能不成功，仍可能需要你自行準備內容。LWC 不會因為知道一個網址，就自動取得原本沒有的存取權限。

如果資料已經在本機整理，也有 CLI 可以把 Wiki 的 raw/ 素材資料夾同步到雲端。這不代表要搬走整個筆記庫，也不會讀取其他資料夾；同步完成後，仍要執行生成流程，讓新資料進入可查詢的知識內容。

從找文章，變成帶著問題找依據

整理完成後，你可以直接瀏覽來源與條目，也可以從首頁提出問題。LWC 提供 Wiki 與完整兩種查詢模式：前者用來搜尋專案裡的知識內容，後者進一步產生綜合回答。需要快速找到那份說明時，可以先搜尋；需要把多份資料的重點整理在一起時，再使用完整回答。

沿用開發工具的例子，與其先猜資料存在哪一篇文章，不如直接問：「這個工具升級時，有哪些版本與環境限制需要先確認？」找到結果後，再從引用或來源內容核對它適用的條件。如果知識庫沒有足夠資料，回答也不應被當成已經查證的結論。

flowchart LR
    accTitle: 需要資料時的兩種找法
    accDescr: 原本先猜檔名再逐篇比對，使用 LWC 後先在指定專案提出問題，再沿結果和來源確認。
    subgraph Before["原本：先想起資料在哪裡"]
        direction TB
        B1["我記得之前讀過"] --> B2["猜檔名、書籤或文章標題"]
        B2 --> B3["逐篇閱讀，比對版本與條件"]
    end
    subgraph After["使用 LWC：從問題開始"]
        direction TB
        A1["選擇對應的知識專案"] --> A2["搜尋主題，或提出完整問題"]
        A2 --> A3["閱讀結果，回看引用與來源"]
    end
    Before ~~~ After

圖二：搜尋幫你縮短找到相關資料的路徑，來源與引用則讓你有地方核對答案。整理與問答都不會取代資料本身的可信度。

同一份資料，可以依你的重點整理

一份資料值不值得留下某個細節，常常取決於你想拿它做什麼。整理餐廳筆記的人，可能特別在意停車、兒童座椅與走道空間；整理開發文件的人，則可能更在意版本限制、設定步驟與已知問題。

LWC 的 Profile 讓你用自己的文字描述專案的整理與搜尋偏好，再查看系統如何理解，以及目前真正生效的設定。它的用途是讓整理流程知道應該留意什麼，不是替資料補上沒有出現的事實。例如來源沒有說明嬰兒車能否通行，不能因為餐廳有兒童座椅，就推論一定適合推車進入。

這也不是儲存設定後，所有舊文章立刻重寫。新的需求要套用到先前編譯的條目內容，需要重新生成；只是修改 Profile，不等於既有 Wiki 已經全部更新。網頁會分開呈現設定與處理狀態，讓你知道目前使用的是哪個結果。

讓 Bot 使用你累積的知識，不必每次重新貼資料

知識庫如果只能由人打開閱讀，仍然少了一段。當你請 AI agent 協助工作時，往往又要把相同背景貼進新對話：專案之前採用哪個做法、某個工具有什麼限制、過去留下哪些注意事項。

我現在使用的 Bot，就是以 LWC 作為知識庫的輔助，讓平常累積的文件與筆記，也能成為 Bot 協助我處理問題時的參考。

LWC 提供 MCP 連線，讓支援的 AI client 在授權範圍內查詢專案知識。MCP 是讓 AI client 使用外部工具與資料的通訊協定；例如使用 Hermes Agent 時，可以讓 agent 先查詢指定的 LWC 專案，再結合找到的內容處理原本的問題，而不是只靠聊天記憶猜測背景。

sequenceDiagram
    accTitle: AI agent 如何使用專案知識
    accDescr: 使用者提出工作，已授權的 agent 先查 LWC 專案，取得結果與來源後，結合證據回應原本的需求。
    actor U as 你
    participant A as 已連線的 AI agent
    participant W as LWC 專案知識庫
    U->>A: 請依我們的既有資料分析這個問題
    A->>W: 在授權的專案內查詢
    W-->>A: 回傳相關結果與來源資訊
    A-->>U: 結合查到的依據回答原問題
    Note over A,W: 有連線不等於每次自動查詢；實際使用依 client 與 agent 的操作指示

圖三：LWC 提供可查詢的知識，agent 負責把找到的依據用回原本的任務。若沒有找到足夠證據，也應如實說明，而不是把工具呼叫成功當成答案可靠。

你可以把期待說清楚，例如：「處理這個專案的問題前，先查 LWC 裡的相關資料，指出使用的來源；找不到的部分請直接說明。」至於連線方式與授權範圍，依 LWC 提供的設定說明與實際使用的 client 操作，不需要把私密金鑰貼進對話。

從一組你確實會再用到的資料開始

不必一開始就把所有收藏都丟進知識庫。先選一個主題，放入幾份彼此相關、而且你確實會再次使用的資料，完成整理後，用平常真的會問的問題試查一次。看看是否能找到需要的內容、引用能否幫助核對，再逐步增加資料與調整偏好。

目前 LLM Wiki Cloud 正式站仍處於受邀測試階段。你可以從登入頁的「試用 Demo」先體驗搜尋、來源與條目閱讀；Demo 使用預先準備的專案資料，部分資料寫入與管理操作不開放，不能當成自己的私人工作區。若想參與測試，可以依站內公告聯絡 Rayer。

整理資料的目的，不只是多存一份副本，而是讓它在下一次有問題、需要判斷或請 AI 協助時，真的能派上用場。LWC 想提供的，就是這個能持續累積，也能持續使用的知識工作區。