本地优先AI编程记忆中枢：用Git+Markdown打通Claude Code、Codex、Cursor

如果你和我一样，电脑上同时装着 Claude Code、Codex 和 Cursor 三款 AI 编程工具，大概率经历过这种崩溃瞬间：上午用 Claude Code 敲定了一套 API 的返回结构，下午切到 Cursor 改前端，它完全不记得这回事，按自己的理解又生成了一套过滤逻辑；晚上想用 Codex 做批量重构，它连项目里有哪些模块都要从头问起。三款工具各自能力都不差，但它们之间没有任何记忆共享——这就是我动手做这个“本地优先的协作中枢”的直接原因。

这个开源项目解决的问题一句话就能讲清楚：用一套纯文本的记忆仓库，让 Claude、Codex、Cursor 在工作时都能读到同一份项目上下文，写下的关键决策、踩坑记录、接口约定互相可见。方案不依赖云端服务，所有数据落在本地 Git 仓库里，因此叫“本地优先”。项目以开源形式发布，代码量很小，但思路和工程细节足够有参考价值，适合频繁在多款 AI 工具间切换的个人开发者，也适合多人协作同一个仓库、但各自用不同 AI 助手的团队。下面把完整的搭建过程和踩坑经验都写出来。

1. 三款工具各自为战：上下文断裂的真实成本

先说清楚我为什么会走到这一步。不是某一款工具不好用，而是它们好用在了不同的场景里：Cursor 的交互式补全适合改样式、写组件，Claude Code 的 Agent 能力适合做架构调整、跨文件重构，Codex 在批量任务上表现稳定。问题是，它们对项目的理解完全来自各自的会话上下文，互相之间没有任何交集。

1.1 同一个晚上，我对着三个工具重复了三遍需求

举一个真实发生过的例子。我在做一个嵌入式相关的开源项目时，需要统一所有子模块的错误码定义。Claude Code 花了大概半小时，把错误码表、头文件、文档全部对齐了，还专门在代码注释里写了“错误码 1001-1999 分配给网络模块”的约定。晚上我想让 Cursor 帮忙写一个新的网络诊断页面，它看到错误码之后，直接按照自己“觉得合理”的方式新定义了一套 9000 段位的错误码，理由是“避免和现有冲突”。

听起来很离谱对吧？但它确实不知道那个“1001-1999”的约定，因为那条约定活在 Claude Code 的会话里，不在代码里。更常见的是这种场景：你让 Codex 批量重命名一个模块里的所有函数，它问你要“哪些文件需要改、新命名规则是什么、有没有需要排除的测试文件”，这些信息你可能昨天已经跟 Claude Code 说过一遍了。于是你不得不把同一份背景知识，今天说三遍，明天再说三遍。

这种重复解释带来的不只是时间损耗，更恶心的是你每次复述的口径还不一样。第一遍说得详细，第二遍图省事只说了主干，第三遍干脆只给了文件名。模型拿到的上下文越来越薄，生成的方向就会越来越偏。

1.2 记忆不共享的三笔隐形成本

• 时间成本：每切换一次工具，至少需要 10 分钟到半小时的“上下文热身”。如果项目复杂度高，这个时间还要翻倍。我算过自己一天的真实编码时间，至少有一个小时花在了反复给模型讲背景上。
• 质量成本：模型没有长期记忆的好处是“每次都是全新助手”，坏处是它不记得你踩过的坑。比如某个第三方库的某个方法有内存泄漏，你之前已经让 Claude Code 写了 workaround，但 Cursor 接手时会毫不犹豫再次调用那个方法，因为“文档上是这么写的”。
• 风格成本：三款工具各自有各自的代码风格偏好。Claude Code 喜欢抽函数，Codex 偏爱改配置少见新文件，Cursor 则习惯在现有文件里内联修改。没有统一的记忆约定，一个仓库里的代码风格会逐渐分裂成三套，未来的维护成本直线上升。

这些成本不是一个“优秀的单点工具”能解决的。只要你在多工具之间切换，就必须有一个独立于工具之外、又能被所有工具读取的记忆层。

1.3 “云端记忆”方案为什么止步于 demo

市面上也有不少“AI 记忆工具”，主打把对话历史和项目要点同步到云端，然后通过浏览器插件或 App 的方式在工具之间共享。我实际试用过几类，最后都放弃了。

