企业官网建设流程全解析

上周一我打开 Claude Code，准备接着做支付模块的重构。前一天我明明已经和它把方案聊得很透了：项目统一用 pnpm、测试框架是 vitest、支付回调在src/modules/payment/callback.ts、重构时不要动 stripe SDK 的版本。结果新的会话一上来，它先客客气气地问我：“这个项目是用 npm 还是 pnpm？测试用 jest 可以吗？”

那一瞬间我真想把屏幕合上。这就是 Claude Code 这类终端产物目前最尴尬的短板：在单次会话里它是近乎完美的结对编程对象，但一旦会话关闭，它对你的项目就只剩“路人记忆”。而 claude-mem 这个开源工具想填的坑，恰好就是这个——它通过非常克制的机制，把“会话结束后的经验”自动沉淀成“下个会话开头的记忆”，让我不用再花十分钟跟 AI 科普自己的项目。

这篇文章我会基于自己这段时间的实测来写，不搞 PPT 式介绍。包括它的工作原理、安装接入、真实效果、踩过的坑，以及和CLAUDE.md、--resume这些官方方案之间到底怎么配合。如果你也是 Claude Code 的重度用户，对“每次新开会话 AI 就失忆”感到烦躁，这篇应该能帮你少走不少弯路。

1. 金鱼记忆的代价：Claude Code 为什么“出了会话就不认识你”

1.1 你大概率经历过的失忆场景

Claude Code 本身的能力毋庸置疑，尤其在单会话里连续改十几个文件、跑测试、修 bug 这种长链路任务上，它表现得很像一位耐心的同事。但问题恰恰出在“会话”这个边界上。

我遇到过三种高频失忆场景：

• 跨天续工。昨天下午刚讨论完的方案，第二天早上新开会话，它完全不记得。你说“继续昨天的重构”，它只能靠读代码猜，猜错方向的话，返工成本比重新聊一遍还高。
• 跨项目切换。手头同时维护三四个仓库，每个项目的包管理器、测试工具、代码风格都不一样。Claude Code 默认不感知这些差异，经常用 A 项目的习惯去改 B 项目的代码。
• 重复犯错。今天刚纠正过“不要在 service 层直接操作数据库”，明天新会话又写出一模一样的代码。你只能再纠正一遍，然后祈祷它这次记住——但基本记不住。

网上有人调侃这是“金鱼记忆”，本质上是因为 Claude Code 每个会话的上下文窗口都是独立初始化的。它没有“长期记忆”这个概念，除非你把信息放进CLAUDE.md，或者手动通过--resume把历史会话的上下文重新拉起来。

1.2 官方方案为什么不够用

Anthropic 其实给过几个官方路径，我挨个试过，各有各的别扭。

--resume和--continue这类参数，本质是把之前的会话日志原封不动地塞回上下文窗口。好处是“无缝续聊”，坏处是它把记忆和原始对话日志画了等号。一个跑了三小时的会话，日志可能有几十万 token，你想要的是“结论”，但它回放的是“全过程”。而且这种原始日志只能用于同一段会话的延续，换个新任务、新仓库，照样归零。

CLAUDE.md则是另一套思路：在每个项目里放一份静态说明文件，告诉 AI 这个项目的约定、结构、命令。它适合写“永远成立”的东西，比如构建命令、目录规范、不要做什么。但问题在于它需要手动维护。我自己深有体会：新项目头两周还会认真更新CLAUDE.md，后面忙起来就忘了。等到项目里有一堆过时说明、甚至和现状冲突时，AI 照着它做，反而比没有它更让人血压升高。

所以我的结论很简单：官方方案解决的是“会话怎么恢复”，而真正缺失的是“项目经验怎么沉淀”。这正是 claude-mem 切入的位置。

1.3 claude-mem 想解决的，是“沉淀”这件事

claude-mem 是一套基于 Claude Code 官方 hook 机制实现的外部记忆工具，发行在 Python 生态里，用pipx或uv tool安装。它不修改 Claude Code 本体，也不劫持对话，而是作为“旁路观察者”存在：会话进行时记录关键信息，会话结束后提炼成结构化记忆，下一次会话开始时主动把相关记忆注入到上下文里。

它和CLAUDE.md最大的区别是：不需要我动手写。它自己能从对话里判断什么东西值得记、什么东西只是临时闲聊。它和--resume最大的区别是：它沉淀的是“结论”而不是“日志”，所以在成本上要经济得多。

