Memory on KnightLi的博客

ChatGPT、Claude Code 和 Gemini 的記憶機制有什麼不同？

Thu, 07 May 2026 14:47:17 +0800

AI 產品裡的「記憶」正在變得越來越重要。它標誌著 AI 從「單次對話工具」走向「長期協作夥伴」：不用每次重新介紹背景，不用反覆解釋偏好，也不用讓模型一次次重新理解項目。

但不同產品裡的記憶並不是一回事。ChatGPT、Claude Code 和 Gemini 都在解決「AI 如何記得更久」的問題，但它們的設計目標、儲存位置、透明度和適用場景差異很大。

截至 2026 年 5 月 7 日，可以把它們粗略理解成三類：

ChatGPT 更像「個人助理記憶」。
Claude Code 更像「工程項目記憶」。
Gemini 更像「Google 生態上下文」。

ChatGPT：圍繞人的長期偏好

ChatGPT 的記憶機制主要面向個人協作。它關心的是「你是誰」「你偏好什麼」「你長期在做什麼」。

OpenAI 目前把 ChatGPT 的記憶分成兩類：saved memories 和 chat history。

saved memories 是 ChatGPT 保存下來的重要資訊，比如你的名字、偏好、目標、常用技術棧、寫作習慣等。你可以直接要求它記住某件事，它也可能在對話中自動保存它認為未來有用的資訊。

chat history 則是讓 ChatGPT 在回答時參考過去聊天。它不等於把每一段聊天都完整變成記憶，而是在需要時從過往對話裡找相關上下文。

所以 ChatGPT 的核心邏輯是：跨會話理解同一個使用者。

典型例子包括：

「以後給我程式碼示例時盡量簡潔。」
「我主要使用 Python 和 TypeScript。」
「我正在寫一個關於 AI 工具的 Hugo 部落格。」
「我喜歡先看結論，再看細節。」

這些記憶不是綁定某個單獨項目，而是跟隨帳號和個人使用習慣。

Memory Sources：讓個性化來源更可見

OpenAI 在 2026 年 5 月的更新中強調了 Memory sources。

它的作用不是新增另一種記憶，而是讓使用者看到 ChatGPT 在個性化回答時參考了哪些來源。根據 OpenAI 幫助文件，Memory Sources 可能顯示：

過去聊天。
保存記憶。
自定義指令。
文件庫中的文件。
已連接 Gmail 中的郵件。

其中，文件和 Gmail 的可見範圍會受到計畫、地區和連接狀態限制。OpenAI 也明確說明，Memory sources 不一定展示影響回答的所有因素，而是幫助使用者理解和管理個性化。

這一步很重要。因為 AI 越會「記住你」，使用者越需要知道它到底根據什麼在回答。否則個性化很容易變成黑箱：你感覺它好像知道你，但不知道它為什麼知道。

ChatGPT 的優勢是跨會話、跨主題持續理解個人偏好；風險是記憶容易過期，或者使用者忘了某條舊記憶還在影響回答。因此，適合定期清理 saved memories 和舊聊天。

Claude Code：圍繞程式碼庫和工程規則

Claude Code 的記憶機制更偏工程協作。它關心的不是「使用者平時愛喝什麼咖啡」，而是「這個程式碼庫應該怎麼改」。

Claude Code 有兩類容易混在一起的記憶：

顯式項目記憶：CLAUDE.md。
自動項目記憶：Auto Memory。

CLAUDE.md 是最基礎、最穩定的項目記憶文件。它可以放在項目根目錄，也可以在子目錄中存在。Claude Code 會讀取這些文件，把它們作為項目說明和操作規則。

適合寫進 CLAUDE.md 的內容包括：

常用構建、測試、lint 命令。
程式碼風格和命名規則。
項目架構說明。
模組邊界和危險區域。
團隊約定和提交流程。

如果 CLAUDE.md 放在程式碼庫裡，它可以提交到 Git，成為團隊共享的 agent 說明書。這一點和 ChatGPT 的雲端個人記憶完全不同。

Claude Code Auto Memory：自動累積項目經驗