第一类的问题是依赖中心化服务。你辛辛苦苦沉淀的项目知识，全部存在别人的服务器上，导出格式还不友好。想把它放进代码仓库里做版本管理？不行。第二类的问题是没有和代码仓库打通。记忆存在“外部”，模型在工作的时候根本感知不到它，除非你手动复制粘贴，这就又回到了老路。第三类的问题更现实——很多项目代码本来就敏感，老板不会同意你把内部架构信息传到第三方平台。

所以我的结论很明确：这个记忆层必须长在本地，长在 Git 仓库里，让模型像读代码文件一样读记忆。这就是“本地优先”四个字的分量。

2. 存储方案推倒重来：为什么纯文本 + Git 而不是向量数据库

确定了“本地优先”的大方向之后，下一个要回答的问题是：记忆用什么格式存？最自然的想法当然是数据库、向量库这类“专业”方案，但实际推演下来，纯文本加版本控制才是这个场景的最优解。

2.1 和 SQLite、向量库、云文档的对比

我把几个候选方案放在一起做了个对比，核心指标有三个：模型能不能直接读、变化能不能追踪、维护成本高不高。

向量数据库看起来高大上，但这里有个根本性的问题：AI 编程工具获取上下文的方式是“读文本”，而不是“查语义”。Claude Code 不会自己去连 Postgres 做向量检索，它只关心 CLAUDE.md 里写了什么，以及你能通过工具给它返回什么。如果我先要写一套向量检索管道，再把检索结果格式化成文本塞回给模型，那为什么不直接省掉中间步骤，用人和模型都能读的 Markdown 呢？

SQLite 也有类似问题。你确实可以用 Python 脚本把数据库里的记录导出成文本，但每次导出都意味着一次加工，而且加工出来的文本也许不是模型最关心的内容。Git 仓库里的 Markdown 文件则不同——它的原始形态就是模型要的输入形态，零转换。

2.2 本地优先到底图什么

“本地优先”这个词这两年很火，但落到这个项目里有非常具体的含义：记忆数据的主副本存放在本地文件系统里，云端只是可选的同步手段，而不是唯一来源。

这样设计有几个直接的好处。第一，离线也能用。我在高铁上写代码是常有的事，断网的情况下 Claude Code 读 CLAUDE.md 完全不受影响，但基于云端的记忆方案就抓瞎了。第二，Git 本身就是最好的同步机制。把记忆仓库和你代码仓库放一起，push 到远程 Git 托管平台，团队其他人 clone 下来就自动拿到了全套记忆，不需要再配一套独立的同步服务。第三，数据主权在你手里。任何一条记忆记录，你都可以直接打开文件修改，不需要通过某个应用的导出功能。

这就像记账。云端记账 App 功能再强，你换一个平台数据就带不走；而一个本地 Excel 表格，虽然朴素，但永远属于你，想怎么处理都行。

2.3 记忆条目的格式设计：让大模型和人都能看懂

确定了纯文本之后，格式细节还需要打磨。我测试过几种写法，最终定下的是“YAML front matter + Markdown 正文”的结构，和很多静态博客系统保持一致的风格：

--- type: decision id: 2025-06-13-error-code-policy tags: [api, error-code, convention] status: active --- # 错误码统一约定 所有子模块错误码范围由公共头文件统一分配。 - 1001-1999: 网络模块 - 2001-2999: 存储模块 - 3001-3999: 协议解析模块 - 新增错误码必须先在公共头文件登记，不能局部定义。

YAML front matter 负责结构化字段，正文负责细节描述。这种格式对模型非常友好，因为它能同时看到“这是一条决策记录”这个类型标签和“错误码范围”这个具体内容，理解和检索的效率都远高于纯散文。之后我会根据这三个字段来做一个关键的优化：每次给模型注入记忆时，只注入必要的字段和摘要，而不是把整个文件目录全部扔进去。

3. 搭建中枢：目录结构、写入协议与一个 30 行的记忆 CLI

方案定下来之后，搭建本身反而不复杂。整个共享记忆中枢由三部分组成：目录结构、写入协议、CLI 工具。三者加起来代码量很小，但缺一不可。

3.1 记忆仓库的目录设计

我的记忆仓库结构长这样：

memory/ ├── README.md # 记忆库使用说明，也是给AI看的入口 ├── decisions/ # 架构决策记录 ├── obstacles/ # 踩坑记录 ├── apis/ # 接口约定 ├── patterns/ # 设计模式/代码范式 ├── contexts/ # 项目上下文快照 └── index.json # 标签索引（自动生成）

