企业官网建设流程全解析

你有没有遇到过这种情况：和 Claude Code 聊了一整个下午，把项目结构、技术路线、历史包袱都交代清楚了，第二天开个新会话，它又像刚入职的实习生，连你昨天反复强调的"这个模块别动"都完全不记得。我一开始觉得这是小事，无非是把上下文再粘一遍，但项目一复杂起来，每轮都要重复背景、重复约束、重复踩坑记录，很快就受不了了。后来我接入了 claude-mem，相当于给 Claude Code 装了一个外挂大脑，会话结束自动存，新会话自动调取。这篇就把我接入、使用、踩坑、调优的完整过程写下来，给同样被上下文折磨的人一个能直接抄的作业。

claude-mem 是个开源工具，核心思路很朴素：把 Claude Code 每次会话的内容沉淀成本地记忆，下次会话开始时按需塞回上下文。它不依赖云端、不额外调大模型接口，存储和检索都在本地完成。和手动维护 CLAUDE.md 相比，它最大的优势是自动化——你不需要自己总结，它会在会话结束后做结构化提取。这篇文章适合所有用 Claude Code 做日常开发的工程师，尤其是多项目并行、经常隔几天才继续同一个任务的人。

1. 为什么 Claude Code 需要外挂记忆：上下文窗口的物理限制

1.1 每次新会话都是一次"选择性失忆"

Claude Code 默认情况下，会话和会话之间是隔离的。它确实会读取项目里的 CLAUDE.md 作为长期指令，也会在启动时扫描项目代码，但是——它不记得你在上一次会话里说过什么、发现过什么、决定过什么。你昨天排查了两个小时的 bug，今天新开窗口让它继续，它只会给你一个礼貌的"我从头看一下"。

这个问题的根源是上下文窗口本身。窗口不是无限大，哪怕是接近百万 token 的模型，也扛不住把一个长项目的历史对话全部塞进去。所以 Claude Code 的原生设计就是"轻装上阵"：每次会话带基础设定，具体上下文靠你现场提供。这在短会话里没问题，但一旦任务跨越多个工作日、涉及大量项目背景和约定，效率就断崖式下跌。

1.2 手动维护 CLAUDE.md 的三宗罪

很多人（包括我早期）的解决办法是把结论往 CLAUDE.md 里写。这个方案能用，但很难坚持，原因有三：

• 总结靠自觉，忙起来根本不记得写。
• 写进去的内容全是"我认为重要的"，而模型的检索逻辑和人不一样，它不一定在最需要的时候读取对应的段落。
• 文件会越来越长，最后变成一坨什么都写、什么都说不清的说明文档，反而稀释了真正关键的指令。

还有一个更隐蔽的问题：用户偏好和项目事实混在一起。比如"我习惯用 pnpm 而不是 npm"这种个人偏好，和"这个仓库的构建产物在 dist/ 下"这种项目事实，本该用不同的管理方式、不同的召回优先级。写在同一个文件里，只能靠模型现场判断，效果很不稳定。

1.3 claude-mem 的定位：会话记忆，而不是文档

claude-mem 解决的正是这个"会话记忆"空白。它的设计思路是把记忆按类型拆开：整段会话历史、从对话里提炼的偏好和事实、以及长期有效的操作流程。存储上它用本地 SQLite，配合向量检索做相似度召回；接入上它利用 Claude Code 的 hooks 机制，在会话开始和结束时自动运行，不需要你手动触发。

我第一次跑通时的感受是：它填补的不是"文档管理"的坑，而是"记忆管理"的坑。文档需要人主动维护，记忆是模型工作时的副产物，自动沉淀、自动调取，这才是它和其他方案本质的区别。

2. 三套记忆系统拆解：episodic、semantic 与 procedural 如何分工

claude-mem 把记忆拆成三种类型，这个分类不是随意的，它对应了人类记忆研究的经典框架。搞清楚三者边界，你就知道为什么它比"把所有东西塞进一个文件"更聪明。

2.1 Episodic Memory：整段会话的时间胶囊

episodic memory 存储的是"发生过什么的完整记录"。在 claude-mem 里，每一次 Claude Code 会话结束，它会把这段会话的缩略记录存成一个 episode，包含时间戳、会话主题、关键结论和任务状态。

我理解它的作用是"回到现场"。比如三天前你和一个 agent 子代理一起排查线上问题，聊了很多零散的中间线索，这些线索单独看都不重要，但它们共同构成了排查脉络。第二天你只需要说"继续昨天的排查"，claude-mem 检索到对应的 episode，把脉络带回上下文，模型就能接上话，而不是从零重新开始。