Claude Code 現在也有 Auto Memory。它的目標是讓 Claude 在多個會話之間自動累積項目經驗，而不要求使用者每次手寫說明。

根據 Claude Code 文件，Auto Memory 會讓 Claude 在工作過程中為自己保存筆記，例如構建命令、調試發現、架構說明、程式碼風格偏好和工作流習慣。它不會每個會話都保存，而是判斷哪些資訊未來可能有用。

這裡有一個容易誤解的點：Auto Memory 預設不是把內容寫到項目根目錄的 .claude/memory.md。官方文件說明，每個項目會在使用者目錄下擁有自己的 memory 目錄，路徑類似：

`1`	`~/.claude/projects/<project>/memory/`

其中 MEMORY.md 會在每次對話開始時載入前 200 行或前 25KB，詳細內容則可能被拆到其他主題文件裡。Auto Memory 文件是本機本地的 Markdown 文件，使用者可以透過 /memory 查看、編輯或刪除。

這讓 Claude Code 的記憶更像「本機上的項目經驗庫」。它比 ChatGPT 的個人記憶更貼近程式碼庫，也比單純的 CLAUDE.md 更動態。

但要注意，Auto Memory 是機器本地的，不會天然跟隨程式碼庫同步到其他機器或雲環境。如果要團隊共享穩定規則，仍然應該優先寫進項目中的 CLAUDE.md。

Gemini：圍繞 Google 生態上下文

Gemini 的記憶邏輯又不同。

Gemini 也有保存資訊和參考過去聊天的能力。Google 幫助文件提到，使用者可以保存關於生活、工作或偏好的資訊，也可以讓 Gemini 在回答前參考過去聊天。Gemini 使用這些資訊時，可能會在回答底部的來源區域顯示 Your saved info 或 Previous chats。

但 Gemini 的差異化不只在「保存幾條偏好」，而在 Google 生態整合。

在使用者授權和功能可用的前提下，Gemini 可以透過連接的 Google 應用獲取上下文，例如 Gmail、Google Drive、Docs、Sheets 等。它的優勢不是讓使用者一條條教它記住什麼，而是把已有的 Google 帳號資料變成可檢索的工作上下文。

典型區別是：

ChatGPT 記得：「我最近在做 LTO 磁帶機修復。」
Gemini 可能可以從 Gmail 找到購買確認郵件，或從 Drive 裡讀取相關維修筆記。

當然，這不代表 Gemini 可以無條件讀取你所有 Google 資料。它取決於帳號類型、地區、權限、連接應用、Keep Activity 設定和具體產品可用性。對企業或學校帳號，還可能受 Google Workspace 管理員控制。

所以更準確地說，Gemini 的記憶不是一個單純的「備忘錄」，而是「保存資訊 + 過去聊天 + Google 生態連接」的組合。

三者核心差異

維度	ChatGPT	Claude Code	Gemini
核心對象	人和偏好	項目和程式碼庫	Google 帳號與生態資料
典型記憶	偏好、背景、長期目標	架構、命令、規範、調試經驗	saved info、過去聊天、Gmail/Drive/Docs 上下文
儲存形態	OpenAI 帳戶內的記憶和聊天上下文	`CLAUDE.md`、`MEMORY.md`、本地 Markdown 文件	Google 帳號活動、保存資訊、連接應用資料
透明度	Memory sources 可見一部分來源	Markdown 文件可直接查看和編輯	透過來源提示、Gemini Apps Activity 和 Google 設定管理
跨項目能力	強，跟隨使用者帳號	弱，主要跟隨項目或本機項目 memory	強，取決於 Google 生態資料和權限
團隊共享	不適合直接共享	`CLAUDE.md` 可隨 Git 共享	主要依賴 Workspace 和權限體系
最適合	個人偏好和長期助理	長期程式碼項目和 agent 協作	Google Workspace 資料檢索和跨工具工作

該怎麼選擇和使用

如果你想讓 AI 記住「我是誰、我喜歡什麼風格、我長期怎麼工作」，ChatGPT 的記憶更合適。

它適合保存個人偏好，例如寫作風格、常用技術棧、回答格式、職業背景、長期項目方向。它的重點是減少自我介紹成本，讓每次新對話更快進入狀態。