每个子目录底下的文件统一以“日期-简短描述.md”命名，比如2025-06-13-error-code-policy.md。为什么把日期放前面？因为按文件名排序时，时间顺序就是自然顺序，既方便追溯，也方便做“把最近一周的新记忆告诉模型”这种时间窗口过滤。

index.json是自动生成的索引文件，记录每个记忆文件的路径、tags、type、最后修改时间。它存在的意义是让 CLI 工具能快速检索，而不是每次都用grep扫一遍全仓库。

3.2 从零实现 mem 命令

CLI 工具是整个中枢的“写入协议”核心。我一开始贪省事，想直接用 Git 仓库加手写文件的方式，不用任何工具。但实际用下来发现，手写 front matter 太容易格式出错了，而且模型在会话里写出来的 YAML 经常带额外修饰，解析时全是坑。所以一个统一的写入入口非常必要。

我用 Python 实现了一个极简版的mem命令，核心逻辑只有 30 行左右。最关键的函数是写入记忆条目：

#!/usr/bin/env python3 import sys, os, json, datetime, urllib.parse MEMORY_DIR = os.path.join(os.path.dirname(__file__), "..", "memory") def add_entry(entry_type: str, title: str, content: str, tags: list[str]): date = datetime.date.today().isoformat() safe_title = "-".join(title.lower().split()).replace("/", "_")[:40] filename = f"{date}-{safe_title}.md" filepath = os.path.join(MEMORY_DIR, entry_type, filename) os.makedirs(os.path.dirname(filepath), exist_ok=True) front_matter = ( "---\n" f"type: {entry_type}\n" f"id: {date}-{safe_title}\n" f"tags: [{', '.join(tags)}]\n" f"status: active\n" "---\n\n" ) with open(filepath, "w", encoding="utf-8") as f: f.write(front_matter + content + "\n") print(f"memory entry written: {filepath}")

实际用的时候，你只需要执行：

mem add decision "错误码统一约定" "所有子模块错误码范围见..." --tags api,error-code mem find "错误码" mem list --type decision --since 7d mem sync # 重新生成 index.json

find和list都做得很简单，核心逻辑就是递归遍历memory目录，解析 front matter，然后按关键词或时间过滤。唯一要强调的是sync命令，它负责扫描所有记忆文件并重新生成index.json。只要目录结构够规整，这个命令跑一次就是毫秒级的事。

这套 CLI 的唯一目的，是让“写入记忆”变成一个标准化动作。不管是人手动敲命令，还是 AI 工具通过调用命令写入，产出的文件格式都是统一的。格式统一是后面所有自动化操作的地基。

3.3 用 Git 自动留痕：记忆也是代码的一部分

记忆文件如果只是躺在磁盘上，和没写也没什么区别。它必须跟着项目走，被版本化，才能发挥协作价值。

我采用的方式非常朴素：在项目仓库根目录建一个memory/文件夹，所有记忆文件直接纳入同一个 Git 仓库管理，不单独开仓不搞子模块。这样做的最大好处是，一次 commit 里可以同时包含代码变更和对应的记忆变更。比如你修了一个 bug，不但改了代码，还写了一条 obstacle 记录，这两者就被牢牢绑在同一个 commit 里，几个月后回溯时一眼就能看懂“这次提交为什么要这么改”。

为了不让记忆文件遗忘在本地，我在全局 Git 配置里加了一条post-commit钩子，自动检查memory/目录是否有未提交的变更，有就自动追加提交：

cat > .git/hooks/post-commit << 'EOF' #!/bin/bash if [ -n "$(git status --porcelain memory/)" ]; then git add memory/ git commit -m "docs(memory): sync memory entries" --no-verify fi EOF chmod +x .git/hooks/post-commit

如果你用的是git commit -am这种带-a的方式，代码和记忆本身就会一起被提交，上面这个钩子反而是个兜底。有了它，即使你忘了单独提交记忆文件，它也会在下次 commit 时自动跟上。

4. 三款工具的接入姿势：约定文件、规则文件与按需检索

记忆仓库建好了，怎么让 Claude Code、Codex、Cursor 三款工具真正“看到”它，是整个过程里差异化最大的一步。三款工具读取上下文的方式各不相同，但都有一个共性：支持通过项目根目录的约定文件来注入指令。

我的做法是为每款工具单独准备一份“导游文件”，在文件里告诉模型记忆仓库的位置、读取方式、写入方式。

4.1 Claude Code：把记忆录进 CLAUDE.md

