TL;DR

• 我把自家產品 iknow.dev 的導覽 AI「iknow Navigator」，從產品的實際程式碼開始培養。83 筆知識、15 個對話驗證題，總共花了 2 小時。
• 但重點在這裡。其實在做出 83 筆知識的4 天後，我新增了一個功能（★重要標記），結果剛寫好的知識立刻過時了。只要產品持續變動，知識就會腐壞（docs drift）。這篇文章的核心不是「做得快」，而是把程式碼當作正本（Single Source of Truth），建立能追上腐壞速度的機制。
• 製作時唯一的鐵則是：「不要讓它憑空想像，要根據實際程式碼來寫」。LLM 不知道未公開產品，但只要手邊有程式碼這個“正解”，就能把內容寫成有根據、可驗證的知識，而不是猜測。

做出來的成果 → iknow Navigator（免登入，現在就能玩）

※ 作者有參與知識庫服務 iknow.dev 的開發。本文是開發者親自做 dogfooding 的紀錄。不是那種一味歌功頌德的成功故事，而是誠實寫出哪些地方有效、哪些地方仍需要人工介入。

引起動機：文件追不上產品的腳步

前陣子，我讀了這篇文章：
“育つ”ナレッジ基盤「LLM Wiki」とは？RAGとの違いをイラスト付きで整理してみた

這是 Karpathy 提倡的「LLM Wiki」概念——不是像 RAG 那樣每次都去搜尋原始資料，而是培養一個由 LLM 編輯、維護的 活的知識庫。

我第一時間想到的，就是我們眼前的問題。開發中的產品天天在變，但文件與 onboarding 卻跟不上。這就是所謂的 docs drift。README、FAQ，常常不知不覺就開始講「舊版規格」了。文件一寫完就慢慢腐化，這種感覺大概很多人都很熟。

那如果把負責說明產品的導覽角色，當成活的知識來培養，並持續與產品變化同步，會怎麼樣？這篇文章就是這個小實驗的紀錄。

要做的東西：產品導覽 AI「iknow Navigator」

我要培養的是一個能替第一次接觸 iknow.dev 的人，導覽產品概覽、術語、權限、知識的建立與營運、聊天提問、MCP 串接（Cursor / Claude）、FAQ 與疑難排解等內容的 官方導覽角色。它不需要登入、匿名也能試用，某種程度上就是產品的「門面」。

順帶一提，在 iknow.dev 裡，會繼承專家領域知識（知識）並回答問題的 AI agent，我們稱為 iknow。iknow Navigator 則是把這個機制用在 iknow.dev 自己的導覽上。也就是說，這是 產品內部的 AI agent。

這裡有一個很關鍵的前提：

如果是一般公開知識，LLM 在預訓練階段就已經“知道”了。但 iknow.dev 是未公開產品，所以 LLM 什麼都不知道。

因此，即使你問它「下一步該學什麼」，它也不會回你正確的產品規格；回來的只會是看似合理的想像，也就是幻覺（hallucination）。如果在這裡停下來，就會做出那種「大致上對，但細節亂講」的文件。

不過這次我們有個優勢。因為是自家產品，最強的第一手資料就在手上——Git repository 裡的實際程式碼。路由定義、controller、model……這些就是產品本身的「正解」。Cursor 可以透過 MCP / 編輯器直接讀這個 repository，所以我們可以不是讓它憑空寫，而是根據實際程式碼來寫。而且，之後還能隨時把寫好的知識跟程式碼對照驗證。

這次主題會變成「從實際程式碼生成」，正是因為這個前提。換句話說，只要抓住這一點，其實沒有做什麼特別神奇的事。

使用工具與整體架構

角色工具LLM agent（撰寫與整理知識）Cursor / Claude知識庫（累積、搜尋、公開）iknow.deviknow.dev 是一個可以累積知識，並以帶有人設的 agent 形式公開的服務。它支援 MCP，因此可以從 Cursor、Claude 這類 LLM agent 直接讀寫知識。對照 LLM Wiki 的三層架構，這次會變成這樣：

LLM Wiki 的層這次的配置Raw sources（第一手資料）Git repository 的實際程式碼・實際畫面／行為The Wiki（編輯後的知識）iknow.dev 上的 iknow Navigator 知識群The Schema（規範・工作流程）給 LLM 的培養指示（後述 prompt）運作流程也直接借用了 LLM Wiki 的 Ingest（匯入）→ Query（提問）→ Lint（同步）。只是這次的 Lint 不只有「消除內部矛盾」，還包含 「與產品實際行為同步」。這是這次最大的學習。 詳細內容會在 Step 3 說明。

這次的前提