如果你想讓 AI 記住「這個程式碼庫怎麼改、哪些命令能跑、哪些坑不能踩」，Claude Code 更合適。

穩定規則寫進 CLAUDE.md，團隊共享；動態經驗交給 Auto Memory 輔助累積；關鍵決策最好仍然整理進文件或 CLAUDE.md，避免只停留在本機自動記憶裡。

如果你的資料大量存在 Gmail、Drive、Docs、Sheets 裡，Gemini 的生態上下文更有優勢。

它適合查找過去郵件、整理 Google Drive 文件、聯動日曆和辦公資料。使用 Gemini 的關鍵，不是反覆在聊天裡提醒它，而是確保相關應用連接、權限和活動設定正確。

一個實用分工

可以把三者這樣分工：

ChatGPT 記住「我的通用偏好」。
Claude Code 記住「這個倉庫的工程知識」。
Gemini 檢索「我在 Google 生態裡的資料」。

也就是說，ChatGPT 更像私人秘書，Claude Code 更像項目裡的資深工程同事，Gemini 更像 Google 帳號裡的資料索引員。

這三種記憶沒有絕對高低，只是目標不同。

最需要警惕的是把它們混為一談。個人偏好不一定適合寫進項目記憶；項目架構不一定適合存在雲端個人記憶；Google 生態檢索也不等於模型真正「長期理解」了你。

簡短判斷

AI 記憶的下一階段，不是簡單地「記得越多越好」，而是記憶要分層、可見、可控。

ChatGPT 的重點是跨會話個人化，Claude Code 的重點是程式碼項目連續性，Gemini 的重點是 Google 生態上下文。真正好用的長期 AI 協作，不是把所有資訊塞進一個黑箱，而是讓不同類型的記憶待在合適的位置。

個人偏好放在個人記憶裡，工程規則放在程式碼庫裡，歷史資料放在原本的文件和郵件系統裡。AI 要做的，是在需要時準確呼叫這些上下文，而不是把所有東西混成一團。

ChatGPT Release Notes 更新：記憶來源、GPT-5.5 Instant 和表格插件

Thu, 07 May 2026 14:30:15 +0800

OpenAI 的 ChatGPT Release Notes 頁面在 2026 年 5 月初更新，最新一批重點包括三件事：ChatGPT 的記憶來源和個性化能力增強，GPT-5.5 Instant 成為新的預設模型，以及 ChatGPT for Excel 和 Google Sheets 全球上線。

這幾項更新放在一起看，方向很清楚：ChatGPT 正在從一個聊天入口，繼續變成更持續、更個性化、也更貼近辦公場景的工作助手。

Memory sources：個性化要更透明

最新更新裡，最值得關注的是 memory sources。

OpenAI 表示，ChatGPT Plus 和 Pro 使用者會開始獲得更強的記憶改進。ChatGPT 可以更好地從過去聊天、保存的記憶、可用文件，以及已連接的 Gmail 應用中提取相關上下文，用來給出更貼合使用者的想法、建議和下一步行動。

這意味著使用者不必在每次新對話裡反覆解釋自己的項目背景、偏好、工作習慣或已有材料。對於長期寫作、項目規劃、資料整理、學習和團隊協作來說，連續性會更強。

但個性化越強，透明度就越重要。OpenAI 因此推出 memory sources，讓使用者看到哪些資訊幫助 ChatGPT 個性化了某個回答。使用者可以點擊回答下方的 Sources 圖示，查看相關保存記憶、過去聊天和自定義指令。Plus 和 Pro 使用者還可能看到資料庫中的文件，以及已連接 Gmail 中被引用的郵件。

如果某些資訊過期、不相關或錯誤，使用者可以更正、刪除，或標記為不相關。

記憶控制仍然是關鍵

OpenAI 也說明，memory sources 不一定展示影響回答的全部因素，後續還會繼續改進這個視圖。

這個提醒很重要。它說明 memory sources 不是完整的「模型思考日誌」，而是讓使用者理解個性化上下文的一種產品介面。它能提高可見性，但不能把所有影響因素都完全展開。

