昨天，我把查通知的方法寫成 Skill。查法留下來了，但換個對話、換張工單，Claude 去哪裡取得這套系統的背景？

通知由哪個服務送？哪裡找接收端紀錄？為什麼不能直接重送？這些答案，有些在程式裡，有些在設計文件裡，還有一些留在之前的對話中。

每次換個對話，都要我重新找資料、解釋一遍，那留下的只是查法，工作還是離不開我。

這是第三幕的第二步，把一個人的做事能力交給團隊：Day 17 留下查法，今天留下查這個系統要先知道的背景。這次我想留下的，是給 Claude 取用的專案知識：現在怎麼運作、根據哪份來源、哪些事情還不能決定。下一個任務進來，它可以先找相關知識，再核對當次資料。

Karpathy 把這類做法叫 LLM Wiki：供 AI 查找、取用，並在查證後持續修訂的外部知識庫。本篇借這個說法，先用 Markdown 實作：Claude 提出差異，我核對後更新檔案，再換新對話確認它能否取用。

我沿用前面的訂單服務，準備一張教學工單：

取消訂單後沒有收到通知。API 回 200，Log 也有 notify_sent。現在需要補送嗎？

要讓它查這張工單，我先整理通知知識。結果第一個需要修正的地方，就在我剛寫好的 Wiki 裡。

LLM Wiki 幫的是什麼？讓 Claude 取得這次需要的 Context

Context（上下文）是 Claude 這一輪實際取得的資訊。 Wiki 放在硬碟上還不算；讀到相關頁面，才有了這次查核的背景，也不會因此永久學會專案知識。

以這張工單來說，三種資訊各有用途：

沒有 Wiki，Claude 仍能讀程式與搜尋文件，但得重新拼出背景。有了整理過的知識，它就多了一個查詢入口。例如讀取本篇的查詢頁後，可以取得 service_name 與 notification-receiver 這兩個具體線索，再去找接收端紀錄。這是使用方式的差異，是否省時仍要量測。

Skill 留下怎麼做；LLM Wiki 留下做這件事需要知道什麼，以及去哪裡核對依據。 今天有沒有送達，仍要查今天的資料。

Anthropic 的 Context Engineering 工程文章介紹按需載入背景。本篇就從「先讀索引、選知識頁、回查來源」開始；相關研究放在文末，實際效果看接下來的查核。

我用哪一套？用 Markdown 建立給 Claude 的知識入口

沿用這個思路，我把來源與整理後的知識分開保存。這次沒有架 Wiki 網站、資料庫或搜尋服務，就是專案裡的一個 wiki/ 資料夾，讓 Claude Code 直接讀檔。

檔案各自負責一件事：

最小版本可以先建三份檔案：

wiki/INDEX.md          連到各個知識頁
wiki/notification.md   取消訂單後，通知怎麼送
wiki/changes.md        改過哪一句，為什麼改

本篇的教學包另有 log-query.md 保存查詢背景；後面遇到補送建議的問題時，再加入使用條件頁。先看完整的使用方式：

任務進來 → 找相關知識 → 核對來源與當次資料 → 提出分析與知識修訂 → 人確認後保存 → 下一次取用。

本次實跑由 Claude 唯讀查核、作者更新檔案，再換新對話取用，沒有讓它自動寫回 Wiki。

第一頁要寫什麼？先回答一個常被問的問題

我先寫「取消訂單後，通知怎麼送」。下面是修訂後的精簡範本，存成 wiki/notification.md。看「來源」和「還不能決定」：接手者才能知道去哪裡核對、哪一步需要停下來問。

# 訂單取消後，通知怎麼送？
適用版本：delivery-hardening-local-r2

一般模式：取消 API → 佇列 → 背景工作 → 接收端。
sync_notify 模式：取消 API 直接呼叫 SendOnce。
notify_sent 只證明發送端看到 HTTP 成功；接收端結果另查。

來源：[通知實作](../sources/Program.cs)，查 SendOnce、notify_sent。
還不能決定：人工補送的方法、去重規則與授權。

再到 INDEX.md 加上「查通知流程 → notification.md」的 Markdown 連結。下次就能請 Claude 從索引選頁面，再沿來源查程式。

sources/ 與 wiki/ 並排，保存這次核對的程式副本。用在自己的 repo，來源連到實際程式位置即可，記下核對版本。

在 Claude Code 裡怎麼用？從同一個資料夾開始

在包含 wiki/ 與來源程式的資料夾開終端機。下面這行的 --tools 選出可用的內建工具，--allowedTools 允許讀取操作：

claude --tools Read,Grep,Glob --allowedTools Read,Grep,Glob

這樣 Claude 可以讀、找與搜尋檔案。本次實跑另外停用了 MCP；自己的環境若有外部工具，也要檢查權限，提示詞本身不會限制工具。

