AI 记忆不必是数据库：试试 Markdown + Git 方案

正文

最近我和 AI 的协作越来越多了。和许多开发者一样，我尝试过各种 AI 编程助手、Agent、Prompt 和工作流。用了一段时间之后，我开始注意到一个简单的问题：AI 和我今天的协作很顺畅。但到了明天，我要重新解释很多事情。为什么我们选择了这个架构？为什么否决了那个库？我们已经尝试过什么？还有什么没完成？我们昨天做了什么决定？项目存活得越久，这件事就越痛苦。于是我开始思考 AI Memory。我想要尝试一个更简单的方案。

如果 AI Memory 是人类可以直接阅读的呢？

当人们讨论 AI Memory 时，有许多技术方案：

这些方案可以非常有用。但我问了自己一个不同的问题：

如果我只是想让人工智能 Agent 在不同会话之间记住重要的项目上下文，AI Memory 必须搞得复杂吗？

如果这个 Memory 只是一个 Markdown 文件呢？大概像这样：

.ai-memory/
├── 2026-08-14.md
├── 2026-08-15.md
└── 2026-08-16.md

我可以打开它。AI 可以读取它。我可以编辑它。Git 可以追踪它。我可以精确看到哪里变了。不需要特殊的数据库查看器。不需要 Memory 服务。不需要专有格式。只是一个文件。这个想法最终变成了 Lean AI Memory。

核心思想非常简单：

Human ⇆ Readable Memory ⇆ AI Agent ⇆ Git

AI 和人类共享同一个项目 Memory。Memory 以 Markdown 格式存储。Git 提供历史记录、diff、分支和协作功能。AI 可以在会话开始时读取 Memory，并在重要事情发生时更新它。例如：

## 新增

- 添加了 PDF 签名验证功能。
- 添加了 Excel 导出功能。

## 决策

- PDF 处理保持在本地进行。
- 本地配置使用 SQLite。

## 问题

- 批量验证速度仍然很慢。

## 下一步

- 调查批量验证问题。
- 改进错误报告。

下一次 AI 会话就可以读取这些内容。不再需要我从头解释一切。

但 Memory 只是问题的一半

深入思考之后，我意识到一件事。存储 Memory 很容易。更难的问题是：

AI 应该记住什么？

应该记住每次对话吗？大概不应该。应该保存每一行代码吗？绝对不应该。应该记住架构决策吗？也许应该。被否决的方案呢？有时候。还没完成的工作呢？肯定应该。项目特定的业务规则呢？这取决于项目。这就是我决定不硬编码答案的原因。

规则应该由用户来定义

Lean AI Memory 使用一个简单的规则文件。例如：

开始工作前：

- 阅读最新的相关 Memory。
- 检查未完成的工作。
- 检查重要的架构决策。

做出重要决策时：

- 记录决策内容。
- 记录决策原因。
- 记录被否决的重要替代方案。

结束工作会话时：

- 记录已完成的工作。
- 记录未解决的问题。
- 记录接下来应该做什么。
- 保持 Memory 简洁。不要存储整个对话。

重要的一点是：这些规则不是固定的。你可以修改它们。开发者可能想要一种 Memory。项目可能需要另一种。研究项目可能需要完全不同的东西。团队可能有自己的约定。我不希望 Lean AI Memory 假装我了解每个行业需要什么。所以我把规则开放了。

Memory 格式是简单的。规则是你自己的。

因为人类可以理解它

这听起来几乎太显而易见了。但我认为这很重要。假设你的 AI 记住了一个重要的架构决策。它在哪里？在向量数据库里？在 Embedding 里？在某个隐藏的 Memory 服务里？也许。但你能打开它并精确理解 AI 记住了什么吗？用 Markdown，答案很简单：可以。你可以打开那个文件。

.ai-memory/2026-08-14.md

你可以阅读它。你可以编辑它。你可以删除不应该被记住的东西。你可以提交它。你可以 review diff。你甚至可以和 AI 争论它自己的 Memory。:)

因为软件项目本来就有 Memory 系统

它叫 Git。Git 已经给了我们：

History + Diff + Branch + Collaboration

所以我找不到一个很强的理由来为 AI Memory 另建一套复杂的历史机制。如果 AI 修改了它的 Memory：

git diff

可以向我展示发生了什么。例如：

Decision:+ 使用 PostgreSQL 而不是 MongoDB。
Reason:+ 需要事务一致性。

这是一个非常有用的特性。AI 的 Memory 成为了项目历史的一部分。

我刻意保持项目小巧

如果你第一次看到这个仓库，这部分可能看起来很奇怪。Lean AI Memory 非常小。没有 Memory 服务器。没有数据库。没有向量搜索引擎。没有 Embedding 管道。没有云基础设施。核心思想基本上就是：

Markdown + Git + 自然语言规则

就这样。而且这是有意为之的。我不是在试图构建最强大的 AI Memory 引擎。我是在试图回答一个更小的问题：

