知識庫記憶漂移偵測：規則 vs 程式碼不一致檢查

用途

偵測記憶文件中寫的設定值或規則，與實際程式碼的行為之間是否已經脫節，找出哪一邊才是當前的事實，防止因「文件說 A 但程式做 B」造成的判斷錯誤。

何時用

• 適合：懷疑 memory 文件記載的規則和程式碼現實有出入，需要釐清哪邊才是當前生效版本時用。
• 不要用：你的專案根本沒有記憶文件或 memory 資料夾——沒有文件就沒有漂移可偵測，直接讀程式碼就好。

Prompt

請幫我查一個規則漂移問題，只給我事實，不要幫我決定要改哪一邊。

記憶文件：memory/{{例：config-rules.md}}
文件中寫的規則：{{例：所有 API 回應的日期格式應為 ISO 8601，即 "YYYY-MM-DDTHH:mm:ssZ"}}

可能不一致的程式碼路徑：{{例：src/api/response-formatter.ts}}
程式碼中實際用的值/格式：{{例：程式碼裡用 moment().format("YYYY/MM/DD HH:mm")，不帶時區}}

請做以下三件事：
1. 確認兩邊確實不一致（讀程式碼後引用實際行數）
2. 判斷哪一邊是當前「真正生效」的行為（以程式碼為準，不是文件）
3. 建議更新哪一份（記憶文件 or 程式碼），並說明原因——但不要擅自動手修改，等我確認

範例 / 變體

• 填好變數：文件「memory/api-conventions.md」；規則「response status 應回 success 或 error」；程式碼路徑「src/handlers/base.ts」；程式碼實際值「回傳 ok 或 fail」。
• 變體（批次掃描）：如果懷疑多個規則都可能漂移，把多組「文件規則 + 程式碼路徑」一起列出來，讓 AI 一次掃描後輸出一張不一致清單，再由你逐條決定要改哪邊。
• 變體（只查文件）：如果程式碼路徑不確定，先問「幫我在這個 repo 找所有可能涉及 {{日期格式}} 的檔案」，再把找到的路徑填入主 prompt。

🎯 範例輸出（實測）

在 Claude Code 跑這句、把 {{變數}} 填成「記憶文件：memory/api-conventions.md；規則：response status 應回 success 或 error；程式碼路徑：src/handlers/base.ts；實際值：程式碼回傳 ok 或 fail」的結果：

點開看 AI 實際輸出

步驟 1：確認不一致

讀取 src/handlers/base.ts 第 47 行：

return res.json({ status: 'ok', data: payload });

讀取 src/handlers/base.ts 第 83 行（錯誤路徑）：

return res.json({ status: 'fail', error: message });

memory/api-conventions.md 記載的規範是 success / error，程式碼實際使用 ok / fail。兩者確實不一致。

---

步驟 2：哪一邊是當前生效的行為

以程式碼為準：當前生效的是 ok / fail（src/handlers/base.ts 第 47、83 行）。這也是前端實際 parse 的值——若前端有 if (res.status === 'success') 這類判斷，目前已是靜默 bug。

---

步驟 3：建議更新哪一份

建議更新 memory/api-conventions.md，把 success / error 改成 ok / fail，理由：程式碼是已部署的生效版本，動程式碼的影響範圍（前端判斷、測試案例、文件）遠大於更新記憶文件。

等你確認後我再動手。

💡 實測心得：「不要擅自動手修改，等我確認」這句話非常關鍵——沒有這行的話，Claude Code 有時會直接改掉文件，但你可能其實想改程式碼而不是文件；保留人工決策點可以防止改錯方向。

延伸

你有沒有遇過這種情況？改了程式碼之後忘記更新 memory 文件，半年後 AI 給了根據舊文件推理出的建議，實際上和程式碼邏輯完全不同——這種漂移通常無聲無息地累積。建議每次重大重構後把這個 prompt 當作 checklist 跑一次，把漂移控制在可追蹤的範圍內。