隱私和控制方面，OpenAI 表示 memory sources 只會顯示在使用者自己的帳戶體驗裡。如果使用者分享聊天，相關 sources 不會出現在共享聊天中。使用者也可以刪除聊天，使用不會使用或更新記憶、也不會出現在歷史記錄中的臨時聊天，關閉記憶，隨時斷開應用連接，並管理自己的內容是否用於改進模型。

這說明 ChatGPT 的個性化正在走一條更明確的路線：既要更懂使用者，也要讓使用者知道它為什麼這麼回答，並保留管理入口。

GPT-5.5 Instant 成為預設模型

Release Notes 還確認，GPT-5.5 Instant 正在作為 ChatGPT 的新預設模型推出，並替代面向所有使用者的 GPT-5.3 Instant。

這次預設模型更新主要改善幾個方面：

準確性。
清晰度和簡潔度。
圖片理解。
STEM 問題回答。
判斷何時需要聯網搜尋。

OpenAI 強調，GPT-5.5 Instant 在事實可靠性上更好，尤其是在準確性更重要的提示詞中表現更穩。它也會給出更緊湊、更直接的回答，減少不必要的追問，降低過度格式化和無意義裝飾帶來的干擾。

對使用者來說，這類變化可能不會像新功能按鈕那樣顯眼，但會影響每天打開 ChatGPT 時的體感：回答更少繞路，更少囉嗦，也更少在簡單問題上堆格式。

個性化和預設模型結合起來

GPT-5.5 Instant 對 Plus 和 Pro 網頁端使用者還會更有效地使用過去聊天、文件和已連接 Gmail 的上下文。

這和 memory sources 是同一條產品線。模型不只是「更聰明」，還要在合適的時候知道你之前做過什麼、關心什麼、已經提供過哪些材料。比如繼續一個項目、寫一份計畫、整理郵件裡的資訊，或根據過去偏好給出建議時，ChatGPT 可以減少重複詢問。

付費使用者仍可在三個月內透過模型配置繼續使用 GPT-5.3 Instant，之後該模型會退役。

ChatGPT for Excel 和 Google Sheets

另一個重要更新，是 ChatGPT for Excel 和 Google Sheets 全球上線。

它把 ChatGPT 放進 Microsoft Excel 和 Google Sheets 的側邊欄中，讓使用者可以在表格裡直接構建、更新和理解資料。OpenAI 提到的場景包括：

追蹤表。
預算。
公式。
多工作表文件。
情境分析。
表格清理。

在可用地區和條件下，它還支援 Skills 和 apps。

這類功能的意義很直接：很多辦公資料並不在專門的 BI 系統裡，而是在 Excel 和 Google Sheets 裡。把 ChatGPT 放進表格側邊欄，比讓使用者複製貼上到聊天窗口更自然，也更容易進入真實工作流。

使用限制和安裝方式

Release Notes 提到，Free 和 Go 計畫包含有限使用量；Plus 和 Pro 使用與 Codex 相同的 agentic 使用限制。如果使用者超出計畫限制，可以購買額外 credits。

安裝方式也比較直接：Excel 版本從 Microsoft Marketplace 安裝，Google Sheets 版本從 Google Workspace Marketplace 安裝，然後使用符合條件的 ChatGPT 帳戶登入。

OpenAI 也提醒，使用者在依賴公式或分析前需要檢查輸出。這點不能忽略。AI 可以加速表格工作，但公式、預算、財務和業務分析仍然需要人工複核。

近期更新脈絡

如果把 4 月底到 5 月初的 release notes 放在一起看，ChatGPT 的方向更清楚。

4 月 30 日，OpenAI 推出 Advanced Account Security，給個人 ChatGPT 帳戶提供更強的登入要求和帳戶保護，包括 passkeys、安全密鑰、恢復密鑰、更短會話和登入通知。

4 月 28 日，模型選擇入口移到輸入框附近，讓使用者在發送消息前更容易選擇模型；Thinking 和 Pro 模型的 thinking effort 控制也被放進模型選擇器。

4 月 22 日，ChatGPT 推出 Fast answers，用於一些不需要個性化、且模型有高置信答案的常見資訊查詢。Fast answers 不引用過去聊天或記憶，使用者也可以在個性化設定裡關閉。

