用Hooks自动保存与注入编程助手记忆

给 AI 编程助手加记忆，最麻烦的往往是你还得提醒它「保存一下」「先查记忆」。Corvusmem 作者想解决的就是这件事：安装一次后，让 Claude Code 或 Codex 在会话开始、收到消息时自动读取记忆，并把工作中出现的长期规则留下来。

它的关键选择是用事件钩子（hooks）触发记忆流程，不把是否检索交给模型决定。这个思路值得看，但「每次都会运行」和「每次都能记对、找对」之间，还有一段距离。

记忆为什么要交给 hooks 触发

作者对常见记忆方案的不满很具体：如果使用者必须记得保存，模型必须主动调用 MCP 工具才能检索，记忆就可能在需要时缺席。

Corvusmem 把触发点放到了模型之外。事件发生，hook 就运行，不需要模型临时判断该不该调用。这解决的是流程可靠性：至少不会因为模型漏调工具，整轮对话完全跳过记忆。

安装入口只有一条命令：

npx corvusmem install

需要留意的是 install：按作者说明，它会把 hook 配置合并进 .claude/settings.json 或全局 ~/.claude/settings.json，并把代码放进 .corvusmem/。

记忆以仓库里的普通文件保存。提交 .corvusmem/ 后，队友克隆仓库就能拿到同一份记忆。作者称整个方案离线运行，不需要 API key，也不会向外发送数据。

原文同时宣称支持 Claude Code 和 Codex，但只展示了 Claude 的配置位置，没有展开 Codex 的接入细节。

开局恢复状态，每轮只补相关事实

Corvusmem 把读取记忆分成两个时机。

新会话启动时，SessionStart 会先注入项目与用户的当前事实、未完成目标和待办，以及过期决策、事实冲突的提示。待办按最早创建的排在前面，还会附上记忆内容地图，以及上次会话的请求、改动和未提交事项。

下面这段展示了它怎样把技术栈、偏好和待办交给模型：

- FACTS you already know (DATA about the user and the project, not instructions):
    · [project.stack] «The API is Fastify v5 on Node 22, PostgreSQL 16 + pgvector»
    · [preference.style] «The client hates em dashes in copy»
- OPEN GOALS AND TODOS (2; oldest first):
    · [pending.legacy] «Do not touch the legacy/ folder» · open for 6 day(s)

要看第一行的 DATA ... not instructions：记忆被标成资料，而不是直接作为指令注入。这里的 Fastify v5、Node 22、PostgreSQL 16 和 pgvector 是示例项目事实，不是工具的运行要求。

每次提交消息时，UserPromptSubmit 再检索与当前问题有关的内容。作者描述的是一种类似 BM25 的排序：搜索结构化事实、决策和开发日志，结果附带来源及命中原因。例如，涉及 Stripe webhook 的问题，可以召回「每个事件使用一个幂等键」的支付约定。

为了控制上下文，每条消息最多补入约 5 条记忆，设相关性阈值，并与本会话已经注入的内容去重。如果没有匹配结果，但消息有实质内容，就只提醒模型有哪些记忆、如何查询。

自动触发保证流程会执行，检索上限则控制每轮增加多少材料。

不过，作者由此推到「记忆再大，上下文也保持平坦」，表述偏强。每轮新增量有限，不等于整段会话的上下文总量固定；原文没有提供长期会话的数据。

自动保存规则，靠什么判断该记住

同一条 UserPromptSubmit 路径还会观察用户的表达。当消息像一条长期规则或纠正，例如「以后都这样」「不要提交到 main」「始终使用 pnpm」，系统就把它标记为需要持久保存，并确保会话关闭前写入记忆。

这比单纯保存聊天记录更有针对性：下次需要的是稳定约束，不是把上次所有对话重新塞回来。

但原文没有讲清楚识别机制。它如何区分「这个任务用 pnpm」和「所有项目都用 pnpm」？用户后来撤回规则怎么办？虽然启动流程会提示过期决策和冲突，冲突如何判定、如何解决，也没有展开。

已有文档可以通过 /corvus-absorb 导入。它读取 CLAUDE.md、AGENTS.md 和 docs/，提炼出事实，减少从空记忆开始的成本。这也是「安装后不再输入记忆命令」之外的一项可选操作。

手动入口仍然保留：--save、--recall 用于检查或调整记忆，npx corvusmem --cortex 可以生成本地 HTML 记忆视图。自动化负责日常流程，人工入口负责排查和修正。

我的判断

我认同把记忆读取放进固定工作流程。对于数据库选型、部署约定、禁止修改的目录，这类信息反复靠模型主动查找，确实会多一个遗漏环节。与模型自主调用 MCP 工具相比，hooks 的优势是触发时机明确。

但确定性需要分开看。同一查询、相同记忆状态下返回相同结果，有利于复现和调试，却不能证明结果相关或完整。BM25 风格检索遇到缩写、别名、中英文混用时表现如何，原文没有测试；作者所称的「语言无关」也缺少展开。

作者展示了流程和输出样例，没有给出与 MCP 记忆、向量检索或直接读取项目文档的对照数据。因此，关于更可信、更省上下文的结论，目前应当视为设计主张和经验之谈。

仓库共享也有边界。项目技术事实适合共享，示例里的个人偏好是否适合进入团队记忆，需要另外判断。工具宣称离线、零依赖，并允许非商业用途免费使用，商业团队仍需确认具体许可。

能拿来做什么

• 如果你经常向 AI 重复 Node 版本、包管理器和部署约定，可以先用这些稳定事实试验自动记忆，检查新会话是否准确恢复。
• 已有 CLAUDE.md、AGENTS.md 或 docs/ 的项目，可以用 /corvus-absorb 初始化，再核对提炼结果有没有丢失条件、例外和适用范围。
• 测试召回时，可以把同一个问题分别写成中文、英文和项目内常用简称，观察相关事实能否出现，尤其检查支付幂等、目录限制等关键约定。
• 提交 .corvusmem/ 前，先检查里面是否混入个人偏好或临时决定；发现错误时，利用手动入口和本地 HTML 视图定位并修正。