我第一次感受到它的价值，不是某个瞬间的“惊艳”，而是一种“终于对了”的踏实感——周五下班前我跟 AI 说“下周一继续改这个模块”，周一一上班，它真的知道我们在改哪个模块、怎么改的、改到哪一步了。

2. 它凭什么能记住：hook 机制 + 摘要提取 + 向量召回

2.1 Claude Code 的 hook 体系，是外部工具接进来的钥匙

Claude Code 从很早期开始就支持 hooks，简单说就是：在整个会话生命周期中的某些时间点，触发你配置的外部脚本，脚本可以读取上下文、执行命令、把输出返回给 Claude Code。常见的事件类型包括用户提交 prompt 时（UserPromptSubmit）、工具被调用前后（PreToolUse、PostToolUse）、会话结束（Stop/SessionStart）等等。

claude-mem 的思路很直接：在SessionStart时初始化会话状态，在UserPromptSubmit时注入记忆，在PostToolUse或Stop时沉淀记忆。装好之后，你的settings.json里会出现一节 hooks 配置，指向 claude-mem 提供的几个子命令。它不是一个常驻进程，而是一堆会在特定时机被 Claude Code 自动拉起的 CLI 脚本，每个都干特定的事。

我一开始担心“用 hook 做记忆注入，会不会拖慢每次对话”？实测下来，它的注入逻辑不是每个 prompt 都跑，而是倾向于在合适时机插入，比如会话开头的第一个 prompt。即便每次都跑，本地脚本加检索的开销也就是几百毫秒级别，远没有模型推理耗时明显。

2.2 写入流程：从“对话噪音”里提炼出“值得记忆的东西”

claude-mem 真正核心的部分是“提炼”。它不会把一整段对话原封不动存进数据库，那样和--resume就没区别了。它的默认做法是：在会话告一段落时，调用一次 LLM，把当前会话的上下文摘要输入进去，问它“这段会话里有哪些信息值得长期记住”。

什么样的东西算“值得记住”？从我的使用经验来看，大概能归纳成几类：

• 用户偏好：比如“这个项目里作者更喜欢用ruff而不是black”。
• 技术决策：比如“支付模块决定用 Stripe 的 webhook 事件驱动，不改 SDK 版本”。
• 项目事实：比如“测试目录是tests/，CI 脚本在.github/workflows/ci.yml”。
• 进度状态：比如“用户重构到一半，callback.ts已经改成异步，但refund流程还没动”。

这套“提问式提炼”的设计让我觉得它很聪明。因为对话日志本身就是大量噪音夹杂少量信号，人工都很难快速总结，如果靠简单的关键词抽取，效果会非常差。claude-mem 把“总结”这件事委托给 LLM，等于是在保留语义理解能力的同时，把存储体积压缩到了极小。

2.3 读取流程：每次开局，先“想”起和当前事项最相关的记忆

到了下一次新会话，claude-mem 会做一次“回忆”操作。它读取当前项目目录，结合你正在处理的内容，去记忆库里做一次相似度检索，把最相关的几条记忆取出来，拼成一段精炼的“记忆上下文”，注入到 Claude Code 的 prompt 前面。

它不是把记忆库里所有东西都灌进去——那样成本太高，而且信息多了反而干扰模型。它更像一种“按需唤醒”：你在改支付模块，它就把支付相关的决策翻出来；你在写测试，它就把测试约定翻出来。这个检索用的是向量相似度。每条记忆在写入时都会生成向量表示，存进索引里；检索时把当前项目路径或者用户 prompt 也转成向量，然后找出最相近的 top-k 条。

我自己理解这套机制时打了个比方：它像一个人的“长期工作记忆”——不是把所有日记本都摊开，而是你刚坐下提了一句“今天继续改支付”，它就凭着这句话联想到支付模块相关的几页笔记，摆在桌面上。桌面只放这几页，其他全在抽屉里。抽屉就是 SQLite 数据库和向量索引。

2.4 落地存储：SQLite + 向量，轻量但够用

claude-mem 默认把所有记忆数据放在用户目录下的一个独立文件夹里（不同机器上位置略有差异），核心是 SQLite 数据库加向量索引文件。这样做有几个好处：单个用户的数据量很小，日常对话级的使用撑不起多大的库；不依赖网络服务，属于本地优先；备份和迁移也很直白，直接拷贝目录就行。