存储上，episode 的正文会做向量化。默认用的是本地轻量 embedding 方案，不调用外部 API，所以没有额外的成本和隐私顾虑。向量化的意义在于：不需要精确匹配关键词，你说一句"上次那个权限问题"，它能按语义找到对应的会话记录。

2.2 Semantic Memory：偏好与事实的提炼

和 episodic 的"整段记录"不同，semantic memory 存的是从对话中提炼出来的、可独立复用的命题式知识。比如：

• 用户偏好："这个项目统一用双引号，不用 prettier。"
• 项目事实："线上部署走 GitHub Actions，手动部署的流程已废弃。"
• 技术决策："为什么这里选了 Postgres 而不是 MySQL。"

这些内容如果只在某次会话里出现，下次就丢了，非常可惜。claude-mem 在会话结束时会对对话内容做提取，把这类"值得长期记住"的句子单独入库。每次新会话启动时，它会做一次相似度检索，把最相关的 semantic memory 注入系统提示词。

我个人的体会是，semantic memory 是最能减少重复沟通的部分。以前我每次开新会话都要重新交代"这个项目别用 localStorage 缓存登录态，有安全坑"，有了它，我只需要说"按记忆来"，它自己就知道。

2.3 Procedural Memory：怎么做事的流程沉淀

procedural memory 管的是"流程性知识"。它更接近操作手册，比如：

• 发布流程分几步，每一步跑什么命令。
• 加一个新 API 要同步改哪些文件。
• 处理某个报错的标准排查顺序。

这类知识和"事实"不同，它是有步骤、有顺序的。claude-mem 会从你的历史会话里识别这类内容，沉淀成可复用的流程。在和 Claude Code 的 agent 模式配合时特别有用——子代理做探索时发现的步骤，可以通过 SubagentStop 钩子捕获进 procedural memory。

2.4 自动压缩：会话太长时的兜底机制

除了三种记忆，claude-mem 还有个自动压缩机制。当会话 token 数超过预设阈值时，它会把当前会话压缩成一份摘要，存成一条 episode，然后建议或直接在当前上下文中做精简。这样做的意义是：一个超长会话不会因为上下文耗尽而被迫中断，它的"价值精华"已经被提取保存。

在理解自动压缩之前，我一直担心"记忆会不会越积越多，最后把上下文撑爆"。实际上它的注入策略是检索式而非全量式，每次启动只注入和当前任务最相关的记忆片段。这个设计很关键，后面我会专门聊 token 成本的控制。

3. 从零接入：安装、hooks 注册与首轮会话验证

3.1 一条命令完成初始化

接入 claude-mem 不需要改 Claude Code 源码，也不用装额外的运行时环境。前提是机器上有 Node.js 环境，Claude Code 已经能正常工作。我的安装过程是这样的：

npx claude-mem@latest init

这条命令会做几件事：下载 claude-mem 本体、创建本地数据目录、向 Claude Code 的配置文件注册 hooks。跑完之后，它会提示你检查 hooks 是否写入成功。我建议你执行完 init 后，打开 Claude Code 的配置文件确认一下，路径一般在~/.claude/settings.json或项目级.claude/settings.json里，能看到类似这样的注册记录：

{ "hooks": { "SessionStart": [ { "matcher": "", "hooks": [ { "type": "command", "command": "npx claude-mem@latest hooks session-start" } ] } ], "SessionStop": [ { "matcher": "", "hooks": [ { "type": "command", "command": "npx claude-mem@latest hooks session-stop" } ] } ], "SubagentStop": [ { "matcher": "", "hooks": [ { "type": "command", "command": "npx claude-mem@latest hooks subagent-stop" } ] } ] } }

这段配置是 claude-mem 的实际运行骨架。SessionStart 负责在会话开始前注入记忆，SessionStop 负责在会话结束后归档和提取记忆，SubagentStop 负责捕捉子代理探索过程中的新知识点。三个钩子各管一段，少一个都会影响体验。

3.2 首轮会话：验证记忆真的生效

装完之后，我第一次开新会话，最关心的是"它到底有没有给我注入记忆"。验证方法很简单：新建会话后输入/status或者直接问 Claude "你当前加载了哪些关于我的记忆信息？"。

如果 hooks 生效，你能在系统提示词里看到额外的 Memory 段落，里面列出了检索到的 semantic memory 和最近的 episode 摘要。第一轮会话因为还没有任何历史记忆，这段是空的，很正常。这时候你正常干活，把项目背景、几个关键约束告诉它，然后正常结束会话。

3.3 第二轮会话：让子弹飞一会

第二次启动会话，才是真正检验效果的时候。我当时的场景是：前一天让 Claude Code 帮我梳理了一个遗留服务的调用链，结束后没有做任何手动总结。第二天我重新打开项目终端，起了新会话，只说了一句"继续分析昨天那个服务的调用链"，它就能准确说出上一天聊到的几个关键模块和未完成项。