• 對象：自家未公開的 Web 產品 1 個（Laravel + Vue 架構）。因為是內部產品，屬於「LLM 事前不知道」的典型案例。
• 第一手資料：Git repository 的實際程式碼（路由定義、controller、model）與規格文件。
• 規模：從實際程式碼產生 66 筆知識，加上 AI 提案的 17 筆，共 83 筆知識（不含目錄頁）。
• 耗時：初稿製作的實際工作時間約 2 小時。後續的整理與同步（Lint）則會持續進行。
• 前置技能：不需要特別技能。只要把 Cursor / Claude 跟 MCP 接起來，之後就是自然語言指令。

準備：將 iknow MCP 登錄到 Cursor

為了讓 LLM 幫忙工作，先從 iknow.dev 的帳號設定把它安裝到 Cursor。只要點選「安裝到 Cursor」，再照著指示操作即可，幾分鐘就完成。

這樣一來，LLM agent 就能透過 MCP 讀寫 iknow.dev 的知識了。準備完成。

Step 1. 先做目錄

第一步是先建立整體地圖，也就是目錄。iknow.dev 有一個小規則：把「No.0 當作目錄（index.md）來運用」。把前提、整體結構、不同讀者的快速導覽放在這裡，之後的頁面就會掛在這張地圖下面。也就是說，比起直接寫單篇內容，先做出骨架型的目錄比較重要。

不過，LLM 並不知道未公開產品的結構。因此我讓 Claude 讀 repository，根據實際存在的畫面、路由、功能反推來設計目錄。實際下的指示只有這樣：

我想根據 iknow.dev 的目錄來建立知識。
請確認原始碼，並建立合理的目錄。

先把它產出的骨架人工修正後，註冊成 No.0（index.md）。最上層是目錄，下面分出「畫面與知識對照」、「角色別指南」、「Web 與 MCP 的使用方式」……等導覽路線。因為先有目錄，後面的撰寫與 Lint 才能一項一項對應到明確的頁面，之後也不會混亂。

Step 2. 生成知識

接著依照 Step 1 做好的目錄（index.md），整理第一手資料（原始碼）來建立知識。

我想依照 iknow-navigator 的目錄建立 iknow.dev 的知識。
請確認原始碼，並為各項目建立知識。
這個知識庫是給終端使用者看的。
請正確整理終端使用者可使用的功能。
相關知識不要寫在本文中，而是指定相關知識。

建議用 Cursor 來做知識建構。從原始碼產出了 66 筆知識。大約 2 小時，就有整套「產品說明書」的初稿成形。

產出的知識可以直接在 iknow.dev 上閱讀。

我還想再把它補完整一些，所以這次改成讓它提出建議。

請提出一些適合用來導覽 iknow.dev 服務的知識。

這是 Cursor 的提案。

我請它「全部加進去」，結果又新增了 17 筆知識。前面的 66 筆是根據實際程式碼的“說明”，這 17 筆則是補上「第一次使用者容易卡住的地方」的“貼心提醒”。有種補上人類容易漏掉部分的感覺。這樣總數就變成 83 筆了。

所有變更紀錄都會保留下來。如果修改錯了，也能回到修改前。AI 敢大膽寫也不可怕，就是因為有這個「隨時可以回復」的機制。

Step 3. 教育知識（這才是重點）

最後要做的是，把預想的問題丟給它，確認它是不是能穩定給出好回答（對話驗證）。做法很單純，就是把「第一次接觸的人可能會問的問題」整理成 15 題，逐一丟給它。這次的結果是 13 題完全沒問題，2 題有點可惜。像是「未登入可以做什麼？」、「MCP 要怎麼串接？」這些問題，都能帶著根據好好回答。

問題出在那兩題「有點可惜」的地方。

內容沒有錯，但不是我真正想表達的。這種「事實正確，但作為導覽不夠理想」的情況，其實最麻煩。下面是其中一題修正時的例子，直接請 Cursor 改。

當權限設定很麻煩的時候，
請把「使用 iknow 設定的構成繼承」這件事加入知識中。

這時候又是實際程式碼派上用場。因為判斷的「正解」就在 repository 裡，所以可以把知識跟原始碼對照來驗證。而且當程式碼變動時，只要從差異點（變更的路由、規格）出發，重新檢查受影響的知識就好。Cursor 會一邊確認原始碼，一邊照指示更新知識。結果就是能回傳我預期的答案。對，就是這個導覽感。

這裡我想老實說一件事。Lint 有兩層，其中一層能自動化，另一層仍然需要人工。

• ① 內部矛盾（頁面之間互相打架、舊說法）→ 這一層 LLM 幾乎可以幫你大量清掉。
• ② 與實際程式碼／實際行為不一致 → 這就只能由知道什麼才是正解的人，拿著程式碼一一核對。只有做內部 Lint，無法抓到和外部世界（也就是實作）之間的落差。

② 其實更棘手。另一題「有點可惜」的答案，正好就是很好的例子。

Q. 如果一個知識超過 80,000 token 會怎樣？

