结构化记忆术

先说清楚要解决的问题

上下文窗口是 AI Agent 的硬天花板。为了不让对话溢出，常见做法是 compact（压缩）、handoff（交接）或把 CLAUDE.md 当垃圾桶塞排查记录。这些"续命"手段都有同一个病根：信息在逐轮转述中悄悄丢失。反复压缩就像反复截图，每一代都在损失细节；handoff 是传话游戏，传到第十个人已经面目全非；而 CLAUDE.md 堆砌会让模型每次对话都要先读几千行过期信息，抓不住重点。更危险的是，模型可能把"没记住"当成"从未发生"，给出自信但错误的回答。

结构化记忆怎么工作

核心思路不是往上下文里塞更多内容，而是把记忆从上下文中抽离出来，变成独立的、可检索的、可维护的文件。

四个标签各管一类信息：

• 👤 user：长期偏好，比如"结论先行，不铺垫"
• 🐛 feedback：踩过的坑和验证经验，比如"flex 的 gap 属性在 Safari 14 上不生效"
• 📋 project：项目状态、阶段结论和重要决策
• 📚 reference：资料位置和外部资源链接

核心原则是"一个文件 = 一个事实"，文件名带日期方便追溯。策展契约包括写前去重、结论推翻时更新旧记录、错误经验直接删除、不存 Git 文档已有的信息。

三步工作流：

1. 检查与初始化：确认项目有没有记忆库，没有就建一个
2. 日常跨对话衔接：上下文快满时，用收尾提示词把结论和失败经验写入记忆库，然后开新对话用启动提示词加载
3. 定期审计：每两周跑一次，把过期条目降到子文件，避免记忆库变成另一个垃圾堆

实测中，用不到一半的字符量，结构化记忆在《茶馆》全本测试中得分 8.5/12，而反复 compact 只有 5/12。关键优势是"遗忘更可见"——主索引里没有的就是没记，你可以主动去查或补记。

适用边界

这个方法不替代项目文档——记忆库记的是"为什么这么做"，不是"怎么做"。也不替代 Git 日志——Git 记录"做了什么"，记忆库记录"换你要怎么做"。它是为个人规模设计的：一个人、一个项目、一个记忆库。多人共用同一个记忆库需要锁和冲突解决，目前不推荐。