AI不记忆。它只是记录。
文件存在，但记忆不存在
任何曾将大型项目交给AI编程代理的人都知道这一点。
第一个任务完成得很出色。 第二个还行。 当大约二十个文件堆积起来后，奇怪的事情发生了。
代理找不到它昨天创建的文件。
$ find . -name "*.md" | head -20
$ grep -r "cache" ./docs/
$ cat ./architecture/overview.md # "不是这个"
$ cat ./design/system.md # "也不是这个"
$ grep -r "cache strategy" . # "啊，在这里"
文件确实存在。代理自己写的。 但它完全不知道什么东西在哪里。
这不是bug。 它记录了，但从未结构化其记忆。
人类的长期记忆完全一样
令人惊讶的是，这种模式与人类长期记忆在结构上完全相同。
你的大脑保存着数十年的经历。 昨天午饭吃了什么，三年级班主任的名字， 2019年读过的一本书中那句令人印象深刻的话。
所有这些都存储在某个地方。 但当你试图检索时？
“那个……是什么来着……我记得当时在咖啡馆读的……”
你摸索着找线索。相关记忆跟着跑出来。无关记忆也插进来。 有时你永远找不到。有时它毫无预兆地突然浮现。
AI编程代理的 grep 与人类"是什么来着……“的体验在结构上完全相同。
信息已存储。检索一团糟。
问题不在存储，而在检索
这一点必须准确阐述。
今天的AI不缺乏记录能力。 LLM写得很好。它们生成结构优美的markdown文档。 它们生成代码，撰写摘要，创建分析报告。
存储已经是一个已解决的问题。
未解决的是检索。
当积累了一百个文件后，现存的AI没有一个能立即回答 “三周前讨论的缓存策略在哪里？”
每个AI系统都用同样的方式"解决"这个问题。 重新阅读所有内容。或者按关键词搜索。
这就像一个拥有一百万本书但没有目录卡的图书馆。 每个问题，图书管理员都从头到尾扫描书架。
一步之遥：结构化文件映射
解决方案并不遥远。只差一步。
一个 .memory-map.md 文件。
# 记忆映射
最后更新：2026-02-26
## 架构
- architecture/cache-strategy.md：3阶段推理缓存设计 (1/28)
- architecture/wms-overview.md：WMS中心枢纽结构 (1/30)
## 码本
- codebook/verb-sidx.md：13,000个动词的SIDX映射 (1/29)
- codebook/entity-top100.md：顶级实体分类体系 (1/31)
## 决策
- decisions/2026-01-28.md：采用SIMD穷举扫描的理由
- decisions/2026-01-31.md：优先进行Go AST概念验证的决策
## 待解决问题
- open/query-generation.md：缓存检索查询生成方法待定
- open/entity-codebook-scale.md：1亿实体映射策略待定
就这些。
每次任务后，在映射中添加一行。 开始下一个任务前，读取这一个文件。
完成。
不需要 find。不需要 grep。
不用翻遍五十个文件，一个映射就够了。
为什么仅凭这一点就能产生巨大的性能提升?
让我们分析AI编程代理在任务上花费的时间。
总任务时间：100%
实际思考和生成：30-40%
上下文发现和探索：40-50%
错误纠正和重试：10-20%
中间的40-50%是关键。
“弄清楚之前做了什么所花的时间"占了总量的一半。 随着项目增长，这个比例上升。 文件达到200个后，探索可能超过总时间的70%。
.memory-map.md 将那40-50%减少到接近0%。
读取映射需要一秒。 立即知道需要的文件在哪里。 马上开始工作。
当探索时间趋近于零时，代理可以将几乎所有时间 投入到实际的思考和生成中。
感知性能的巨大提升是自然的结果。
人类早就发明了这个
这不是新想法。 人类数千年前就发明了同样的解决方案。
目录正是如此。
想象一本没有目录的书。 要在一本500页的书中找到特定内容， 你必须从第1页开始阅读。
有了目录呢？ 看到"第3章第2节，第87页"然后直接翻到那里。
图书馆目录卡正是如此。
在拥有一百万本书的图书馆中， 没有目录就不可能找到你想要的那本。
文件系统的目录结构正是如此。
即使硬盘上有一百万个文件， 你也可以沿着文件夹结构找到你想要的那个。
目录。索引卡。文件夹。 全是同一个原理。
“内容在那边；这里，我们只记录东西在哪里。”
人类知识管理最基本的原则。 然而在2026年，AI并没有在做这件事。
从映射到智能
.memory-map.md 只是开始。
扁平文件列表 -> 层级分类 -> 语义链接 -> 图。
沿着这个方向一步步走会发生什么？
第1阶段：文件列表（现在就可以做到） “cache-strategy.md 在architecture文件夹中。” 你知道东西在哪里。
第2阶段：关系记录 “cache-strategy.md 依赖于 wms-overview.md。” “这个决策源于那次讨论。” 你知道文件之间的关系。
第3阶段：语义索引 “找到所有与推理效率相关的文档。” 按含义搜索，而非按关键词。
第4阶段：结构化知识图谱 每个概念是一个节点，每个关系是一条边。 “给我看影响缓存策略的所有设计决策的因果链。” 这变得可能了。
从第1阶段到第4阶段。
从 .memory-map.md 到WMS。
从扁平文本到结构化知识流。
这一切都是同一段旅程。
这是核心原则
让我们重新审视这种方法的核心原则。
“AI的推理过程不能丢弃——必须记录。”
这句话背后隐含着一个推论：
“记录下来的推理必须是可检索的。”
没有检索能力的记录等于从未记录过。
必须用 grep 摸索着才能找到的记忆不是记忆——是废纸篓。
结构化推理的理由， 使用语义对齐ID系统的理由， 用单个位掩码检索相关知识的理由——
归根结底都是这一点。
这不是记录的问题，而是检索的问题。 这不是存储的问题，而是结构的问题。
.memory-map.md 是这个原则最原始的实现。
而如果连这样原始的实现都能产生巨大的性能提升，
想象一下将这个原则推到极致会发生什么。
总结
AI的记忆问题不在于存储，而在于检索。
- 今天的AI写文件写得很好，但找不到自己写的文件。
- 这与人类长期记忆的局限性在结构上完全相同。
- 解决方案数千年前就被发明了：目录、索引卡、文件夹。
- 一个
.memory-map.md就能巨大地提升AI的有效性能。 - 将这个原则推到极致，就通向结构化知识流。
即使是最精密的AI也在没有一张目录卡的情况下工作。 我们打算改变这一点。