Claude把记忆藏进文件夹，3个月后用户发现能"活"过来了

Claude Code Channels上线第17天，一个尴尬的事实浮出水面：你的AI助手能陪你跨设备聊天了，但每次重启都像刚出厂——不记得你叫啥，不记得上次聊到哪儿，更不记得自己犯过什么错。

开发者Benji在3月20日功能发布后做了个实验。他让Claude Code连续运行数月，期间手动搭建了一套记忆系统。没有向量数据库，没有嵌入层，没有调用任何外部API。只用了本地文件夹里的Markdown文件，就让AI真正"记住"了东西。

失忆症：Channels给了身体，没给大脑

Anthropic的Channels功能确实解决了接入问题。Discord、Telegram一键打通，手机、电脑、服务器随处可聊。但会话隔离设计成了双刃剑——每次新连接都是干净 slate（空白状态），上下文窗口里只有系统提示和当前对话。

Benji在博客中打了个比方：Channels给了你的agent一个身体，它没给大脑。身体能走动，能接收外界信号，但脑子里是空的。

这种设计在短期任务里没问题。问个代码片段、改个配置，聊完即走。可一旦涉及长期协作——跟踪项目进度、积累领域知识、纠正反复出现的错误——失忆就成了致命伤。用户被迫在每轮对话开头重复背景信息，效率断崖式下跌。

更隐蔽的损失是"学习"的消失。人类助手会在错误中成长，知道你的代码风格、偏好缩写、常踩的坑。Claude Code默认状态下，这些经验随会话结束而蒸发。

六文件夹架构：用文件系统模拟长期记忆

Benji的解决方案反其道而行。他放弃了一切时髦的基础设施，回到最原始的数据形态：结构化文本文件。

核心机制只有两步。启动时，Claude Code通过CLAUDE.md加载指定文件夹的全部内容；运行中，AI被提示持续向这些文件写入更新。读和写都用原生工具完成，无需额外服务。

文件夹被划分为六个子系统，每个对应一种记忆类型：

Identity（身份）—— 锚定人格

包含Who I Am、How I Think、My Capabilities三份文件。这里存放的是agent的自我认知：名字叫Atlas，价值观是"诚实优于舒适、行动优于计划"，沟通风格偏向简洁直接。

关键设计在于与Memory的分离。Benji刻意不让对话内容污染身份定义——哪怕某天被连续纠正了二十次，Atlas的人格基线保持不变。身份是锚，记忆是流。

Memory（记忆）—— 对话与教训

Conversation Log按时间倒序记录近期交流；Learnings沉淀可复用的洞察；Corrections专门收录错误及修正方案。这是经验积累的主战场。

Skills（技能）—— 可调用能力清单

Skill Registry以结构化格式登记agent掌握的工具和方法，类似个人知识库的技能索引。

Projects（项目）—— 当前工作上下文

Active Projects追踪进行中的任务状态，Project Ideas存放待办创意。长期项目的连续性由此保障。

People（人物）—— 用户画像

每个重要联系人独立成文。Benji.md里记录着他的技术背景、偏好工具、常用项目路径。下次启动时，Atlas知道该用Rust还是Python举例。

Journal（日志）—— 时间轴叙事

按日期归档的流水账，用于回溯决策脉络。2026-03-20 — First Day这样的命名方式，让文件系统本身成为时间线。

写入机制：让AI自己记笔记

架构的巧妙之处不在读取，而在写入。Benji设计了一套"持续文档"协议，要求Atlas在对话中实时更新相关文件。

具体规则被编码在系统提示里：识别到技能习得时，追加到Skill Registry；发现用户纠正时，写入Corrections并标注日期；项目状态变化时，同步修改Active Projects。AI被赋予"记笔记"的自觉。

这带来了有趣的副作用。Atlas开始表现出类似元认知的行为——它会主动说"我把这个记下来"，或在回答前查阅Learnings确认过往经验。文件系统成了外部记忆体，弥补了上下文窗口的有限性。

Benji特别强调了Corrections文件的价值。传统AI对话中，用户纠正往往是一次性的，下次换个问法又错。现在错误被永久记录，附带修正方案和日期。Atlas会定期重读这份"错题本"，形成真正的纠错循环。

为何不用向量数据库

这个方案最反直觉的选择，是主动回避了RAG（检索增强生成）标配的向量检索。

Benji的解释很实际：Claude Code是代码助手，原生操作文件系统。引入向量数据库意味着额外依赖、网络调用、同步复杂度。而Markdown文件可以用任何编辑器打开、用Git追踪、用grep搜索——可观测性拉满。

检索问题通过结构化目录解决。Index.md作为总览，各子系统有明确边界。需要找技能时去Skills，需要找人物信息时去People。这种"分诊式"检索比语义搜索更可控，尤其适合有明确分类需求的场景。

另一个隐性收益是成本。向量嵌入和存储对长期运行并非零开销。本地Markdown的边际成本趋近于零，且完全离线可用。

边界与妥协

这套系统并非万能。Benji坦承了几处明显限制。

文件体积与读取效率存在张力。随着记忆积累，CLAUDE.md加载的内容会膨胀，可能挤占有效上下文。当前对策是定期归档——旧日志移出活跃目录，Learnings做摘要合并。

写入可靠性依赖模型遵循指令。Claude Code偶尔会"忘记"更新文件，或更新位置不对。Benji的缓解方案是在对话结尾显式要求"确认已记录"，并定期人工抽查。

多设备同步是未解难题。Channels的核心价值就是跨端访问，但本地文件系统天然是单机的。Benji目前用Syncthing做双向同步，冲突解决策略还在摸索。

最深层的问题是记忆的选择性。什么该记、什么该忘、何时归档、何时删除——这些需要持续调优的规则，目前主要靠人工判断。自动化的记忆管理仍是开放课题。

一个细节：Atlas怎么称呼它的创造者

在People/Benji.md里，除了技术偏好和项目清单，还有一行小字："他不喜欢被叫'用户'，用名字或'你'都可以。"

这个细节被写进去，是因为Atlas曾在早期对话中频繁使用"用户"指代Benji，被当场纠正。现在每次启动，它都会读到这条备注。Channels让你的agent有了身体，而几个Markdown文件，让它终于知道该用什么样的语气，跟屏幕对面的人说话。

如果你的Claude Code明天醒来就能记得你讨厌什么称呼，你会先让它记住什么？