简单的、人类可读的项目 Memory 对 AI Agent 来说足够有用吗？

我还没有答案。所以我构建了我能构建的最小的东西。

这不是为了取代向量数据库

我想把这一点说清楚。我不是在说：

"向量数据库是坏的。" "Embedding 没有用。"

它们解决的是不同的问题。如果你有数百万条 Memory 并需要语义检索，你当然可能需要更复杂的技术。Lean AI Memory 针对的是不同的问题。一个项目的 important context 相对较少：

Architecture decisions + Rejected approaches +
Unfinished work + Project-specific rules

对于这种 Memory，也许一个 Markdown 文件就够了。也许不够。这正是我希望人们去尝试的。

AI Memory 不应该变成黑箱

我关心的一件事是人类的控制权。如果 AI 记住了关于我项目的某些东西，我应该能够看到它。如果它错了，我应该能够修改它。如果它不再相关，我应该能够删除它。如果我想知道为什么某个东西在那里，Git 历史应该帮助我理解它。这给了一种非常简单的关系：

AI 可以写 Memory ⇆ 人类可以检查 Memory ⇆ 人类可以修改 Memory

AI 不是 Memory 的所有者。项目才是。

它不只适用于编程

我最初考虑的是 AI 编程 Agent。但越思考这个想法，编程变得越不重要。同样的概念可能适用于：

文档项目 记住：

• 品牌用语规范
• 格式标准
• 审批工作流

业务流程 记住：

• 团队约定
• 角色职责
• 升级路径

团队协作 记住：

• 决策历史
• 未解决的问题
• 正在进行的工作

个人 AI 记住：

• 偏好设置
• 常用工作流
• 重要项目背景

我不知道所有这些用户需要什么。我不想猜测。这就是为什么规则是开放的。

有趣的部分实际上可能是规则

Markdown 格式是有意做得平凡的。有趣的问题是：

人们会创建什么样的规则？

例如，一个软件团队可能会定义：

做出架构决策时，记录决策内容、原因和被否决的替代方案。

另一个团队可能会说：

永远不要将客户数据存储在 AI Memory 中。

一个文档项目可能会说：

不要更改既定的业务术语，除非记录了更改原因。

一个研究项目可能会说：

不要将假设当作事实。记录重要结论背后的证据。

这些规则完全不同。这没关系。我不想构建一个知道所有这些规则的系统。我想要提供一个简单的地方，让人们可以定义它们。

Lean AI Memory 是什么

Lean AI Memory 是一个小型的、Git 原生的协议，用于使用人类可读的 Markdown 和用户定义的自然语言规则来实现持久化 AI Memory。

设计原则：

Simple + Human-readable + Git-native + Extensible

不是：

a semantic search engine
an enterprise memory platform
a replacement for every AI memory solution

我不想仅仅因为增加功能很诱人，就让它变成那样。项目应该保持可理解。如果有人打开这个仓库，他们应该能够理解这个想法，而不需要阅读上百页的文档。

为什么我选择开源？

因为我不知道我是否正确。这大概是最诚实的原因。我可以坐在这里解释为什么 Markdown 更好。我可以解释为什么 Git 就够了。我可以解释为什么自然语言规则有用。但这些都不能证明这个想法。唯一有趣的测试是：有没有人觉得它有用？ 也许有人会用它。也许有人会告诉我这个想法是错的。也许有人会创建一套我从未想到过的规则。也许有人会构建一个集成。也许没有人会在意。所有这些结果都是有用的信息。所以我决定开源。你可以在这里找到项目：Lean AI Memory on GitHub

一个小型实验，不是成熟的解决方案

我不认为 Lean AI Memory 已经完成了。实际上，我甚至不确定底层想法是否正确。这是实验的一部分。我想要构建一个足够小的东西，让人们能够理解它、修改它、不同意它。也许 AI Memory 确实需要数据库。也许语义检索最终会是必要的。也许 Markdown 在某个规模上会变得不方便。这没关系。这些都是工程问题。第一个问题更简单：

人类和 AI 能否在不把 Memory 藏在另一个复杂系统后面的前提下共享 Memory？

这正是我试图找出答案的问题。

我曾经在不同的软件领域花费了大量时间。我学到的一件事是，有时候困难的部分不是写代码。而是决定实际上应该构建什么。对于 AI 来说，这变得更有趣了。AI 可以极快地生成代码。但它不会自动知道什么对你重要。它不会自动知道什么应该被记住。它不会自动知道你的项目应该遵循哪些规则。那些东西仍然需要来自某个地方。所以也许 AI Memory 的未来不只是让 Memory 更智能。也许它还需要让 Memory 可被理解。

也许 AI Memory 不需要更智能。它只需要可被理解。

GitHub: Lean AI Memory

Rules: Natural language

如果你尝试了，我真的很感兴趣看到你会想出什么样的 Memory 规则。