那一刻的体验确实是"有记忆了"。如果你发现第二轮会话依然什么都没记住，优先检查三件事：hooks 是否真的注册成功、SessionStop 是否正常执行（终端会有 claude-mem 的处理日志）、数据目录下是否生成了对应的 SQLite 文件。

3.4 可选：以 MCP 方式接入

除了 hooks 自动模式，claude-mem 还提供 MCP server 模式。如果你需要在会话过程中让 Claude 主动查询历史记忆（而不是依赖启动注入），可以把它注册成 MCP 工具。方式是在 Claude Code 的 MCP 配置里加一条：

{ "mcpServers": { "claude-mem": { "command": "npx", "args": ["claude-mem@latest", "mcp"] } } }

两种模式可以共存。hooks 负责"被动注入"和"自动存储"，MCP 负责"主动检索"。日常我主要依赖 hooks 模式，因为它的存在感最低；只有需要回溯很久以前的某个决策时，才会用 MCP 工具去精确捞。

4. 日常记忆管理：CLI 命令与记忆卫生

4.1 常用命令速查

claude-mem 除了 hooks 之外，还提供一组 CLI 命令让你手动管理记忆。不同版本命令名可能有微调，以claude-mem --help为准。我最常用的几个：

4.2 主动记住与主动遗忘

虽然 claude-mem 是自动工作的，我还是建议养成主动管理的习惯。有些东西自动提取不一定准，比如你刚做了一个重大技术决策，可以在结束会话前顺手输入：

claude-mem remember --content "确定用 xx 方案替换旧的 yy 模块，原因：zz，迁移计划见 issue #42"

这样能确保这条关键信息不走样。反过来，自动提取也可能把一些噪音当成记忆存进去，比如某次随口说的调试中间结论。这时候用claude-mem semantic列出所有记忆，找到不想要的，forget掉。定期做一次"记忆大扫除"，比让数据库无脑膨胀健康得多。

4.3 检查注入 prompt，确认模型视角

我特别喜欢claude-mem mem这个命令。它让我能站在模型的角度，看到"我注入给你的记忆到底是什么"。有时候模型行为不对劲，一查发现是注入了一段过时的 semantic memory，误导了它。这时候删掉那条问题记忆，行为立刻恢复正常。

这种"外显记忆"的设计在我看来是 claude-mem 最稳的一点：记忆不是黑盒，它注入了什么、存了什么，全部可以检查、可以干预。对于把 Claude Code 用于生产工作的人来说，可控性比自动化更重要。

5. Token 成本与检索质量：实测调优的几个关键旋钮

5.1 记忆注入不是越多越好

接入之后我第一个担心的是成本：如果每次会话都注入一大堆记忆，token 消耗岂不是爆炸？实测下来，情况比想象的好。claude-mem 的注入策略是检索式召回，不是全量倒灌。它会把你的记忆库向量化，然后根据当前会话开头的内容做相似度匹配，只挑最相关的 top-k 条注入。

我测过一个积累了几十条记忆的项目，启动注入额外消耗的 token 大概在几百到一两千之间，取决于召回条数和摘要长度。相比重讲一遍项目背景动辄两三千 token，这个成本完全可以接受。

5.2 召回质量的决定因素

召回质量直接决定记忆有没有用。干扰召回效果的主要因素有三个：

• 记忆本身的噪音：如果入库的短句太多、太碎，向量检索容易召回到语义相近但实际无用的内容。
• 会话开头的任务描述：注入发生在 SessionStart，此时模型只知道你当前的第一句话，如果话太泛（比如"继续昨天的活"），召回的准确率会下降。
• top-k 参数：k 值太小，相关记忆可能被漏掉；k 值太大，噪音会混进来。

我的调优经验是：把记忆的"粒度"控制好，别让太碎的内容入库；同时用claude-mem remember主动写一些高质量、关键词明确的记忆条目，相当于给检索做锚点。

5.3 自动压缩阈值的取舍

claude-mem 的自动压缩有一个 token 阈值配置，默认值对大部分任务是合理的。但如果你经常做超长任务，建议根据实际调一调。阈值太低，会话被过早压缩，中间细节丢失；阈值太高，压缩触发太晚，上下文已经接近窗口上限，压缩后能挽救的信息也有限。

我目前的配置思路是：常规开发任务保持默认，长文档生成或大型重构任务手动调高阈值，同时开启阶段性手动检查。压缩后建议让模型在会话内确认摘要是否准确，避免精华内容被误删。

6. 踩坑实录：多项目串味、hook 失灵与压缩误触发

6.1 问题一：多个项目的记忆串味