Navigator 的回答是「會因為 token 超過而被拆分」。乍看之下很合理，但確認實作後，發現其實 會依照路徑而有不同行為。匯入時會自動拆分，但從知識編輯器或 MCP 儲存時，超過就會報錯，無法儲存。把它一概說成「會拆分」是不精確的。

這種落差光靠想像絕對看不出來。「會拆分」和「會報錯」都很像合理答案。真正的答案只存在於程式碼裡。 所以我去確認實作，把知識改成「依路徑不同而有不同行為」。跟①那種修正措辭不同，這個問題是 不打開程式碼，連對錯都沒辦法判斷。這就是需要人工核對的②。

腐化得更快——83 筆在 4 天後開始變舊

83 筆知識是在 6/24 培養完成的。4 天後的 6/28，我在知識列表加上了「★重要標記」功能。它只是個小功能：讓特別重要的知識可以一鍵醒目顯示。

就在那一瞬間，剛寫好的 83 筆知識裡，開始有介紹列表操作的內容過時了。更麻煩的是，它跟原本的「唯讀鎖定」很容易混淆。★ 只是標記，不會限制編輯、刪除、或從 MCP 改寫。但如果知識沒更新，Navigator 就可能誤導使用者，說成「加上重要標記就會受到保護」。一個小小的 UI 新增，就足以造成語意誤解——這就是 docs drift 可怕的地方。以下是我在確認實作後修正過的知識。「和唯讀的差異」這段，就是因為真的容易混淆才加上的。

順帶一提，這篇文章的初稿其實在 6/26 就寫完了。也就是說，這篇高喊著「腐化」的文章，自己在公開前就已經先腐化過一次。

這次因為是我本人新增的功能，所以當場就發現了。但一般團隊裡，新增功能的人和寫文件的人通常不是同一個人。這種落差沒人通報，就會默默被放著不管。所以不能只靠某個人「剛好想到」，而是要建立以程式碼差異為起點、同步更新知識的流程。

這次修正的痕跡，也留在 Claude 寫的變更紀錄裡（6/28 17:49）。從紀錄看，6/25 也有一些修正，那是建立時漏掉的驗證，後來再配合實際 UI 修正。這次的 ★ 則是產品那邊改變了，而知識沒有跟上——也就是貨真價實的 drift。

LLM Wiki 的文章把「Lint」形容成定期的健康檢查，但在自家產品場景裡，最大的優勢是 手上就有一個確切的基準——程式碼。要對抗 docs drift，意思就是 「把程式碼當正本（Single Source of Truth），把知識同步成差異更新的流程制度化」。Ingest（匯入）也許只做一次，但這個 Lint（也就是與程式碼同步）只要產品還活著，就得持續做下去。這不是魔法，是營運流程。

完成：iknow Navigator

最後做出來的，就是產品導覽角色 iknow Navigator。在 iknow.dev 裡，培養好的 agent 可以透過 URL 或 QR code 分享。

實作後的學習

學習內容說明非公開產品不能讓它憑空猜LLM 不知道產品；把 repository 的實際程式碼當第一手資料，並讓它寫出「未確認就是未確認」的內容自家產品的優勢是手上有正解因為能根據實際程式碼撰寫，之後又能對照程式碼驗證，所以能做出正確的知識Lint 有兩層① 內部矛盾＝可由 LLM 大幅消除 ② 實際行為／與程式碼的落差＝仍需人工確認（核對）docs drift 對策＝把同步流程制度化把程式碼當正本，並根據變更差異重新檢查知識，否則一定又會變舊沒有什麼華麗結論，反而很樸素。但能把「產品一變，就用差異去修知識」變成日常流程，這就是這次最大的收穫。

在你的場域也試試：把 onboarding 換成「培養導覽角色」

重點其實不在工具，而在想法。只要你手上有自己的 LLM（像 Cursor / Claude）和想要說明的專案 repository，就可以用同樣的模式：不要讓它憑空想像，而是根據第一手資料撰寫，並用變更差異持續修正。 如果你想一次做到知識累積、公開與分享，那麼這次用到的 iknow.dev 也是一個選項（建立 agent → 註冊 MCP → 讀第一手資料後，從「幫我整理 ○○」開始）。

而我認為最有用的，是去培養一個屬於自己團隊或產品的“導覽角色”。內部 Wiki 跟不上、onboarding 每次都靠口頭、規格只存在腦中——這類情況越多，持續與產品同步的導覽 AI 就越有價值。與其把資料全丟進 RAG 倉庫，不如把它當成圖書館來編輯、整理，並同步產品更新。

這還只是剛開始的小實驗，之後一定也會遇到不順的地方。不過確實有做出成效，所以如果你也想在自己的領域試試看，歡迎動手做做看。若有心得，或「我們這邊是這樣做的」這類分享，我也很期待聽到。

原文出處：https://qiita.com/yamada-iknow/items/5e5ec4d5e96b12fbc75c