Claude Code 的项目级约定文件是CLAUDE.md。只要这个文件存在于项目根目录，Claude Code 每次会话启动时都会自动加载它。所以我在CLAUDE.md里专门加了几个关键句子：

## 项目记忆系统 本仓库采用本地优先的记忆系统，所有关键决策、踩坑记录、接口约定存放在 `memory/` 目录。 - 读取记忆：执行 `python scripts/mem.py find <关键词>` 检索，或直接读取 `memory/README.md` 了解全貌。 - 写入记忆：当你在解决一个值得沉淀的复杂问题、做出架构决策、或发现一个坑时，执行 `python scripts/mem.py add` 写入记忆。 - 注入策略：每个会话开始先读取 `memory/README.md`，并根据任务需求检索相关记忆，不要把全部记忆文件一次性读入。

最关键的其实是“注入策略”那一条。Claude Code 的上下文窗口虽然大，但也不是无限大，一次性读入所有记忆文件纯属浪费。正确的姿势是：先读目录入口文件，再按需检索，让 Claude Code 像查资料一样找到自己需要的记忆条目。这比我最初“全量注入”的方案可靠得多。

实操下来，Claude Code 的确会遵守这个约定。它在接需求时会先去查memory/里有没有相关决策，发现error-code-policy记录后，生成的代码就直接遵循了错误码分段约定，不再自作主张。

4.2 Codex：AGENTS.md 是记忆入口

OpenAI Codex 对项目上下文的读取方式也是读取项目根目录的约定文件，名字叫AGENTS.md，它的作用类似CLAUDE.md。我在里面写的内容思路一致，但措辞更偏“任务导向”：

# AGENTS.md ## 项目记忆系统 - 本仓库的记忆文件位于 `memory/`，采用 Markdown + YAML front matter 格式。 - 在执行任何跨模块改动前，先运行 `python scripts/mem.py find <模块名>` 检索相关记忆。 - 如果改动涉及错误码、公开 API、核心模块边界，必须先阅读 `memory/apis/` 和 `memory/decisions/` 中的相关文件。 - 完成路径探索或发现新坑后，使用 `python scripts/mem.py add obstacle "描述" --tags <标签>` 写入记忆。

与CLAUDE.md相比，这里多了一个“跨模块改动前必须检索”的硬性约束。Codex 在自动化批量处理场景下更容易忽略上下文约束，直接用几个关键词去记忆库里查一下，成本很低，但能避免大量方向性错误。

值得留意的是，Codex 对 AGENTS.md 里的语言风格非常敏感。我试过用很委婉的措辞，比如“如果有时间可以看看记忆目录”，结果它真的就不看。后来改成“在执行 X 前，必须做 Y”的强制句式，执行率立刻上来了。这算是约定文件编写里的一个隐形技巧。

4.3 Cursor：规则文件加手动检索双通道

Cursor 的规则系统比较特殊。它的全局规则和项目规则都写在.cursorrules文件里，但在实际使用中，我发现 Cursor 对.cursorrules的遵循程度没有 Claude Code 对CLAUDE.md那么高。所以我采用了双通道策略。

第一通道是规则文件声明。在项目根目录的.cursorrules里写：

- 项目记忆仓库为 `memory/` 目录，所有记忆条目为 Markdown 格式。 - 修改公共模块或 API 前，先查看 `memory/apis/` 里的相关文件。 - 当用户询问“之前是怎么做的”“为什么这样设计”时，优先去 `memory/` 目录查找答案。

第二通道是人工触发检索。Cursor 的优势在于你可以在对话中随时插入指令，所以当我发现 Cursor 没有主动读记忆时，会直接发送一条指令让它去查记忆库。比如我会在对话框中输入“读一下 memory/decisions/2025-06-13-error-code-policy.md，然后告诉我你的理解”。这样既让 Cursor 获得了上下文，也验证了它对记忆条目的理解是否准确。

这两条通道互补以后，Cursor 在项目里的表现才真正和其他两款工具站在了同一水平线上。在此之前，它完全是我一天里最容易“失忆”的工具。

4.4 模型端点独立配置的补充

还有一件事值得一提。三款工具接入同一套记忆系统后，很多人会顺带问：它们必须用同一个模型吗？我的结论是不必。Claude Code 可以仍然用 Claude 系列模型，Codex 也可以把请求指向其他兼容服务，Cursor 更可以自己配模型厂商。工具本身有各自的模型接入渠道，互不冲突。

