Anthropic工程师踩坑1500次：AI记忆不是越大越好

我见过太多人试图用「堆量」解决AI失忆问题。500行、1000行、2000行的CLAUDE.md（或.cursorrules），文件越膨胀，AI越糊涂。研究早就证实：上下文过长时准确率暴跌，大文件中间的指令会被直接忽略。你还没提问，上下文窗口已经被塞爆了。

真正有效的方案完全相反：小文件、分层加载、按需唤醒。

1500次对话后的实战结构

这位工程师在60多个项目、1500多场对话后，摸索出一套四层架构。核心逻辑像图书馆索引——不是把书全堆在桌上，而是告诉AI「某本书在第几排」。每层都有严格的字数预算，超了就强制迁移，绝不姑息。

Tier 1 宪法层（约200行，始终加载）

这是你的「 standing orders」。偏好设置、硬性规则、以及指向其他层的路由表。「永远用TypeScript严格模式。」「测试里不许mock数据库。」就这些。如果这层超过200行，说明你把东西放错地方了。

路由表是整套系统的枢纽。它不存储知识，只存储知识的位置。Tier 1从不回答「怎么做」，只回答「去哪里找」。这种设计把上下文窗口从「仓库」变成了「调度中心」。

Tier 2 活记忆层（约50行，始终加载）

一个简短的纠错清单——AI反复踩坑的地方。「这张表存的是增量，不是累计值。」「VS Code插件不会触发CLI钩子。」每条记录都直接阻止一次重复错误。这层见效最快，因为痛点就在眼前。

50行的限制极其苛刻。工程师发现，约束倒逼质量。当你不能再随手塞内容时，被迫思考：这件事真的需要永远在线吗？还是该下沉到项目层？

Tier 3 项目脑（按项目加载）

每个项目一个文件，深度上下文：业务规则、数据schema、关键文件、决策日志、变更记录。只在进入该目录时加载。5个项目的话，80%的知识只对一个项目有用——何必每次都全量加载？

这层解决了跨项目污染。你在A项目积累的约定，不会干扰B项目的对话。AI看到的永远是当前项目的「专属记忆」，而非一锅乱炖的全局配置。

Tier 4 知识库（按需查询）

可搜索的数据库（SQLite + FTS5，或纯markdown文件）存放参考资料：完整schema、API文档、术语表。AI需要时主动搜索，而非被硬塞进指令文件。

这层的关键是「拉取」而非「推送」。传统做法是把文档切片塞进上下文，现在反过来——AI先判断需要什么，再精准调取。上下文窗口的压力骤减。

会话记忆（连续性层）

SQLite数据库记录每场对话的摘要。新会话启动时，AI查询项目简报：最近做了什么、做了哪些决策、还有哪些开放问题。再也不用玩「我们上次聊到哪儿了」的猜谜游戏。

血泪教训：预算必须硬

每层都要严格预算。Tier 1限200行，Tier 2限50行。工程师强调：「约束强制质量。」 hitting the limit forces you to move things to the right tier instead of dumping them in the always-loaded file.

另一个反直觉原则：别存AI能推导的东西。文件结构、源码里可见的代码模式、git历史——AI都能自己读。只存那些「没有提示就会出错」的信息。这是区分「必要知识」和「冗余噪音」的试金石。

如果要用AI总结会话，务必加防护。他们曾有一个 summarizer 没有批量限制，试图一次性处理50场会话，遇到API错误后循环重试整批任务，烧掉了周token预算的三分之一。Batch cap，这是用真金白银换来的教训。

这套架构的本质是「认知卸载」。人类工作记忆有限，所以我们用便签、日历、书签。AI的上下文窗口就是它的工作记忆—— Tier 1到Tier 4 相当于给AI配了一套外部存储系统。区别只在于，AI可以毫秒级检索，而我们需要翻找。

200行宪法 + 50行纠错 + 按需加载的项目脑 + 主动查询的知识库。这个数字组合，是1500次对话后的收敛解。不是越大越好，而是越准越好。你的CLAUDE.md今天多少行了？