On Persistent Memory让 AI 记住你 · 关于跨会话的工作记忆

跟 AI 协作久了, 你会发现一个特别烦的事 — 它没记忆。

每次开新会话, 上次的争论、上次的决定、上次踩过的坑, 全归零。你要么从头讲一遍, 要么默默接受它再犯一遍同样的错。

这件事一开始我以为是"AI 还不够强", 后来想明白了 — 没记忆这个特性, 跟 AI 强不强其实没关系。它的本质是 session 的边界。每一次对话都是一个独立的进程, 退出就清零, 跟你重启浏览器一样合理。

所以问题不是"怎么让 AI 变得有记忆", 是 怎么把记忆做成一份外部协议, 让每个新会话都能从那里捡起来。

Memory 不是 chat log

最朴素的想法是: 把所有对话存下来, 下次开会话喂回去。

这个方案我试过, 不 work。原因有三:

一, 对话太啰嗦。一万字的聊天记录里, 真正有价值的可能就 200 字, 剩下 9800 字是 "好的我来试试" / "等等我看一下" / "刚才那段你能再解释下" 这种过程话语。喂回去全是噪音。

二, 对话有时序性, 但记忆要无时序。"刚才你说" 这种引用, 在新会话里完全失效。

三, 对话里有大量当时正确但现在过期的信息。"我们决定用方案 B" — 后来又改成了 C。如果你把对话原封不动喂回去, AI 看到的"事实"可能已经错了。

所以 memory 不能是 chat log。它得是 结构化的、去时序的、定期更新的外部脑。

四类 memory, 各自的写法

我现在跑的 memory 系统分四类。每类对应一种用途, 写法不同。

① user — 你是谁。 用户的角色、目标、知识背景、偏好。比如 "Han 是 GGBOYS 的 CTO, 中文交流, 习惯先 test 再 prod"。这类 memory 写一次就稳定, 很少变。

② feedback — 你纠正过我什么。 用户的指令、规则、做事方式。比如 "deploy 必须先 test 验证再上 prod"。这类 memory 是协作纪律的核心。

③ project — 谁在做什么, 为什么。 当前项目的状态、决策、上下文。比如 "我们正在做统一订单系统 v3, 因为 2024 年的 7 张小桌子撑不住了"。这类 memory 会过期, 需要定期清理。

④ reference — 外部系统在哪儿。 不是知识本身, 是知识的指针。比如 "bug 列表在 ggboys-sheets MCP, sheet ID = xxx"。

四类各司其职, 不混在一起。

写 feedback memory 的纪律

四类里, feedback 是最重要也最容易写错的。

典型的"差不多"写法是这样的:

feedback: deploy 必须先 test 再 prod

看起来没错。但半年后我自己再读, 已经忘了为什么了 — 是因为 prod 太脆弱? 还是因为 test 环境有专门的验证流程? 还是某次踩过坑?

当我忘了"为什么", 这条 feedback 就开始失效。下次遇到一个看起来"很简单不会出问题"的 deploy, 我可能就跳过 test 直接 prod 了。

所以好的 feedback memory 必须包含三段:

· 规则本身: 一行话说清楚要做什么或不要做什么。

· Why: 这条规则是怎么来的 — 哪次踩坑、哪个用户偏好、哪个具体场景。

· How to apply: 适用边界 — 什么时候该用, 什么时候不该用。

举个真实例子:

规则: 跨服务 saga 触发方必须 inline 主动推进到 COMMITTED.
       reconcile cron 只验证不主动 lock.

Why:   2026-04-15 一次跨服务 saga 主链路崩, cron 兜底
       lock 跟主链路 retry 撞车, 状态机推进两次, 用户钱
       先扣两次再退一次. 体验比卡死还糟.

How:   适用所有跨服务 saga (admin_service ↔ steam_auth).
       不适用单服务内部状态机 (单服务 cron 兜底没问题).

这样写, 半年后我自己 (或者另一个 agent) 看到这条 memory, 能立刻判断:

· 这条规则现在还成立吗? (Why 那段 — 看现在还有没有 cron 兜底)

· 我手上这个改动适用吗? (How 那段 — 是不是跨服务 saga)

没有 Why 和 How 的 feedback, 是 死的规则。它会被无差别遵守一阵子, 然后被无差别忽略, 然后被悄悄遗忘。

Project memory 会过期, 这件事要承认

四类 memory 里, project 类的衰减最快。

"我们正在做 X" — 三个月后, X 可能已经做完了; 半年后, 可能整个方向都换了。

所以 project memory 必须 定期 review。我现在的纪律是:

· 每个会话结束前跑 /memory 整理一次 (新增 + 更新 + 标记过期)

· 用户消息里出现"现在是 X 月" / "上周做了 Y" 时, 主动更新 project memory

· 永远把相对时间 ("Thursday", "下周") 转成绝对日期 ("2026-04-30") 再写入, 否则一周后这个 memory 就读不懂了

更深一层 — 一份过期的 project memory 比没有 memory 更糟。它会让 agent 在错误的假设上跑得更远。

Memory 是 cross-session 协议层

写到这里你可能会发现 — memory 跟上一篇 (№ 007) 讲的 handoff 文档, 本质是同一件事的两种形态。

Handoff 文档: 一次性的, 跨 session、跨 agent 的协议。"我现在写, 你后看"。

Memory: 持续性的, 跨多 session、可能跨多 agent 的协议。"以后所有人都从这里读"。

都是 把状态外化到磁盘, 让下一个时刻的 agent 能捡起来。区别只是时间尺度。

这个视角让我意识到, 跟 AI 协作的核心技能, 其实不是 prompt engineering, 是 给未来的自己写文档的能力。每一份 handoff、每一条 feedback memory, 都是给未来某个时刻的某个 agent (可能是 AI, 可能是几个月后那个忘了细节的我) 留下的便条。

一个反例 + 一个正例

反例: 早期我跟 Claude 协作时, 把所有 "重要的" 内容都堆进一份巨大的 CLAUDE.md。一年下来, 这个文件 4000 多行, agent 每次读它要消耗大量 context, 而且经常找不到自己要的东西。后来拆成索引 + 子文件, 按任务类型路由读取, 才变得能用。

正例: 一份 60 字的 feedback memory 救过一次事故。规则是: "AI 写的代码改动里, 任何 git commit 必须由 AI 自己提交; 不要把 AI 改动用人工 commit 包起来, 否则审计追溯失效"。半年后某次紧急修复, agent 想替我跑 commit, 看到这条 memory 立刻改成 "patch 准备好了请你 commit", 避免了一次责任不清的提交。

这就是 memory 的真实价值 — 不是让 AI "聪明", 是让协作的 边界 在每次会话里都自动重建。

收尾 — 真正的资产是事故档案

我越来越相信一件事: 一个团队 (无论是人, 还是人 + AI) 真正的资产, 是它的事故档案, 不是它的代码库。

代码会被重写, 框架会被替换, 同事会换一拨。但那些"我们当年踩过这个坑所以现在不再做 X"的笔记, 是真正在跨时间、跨人地积累的东西。

Memory 是给 AI 用的事故档案。Handoff 文档是给 AI 用的工程师笔记。本质上都在做同一件事 — 把短期的、易逝的、当下的洞察, 沉淀成长期的、稳定的、未来可读的知识。

这件事跟 AI 没关系, 跟 LLM 没关系, 跟 prompt engineering 也没关系。它是任何认真对待自己工作的人都需要的纪律。AI 的出现只是把这件事的杠杆放大了 — 因为 AI 真的会按你写的 memory 行事, 而它的"金鱼脑"逼得你不得不把这件事做扎实。

从这个角度看, AI 让我们成了更好的工程师 — 不是因为它代写代码, 而是因为它逼我们把以前混在脑子里的东西落到纸上。