共享的是“记忆层”，不是“模型层”。记忆层是纯文本，喂给哪个模型都行，不挑食。这也是我坚持用 Markdown 而不用任何私有格式的根本原因——它可以被任何模型、任何工具平滑消费。

5. 实测避坑：上下文占满、解析打架、并发写入与 Windows 报错

方案跑通只是第一步，真正折磨人的是线上跑起来之后的细节问题。这套记忆中枢我实际用了两个多月，踩过不少坑，有些坑不遇到根本想不出来。

5.1 记忆库本身成了上下文黑洞

最开始的版本，我在约定文件里写的注入策略是“每次会话加载整个memory/目录”，我以为几十个 Markdown 文件撑死也就几百行，占不了多少 token。结果两周后记忆库膨胀到 40 多个文件，每次会话光加载记忆就要烧掉一大截上下文。

更致命的是，模型不是把记忆当作“参考”来用，而是把大量无关记忆也当成了“上下文的一部分”。它看到一个关于内存泄漏的 obstacle 条目，哪怕当前任务是在写一个上传组件，也会尝试往里加防泄漏逻辑，反而拖慢了主流程。

后来我改成了“摘要 + 按需检索”的策略：每次会话只读memory/README.md，读完后根据任务目标用检索命令定位真正相关的记忆。这个改动立竿见影，上下文消耗下降了大半，模型也更专注了。我建议任何做类似记忆系统的人，直接从摘要策略开始，别走全量加载的弯路。

5.2 三款工具对同一份 Markdown 的解析不一致

记忆文件是同一份，但三款工具解析它的方式并不一致。Claude Code 对 YAML front matter 和 Markdown 正文的分隔处理得很好，会明确区分“字段”和“内容”；Cursor 有时候会把 front matter 里的tags字段当成正文的一部分来理解；Codex 则偶尔会在回答里“复述”它看到的 front matter 原始内容，而不是直接进入正文。

这个问题最直接的暴露场景是索引查询。记忆文件多了以后，我依赖tags字段做检索，但 Cursor 在回答时经常引用错误的标签。后来我意识到，与其指望三款工具理解完全一致的 front matter 语义，不如在正文开头用自然语言把关键标签再强调一遍。比如文件里写上“本文档是决策记录，涉及 API 和错误码约定”，这样即使解析器对 front matter 处理有偏差，正文开头也提供了足够的信息。

这个改动非常小，但对三款工具的实际理解一致性提升很大。现在我的记忆模板里固定有一条“摘要行”，位置就在标题下面：

> 一句话摘要：本文档定义了统一错误码分段规则。

5.3 并发写入导致记忆互相覆盖

这个坑是在我同时开着 Claude Code 和 Cursor 干活的时候踩的。Claude Code 往memory/obstacles/写了一条踩坑记录，几乎同时，Cursor 执行了mem sync重新生成index.json。由于两个进程互相不知道对方的存在，后执行的sync直接把前一条记忆从索引里抹掉了。文件本身还在，但索引里找不到，等于“失忆”。

解决方式分两层。第一层是给sync命令加一个合并逻辑，而不是“扫描目录后直接重写索引”。如果索引文件已经存在，就用新旧数据的并集来更新，而不是全量替换。第二层是操作习惯上的：尽量避免两个工具同时执行写操作，我在约定文件里加了一条规则——“写入记忆后，用git status确认变更再继续下一个任务”。

这个坑的本质是“多个 Agent 共享同一份可变状态”，这种问题在传统多人协作代码仓库里早有成熟方案，但在 AI 工具互相同步的语境里还属于新问题。简单的流程约束比复杂的文件锁机制实用得多。

5.4 Windows 下的两个典型报错

很多读者是在 Windows 上用这些工具的，我也实际在 Windows 环境部署过一次，遇到了两个有代表性的报错。

第一个报错来自 Claude Code，提示大概类似“Claude 的工作区需要 Windows 上的虚拟机平台，请启用”。这个问题需要通过 Windows 的“可选功能”启用“虚拟机平台”，或者直接用 WSL2 来跑 Claude Code。WSL2 本身就和 Git 仓库协作良好，记忆文件在 Windows 文件系统和 WSL 文件系统之间简单共享反而不太方便，最省心的做法是整个项目都在 WSL2 内操作。这个坑我在 Windows 上实测折腾了近一小时，最后是切换到 WSL2 才彻底解决。