它在权限设计上也踩了我想过的点：默认只读取它自己的存储目录，不主动扫描整个文件系统，更不会偷偷读你的代码库。所以如果你对隐私比较敏感，第一件该做的事就是确认它写入了哪些路径、有没有跟云端服务通信。

3. 从零到一接入 claude-mem：我的安装路径和首次验证

3.1 安装前要准备的几件事

如果你也想试，建议先确认系统里有 Python 3.10 以上环境。我自己用的是 macOS + 国内开发者常用的一整套终端环境，安装过程没什么特殊之处。另外因为它的一部分“提炼”能力要调 LLM 接口，所以你得有一个可用的模型 API 配置——支持 Anthropic 自家模型，也支持 OpenAI 兼容接口，甚至能配到本地 Ollama 上。

这里有个容易踩的坑：很多人以为装了 claude-mem 之后它自带模型，免费就能跑。不对。它本质是个“壳”，核心的记忆提炼还是要借助模型能力。不过好消息是它对模型大小没那么挑剔，我用过好几档配置，体验差异主要集中在“总结得精不精炼”上，不至于完全不能用。

3.2 安装和初始化

安装过程非常短。两条命令的功夫：

uv tool install claude-mem claude-mem init

init会帮你做两件事：生成默认配置文件，同时把 hook 配置写入 Claude Code 的settings.json。如果你只想针对某个项目启用，可以在项目根目录下执行，这样 hook 会落到项目的.claude/settings.json；如果想全局生效，就放到用户全局配置里。我个人的建议是：新手期先项目级启用，搞懂后再全局启用，避免一上来就在所有项目里注入记忆，互相污染。

初始化完成后，它会在启动时自动创建记忆库目录。这个时间点你可以打开settings.json瞧瞧，里面应该多了几个 hooks 条目，分别指向 claude-mem 的 session-start、prompt-submit、stop 之类的处理器。

3.3 让第一条记忆诞生的验证实验

装完之后怎么验证它真的在干活？我的做法是做一个“有意识”的实验：

1. 新开一个 Claude Code 会话，故意说一些明确的约定和决策。比如“以后这个项目所有数据库操作都走 repository 层，不要在 controller 里直接写 SQL”。
2. 正常干一轮活，让会话自然结束，或者主动退出。
3. 再过几分钟，去看记忆库目录，确认文件已经被创建和更新。
4. 再开一个新会话，随便说一句“继续之前的工作”，然后观察 Claude Code 开头是不是多了一段“记忆上下文”，里面包含上一步那个约定。

我第一次验证的时候，第二条会话确实冒出来一句类似“该项目的长期记忆：数据库操作必须通过 repository 层”的提示，当场就有点小激动。这种“自动写入 + 自动召回”的闭环一旦跑通，后面的使用就顺了。

3.4 hook 不生效时的排查思路

如果验证发现它没反应，不要慌，大概率是以下几个原因：

• settings.json写错了位置。Claude Code 的 hook 我印象里按“项目级优先于用户级”的规则合并，如果你两处都配了，要确认是不是项目级配置覆盖了全局配置。
• Python 环境对不上。用uv tool安装后在PATH里能找到claude-mem，但 Claude Code 触发的 hook 脚本可能用的是另一个 shell 环境，找不到命令。最简单的排错是先在终端手动跑一遍 hook 对应的命令，看有没有报错。
• 模型 API 没配好。第一次提炼时如果请求失败，它通常会静默跳过而不是打断你开会话。别指望它弹窗报错，主动去日志里看才能发现问题。

我见过不少人卡在第三步，因为 Claude Code 的settings.json里 hook 配置很灵活，一不小心就容易写串。如果你对 JSON 结构没有十足把握，claude-mem init生成的版本是最稳的，后面尽量手动编辑增量项，别整体重写。

4. 接入之后，它到底记住了哪些“真正值钱”的东西

4.1 项目约定和技术栈偏好，是最立竿见影的

我用 claude-mem 大概两周后，感受最明显的是“重复科普”少了很多。拿一个实际例子：我手头有个 Python 项目，早期我明确说过“用 uv 管依赖、用 ruff 做 lint、测试用 pytest，不要用 pip 和 black”。这条约定进了记忆库。之后不管我隔几天再去动这个项目，新会话里的 Claude Code 都能在开头读到这条，写代码的时候会自动切换到对应工具，不用我再强调一遍。

