Claude Code 自動記憶系統完整教學 — 讓 AI 跨 Session 記住你的一切

你有沒有那種經驗——搬到一間新公司，坐下來，隔壁的前輩跟你說：「資料庫密碼在 wiki 第三頁，build 指令用 make 不要用 gradle，還有，千萬不要動 legacy 那個資料夾。」

你點頭，記在腦子裡。第二天醒來，全部忘了。

Claude Code 每次開新 session，就是在經歷這件事。你跟它講了很多：「我偏好用 pnpm」「commit message 要用繁體中文」「這個 API 的 rate limit 是每秒 10 次」——然後下一次對話，它什麼都不記得，因為 session 一關，記憶就清零了。

CLAUDE.md 解決了一部分問題，讓你把「規則」寫死在檔案裡。但規則和記憶是兩件事。規則是「公司 SOP」，記憶是「跟這個同事相處一個月後，你知道他習慣什麼、踩過什麼坑、哪些東西要特別注意」。

Claude Code 的自動記憶系統（auto memory）就是在做這件事。

一本自動更新的工作筆記

想像你入職第一天，公司發了一本空白筆記本給你。沒人叫你寫什麼，但你自然會開始記——「前輩說那個 API 有 bug 先不要碰」「老闆偏好用 bullet point 報告」「上次部署出事是因為忘記跑 migration」。

這本筆記不是 SOP 手冊，是你自己的工作筆記。別人不會幫你寫，但每次新任務來的時候，你都會翻一下。

Claude Code 的 auto memory 就是這本筆記。它存在 ~/.claude-company/projects/<project-path>/memory/ 目錄底下，每個記憶是一個 .md 檔案。而 MEMORY.md 是目錄裡的索引頁——每次新 session 啟動時，Claude 會先讀這個索引，知道有哪些記憶可以參考。

這裡有個跟直覺不太一樣的地方：MEMORY.md 不是記憶本身，而是記憶的目錄。真正的內容在各個獨立的 .md 檔案裡。就像書的目錄頁告訴你第三章在第 87 頁，但內容要翻到第 87 頁才看得到。

四種記憶，四種用途

不是所有記憶都一樣。Claude 會根據它觀察到的內容，自動分成四種類型，每種有不同的觸發時機和用途。

類型	像是什麼	什麼時候觸發
user	同事的個人檔案	聊到你的角色、技術背景、工作習慣
feedback	便利貼上的修正紀錄	你糾正它的行為，或肯定它做對了
project	專案看板的備忘欄	討論到進行中的工作、截止日、技術決策
reference	書籤列	提到外部系統（Jira、Slack、Grafana）和它的用途

user 記憶是最穩定的那種。你告訴 Claude「我是後端工程師，主要用 Java 和 Spring Boot」，它會記下來。之後每次新 session，它就知道不用跟你解釋什麼是 dependency injection。

feedback 記憶是最值錢的那種。每次你糾正 Claude——「不要用中國用語」「commit message 不要加 emoji」「測試要用 JUnit 5 不要用 JUnit 4」——它會存成一條 feedback 記憶。這表示你只需要糾正一次，以後它都記得。老實說這是整個記憶系統最划算的投資。

project 記憶是最容易過時的那種。「小明在做支付模組重構，預計下週完成」——這種資訊三個禮拜後就過期了。Claude 發現事實有衝突時會自動更新，但你偶爾也要主動清理。

reference 記憶是最容易被忽略的那種。「我們的 Grafana dashboard 在 https://grafana.internal.com，看 API latency 用 ‘Backend Overview’ 面板」——存一次，以後每次問它查效能數據，它都知道去哪裡看。

記憶檔案長什麼樣

打開一個記憶檔案，你會看到 YAML frontmatter 加上 Markdown 內容：

---
name: feedback-no-china-slang
description: 所有輸出都用台灣用語，不只文章正文，對話和設計討論也算
metadata:
  type: feedback
---

所有輸出使用台灣繁體中文用語，禁止中國大陸用語
（「信息」→「資訊」、「視頻」→「影片」、「軟件」→「軟體」）。

**Why:** 使用者是台灣工程師，讀者也是台灣社群，
用語不一致會降低信任感。

**How to apply:** 每次輸出前檢查，包括對話、文章、
程式碼註解、commit message。

結構很單純：name 是識別用的 key，description 是一句話摘要（會出現在 MEMORY.md 索引裡），metadata.type 是上面說的四種之一，底下的 Markdown 是完整內容。

而 MEMORY.md 索引長這樣：