第二个报错来自 Codex 安装过程，典型表现是“Windows 安装未完成”。原因大多是 Node 版本过低或者权限不足。Codex 对 Node 的版本要求比一般工具更高，检查node --version是否达到要求是第一步；其次安装路径不能带中文或空格，否则会直接静默失败。这两个细节不解决，安装到一半会卡住且不报错，排查成本很高。

5.5 敏感信息差点进了 Git 历史

最后这个坑值得特别注意。为了让记忆系统更完整，我把一次调试过程中用到的内部数据库连接串写进了障碍记录里，当时只是想留个上下文，没多想就提交了。过了两天才意识到，这条信息已经进入了 Git 历史——即使后来删掉文件，历史里依然可以翻出来。

所以我在记忆模板里强制加了三条“禁区”规则：不得记录密钥、令牌、密码；不得记录与公网无关的内网基础架构细节；涉及客户数据的记录一律用脱敏占位符。这个规则不是写给人看的，是写给模型看的。约定文件里明确写了“当你认为需要记录敏感信息时，用<替换文本>占位，并把真实信息放在受保护的文件中，或者干脆不记录”。

记忆系统天然有“越写越细”的趋势，如果不加这条边界，失控只是时间问题。你的记忆仓库越有价值，越要控制它不要记录不该记的东西。

6. 记忆沉淀之后：角色分工、团队红利和后续规划

记忆系统稳定跑了一段时间后，我开始体会到它带来的不只是“少说几遍话”这么简单。它实际上改变了我和三款工具的协作方式。

6.1 一套记忆同时喂养三个模型

过去我的使用方式是根据任务挑工具，任务之间是割裂的。现在三款工具共享一套记忆，我反而更愿意做任务拆解：让 Claude Code 做架构设计和接口定义；让 Codex 去做大批量的代码重构和格式统一；让 Cursor 处理需要频繁交互的前端细节调整。每个工具在自己擅长的领域发挥最大价值，同时因为记忆统一，产出结果能自然接合。

最直观的收益是“评审成本”下降了。以前每换一个工具，我都要从头检查它是否遵守项目约定。现在只要记忆库里对应的决策条目存在，三款工具默认都能遵守。从代码审查中解放出来的时间，用来看更高层次的架构问题，这才是项目长期健康的关键。

6.2 从个人记忆到团队 onboarding

这个记忆中枢对个人有效，对团队的价值更大。新成员加入项目时，不再需要翻几十个文档去理解“这个项目为什么这么设计”，只需要让他先读memory/README.md，然后按需要检索具体的决策记录和踩坑记录。记忆库实际上成了一个活的、持续更新的项目文档。

我有次尝试让一名新同学基于记忆库写一份模块设计文档，他先检索了memory/apis/里的接口约定，又看了两条相关的 obstacle 记录，最后给出的设计文档几乎没有踩坑，这在以前是不可能的。过去新人对项目上下文的理解至少需要一两周，现在两天就能构建起一个够用的全局观。

6.3 后续想做的几个扩展

当前版本还比较朴素，后续有几个方向我觉得值得做，也分享出来供参考。

第一个是“自动记忆失效”。目前所有记忆条目的status都是active，但很多决策和踩坑记录是有时间效力的。比如一个第三方库的报错坑，可能在下个版本就修复了。我想做一个定期扫描，让模型判断哪些记忆条目已经过时，自动把status改成deprecated，避免老记忆长期“占座”。

第二个是“记忆自动沉淀”。现在的写入主要靠人或模型主动执行命令。后续可以考虑接一个后台进程，监听 Git 提交信息，当检测到一次修复 bug 的提交时，自动生成一条草稿记忆，等人工确认后入仓。这样能减少写记忆的摩擦，让沉淀变得几乎无感。

第三个是“跨项目记忆共享”。不同项目的记忆仓库互相独立，但有些经验是通用的，比如“某个 Vue 组件库的更新策略”或者“某种 ARM 架构下的踩坑点”。把这些共性经验抽到一个独立的全局记忆仓库，然后通过符号链接或 Git 子模块挂载到具体项目下，是我正在试验的一个方向。

在实际使用的过程中，我的一个体会是：这套系统的成功，不取决于你选了什么存储、写了多少代码，而取决于你是否养成了“随手留记忆”的习惯。所以如果你的时间只够做一件事，先别折腾 CLI 和自动化，先在项目根目录建一个memory/文件夹，然后用记事本写第一条 decision 记录。只要开始沉淀，后面的一切优化都会自然发生。