别再从零开始教每一个 AI

先说结论

到了 2026 年，我反复在想的一个 Dense-Mem 问题，已经不只是"怎么给一个 AI 助手加上记忆"了。

更棘手的问题是：怎么让每个 AI 工作流别再各自为战地学东西？

同一种翻车模式我见了太多回。我写了一个 skill，改了一条静态笔记，调了一段自动化 prompt，或者纠正了某个助手——当时那个环节确实变好了。但经验也就到此为止了。下一次 AI session 照样从零开始，下一段自动化照样带着过时的上下文，下一个 plugin 还得重新摸索那些我早就做过的决定。

之前我写过一篇AI 记忆不能只靠 RAG。这次的问题更偏实操层面，它把我推到了一个不同的心智模型上：

skill 和文件 = 意图的快照
Dense-Mem       = 事实的唯一来源
LLM            = 给人看的可读接口

我最终得出的结论不是"把文档也当成一个事实源"。那不过是换了个更好看的格式，重复制造同样的问题。更合理的拆法是这样的：流程放在 skill 里，规范知识放在 Dense-Mem 里，人通过 LLM 去查询、解读、总结、甚至质疑这份记忆。

那个一直困扰我的问题

我一开始可没有"集中式 knowledge graph"这种高大上的说法。

一开始纯粹就是烦。

我把一个 AI 工作流调好了，然后发现改进根本传不过去。写博客的 skill 不会从上一次被毙掉的草稿里学到任何东西，除非我手动去改 skill。做解读的工作流不知道支持工作流已经摸清了什么。发布检查器用的还是我几周前粘贴进去的上下文。新开的 Codex session 也不会自动知道 Claude Code 刚帮我做了什么决定。

一开始，最直觉的反应就是：写更多文件。

写更好的静态笔记，写更好的 skill，写更好的 prompt 模板，多加例子，多加指令，再加一个 checklist。

短期内确实有用。但问题也很快暴露了。每一份静态文件都得靠有人记得去更新它。如果五个工作流都复制了同一份上下文，那我现在就有五份注定会各自跑偏的过期副本。如果一条纠正只活在某一次对话里，下一次对话就会犯同样的错。

就是在这个节点上，我不再把记忆仅仅看作"聊天机器人的功能"，而是开始把它当成共享基础设施来思考。

skill 很管用，但它不会自己长大

skill 到现在依然是让 AI 工作流可复用的最好方式之一。我一直在用，因为它能把流程封装得很干净：

When writing release notes:
- read merged pull requests
- group changes by user impact
- avoid unreleased claims
- run the content check before finishing

这种东西就该放在 skill 里。它是稳定的，不应该依赖 recall。

但问题出在 skill 跑了几次之后。

用户纠正了语气。reviewer 否了一句措辞，因为它暗示了一个还没发布的功能。支持团队发现客户用的术语跟旧版解释里的不一样。自动化跑着跑着发现某个 checklist 项在 demo build 上会挂。工程团队改了架构决策。

这些经验不一定适合塞回 skill 文件里。它们是实战中积累的教训。如果把每条教训都堆进 skill，skill 就会变成一堆历史流水账。如果不存下来，助手就永远学不到持久的东西。

这就是为什么共享记忆比只共享 skill 更有威力。这个方向我在Skills + Dense-Mem里探讨过，但这次"单一事实源"这个问题让论点更加清晰了。

skill      -> 稳定的工作流程
Dense-Mem  -> 事实源 + 持续进化的经验
LLM        -> 按需生成人类可读的解释

skill 告诉助手怎么干活。记忆告诉它这个项目在干活过程中学到了什么。

静态参考资料也是同一个坑

静态的解释性材料也有同样的毛病。

静态文件容易让人放心，因为看得见摸得着。一个 Markdown 文件很具体，一个文件夹看起来井井有条。但如果我把这些文件当成权威事实，那就等于又多了一份需要跟记忆系统同步的"真相副本"。

这直接违背了我真正想要的单一事实源模式。

我找到的解法是换一种交互方式：

• Dense-Mem 存证据、当前 fact、过期 fact、冲突和来源
• skill 定义可复用的 AI 流程，而不是存放权威的产品知识
• 人让 LLM 去读 Dense-Mem，解释当前的真相是什么
• 任何生成的页面或总结都只是输出，不是事实源

一个有用的知识数据库可以从日常工作中自然生长出来：

• support ticket 变成证据片段
• 工程决策变成类型化的 claim
• 经过审查的 claim 升级为 active fact
• 过期的 fact 被取代，而不是被覆盖
• 冲突变成需要澄清的任务
• 导入把另一个 workspace 里已审查的知识带进来
• 只读客户端可以 recall 上下文，但不能修改

有一点必须说清楚：记忆不会因为你建了就自动变好。只有当工作流能捕捉证据、校验 claim、谨慎地提升 fact、暴露过时的知识、在记忆冲突时主动请求澄清，它才会真正改善。

工作发生 -> 证据被捕获 -> claim 被校验
            -> fact 被提升 -> 过时的知识被暴露
            -> 下一轮 AI 工作带着更好的上下文起步

这个闭环就是静态解释文件一直缺的东西。可读层可以随时重新生成、重新解读。memory graph 才是真正的规范存储。

只读 key 彻底改变了我对自动化的看法

自动化场景把这个问题暴露得最彻底。

