如何讓 Codex 使用有來源的專案知識庫

把 coding agent 的專案知識分成三層：AGENTS.md 或 CLAUDE.md 放短而穩定的操作規則；程式、測試、規格與文件保留為單一事實來源；有來源的知識庫保存需要跨檔整理、引用與審查的目前答案。

Agent 接到任務時先讀最小規則，再按問題取用一個相關 Page，最後回到引用、程式與測試驗證。這比把全部內容塞進 instruction file，或每次重掃整個 repo 更容易保持目前與可檢查。

AGENTS.md 適合放 build、test、branch、權限與禁區等 agent 無法只靠讀 code 推出的規則；Claude Code 使用者可用 CLAUDE.md 表達同一類專案指引。檔案越長，越容易擠掉目前任務真正需要的 context。

知識庫不應複製 repo。架構理由、外部限制、跨檔結論、決策歷史與已驗證的操作手冊，才是適合維護成有引用 Page 的內容。程式與測試一旦改變，Page 應進入 stale 或 review，而不是繼續假裝正確。

先選一個會重複詢問的小主題，例如 release 流程或資料遷移邊界。完成 Wenlan 與 Codex 連線後，只加入能回答該主題的 Markdown、文字或可擷取文字 PDF；不要一開始匯入整個 repository。

把來源蒸餾成 Page 後，檢查重要說法能回到來源，再跑 lint 與 review。只有 MCP 連線的 client 應使用該 client 顯示的 Wenlan tools；下列 slash commands 適用於已安裝 Wenlan plugin 的 client。

不要在每次 session 開始時重播全部文件。先用任務名稱、錯誤症狀或模組查詢最相關的 Page，再沿引用打開真正需要的來源。若答案直接存在目前 code 或 test，就讓 agent 讀原檔，不要多繞一層摘要。

任務結束時只保存能影響未來工作的決策、限制、修正或交接。聊天摘要、暫時探索與 agent 自己可以從 repo 推出的內容，不應自動升格為專案知識。

準備一個來源中有答案的問題、一個必須跨兩份文件才能回答的問題，以及一個來源沒有答案的問題。前兩者應顯示支持材料；最後一個應保持未知，不應因為文字流暢就補成確定結論。

修改其中一份來源並重新同步，再確認受影響 Page 能被標成需要刷新或產生可審查修訂。這個 acceptance test 比『agent 看起來記得』更能證明知識庫有用。

如果資訊已在一份短而目前的 README、規格或測試裡，coding agent 直接讀來源通常更準。只有當同一問題跨多個來源、反覆出現，且重建答案的成本明顯時，才值得維護額外的 source-backed Page。

這條邊界即使不使用 Wenlan 也成立：先維持權威來源，再決定哪些結論值得做成可查詢、可引用、可刷新的專案知識。