这种效果非常像给团队新同事发的“前三天必读”文档，只不过这次是 AI 自己在维护这份文档。而且它是通过观察我的真实对话主动提炼的，不是我手动记录的，所以我忘写文档的问题也被绕过去了。

4.2 架构决策与迁移进度，是长线会话最需要的锚点

比工具偏好更重要的是架构层面的决策。你想想，一个项目做三个月，期间会做几十个有得有失的技术选型：为什么用这个方案而不用那个、哪个模块准备拆掉、哪块的兼容性不能动。这些决策如果只存在某个历史会话的日志里，下次基本等于不存在。

claude-mem 能把这类决策单独沉淀成条目。我就遇到过一次：三个礼拜后我在另一个分支上想重写一个模块，正犹豫要不要换掉当时那个有点笨拙的实现，结果 Claude Code 在记忆上下文里提到了“当初决定保留这个实现是为了兼容旧客户端”，我立刻打消了重构念头。这种“想起当初为什么这么做”的能力，比单纯记住工具命令要值钱得多。

4.3 搜索旧记忆，等于给自己配了一个“项目笔记本”

除了自动注入，claude-mem 还提供了手动查询的能力。比如我经常会问它“我们之前讨论过关于缓存方案的结论是什么”或者“我们在某个会话里决定过不采用 ORM 吗”，它会去记忆库里做检索，然后返回相关条目。

这个能力让我觉得它不只是“备忘录”，更是“索引”。它把散落在不同时间段、不同项目里的决策串成了一张可以随时查的网。对多项目并行的人来说，这种“快速翻旧账”的能力非常省心：不用再一个个翻历史会话，也不用靠CLAUDE.md里那点干巴巴的文字猜测。

当然，它不可能是完美的。我后面会说它有哪些边界——它记不住“进行中的待办清单”，它也不理解“复杂而微妙的人类权衡”，它只擅长记录“明确说出口的话”。但工具能做好这一点，已经超过我预期了。

5. 不是神话：claude-mem 的成本、误记忆和隐私边界

5.1 成本怎么算？不是工具本身贵，是“提炼”要吃 token

claude-mem 本身免费开源，但这不代表零成本。每次会话结束做记忆提炼，本质上是调一次 LLM，我按自己比较忙的一天做过粗略估算：一天大概开七八个会话，每个会话结束时做一次上下文摘要。按主流的模型价格算，一次摘要的 token 消耗可能在几千到一万 token 上下，一天下来不到一块钱，一个月也就是十几块的量级。对个人开发者来说基本不敏感，但对重度使用者来说，这笔账值得心里有数。

另外，每次会话开始注入的记忆也会占用一部分 prompt token。如果注入不善，会把长上下文喂得更满。我自己一般会控制记忆注入条数，宁可少注入几条最相关的，也不要一次性塞一堆边角料。这里的关键词是“克制”。

5.2 记忆污染：它会固执地把错事记一辈子

claude-mem 最让我头大的问题，是“错误记忆的惯性”。它有段时间记住了“这个项目已经迁移到 pydantic v2”，但实际情况是迁移只做了一半，模型层还没改完。结果我在另一个分支上做新功能，它上来就按“已经迁移完”的前提写代码，报错之后我花了好久才反应过来，问题是它记忆里的前提错了。

这类问题很难靠工具本身解决，因为它无法判断“用户随口说的”和“用户深思熟虑后确定的”之间的区别。我的应对办法是：碰到明显可疑的记忆时，直接在 prompt 里纠正它并强调“不要遵循这条记忆”；过一段时间，把记忆库里过时或者错误的条目删掉。claude-mem 提供了查看和删除记忆的手段，但需要你自己养成“定期清理”的习惯，否则错误条目就会像滚雪球一样越滚越大。

5.3 隐私边界：代码和决策到底去了哪

记忆提炼要调 API，这意味着你的对话内容以及被提炼出来的项目决策，会经过模型提供方的服务器。如果你写的是闭源商业项目或者带敏感信息的代码，这个点一定要想清楚。