1 2	- [禁止中國用語（含對話）](feedback_no_china_slang.md) — 所有輸出都用台灣用語 - [封面圖升級方案](project_cover_image_upgrade.md) — Imagen 4 vs notebooklm-py

每一行就是一條記憶的連結加摘要。Claude 開新 session 時讀這個索引，判斷哪些記憶跟當前工作有關，再去讀對應的檔案。不是每次都全部載入——它會挑著看，跟你翻筆記本一樣，只翻跟眼前任務有關的頁。

MEMORY.md 索引有 200 行的實用上限。超過這個長度，後面的記憶被參考到的機率會明顯下降。保持精簡，定期清理過時的條目。

主動管理你的記憶

auto memory 雖然叫「自動」，但完全放著不管不是好策略。就像你的工作筆記本——如果從來不整理，半年後翻開來全是過期的東西，反而會干擾判斷。

主動儲存

直接跟 Claude 說你要記住什麼：

1 2	記住這個：我們團隊的 code review 規則是至少一個人 approve 才能 merge，而且 approve 的人不能是 PR 作者本人。

Claude 會自動建立一個記憶檔案，分類、命名、寫入索引，整個流程不到五秒。

主動刪除

1	忘記關於舊版支付系統的記憶，那個模組已經被移除了。

Claude 會找到對應的記憶檔案刪掉，同時更新 MEMORY.md 索引。

直接翻閱

不確定 Claude 記了什麼？直接打開 memory/MEMORY.md 看索引，或者用 /memory 指令列出所有已載入的記憶來源。

手動編輯

記憶檔案就是 Markdown，你可以直接用編輯器打開改。要調整措辭、合併重複的記憶、或加上 Claude 遺漏的細節，改完存檔就好。下次 session 會讀到更新後的版本。

這裡有個小撇步：如果你想讓某條記憶特別醒目，在 MEMORY.md 索引裡把它排到前面幾行。Claude 對索引開頭的項目注意力會稍微高一點，跟人讀清單的習慣差不多。

什麼不該存進記憶

記憶系統不是垃圾桶，有些東西塞進去反而會造成問題。

程式碼結構和檔案路徑——Claude 可以直接讀你的 codebase，不需要把 src/api/handlers/auth.ts 這種路徑存成記憶。程式碼會變，記憶不會自動跟著變，最後記憶裡的路徑反而會誤導它。

Git 歷史——誰在什麼時候改了什麼，git log 是權威來源。把 commit 記錄存進記憶等於是在做一份會過時的副本。

暫時性的任務狀態——「目前在修 issue #1234 的 bug」這種事用 Task 系統追蹤更合適。記憶是持久化的，暫時性的東西放進去會製造噪音。

CLAUDE.md 已經寫過的東西——如果你在 CLAUDE.md 裡已經寫了「用 pnpm 不要用 npm」，就不需要再存一條記憶說同樣的事。重複的資訊不會讓 Claude 更遵守，只會浪費 context window。

判斷標準就一句話：這個資訊是不是「Claude 自己沒辦法從其他來源取得」的？ 如果 git log 查得到、codebase 讀得到、CLAUDE.md 寫了，就不要存。記憶系統存的應該是那些「只存在於你腦子裡」的東西。

新專案的記憶冷啟動

剛開一個新專案的第一次對話，Claude 的記憶是空的。這時候花兩分鐘做一件事，投資報酬率超高：

自我介紹。

不是客套那種，而是告訴它對工作有用的事：

我是後端工程師，主要用 Java 17 + Spring Boot 3。
偏好 functional style，不喜歡 inheritance 超過兩層。
Commit message 一律用繁體中文 conventional commit 格式。
這個專案是內部工具，使用者大概 50 人，不需要考慮超大規模的效能最佳化。

講完這段，Claude 會自動把它存成 user 記憶。往後每次新 session，它就帶著這些背景知識進來。你不用再解釋自己是誰、用什麼技術、偏好什麼風格。

然後在接下來幾天的工作中，每次你糾正它——「不要用 var，我要明確型別」「API response 統一用 envelope pattern」——每一次糾正都會累積成 feedback 記憶。一個月後，它的行為會非常貼合你的習慣，像是被你帶了一個月的 junior engineer。

記憶之間的連結

記憶不是一個一個獨立的便利貼。它們可以用 [[name]] 語法互相連結：

---
name: project-payment-refactor
description: 支付模組重構進度追蹤
metadata:
  type: project
---

支付模組正在從 legacy SOAP API 遷移到 REST API。

相關決策：
- 使用 Stripe 取代原本的自建金流 [[reference-stripe-dashboard]]
- API 設計遵循團隊規範 [[feedback-api-envelope-pattern]]