别再从零开始教每一个 AI

答案快照

在 2026 年，我反复思考的 Dense-Mem 问题已经不只是“怎样给一个 AI 助手记忆”。

更难的问题是：怎样阻止每个 AI 工作流孤立地学习？

我反复看到同一种失败模式。我会写一个技能，更新一个静态笔记，调一个自动化提示词，或者纠正一个助手。那个环节变好了。但经验也就停在那里了。下一个 AI 会话仍然冷启动。下一个自动化仍然带着过时上下文。下一个插件还得重新摸索我已经做过的决策。

我已经写过为什么 AI 记忆必须超越 RAG。这一次，问题更偏操作层面。它把我推向另一个心智模型：

技能和文件 = 意图快照
Dense-Mem        = 事实源
LLM              = 面向人的可读接口

我得到的结论不是“把文档当另一个事实源”。那只是用更漂亮的格式制造同样的重复问题。更有用的拆分是：流程放在技能里，规范知识放在 Dense-Mem 里，人通过 LLM 让它解释、追溯、总结或挑战那份记忆。

我反复遇到的问题

我一开始没有用 “集中式知识图谱” 这个词。

我一开始只是觉得烦。

我让一个 AI 工作流变好了，然后发现改进没有传播。博客写作技能不会从上一次被拒绝的草稿中学习，除非我去编辑技能。解释器工作流不知道支持工作流已经发现了什么。发布检查器用的是几周前我粘进去的上下文。新的 Codex 会话不会自动知道 Claude Code 刚帮我做了什么决策。

一开始，显而易见的答案似乎是：写更多文件。

写更好的静态笔记，写更好的技能，写更好的提示词模板，加更多示例，加更多指令，再加一个检查清单。

这在一段时间内确实有帮助。但也暴露了局限性。每个静态文件都依赖某个人记得更新它。如果五个工作流复制了同一份上下文，我现在就有五份注定会各自分叉的过时副本。如果纠正只停留在某一次对话里，下一次对话会重复同样错误。

从那时起，我不再把记忆仅仅看作”聊天机器人功能”，而是把它看作共享基础设施。

技能有帮助，但仍然静态

技能仍然是让 AI 工作流可复用的最好方式之一。我用它们，是因为它们能清晰地封装流程：

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

这应该放在技能里。它稳定，不应该依赖召回。

问题是技能运行几次后会发生什么。

用户纠正语气。审查员拒绝某个措辞，因为它暗示了一个尚未发布的功能。支持团队发现客户使用的术语和旧解释不一样。自动化发现某个检查清单项在演示构建上会失败。工程团队改了架构决策。

这些不总是适合放回技能文件。它们是经验。如果我把每条经验都塞进技能文件，技能就会变成一堆历史垃圾。如果我不把经验存起来，助手就没有持久学习。

这就是共享记忆比只共享技能更有力的地方。这个方向我在 Skills + Dense-Mem 里已经探索过，但这次单一事实源问题让论点更清楚。

技能      -> 稳定工作流
Dense-Mem  -> 事实源和持续演化的经验
LLM        -> 按需生成的可读解释

技能告诉助手如何工作。记忆告诉它这个项目在工作中学到了什么。

静态参考资料也有同样问题

我在静态解释材料上也看到同样模式。

静态文件容易被信任，因为它可见。一个 Markdown 文件很具体，一个文件夹看起来很有条理。但如果我把这些文件当成规范事实，我就又多了一份需要和记忆系统同步的事实副本。

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

我找到的处理方式，是改变接口：

• Dense-Mem 存证据、当前事实、过时事实、冲突和来源
• 技能定义可重复的 AI 流程，而不是规范产品知识
• 人让 LLM 读取 Dense-Mem，并解释当前事实
• 任何生成页面或总结都是输出，不是事实源

有用的知识数据库可以从正常工作里增长：

• 支持工单变成证据片段
• 工程决策变成类型化声明
• 经过审查的声明变成活跃事实
• 过时事实被取代，而不是被覆盖
• 冲突变成澄清任务
• 导入把已审查知识从另一个工作区带进来
• 只读客户端召回上下文，但不能修改

重要的一点是：记忆不会因为建了就自动变好。只有当工作流捕捉证据、检查声明、谨慎提升事实、暴露过时知识，并且在记忆冲突时请求澄清，它才会改善。

工作发生 -> 证据被捕获 -> 声明被检查
             -> 事实被提升 -> 过时知识被暴露
             -> 未来 AI 工作带着更好的上下文开始

