AI 工具 18 min read ★ Featured

Memory 治理 EP2｜為什麼 AI 記不住你寫的規則

你寫了一堆 CLAUDE.md 原則,Claude 還是每次重蹈覆轍 — 不是它記憶不好,是你寫的規則「沒辦法照著做」。大部分人寫的是「描述性原則」(該做什麼、不該做什麼),但 AI 真正會跟的是「程序性 SOP」(動手前必跑的步驟、自我糾正的條件)。本文拆兩種寫法的差異、給改寫公式 「描述狀態 → 觸發條件 + 強制動作 + 違規判斷」、附 CLAUDE.md before/after 實際 diff,以及解釋為什麼 LLM 對程序性指令反應特別好。

#Claude Code #CLAUDE.md #Prompt Engineering +4 tags
Memory 治理 EP2｜為什麼 AI 記不住你寫的規則
本文目錄 · 14

# Memory 治理 EP2｜為什麼 AI 記不住你寫的規則

TL;DR
- 你寫了一堆 CLAUDE.md 原則,Claude 還是每次重蹈覆轍 — 不是它記憶不好,是你寫的規則「沒辦法照著做」。
- 大部分人寫的是「描述性原則」(該做什麼、不該做什麼),但 AI 真正會跟的是「程序性 SOP」(動手前必跑的步驟、自我糾正的條件)。
- 改寫公式:描述狀態 → 觸發條件 + 強制動作 + 違規判斷。本文有實際 CLAUDE.md before/after diff。

EP1 講了我用 Obsidian 打開 Claude 的 memory,看到一片花朵狀的慘況。整理完當下 graph 漂亮了,但我馬上問自己一個問題:

「過 3 個月,會不會又長回花朵狀?」

幾乎一定會。因為我整理的是「結果」,沒整理「行為」。

這一篇講行為層 — 怎麼改 CLAUDE.md,讓 Claude 不會三個月後又把 memory 寫爛。

---

我寫的規則,Claude 看得懂、做不到

整理完 memory 之後,我隨手翻自己半年內寫過的 CLAUDE.md 行為規範,看到一堆這樣的句子:

- 不要重複造輪子,動手前先查 memory 有沒有踩過坑

  • 寫 memory 時注意分類,避免同主題開新檔
    •  
  • 跨檔的關聯要記得 link,讓 graph 不要太花
    •  
  • 對自己嚴格,看到自己違規要主動修正
每一條我都認同。每一條我都看過 Claude 違反。為什麼?

我去 mempalace 翻了一輪過去三個月的對話,找「我罵 Claude 違反規則」的場景。歸納出來的模式很清楚:

時間Claude 的違規我當下的反應
2026-03同主題開新 memory 檔(明明既有檔可以擴)「你怎麼又開新檔?」
2026-04寫完 memory 沒加 ## 相關 區塊「graph 又花了」
2026-04跨專案規範存到專案級 memory「這應該全局啊」
2026-05同上,再一次「你 CLAUDE.md 沒看?」
最後一行特別刺眼。Claude 真的看了 CLAUDE.md,我每個 session 開頭它都會吃進去。但它就是做不到。

問題不在「沒看」,在「看了不知道什麼時候該動」。

---

描述性 vs 程序性:差在哪

我用兩個寫法對比同一條規則。

描述性寫法(舊版,沒用)

## Memory 寫入紀律

  • 不要重複造輪子,動手前先查 memory 有沒有踩過坑
    •  
  • 寫 memory 時注意分類,避免同主題開新檔
    •  
  • 跨檔的關聯要記得 link,讓 graph 不要太花
    •  
  • 對自己嚴格,看到自己違規要主動修正
讀這段,你會覺得「合理啊,寫得很清楚」。但問題是:
  • 「寫 memory 時注意分類」— 什麼時候「注意」?注意的動作是什麼?
  • 「避免同主題開新檔」— 怎麼知道這是同主題?要不要查既有檔?查的指令是什麼?
  • 「對自己嚴格」— 嚴格的判準在哪?違規定義是什麼?