我自己的处理方式是分两层：个人玩具项目和开源项目，随便用云端模型，省心；公司内部或者有保密要求的代码，把记忆提炼的模型指向本地 Ollama，或者干脆不开 claude-mem。你可以在 claude-mem 的配置文件里指定 provider，不必全局绑死一个。安全性不是这家工具的问题，而是“任何外部记忆工具”都要面临的共同边界。

6. 该不该用它：和 CLAUDE.md、--resume、MCP 知识库的横向选择

6.1 一条简单的对比

有人问我 claude-mem 是不是能完全替代CLAUDE.md和--resume，我的答案是不能，也不该那么用。下面是我做的一张对比表：

能看出来，CLAUDE.md的强项在于“规则性”、--resume的强项在于“延续性”、claude-mem的强项在于“积累性”。三者本质上解决不同阶段的问题：进场的时候靠规则，中场的时候靠日志，长期靠记忆。

6.2 我自己实际用的组合方式

现在的标准流程是这样的：

1. 项目根目录放一份精简的CLAUDE.md，只写“雷打不动”的规范，比如目录结构、构建命令、禁止事项。
2. 日常工作全部开着 claude-mem，让它自动沉淀会话经验。
3. 如果某个任务因为被打断而需要当天继续，用--resume续上下文。
4. 每隔一两周，翻一遍 claude-mem 的记忆库，删掉过时的，修正错误的。

这套组合用下来比任何单一路径都舒服。CLAUDE.md承担“宪法”的角色，claude-mem 承担“日记”的角色，--resume承担“临时便签”的角色。各管一摊，互不干扰。

7. 进阶玩法：把 claude-mem 从“个人助手”变成“团队记忆库”

7.1 共享记忆库：让新同事的 AI 也“认识”这个项目

claude-mem 的存储是本地目录，但这个特性也意味着你可以把它做成团队共享。做法不复杂，把记忆库目录放到一个团队都能访问的同步目录里，然后把 claude-mem 的 store 路径指过去。这样，你在会话里沉淀的决策，同组其他人新开会话时也能读到。

但我得提醒一句：SQLite 在多人同时写入的场景下可能会出问题。我的建议是不要“实时共享”，而是每天收工前手动同步一次。团队小、节奏慢的时候这样最省心。真正要做成多人实时协作，还是得考虑更复杂的后端方案，个人工具级别的产品不会自动适配那种场景。

7.2 用 Git 提交信息喂养记忆

有过一个我觉得很值得尝试的玩法：把 Git 提交记录作为记忆来源。具体做法很简单，写个钩子脚本，在每次 commit 或 merge 之后，把 commit message 喂给 claude-mem 做一次提炼。Commit message 本身就是高度浓缩的“发生了什么”，很适合变成记忆条目。

我试过的效果是：AI 对项目“最近发生了什么”的感知变得很敏锐。它知道“前天刚把用户模块的数据库层迁移到 repository 模式”，所以在新会话里提到这块代码时，它会基于最新状态去理解，而不是基于几个月前的旧结构。

7.3 记忆卫生：定期 review 比追求“记得多”更重要

随着使用时间拉长，记忆库一定会膨胀。我踩过一个很明显的坑：初期舍不得删任何东西，结果记忆里充满了细碎无用的条目，比如“用户今天不想用某个颜色”这种一次性偏好。这些噪音反向干扰注入效果。后来我养成了每周 review 一次的习惯，把明显过时或没营养的条目清掉。

另外值得注意：claude-mem 的记忆注入会有条数上限，如果不做清理，新项目里最相关的记忆可能会因为历史噪音太多而排不上号。记忆这个东西，不是越多越好，而是越对越好——这一点在人和 AI 身上都一样。

最后再分享一个小感受。刚开始用 claude-mem 那几天，我并不觉得它有多神，甚至觉得它记录的内容有点“普通”。但用了一个多月后，有一天我在一个搁置了三周的项目里重新开会话，Claude Code 开口就提到了三周前我们确定的技术选型，我没有解释任何背景，直接进入了开发状态。

那一刻我意识到，claude-mem 这类工具真正改变的不是“AI 的记忆力”，而是我作为开发者的协作方式——以前我是那个每次都要重新介绍项目的人，现在 AI 变成了那个真正“记得我们怎么走到这一步”的同事。如果你也烦透了“每次开会话都像第一次见面”的体验，给它一个周末的时间，你大概率会愿意把它留在工作流里。