这是我最开始遇到的坑。我的终端习惯是多个项目文件夹切来切去，用了 claude-mem 之后，发现 A 项目的偏好居然在 B 项目的会话里被检索出来了。虽然相似度不高，但偶尔会引出一句无关的项目背景，干扰判断。

排查后发现，claude-mem 默认按项目隔离数据目录，但如果项目文件夹命名不规范（比如所有临时目录都叫 test），或者 git 根目录没识别对，就可能落到同一个记忆库里。解决办法是检查数据目录结构，确认每个项目有独立的库；如果某些目录确实不需要记忆，可以在配置里把对应路径排除掉。

6.2 问题二：hooks 注册成功但不触发

有一次我升级了 claude-mem，之后发现新会话完全没有记忆了。终端里看不到任何错误，status也正常，但 SessionStart 就是不执行。后来发现是我在 Claude Code 项目级配置里覆盖了 hooks，把 claude-mem 的注册给挤掉了。

这类问题的排查路径我总结成一条：先看配置文件里 hooks 是否真的存在，再手动跑一遍npx claude-mem@latest hooks session-start看是否有报错，最后看数据目录有没有新写入。三步走完，基本上能定位 90% 的问题。还有一个小坑：如果你用了某些终端别名或环境管理工具，npx的路径可能和 Claude Code 启动时不一致，建议在 hook 命令里写绝对路径。

6.3 问题三：自动压缩在会话中途误触发

自动压缩的本意是保护上下文，但我在一次长会话里发现，它在一个非常不合适的时机把前面的讨论压成了摘要，导致模型忘了某个刚说过的细节。原因是我那个会话包含大量长日志输出，token 数快速飙升触发了阈值，但这些内容并不是真正有价值的对话。

应对方式有两个：一是调高触发阈值，给"日志噪音"留出余量；二是养成及时让子代理整理日志的习惯，别让原始输出直接堆在主对话里。压缩机制本身是好的，但需要给它配一个干净的输入环境。

6.4 记忆库膨胀时的清理策略

用久了之后，SQLite 数据库会越来越大，检索速度也可能变慢。我的做法是每完成一个里程碑就做一次记忆归档，用claude-mem sessions --prune或手动删除过时的 episodes（不同版本支持的命令不同）。清理之后跑一次claude-mem status，确认库体积和数据完整性都没问题。这个动作有点像整理笔记：不是删掉一切，而是把真正还有价值的留下来。

7. 团队协作与进阶扩展：让记忆成为团队资产

7.1 团队共享记忆的两种思路

claude-mem 默认是纯本地的，数据存在个人机器的~/.claude-mem/下。如果你想把它变成团队共享资产，我试过两条路：

• 共享记忆目录：把某个项目的记忆库放到团队共享盘或 Git 子模块里，让大家读写同一个数据目录。优点是最简单，缺点是并发写入存在冲突风险，更适合只读共享或小团队。
• 约定式沉淀：每个人本地各自跑 claude-mem，但要求关键决策统一用claude-mem remember写进项目笔记，再通过代码评审同步。优点是灵活，缺点是依赖自觉。

我个人的建议是：先用个人模式跑两周，确定它对你真的有价值，再决定要不要做团队共享。团队共享的本质问题是信任和一致性，这和技术栈关系不大。

7.2 进阶玩法：自定义注入规则

claude-mem 支持配置文件，你可以在里面调整注入规则、召回数量、压缩阈值等参数。以 JSON 格式为例，大致长这样：

{ "triggerTokenCount": 70000, "enableEpisodicMemory": true, "enableSemanticMemory": true, "enableProceduralMemory": true, "recallTopK": 5, "excludeDirectories": ["node_modules", "dist"] }

具体字段名在不同版本可能不同，但设置思路是通用的：需要记忆什么、不需要什么、注入多少，都由你控制。我通常把recallTopK调低一点，宁缺毋滥；把 node_modules、dist 这类目录明确排除，避免向量化时被无关代码噪音干扰。

7.3 结合实际工作的最终建议

这段时间用下来，我对 claude-mem 的定位有了更清晰的判断：它是 Clauaude Code 从"一次性对话工具"走向"可持续协作工具"的关键拼图。但它不是银弹，记忆质量取决于输入质量。如果你本身和模型的沟通就很随意、结论不明确，它沉淀出来的东西自然也是碎片化的。

最后分享一个小技巧：我习惯在每天收工时，用一句话总结当天和 Claude Code 会话的核心进展，然后remember进去。这个动作只要十秒钟，但第二天续接任务时，模型能准确接住你的节奏，那种顺畅感是之前反复粘贴背景信息时完全体会不到的。记忆这件事，自动化负责兜底，主动维护负责上限，两者结合才是正确的用法。