這些更新都圍繞同一個目標：讓 ChatGPT 更適合日常高頻使用。該快的時候快，該個性化的時候個性化，該需要安全保護和可見控制的時候給出入口。

簡短判斷

這次 ChatGPT Release Notes 的重點，不是單個功能，而是產品形態繼續收束。

GPT-5.5 Instant 提升預設回答品質，memory sources 讓個性化更可見，Excel 和 Google Sheets 插件把 ChatGPT 放進辦公表格，Advanced Account Security 和模型選擇改動則補上帳戶安全和操作體驗。

ChatGPT 正在變成更長期的工作層：它會記住更多上下文，進入更多工具，也承擔更多日常任務。接下來真正需要觀察的是，個性化透明度是否足夠清楚，辦公插件在真實複雜表格裡是否穩定，以及使用者能否在便利和控制之間保持平衡。

Claude Code 環境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次講清

Thu, 23 Apr 2026 10:43:40 +0800

如果你用了 Claude Code 一段時間，很快就會發現一件事：模型本身當然重要，但你給它什麼環境、什麼邊界、什麼規則，同樣重要。

很多人一開始會把注意力放在「這次 prompt 要怎麼寫」，但真正把 Claude Code 用成熟之後，你會更在意另一件事：

它知不知道你是誰
它知不知道你怎麼工作
它知不知道哪些規則不能違反
它知不知道哪些事情必須先確認
它能不能長期記住這些邊界

Claude Code 之所以能變成一個成熟工具，不只是因為模型強，而是因為它有一整套機制，幫你把這些工作方式沉澱下來。核心上可以拆成四層：

CLAUDE.md
Rules
Memory
Hooks

這篇文章就把這四個部分一次講清楚。

為什麼環境配置比單次提示詞更重要

你可以把 Claude Code 想成你請來的一位助理。

第一天上工時，你不會只跟他說一句「幫我做事」，而是會給他一份說明書，告訴他：

你的身份是什麼
你的溝通語氣偏好是什麼
哪些操作必須先確認
哪些錯誤以前犯過、之後不能再犯
這個專案最重要的文件放在哪裡

這就是為什麼，長期來看，環境配置往往比單次 prompt 更重要。

因為 prompt 解決的是「這一次要做什麼」，而環境配置解決的是「以後每次都要怎麼做」。

第一層：`CLAUDE.md`

先從最基礎的開始。CLAUDE.md 本質上就是一個文字檔。

你可以在裡面寫給 Claude 的說明，例如：

你是誰
你在做什麼
你的溝通偏好
需要遵守的規則
當前專案的特殊背景
重要文件或目錄的位置

每次 Claude Code 啟動時，這份文件都會自動被送進上下文，所以模型一定會讀到。

我通常把它叫做「默契檔」，因為它本質上就是你和模型之間長期協作的默契。

`CLAUDE.md` 適合寫什麼

最適合寫進 CLAUDE.md 的，大致有這幾類：

身份與工作背景
溝通語氣與輸出偏好
全域性的行為規則
常會用到的重要專案背景
常見錯誤與避免方式

例如：

你的時區
你是否接受模型直接發送郵件或訊息
哪些操作屬於不可逆行為
你處理文件與檔案的習慣
安全規範與敏感資訊邊界

一個很重要的原則：盡量精簡

CLAUDE.md 有一個很重要的原則，就是一定要盡量精簡。

原因很簡單：它每次都會被強制注入上下文。

如果你寫得太長，就會佔掉大量上下文空間，導致真正重要的資訊被稀釋。模型不是不讀，而是注意力會分散，最後更容易漏掉你最在意的規則。

官方建議通常是最好不要超過 400 行。

我自己的習慣會更保守一些，盡量控制在 200 行以內。

`CLAUDE.md` 的常見作用範圍

CLAUDE.md 實際上有不同的放置層級，對應不同的作用範圍。最常用的是兩個：

1. User Level

這是全域層級。

它放在你的電腦環境裡，對你本機操作的所有專案都有效。

這個位置適合放：