发布检查器、issue 分流工作流、解读审查员——它们都需要上下文。它们需要知道哪些功能已经上线了，哪些术语可以放心用，哪些给客户的承诺还没获批，上次事故之后哪个工程决策变了。

我以前习惯的做法是把上下文直接粘贴到自动化的 prompt 里。

能用是能用，直到上下文过期。然后我就得满世界去找所有复制过这份上下文的工作流。

我现在更倾向的模式是：

自动化任务 -> 只读 Dense-Mem key -> recall 最新上下文
自动化任务 -> 没有写入 scope     -> 无法修改记忆

到了这里，RBAC 不再像是企业采购清单上打个勾的东西，而是真正派上了用场。

有些工作流应该写记忆，很多不应该。reviewer bot 可能需要 recall 当前的项目决策，但不需要权限去改写团队的记忆。批量任务可能需要上下文，但不应该去提升 fact。面向人的助手在合适的场景下可以给更宽的权限。

对我来说，关键的 insight 是：集中式记忆的价值不只是让回答更聪明，更是让过时的上下文副本越来越少。

模型越强，共享记忆越值钱

还有一个面向未来的理由让我很在意这件事。

LLM 和 plugin 一直在进步。现在的 plugin 可能只能 recall 几个 fact，用起来还笨手笨脚的。未来的 plugin 可能会更好地组装上下文，更好地追溯来源，更善于提出尖锐的澄清问题，也更不容易被过时的 fact 带偏。

如果记忆被困在某个 prompt 文件、某个工具、某个聊天产品里，每次升级又得从残缺的知识重新开始。

如果记忆住在共享的 Dense-Mem 服务器上，更强的客户端可以直接复用同一份积累下来的知识：

同一份 knowledge graph
  -> 今天的 Claude Code session
  -> 今天的 Codex session
  -> 明天的 plugin
  -> 未来的自动化
  -> 更强的模型用上更丰富的上下文

这不等于推理质量自动变好。强模型照样可能被烂记忆带沟里去。但如果记忆有治理、有审查、有可追溯性，更强的模型会让工作流更顺畅——因为它们不用再从零开始重新发现团队的上下文。

这就是我押注的复利效应。知识数据库在增长，客户端也越来越会用它。

Dense-Mem 给我的那个"形状"

Dense-Mem 里面让我反复回来的，是边界。

我不想让每个宿主 LLM 都自己发明一套记忆格式。也不想让 LLM 看到一句自信的话就悄悄去改长期记忆。

我觉得更靠谱的形状是这样的：

source fragment -> typed claim -> verification -> promotion gate -> active fact
                                                   |
                                                   v
                                            clarification task

宿主 LLM 依然负责对话、抽取和判断。Dense-Mem 负责持久的记忆状态：source fragment、typed claim、verification、promotion gate、recall、团队隔离、API key、审计元数据、MCP、REST 和 OpenAPI 接口。

这套结构让我能问出真正有意义的问题：

• 当前的 fact 是什么？
• 哪些证据在支撑它？
• 它取代了哪条旧 fact？
• 哪个未解决的冲突需要人来拍板？
• 这条记忆属于哪个团队？
• 哪个 key 或角色有权使用这个工作流？

这就是为什么我觉得"集中式 knowledge graph"才是准确的说法。不是因为 graph database 有什么魔法，而是因为有用的记忆天然就有关系、有历史、也需要权限边界。

导入导出让知识不再局限于本地

一旦我开始把记忆看作积累下来的经验，导入导出就变得更加重要。

一个团队学到了有价值的东西，不应该永远困在一个环境里。但盲目复制记忆是有风险的。我可不想导入一堆来路不明的 fact，然后悄悄把本地知识全覆盖了。

更安全的做法是"经过审查的可移植性"：

到这里，共享记忆才真正跟共享 skill 拉开了差距。skill 能教工作流怎么做。记忆包可以把经过审查的实战经验带到另一个 workspace。

我觉得值在哪

踩过这些坑之后，我在意的收益都很实在：

最后一行才是重头戏。静态文件需要人去维护。知识数据库也需要治理，但它可以参与到工作循环里。它能随着工作动态增长，未来更强的 LLM 客户端也能更顺畅地复用同一份记忆。

我的边界在哪

这不意味着"什么都往记忆里塞"。

Dense-Mem 不是密码管理器。我不会把凭证、私钥、助记词、支付卡信息或任何秘密当记忆存进去。

Dense-Mem 也不是外部的"真理机器"。它可以保存证据、状态、冲突信号和来源，但它本身没法证明外部世界的事实。

Dense-Mem 更不是 skill 的替代品。流程需要稳定的地方，skill 就该在那。但我不想再要一个靠人维护的文件树来当第二事实源了。知识会变化、会冲突、会积累、需要被多个 AI 客户端 recall——在这种场景下，memory graph 才是更合适的归宿。

我最终信奉的规则是：

流程放在 skill 里。规范知识放在 Dense-Mem 里。让人通过 LLM 去查询和解读这份记忆。

这就是 Dense-Mem 帮我命名的那个问题。

不是"AI 什么都记住"。

而是一个更窄、也更实用的东西：一个有权限边界的地方，让 AI 工具能保存工作教会我的东西，追溯记忆为什么存在，在记忆冲突时主动提问，并把上下文带进下一个工作流。