這些規則只描述「期望狀態」,但沒給 AI 任何「進入該狀態的途徑」。AI 看完心想「好我會的」,然後該違規還是違規。因為它不知道什麼動作算遵守。

這就像跟新人說「要有 sense」— 他點頭,然後一樣出包。

程序性寫法(新版,有效)

把同一條規則改寫成「觸發 → 動作 → 違規判斷」三段:

## auto-memory 寫入 SOP(寫 memory 前必跑)

Step 1 — 找既有檔(15 秒)


寫新 memory 前必跑:
bash
# 全局
ls ~/.claude/memory/{feedback,reference,project,debugging}_*.md
# 專案級
ls ~/.claude/projects/-Users-yanchen/memory/*.md

對照即將寫的主題:


既有檔狀態動作
有完全同主題擴充(append / edit),不開新檔
有相近主題評估「合併到既有檔當成一節」優先
確認無相關檔才開新檔

禁止症狀:看到「這次討論的是 X」就反射性開新檔 — 必須先 ls 確認沒有 feedback_X*.md 或 feedback_*X*.md 才動筆。

Step 2 — 判斷全局 vs 專案級


內容類型寫到哪
跨專案行為規範全局 ~/.claude/memory/
單一專案細節專案級 ~/.claude/projects/<cwd>/memory/

不確定 → 寫全局。

Step 3 — 寫完必加 ## 相關 區塊(強制)


每份 memory 結尾必須有 ## 相關 區塊,至少 1 條 [[name|描述]]。


禁止症狀:寫完直接收工沒加 ## 相關 → Graph 又會變回花朵狀。


自我罵點清單(看到自己犯就糾正)


  • 寫 memory 跳過 Step 1(沒 ls 既有檔就動筆)→ 違規

  • 寫完沒加 ## 相關 區塊 → 違規

  • 內容明顯跨專案規範卻存到專案級 → 違規

    • 差在哪?

    層面描述性程序性
    觸發條件模糊(「注意」「記得」「避免」)明確(「寫新 memory 前必跑」「結尾必須有」)
    動作抽象(「分類」「link」)可執行(ls ~/.claude/memory/、加 ## 相關 區塊)
    違規判斷主觀(「太花」「太多」)客觀(「沒 ls 就動筆」「沒 ## 相關 區塊」)
    自我糾正全靠自覺列「罵點清單」逐項對應
    程序性寫法的關鍵不是「更詳細」,是「把判斷外化」。原本要 AI 「自己判斷該不該」,現在改成「有一個 if-then 流程,跟著跑就對」。

    ---

    從原則到 SOP 的改寫公式

    我自己用了一個簡單公式重寫 CLAUDE.md 的每一條規則:

    描述性(壞):「<期望狀態 / 抽象原則>」
                      ↓
程序性(好):「<觸發條件> → <強制動作> → <違規判斷>」

    舉幾個對比:

    例 1:檔案路徑紀律

    舊:

    檔案路徑要清楚,避免讓使用者猜。

    新:

    檔案路徑一律給完整絕對路徑 + 行號(如 /Users/yanchen/workspace/.../foo.ts:42)。禁止相對路徑。

    >
    觸發條件:任何要對使用者寫檔案位置時。包括結尾總結、表格、追蹤清單、回答「在哪」「給我看 X」的提問。

    >
    強制動作:寫的時候用 pwd 確認 cwd,再拼出絕對路徑。

    >
    違規判斷:看到自己寫 docs/foo.md、./src/bar.ts 立刻停。

    例 2:不要過度設計

    舊:

    避免過度設計,保持簡單。

    新:

    不要過度設計:內部系統不需要高流量架構,YAGNI 優先;最佳實踐以「當前規模下可維護的最簡方案」為準。

    >
    觸發條件:設計層決策(技術選型、資料模型、API 形狀)時。

    >
    強制動作:給 2-3 選項,每個附 trade-off 跟適用規模。預設選最簡的那個。

    >
    違規判斷:看到自己加「以後可能需要」「為了擴展性」這類詞 → 立刻刪掉那個方案。

    例 3:卡關升級

    舊:

    不要無限重試,卡住要說。

    新:

    同一個問題自己嘗試 3 次仍無進展 → 停下來升級。

    >
    觸發條件:同一個錯誤連續嘗試 3 次。

    >
    強制動作:用這個格式回報:「已試 3 種做法都沒過:[A 做了什麼/為什麼掛] / [B 做了什麼/為什麼掛] / [C 做了什麼/為什麼掛]。我打算走 D({具體方案}),除非你叫停我就動了。」

    >
    違規判斷:在第 1、2 次就跳過來假裝是 3 次 / 用「不行欸」這種沒資訊量的話回報 → 違規。

    每一條改寫都遵循同一個套路:把模糊形容詞換成可驗證條件。

    ---

    為什麼 AI 對程序性規則的反應這麼好

    這不是玄學,是因為 LLM 的訓練資料分佈決定的。

    LLM 接受過大量 "step-by-step" 數據:技術文件、Stack Overflow 答案、教科書、code review 評論。這些資料的共通格式就是「先 A 再 B 最後 C」。當你給它的指令也是這種格式,它的 next-token 預測會自然走「執行步驟」這條路徑。

    反之,「要有 sense」「要小心」「對自己嚴格」這類抽象指令,在訓練資料裡多半出現在「無效的職場 feedback」「無效的家長嘮叨」這類文本 — LLM 學會的回應是點頭認同 + 不知道下一步。

    換句話說,你寫 CLAUDE.md 的時候:

    • 寫成「期望 AI 變成怎樣」→ AI 認同 + 做不到
    • 寫成「期望 AI 跑哪個程序」→ AI 真的跑
    這也是為什麼「禁止短語清單」、「自我罵點清單」、「禁止症狀」這類具體列舉特別有效 — 它把判斷成本從「主觀理解」降到「字串比對」。AI 看到自己打出「應該長這樣」「通常是」「我記得」這幾個字,就觸發停下來查的反射,根本不需要理解為什麼。

    ---

    CLAUDE.md before/after:實際 diff

    EP1 整理完 memory 之後,我同步改了 CLAUDE.md。最大的一段差異在「驗證紀律」這節 — 原本只有兩句描述,改成完整 SOP 表格 + 自我罵點。

    Before(2025 年舊版,180 行)

    ## 紀律

    • 路徑要絕對,別用相對路徑
      •  
    • 不要憑印象寫指令,先查再寫
      •  
    • 重要任務交付前自己審一次
      •  
    • 出包要先檢討驗法不是再賭一次
    整個 CLAUDE.md 180 行,大概有 60 條這種句子。每條都對,合起來一條都沒人(沒 AI)真的執行。

    After(2026-05-21 版,330 行)

    ## 驗證紀律:可執行內容當下驗、收工前 round-trip

    **寫進文件 / skill / 回覆裡的任何可執行內容(指令、regex、log 字串、
    路徑、檔名、API 端點、CLI flag、成功條件),都不准憑印象寫**,
    寫的當下就驗一次,驗完才落字。
    

    內容類型寫之前必跑
    grep / regex patterntail <log> \/usr/bin/grep -E "<pattern>" 確認真的抓到
    工具 / 套件指令which <tool> / <tool> --help 看 flag 拼字
    路徑 / 檔名ls <path> 確認存在
    log 成功字串實際觸發一次,複製真的 log 行,不是「應該長這樣」
    套件安裝法先看 venv 是 pip / uv / poetry 哪個管的,別套通用印象
    
禁止短語(打字打到這幾個 → 立刻停下來查):
「應該長這樣」「通常是」「我記得」「印象中」「八成是」。

    「修好了」的判斷標準:round-trip,不是 handshake
    

    handshake 級訊號(SSL connected、service started、process running、port open)
    不算修好,只算「沒在最外層掛掉」。真的修好的證據是 round-trip
    — 從輸入端進、輸出端出、人看得到結果。
    

    對應到常見情境:
    • bot 上線 → 看 Discord 端真的收到回覆,不是看 log 寫 Connected
      •  
    • API 部署 → curl 打一次拿到預期 response,不是看 systemctl status 綠燈
      •  
    • 資料寫入 → 從 read 端讀回來,不是看 INSERT 沒噴錯
      •  
    • 前端改版 → 開瀏覽器點一次,不是看 build 成功
      •  
    自我罵點(自己看到就糾正,不要等 Bob 罵)
    

    • 寫 regex / 指令時沒有「先跑一次再貼上」→ 違規
      •  
    • 看到 log 有「success」字串就回報好 → 違規,沒做 round-trip
      •  
    • 第二次喊「修好了」的力道 ≤ 第一次 → 違規,該更小心
      •  
    • 文件裡寫「應該」「通常」「我記得」→ 違規,立刻去查再改回斷句
    長很多沒錯。但這 4 句 → 4 個小節的改寫,直接讓 Claude 寫 regex 前先跑 tail、報「修好了」前先 round-trip 驗、自己看到「應該長這樣」會停下來查。

    這不是更聰明的 AI,是更可執行的指令。

    ---

    那為什麼大部分人不這樣寫?

    因為程序性 SOP 不好寫。

    寫描述性原則只要 1 分鐘:「不要過度設計」打字打完。寫程序性 SOP 要 30 分鐘:你得想清楚「什麼時候算過度設計」「該跑什麼動作」「違規長什麼樣」。

    但這個成本一次付完,換來的是規則自己會運行。三個月後你不會回頭問「為什麼又這樣」,因為規則裡寫了該怎麼避免。

    短期慢、長期省。寫 CLAUDE.md 不是寫「期望」,是寫「程式」— 給 AI 跑的程式。你不會用「希望這個 function 表現好」當 code,你會寫 if x then y。CLAUDE.md 也一樣。

    ---

    不是學術術語,是我的框架

    寫到這裡要老實說一句:「描述性 vs 程序性」這個對立不是 prompt engineering 的固定學術術語,是我自己整理 CLAUDE.md 時找到最能解釋我踩坑的對比。

    學術上比較接近的概念是 ASTP(Assistant Specialization Through Prompts)、Chain-of-Thought prompting、structured prompting。但這些術語涵蓋範圍太廣,對應到「個人 AI 工作流規則該怎麼寫」這個具體問題時,描述性 vs 程序性這個切分對我最直觀。

    你看到這個框架覺得有用 → 拿去用。覺得有更好的詞 → 告訴我,我換。

    ---

    接下來(EP3 預告)

    CLAUDE.md 改成 SOP 之後,規則會自己運行 — 但你怎麼確認它真的有運行?

    過去三個月我發現:最可靠的判讀工具不是看 log,是看 Obsidian Graph。

    如果規則生效,memory graph 會持續長成星雲狀 — cross-link 自然增加、cluster 自然形成、孤島檔案越來越少。如果規則沒生效,graph 又會慢慢退化成花朵。

    📅 明天(2026-05-22)會發:Memory 治理 EP3｜用 Obsidian 看你的 AI 大腦
    EP3 拆 Obsidian vault 配 Claude memory 的具體設定步驟,以及我怎麼用 Graph View 每週做一次「AI 大腦健診」。

    ---

    ❓ 常見問題

    Q1: 我的 CLAUDE.md 才 50 行,真的需要改成程序性嗎?

    50 行剛好。你現在改的成本最低 — 規則少、踩坑少、習慣還沒固化。等到 200 行才改,你會發現一半規則早就互相矛盾,得先做整理才能重寫。短:現在改最划算。

    Q2: 程序性 SOP 是不是會讓 CLAUDE.md 變超長?80-120 行的社群建議不就破了嗎?

    會變長,我的 CLAUDE.md 從 180 行長到 330 行。但社群 80-120 行的建議基於「每個 session 全文載入」的 context cost — 這個 cost 真實存在,但比起 AI 反覆違規再來校正的 cost,長一點的 CLAUDE.md 划算。建議:核心規則 SOP 化(占 60-70%),補充原則描述性(30-40%),不要為了短而把所有規則都描述化。

    Q3: 描述性原則就一無是處嗎?

    不是。對人寫的東西(README、設計文件、團隊 onboarding)描述性原則比較適合 — 人會用「sense」自己腦補執行流程。對 AI 寫的東西(CLAUDE.md、Skill、Agent prompt)才需要程序化。差別在讀者:人是「理解後執行」,AI 是「pattern match 後執行」。

    Q4: 我寫了 SOP,Claude 還是會違規,怎麼辦?

    兩種可能:(1) 觸發條件寫不夠具體,Claude 沒抓到該動的時機 — 把觸發條件用「禁止短語」「禁止症狀」這種字串比對級的描述補強。(2) 違規判斷沒列「自我罵點」 — 加一條「看到自己 X 就立刻停下糾正」。我用這兩招過去三週違規率降到原本的 1/4。

    Q5: 那 memory 本身需要寫成程序性嗎?

    不需要。memory 是「事實 + 過去踩坑」,本來就是描述性的。程序性適用於行為規範(CLAUDE.md / Skill),描述性適用於知識儲存(memory)。不要把兩者混在一起,memory 該是查得到的字典,不是該照著跑的程式。

    ---

    🔗 延伸資源

    ---

    「不怕死,只怕不過癮」

    — 陳彥彤 YC

    author
    陳
    陳彥彤

    AI 工程師 · AI 顧問。Java 後端 8 年、AI 工程師 2 年。AI 內訓 · AI 導入顧問 · 前後端與雲端培訓。

    support

    覺得文章有用可以到 GitHub 給個 star，或是透過信箱聊聊 AI 內訓、AI 導入顧問或前後端 / 雲端培訓。

    email github
    related

    相關文章

    [AI 工具] · 16min
    Memory 治理 EP1｜我的 Claude 記了一堆爛筆記
    用 Claude Code 半年,memory 從 10 個檔長到 76 個,以為自己在養 AI 大腦,結果用 Obsidian Graph View 一打開全是花朵狀:所有檔只連中心的 MEMORY.md,檔跟檔之間幾乎沒連線。三胞胎重疊 70% 的 feedback、9 個全局/專案級同名檔、cross-link 趨近 0。本文拆三個結構性根因:同主題開新檔不擴充既有、寫完不加 [[link]]、全局 vs 專案級沒判準,以及整理之後做的三件事(合併三胞胎、重寫 MEMORY.md 成 cluster、CLAUDE.md 加程序性 SOP)。
    [AI 工具] · 26min
    讓 Claude 每天早上幫你寫一封 SEO 解讀信：cron + claude -p stateless 走 Max 訂閱 0 元 pipeline
    上週寫過「我請 AI 每天早上 9 點寄 SEO 報告給我」 — 但信內容是 raw 數字,我每天還是要花 10 分鐘自己腦補解讀。這篇是第二階段:在原本 cron 腳本裡加 35 行 bash,用 claude -p stateless 模式呼叫 Claude(走 Max 訂閱 0 額外成本),把昨天的 GSC + Firestore 數字翻成「總評 / 需要注意 / 今天可以做」三段繁體中文解讀,放在信最上面。完整實作 + prompt 設計關鍵點 + 5 個踩坑 + 抄回家自己用 + 順手澄清「這跟 claude.ai 接 Gmail connector 完全不同」常見誤會。
    [AI 教學] · 19min
    CLAUDE.md 怎麼寫?Claude Code 第二堂——馴服系統提示 + 十大 prompt 定義 + Ultra Think
    Claude Code 預設每次開啟都是失憶的,但只要你寫好 `~/.claude/CLAUDE.md`(全域) + 專案 `CLAUDE.md`,它就會在每次對話開頭把這兩份檔讀進去當作永遠的指令。本文是 2026-05-05 Pro 版第二堂的完整紀錄——十大 prompt 定義對照表(指令/上下文/人設/輸出格式/約束/範例/評估/迭代/護欄/記憶)、`/compact /resume` 救命指令、pwd/ls/cd 在 Claude 內的座標系、Ultra Think 馬力全開、最後用一個「每天早上 7 點 Line 通知前一天踩坑」的 `/schedule` 收尾。
    ← all posts