你的身份資訊
通用的溝通偏好
你跨專案都適用的做事習慣
全域性的安全規則

例如，如果你的時區不是常見的預設值，而是曼谷時間，那這類資訊就很適合放在 user level，這樣模型之後幫你安排時間時就不容易出錯。

2. Project Level

這是專案層級。

它放在具體專案目錄下面，只對那個專案有效。

這個位置適合放：

專案專屬背景
只在這個專案裡成立的規則
專案目錄結構說明
這個專案的重要文件入口

舉例來說，如果一個專案處理財務，另一個專案處理人事，那兩邊的背景和限制顯然不同，就不應該混在同一個全域說明裡。

怎麼判斷該放哪一層

判斷方式其實很簡單：

你寫進去的東西，如果換到另一個專案裡還成立，那就放 user level。

如果一換專案就不成立，那就放 project level。

怎麼開始寫第一版

最常見的起手方式有兩種：

1. 用 `/init`

你可以直接在終端執行斜線命令 /init，讓 Claude 掃描目前專案，自動幫你生成一份基礎版 CLAUDE.md。

2. 讓 Claude 幫你整理

你也可以直接讓 Claude 去搜尋別人怎麼寫 CLAUDE.md，再結合你的情況問你問題，最後幫你整理成適合你自己的版本。

很多時候，這會比自己從零開始寫輕鬆得多。

一個很實用的習慣

在你和 Claude 長期協作的過程中，只要你發現某件事情屬於「以後一定要記住、不要再犯」的內容，就可以直接讓它寫進 CLAUDE.md。

不過寫之前，還是要先判斷：

這是全域規則
還是目前專案規則

不要把所有東西都塞進同一個檔案裡。

第二層：`Rules`

接下來是 Rules。

它和 CLAUDE.md 最大的差別，不是檔案形式，而是載入方式。

CLAUDE.md 是無論你做什麼，模型都會讀到。

而 Rules 的優勢在於：可以條件載入。

也就是說，只有在某些路徑、某些檔案、某些工具或某些場景下，這條規則才會被讀到。

為什麼條件載入很重要

因為上下文空間永遠是稀缺資源。

如果所有規則都無差別塞進上下文裡，就會發生兩件事：

模型負擔變重
真正關鍵的規則反而被淹沒

按需載入的價值就在這裡：讓模型在剛好的時候讀到剛好的資訊。

什麼時候該把規則從 `CLAUDE.md` 挪到 `Rules`

通常有兩種情況：

1. `CLAUDE.md` 太長了

如果你的 CLAUDE.md 開始超過 200 行，規則越來越多，重要內容被稀釋，那就該考慮把一部分規則拆出去。

2. 某些規則只和特定路徑相關

如果你已經很明確知道某些規則只在某些類型的檔案裡才有意義，例如：

只對 Python 腳本有效
只對某個 hooks 目錄有效
只對某個子專案有效

那這些規則就更適合移到 Rules。

`Rules` 最適合的場景

最典型的就是「特定情境、特定路徑、特定檔案類型」。

例如：

只在處理 hook 檔案時觸發的規範
只在某類腳本中要遵守的編碼規則
只在某個目錄下適用的工作方式

這些內容如果繼續塞在 CLAUDE.md 裡，其實不太划算。

第三層：`Memory`

第三個層面是 Memory。

它和 CLAUDE.md、Rules 一樣，也會進入模型上下文，但它最核心的差別是：

CLAUDE.md 是你主動設定的。

Memory 更像是 Claude 在協作過程中，寫給自己的筆記。

`Memory` 記的是什麼

當 Claude 判斷某件事值得記住，或需要短期保留，它就會把這些內容寫進 Memory。

常見內容包括：

你糾正過它的某種做法
你最近新增的偏好
當前專案的暫時狀態
你今天沒做完、明天還要繼續的事
你最近在跟哪些人合作
某些最近才提到的個人資訊或上下文

換句話說，Memory 更像動態知識，而不是長期制度。

`Memory` 和前兩者的差別

一個簡單的區分方式是：

CLAUDE.md / Rules：偏長期、偏制度、偏明確規則
Memory：偏暫時、偏動態、偏工作過程中的新理解

