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:35:00 +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` 最适合的场景

最典型的就是“特定情境、特定路径、特定文件类型”。

比如：

只在处理 hooks 文件时触发的规范
只在某类脚本中要遵守的编码规则
只在某个目录下适用的工作方式

这些内容如果继续塞在 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`