第一次先查知識本身，貼上這段提示。看第二行：要求附來源位置，才能回頭核對修改建議。

從 wiki/INDEX.md 找到通知相關頁面，再核對來源程式。
列出文件與程式不一致的地方，每項附檔案與位置。
提出建議修改文字，先不要修改檔案。
找不到來源的內容列為待確認，不要自行補成系統規則。

我實跑時（9 回合、29 秒、US$0.089），Claude 先讀 wiki/INDEX.md 與通知頁，再讀 Program.cs。結果第一個需要改的，竟然是我才整理好的 Wiki。

我寫漏了，怎麼更新才不會下次繼續錯？

原本的通知頁寫著：

notify_sent 由 worker 在 HTTP 回應成功後寫入。

Claude 指出，啟用 sync_notify 時，通知由 API 請求路徑的 SendOnce 送出，也會寫這個事件。

我回到已公開的 Program.cs 核對。連結固定到已核對的版本，與本篇來源副本統一換行後相同。下面節錄第 85–88 行，只將最後一個網址參數縮成 ...。看 if：同步模式直接呼叫送出方法，並不經過背景工作。

if (faults.SyncNotify)
    await NotificationWorker.SendOnce(n, metrics, log, ...);
else
    await channel.Writer.WriteAsync(n);

SendOnce 與背景工作 都會在 HTTP 成功後寫 notify_sent。差別看圖：同步模式走下方那條路，事件多帶 sync=true。原本 Wiki 只寫上方那條，接手者就可能查錯位置。

sync_notify 是教學服務的故障注入設定，不是正式環境的預設模式。

核對後，我更新通知頁。下面 - 是改前、+ 是改後；看第二行新增的同步模式，它決定接手者該查哪個位置：

- notify_sent 由 worker 在 HTTP 回應成功後寫入。
+ 一般模式由 worker 寫入；sync_notify 模式由 SendOnce 寫入，帶 sync=true。
+ 兩者都只證明發送端觀察到 HTTP 成功；接收端結果需另查相同通知 ID。

changes.md 留下漏寫原因與三個核對位置：85–88 行是 API 分流，222 行是同步路徑的成功紀錄，257–260 行是背景工作寫成功紀錄的位置。下次任一條路改了，就回頭檢查這頁。

接著換新對話，避免 Claude 只是沿用剛才聊天的答案。它先讀索引、通知頁與程式，回覆的這段原文我保留下來：

「notify_sent 只由 worker 寫入」
判定：修訂（已修）。
理由：sync_notify 時由 SendOnce 寫入，並帶 sync=true。
範圍：僅限故障注入設定。

這份回答另外保留了一個缺口：缺少獨立 VERSION 檔，不能驗證部署版本；頁上的版本名來自程式核對，不是獨立 VERSION 檔的佐證。

這輪留下了可回查的修改，下一張工單才開始使用它。

換張工單，留下的知識用得上嗎？

接著回到開頭那張「取消後沒收到通知」的工單。這次除了問題，也提供訂單 ID、通知 ID、時間窗與一筆帶 sync=true 的發送端事件。工單與事件都是教學輸入，不是正式事故紀錄。

這次交給 Claude 的任務很直接：讀工單，從 wiki/INDEX.md 找相關頁面，核對程式後交回「已確認、缺件、下一步查詢與需要誰決定」，每項附來源。

先看「沒加使用條件頁」的第一次回答。它找到同步送出的路徑，卻多給了一句操作建議：

補送時要沿用同一個 notification_id，但接收端是否去重沒有來源可證，因此不能保證不重複通知。

這句我沒有接受。程式內的自動重試沿用同一個通知，不代表人工補送也應採相同規則；接收端怎麼去重、誰能授權，都還沒有資料。

我另外加入 applicability.md，也就是「這些知識在什麼情況下能用」。內容不是另一套框架，而是把剛踩到的缺口寫下來：發送端成功不能推出使用者收到；重複取消不是補送入口；人工補送要先確認方法、去重與授權。再由 INDEX.md 連到這頁。

加上這頁的第一份回答寫的是：

目前不可以。沒有補送 API、去重契約或授權，補送可能造成重複通知。

實際工具軌跡留下 Read → wiki/applicability.md，之後是 Grep → Program.cs。我先確認它取得新頁，再逐份核對回答，不能只看到「讀過」就算成功。

我用同樣的工單、事件、程式、提示與工具設定，比較加頁面前後的回答。模型都是 Sonnet 5.5，新對話各跑三次（每次 9–11 回合、約 18–22 秒、US$0.05–0.08），後兩組是在第一次看到差異後追加的查核。

六份回答都沒有授權當下補送。第一次若只看前後兩份，我很容易寫成「新增一頁就改善了」。重跑卻發現，原本的 Wiki 也有兩次保留缺口。我撤回的是改善效果的推論，不是把這頁刪掉。 三次只支持這六份回答的觀察，不能估成功率。