如果某件事只是在最近幾天有效，或專案狀態持續在變，那它通常更適合放進 Memory，而不是寫成長期規則。

`Memory` 也可以手動寫

雖然 Memory 有自動整理能力，但你也可以主動告訴 Claude：

請記下來我明天要做什麼
請記下來我要追蹤誰的狀態
請記下來這個月某個專案的關鍵節點

它也可以幫你寫進 Memory。

你也可以透過斜線命令 /memory 查看目前有哪些記憶，並手動編輯或刪除。

不過很多時候，我自己不會太頻繁手動維護，因為 Claude 本身也會定期整理這些記憶，把已經過時的部分清掉。

第四層：`Hooks`

最後也是最重要、最進階的一層，就是 Hooks。

前面講到的 CLAUDE.md、Rules、Memory，本質上都還是自然語言說明。

你寫了規則，模型通常會遵守，但它本質上仍然是在「理解之後再執行」。

只要還停留在自然語言，就會存在幾個問題：

模型偶爾會漏掉
規則太多時，注意力會分散
某些情境下，它會自己判斷這條規則不重要

這不是你寫得不夠認真，而是自然語言規則本來就很難做到 100% 強制。

`Hooks` 的本質是什麼

Hooks 不再是自然語言說明，而是一段腳本。

它是事件觸發的、程式層級的強制邏輯。

只要某個事件發生，這段邏輯就一定會執行，不會被模型「自己判斷後略過」。

這就是 Hooks 最關鍵的價值：

把「建議遵守」變成「必須執行」。

什麼時候該上 `Hooks`

當你發現某條規則已經寫進 CLAUDE.md 或 Rules，但 Claude 偶爾還是不執行，而且這件事一旦漏掉，風險又很大，那就應該考慮把它改成 Hooks。

簡單說：

低風險的，用規則
高風險的，用 Hooks

最典型的 `Hooks` 場景

最典型的，就是那些你絕對不希望出錯的動作，例如：

發郵件前必須確認
發 Slack、Outlook、Gmail 訊息前必須確認
刪除危險檔案前必須攔截
偵測到要外發密碼或 API Key 時必須阻止

如果這些要求只是寫成一句自然語言規則，模型有可能哪天真的忙中出錯，就送出去了。

但如果寫成 Hooks，只要事件發生，就會被強制攔截。

這才是程式層面的硬防線。

`Hooks` 常見的觸發時機

Hooks 可以設定在很多不同階段，例如：

對話剛開始時注入提醒
某個工具執行前先做檢查
某個工具執行後做結果校驗

你不一定需要自己知道那些專業術語。

很多時候，只要你能清楚描述需求，再讓 Claude 幫你判斷這條規則適不適合改成 hook，它就能幫你一起設計。

你也可以透過斜線命令 /hook 查看系統目前已經設定了哪些 hooks。

一套更實用的上手順序

如果你想把這四層串起來，我自己更推薦下面這條路徑：

第一步：先用 `/init` 生成基礎版 `CLAUDE.md`

不要一開始就手寫一份特別完整的規則文件。

先讓 Claude 幫你掃描專案，生成一個起點版本，再慢慢迭代。

第二步：邊用邊補

在協作過程中，只要你發現：

這件事以後一定要記得
這個錯誤以後不能再犯
這個偏好以後每次都適用

就讓 Claude 幫你寫進 CLAUDE.md。

第三步：當 `CLAUDE.md` 變長時，拆到 `Rules`

一旦你發現 CLAUDE.md 越來越長，模型開始不一定遵守每一條規則，就該考慮拆分：

哪些是全域規則
哪些只和某些路徑相關

把後者移到 Rules，改成條件載入。

第四步：再把高風險規則升級成 `Hooks`

如果某些規則即使寫了，模型還是偶爾會漏，而且漏掉代價很高，那就不要再停留在自然語言層面，直接升級成 Hooks。

也就是把「提醒」變成「強制」。

第五步：把暫時狀態交給 `Memory`

對於那些會過期、會變化、不是長期制度的內容，不要一股腦全寫進 CLAUDE.md。