这就是静态解释文件缺少的循环。可读层可以重新生成、重新解释。记忆图谱才是规范存储。

只读密钥改变了我看自动化的方式

自动化让问题更明显。

发布检查器、议题分流工作流、解释审查员都需要上下文。它们可能需要知道哪些功能已发布，哪些术语是安全的，哪些客户承诺还没被批准，哪个工程决策在上一次事故后变了。

我以前的本能是把上下文粘进自动化提示词。

这能工作，直到上下文变旧。然后我必须找到每一个复制了它的工作流。

我现在更偏好的模式是：

自动化任务 -> 只读 Dense-Mem 密钥 -> 召回当前上下文
自动化任务 -> 无写入范围          -> 不能修改记忆

这时 RBAC 不再像企业采购清单上的勾选项，而是实际有用。

有些工作流应该写记忆。很多不应该。审查机器人可能需要召回当前项目决策，但不需要权限改写团队记忆。批量任务可能需要上下文，但不应该提升事实。面向人的助手在合适时可以有更广访问。

对我来说，关键洞见是集中式记忆不只是更聪明的答案，也是更少过时上下文副本。

模型越强，共享记忆越有价值

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

LLM 和插件会继续变好。当前插件可能只会召回几个事实，而且用得笨拙。未来插件可能更会组装上下文，更会解释来源，更会提出尖锐的澄清问题，也更少使用过时事实。

如果记忆被困在一个提示词文件、一个工具或一个聊天产品里，每次升级又要从局部知识开始。

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

同一个知识图谱
  -> 今天的 Claude Code 会话
  -> 今天的 Codex 会话
  -> 明天的插件
  -> 未来自动化
  -> 更强的模型使用更丰富的上下文

这不保证推理更好。强模型仍可能被坏记忆误导。但如果记忆有治理、审查、可追踪性，更强模型应该让工作流更顺，因为它们不必每次从零重新发现团队上下文。

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

Dense-Mem 给我的形状

Dense-Mem 里我反复回到的是边界。

我不希望每个宿主 LLM 都发明自己的记忆格式。也不希望 LLM 因为看到一句自信的话，就静默改写长期记忆。

我更信任的形状是：

源片段 -> 类型化声明 -> 验证 -> 提升关卡 -> 活跃事实
                                                   |
                                                   v
                                            澄清任务

宿主 LLM 仍然负责对话、抽取和判断。Dense-Mem 负责持久记忆状态：源片段、类型化声明、验证、提升关卡、召回、团队隔离、API 密钥、审计元数据、MCP、REST 和 OpenAPI 接口面。

这让我能问真正有意义的问题：

• 当前事实是什么？
• 什么证据支持它？
• 它替换了哪个旧事实？
• 哪个未解决冲突需要人来回答？
• 这条记忆属于哪个团队？
• 哪个密钥或角色可以使用这个工作流？

这就是为什么我认为“集中式知识图谱”是正确说法。不是因为图谱数据库有魔法，而是因为有用记忆有关系、有历史，也需要权限边界。

导入和导出让想法不再局限本地

一旦我把记忆看作累积经验，导入和导出就变得更重要。

如果一个团队学到了有用东西，它不应该永远局限在一个环境里。但盲目复制记忆很危险。我不想导入一堆未知事实，然后静默取代本地知识。

更安全的形状是经过审查的可移植性：

这时共享记忆才真正不同于共享技能。技能可以教工作流。记忆包可以把经过审查的经验带到另一个工作区。

我认为好处是什么

遇到这些问题后，我在意的好处都很实用：

最后一行是大的。静态文件需要被维护。知识数据库也需要治理，但它可以参与工作循环。它可以随着工作动态增长，未来更好的 LLM 客户端可以更顺地使用同一份记忆。

我在哪里画边界

我不认为这意味着“把所有东西都放进记忆”。

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

Dense-Mem 不是外部真理机器。它可以保存证据、状态、冲突信号和来源。它自己不能证明外部世界为真。

Dense-Mem 不是技能的替代品。流程必须稳定时，技能仍然应该存在。但我不再希望另一个可读文件树成为第二事实源。知识会变化、冲突、积累，并且需要被多个 AI 客户端召回时，记忆图谱才是更合适的地方。

我最终信任的规则是：

流程放在技能里。规范知识放在 Dense-Mem 里。让人通过 LLM 询问、解释那份记忆。

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

不是“AI 记住一切”。

而是更窄、更有用的东西：一个有权限边界的位置，让 AI 工具保存工作教会我的东西，追踪记忆为什么存在，在记忆冲突时询问，并把上下文带进下一个工作流。