所以這頁的價值，是留下共同判準，不是保證 Claude 再也不會多說一句。 下一個人審查回答，可以依相同條件核對，不必猜我當初為什麼退回。完整回答與重跑方式保留在附件。

頁面一多，維護者怎麼確認關係沒跑掉？

Claude 沿索引查知識；維護的人則要看懂頁面之間的關係對不對。我用 Claude Code 跑 Understand Anything，把這份教學 Wiki 畫成關係圖（15 節點、20 關係，下圖取主幹）。

以 Claude Code 跑 Understand Anything 產生；索引分類到各頁、頁面來源回指程式，約束與角色邊另標。

這張圖最值得看的，不是它畫了什麼，而是它沒有亂連什麼：它沒有把「這些 Wiki 由誰寫」指向 Claude。 事實是作者核對來源、接受修訂，Claude 只負責指出差異與提建議。一個隨手跑的流程很容易把兩者併成一條「Claude 撰寫」，那會把「誰為內容正確負責」錯置；而這份 Wiki 能被信任的前提，正是維護責任留在人身上。所以圖上保留兩種角色邊，不合併。

有了這張圖，維護者點一個約束（例如「送達未知≠未送達」），就能沿邊看到它綁著哪些頁、來源在程式哪裡，不必逐頁翻。完整的節點、關係與作者歸屬檢查，見關係圖實作附件。

從這次查懂，到下一次能用，再到團隊共用

這次找到 sync_notify 的例外後，我不只修正當次答案，也更新通知頁與 changes.md。下次 Claude 查另一張工單，就能讀到修訂後的知識，再對照程式與當次紀錄。

之後沿用同一個更新方式：程式改了或查到漏寫，就由 Claude 對照差異、人核對後修訂頁面與來源版本；下一張工單則讀索引、回查來源，把值得留的新知識補回 Wiki。

前面十七天的產物（目標與量測、需求與設計、審查、測試與交付、查通知）同樣能依任務整理進 Wiki，但那是延伸；本篇已做的是通知流程、查詢背景、使用條件與修訂紀錄。Wiki 保存解釋與索引，程式、Skill、測試、即時 Log 仍留在原本的位置；過去的測試結果也不代表這次已通過。

共用時，可以把 Wiki 跟程式放在同一個 Git repo，由服務維護者在 PR 確認修訂。團隊因此有共同的知識版本，也能核對 Claude 用了哪些依據。本次已驗的是本機修訂與新對話取用，尚未驗證真人團隊採用或減載。

回到一開始：每次都要重新解釋專案嗎？

這次換新對話，通知流程與使用條件可以從 Wiki 讀取，不必全部再寫進提示；新的訂單 ID、時間窗與事件紀錄，仍要隨任務提供。

• 背景有了共同入口。 換對話、換工單，系統知識都能從 Wiki 取用，不必每次重講。
• 查出差異，要留下修訂。 Claude 指出漏寫的路徑，我核對程式後更新頁面，下一次才有新知識可查。
• 知識被使用，不等於效果已證明。 新對話讀到了修訂內容，必要的操作決定仍由人確認。

不用每次從頭解釋，不代表不用重新查證。 背景留下來了，這次能不能套用，仍要對照當次資料。

接下來，把其中每次都要核對的固定條件寫成程式，讓缺件先被攔下。

參考資料：

• Context 設計： Anthropic：Effective context engineering for AI agents，說明按需讀取、管理上下文與外部筆記的工程做法。

• 外部知識研究： Lewis 等人：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，研究檢索知識與生成回答的結合；不是本篇 Markdown Wiki 的成效驗證。

• 長上下文研究： Liu 等人：Lost in the Middle，受測模型使用資訊的表現受位置影響；不直接推論到本篇模型。

• 方法： Karpathy LLM Wiki，借鏡來源、整理後知識與修訂分開保存的思路。

• 知識關係圖： Understand Anything，本篇用 Claude Code 跑一次教學 Wiki 的關係分析，產出 15 節點／20 關係。

• 前篇案例： Day 17 操作附件，本篇沿用訂單教學程式與設計副本。

• 來源程式： 本篇核對的固定版本，可直接檢查 API 分流與兩處成功紀錄；程式碼公開不等於模型執行紀錄已公開。

• 實作紀錄： 原回答與重跑說明。教學包 examples/day18-knowledge-lab/ 保留來源、Wiki、凍結輸入與工具軌跡，公開 repo 尚待同步；本文的精簡範本可先在自己的專案建立。

• 資料範圍： 本篇沒有執行服務、實際補送或驗證團隊採用，不推估成功率與省時。既有四次知識查核加上六次工單回答，組成十個新對話，保存於附件。17 項靜態檢查只核對來源雜湊、連結與程式位置，不代表模型回答全對。