更合適的做法是交給 Memory：

當前專案進度
最近合作對象
最近新增偏好
近期計畫和待辦

這樣上下文會更清爽，模型也更容易保持穩定表現。

這四層分別該記什麼

如果你想快速記住，可以直接用下面這個區分：

CLAUDE.md：長期默契、全域說明、專案基礎背景
Rules：按路徑或場景載入的專項規則
Memory：動態知識、暫時狀態、最近學到的東西
Hooks：高風險操作的程式級強制攔截

結語

很多人把 Claude Code 當成「會寫程式的聊天介面」，但真正用深之後，你會發現它更像一個長期協作的智慧工作台。

關鍵不只是你每次怎麼下指令，而是你有沒有給它一套穩定、清楚、能長期累積的環境。

一旦你把這四層搭起來：

CLAUDE.md
Rules
Memory
Hooks

你和模型之間的協作品質，通常會有非常明顯的提升。

因為你終於不是每次都從零開始解釋自己是誰、怎麼工作、哪些事不能做，而是把這些真正沉澱成了環境的一部分。

這才是把一個強模型，真正用成成熟工具的關鍵一步。

Memory on KnightLi的博客

ChatGPT、Claude Code 和 Gemini 的記憶機制有什麼不同？

ChatGPT：圍繞人的長期偏好

Memory Sources：讓個性化來源更可見

Claude Code：圍繞程式碼庫和工程規則

Claude Code Auto Memory：自動累積項目經驗

Gemini：圍繞 Google 生態上下文

三者核心差異

該怎麼選擇和使用

一個實用分工

簡短判斷

相關連結

ChatGPT Release Notes 更新：記憶來源、GPT-5.5 Instant 和表格插件

Memory sources：個性化要更透明

記憶控制仍然是關鍵

GPT-5.5 Instant 成為預設模型

個性化和預設模型結合起來

ChatGPT for Excel 和 Google Sheets

使用限制和安裝方式

近期更新脈絡

簡短判斷

相關連結

Claude Code 環境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次講清

為什麼環境配置比單次提示詞更重要

第一層：CLAUDE.md

CLAUDE.md 適合寫什麼

一個很重要的原則：盡量精簡

CLAUDE.md 的常見作用範圍

1. User Level

2. Project Level

怎麼判斷該放哪一層

怎麼開始寫第一版

1. 用 /init

2. 讓 Claude 幫你整理

一個很實用的習慣

第二層：Rules

為什麼條件載入很重要

什麼時候該把規則從 CLAUDE.md 挪到 Rules

1. CLAUDE.md 太長了

2. 某些規則只和特定路徑相關

Rules 最適合的場景

第三層：Memory

Memory 記的是什麼

Memory 和前兩者的差別

Memory 也可以手動寫

第四層：Hooks

Hooks 的本質是什麼

什麼時候該上 Hooks

最典型的 Hooks 場景

Hooks 常見的觸發時機

一套更實用的上手順序

第一步：先用 /init 生成基礎版 CLAUDE.md

第二步：邊用邊補

第三步：當 CLAUDE.md 變長時，拆到 Rules

第四步：再把高風險規則升級成 Hooks

第五步：把暫時狀態交給 Memory

這四層分別該記什麼

結語

第一層：`CLAUDE.md`

`CLAUDE.md` 適合寫什麼

`CLAUDE.md` 的常見作用範圍

1. 用 `/init`

第二層：`Rules`

什麼時候該把規則從 `CLAUDE.md` 挪到 `Rules`

1. `CLAUDE.md` 太長了

`Rules` 最適合的場景

第三層：`Memory`

`Memory` 記的是什麼

`Memory` 和前兩者的差別

`Memory` 也可以手動寫

第四層：`Hooks`

`Hooks` 的本質是什麼

什麼時候該上 `Hooks`

最典型的 `Hooks` 場景

`Hooks` 常見的觸發時機

第一步：先用 `/init` 生成基礎版 `CLAUDE.md`

第三步：當 `CLAUDE.md` 變長時，拆到 `Rules`

第四步：再把高風險規則升級成 `Hooks`

第五步：把暫時狀態交給 `Memory`