為什麼 AI agent 應該維護你的 wiki，而不是回答你的問題

AI agent 最該做的不是重複回答問題，而是維護一個會持續更新的 wiki，成為團隊的單一事實來源。

我站在這一邊：AI agent 的價值在於維護知識庫，不在於每次都重新回答同一題。Ar9av/obsidian-wiki 把這件事做得很直接，先 ingest 一次，再抽取概念、處理衝突、更新交叉連結，讓知識留在一個可追蹤、可修正的系統裡，而不是散落在聊天紀錄與零碎 prompt 中。

第一個論點：重複生成答案，是知識工作的最大浪費

多數團隊其實不是缺答案，而是一直在重做答案。當同一個概念被問第 5 次、第 20 次，最昂貴的不是模型 token，而是上下文分裂與版本漂移。這個 repo 的做法很明確：如果某個概念頁已存在，agent 不是另寫一篇摘要，而是合併新資訊、標註矛盾、補上來源，讓知識逐步收斂。

它的 ingest 管線也說明了這點：markdown、PDF、JSONL、純文字紀錄、逐字稿、圖片都能進來，最後都被整理進 wiki，並在 frontmatter 保留來源。這不是單純的搜尋問題，而是知識治理問題。當系統能追溯每個主張的來源，AI 就不再像客服機器人，而更像一位編輯。

第二個論點：agent-as-maintainer 比 prompt 技巧更能長期擴張

obsidian-wiki 真正有價值的地方，不是某個特定模型，而是它把工作流做成一組 markdown skills，Claude Code、Cursor、Windsurf、Codex、Gemini CLI、Kiro 等工具都能讀。安裝腳本會把 canonical skill 檔案連到各 agent 的預期位置，這代表流程不會被綁死在某一家廠商的外掛裡。

這種可移植性不是小優點，而是能不能活過工具迭代的分水嶺。團隊可以讓不同 agent 指向同一個 vault，持續 ingest 新材料，同時維持 schema 一致；repo 也會記錄每個 source，並在下一次 ingest 時計算 delta，只處理變動部分。這種運作方式把 AI 工具從一次性 demo，拉回到真正可維護的基礎設施。

反方可能怎麼說

最強的反對意見是：living wiki 只是把維護成本換個地方放。既然 agent 要負責合併頁面、解決衝突、管理 schema，系統本身就會變成新的複雜來源。另一派會說，retrieval 已經能回答大多數問題，何必還要強迫團隊經營一個 markdown 知識庫。

這個批評不是錯的，但它只打到表面。retrieval 能把文件找出來，卻不會自動把概念標準化、建立 cross-link，也不會把互相矛盾的說法整理成穩定結構。維護成本確實存在，但它不是每次都付，而是把整理成本前置一次，之後換來的是累積型價值。對知識工作來說，這筆帳是划算的。

你能做什麼

如果你是工程師，別再把筆記當死資料夾，改成讓 agent 可讀、可更新的系統紀錄；如果你是 PM 或創辦人，就把產品決策、研究筆記、客戶訪談、架構選擇放進同一個可追溯 vault，避免團隊一再重談同一批事實。實作上先選一個唯一知識庫，定義 ingest 來源，強制來源標註，然後讓 agent 更新頁面，不要重複產生新版本。目標不是更多 AI 回答，而是每次碰到知識都讓 wiki 變得更準確。