三层记忆系统
为什么需要记忆
Section titled “为什么需要记忆”AI 每次会话都是“失忆”的重新开始。没有记忆系统，你每次都要重复交代背景：项目是什么、偏好是什么、上次做到哪了。
三层记忆解决的就是这件事——让跨会话的连续性成为可能。
| 层级 | 位置 | 作用域 | 谁来写 |
|---|---|---|---|
| 云记忆 | 服务端 | 所有项目 | 系统自动维护 |
| 用户级 | ~/.workbuddy/MEMORY.md |
跨项目通用 | 你明确要求时写 |
| 工作区 | .workbuddy/memory/ |
当前项目 | 完成实质工作后写 |
第一层：云记忆
Section titled “第一层：云记忆”两部分：
自动注入的档案：系统根据你长期的使用生成的画像，每会话开头自动带上。只读，不要手动改（改了下次会被覆盖）。
历史会话检索：跨会话搜索“我们之前讨论过 XX 方案是什么”。它搜的是历史对话，需要你把问题描述完整——因为它看不到当前会话。
适合查：之前讨论过的某个具体事件、某个决策的来龙去脉。 不适合查：你的通用偏好（那在用户级记忆里）。
第二层：用户级记忆
Section titled “第二层：用户级记忆”~/.workbuddy/MEMORY.md，跨所有项目生效。
写什么：
- 硬件环境（机型、内存、有没有本地跑模型的能力）
- 沟通偏好（中文、要不要客套、输出格式）
- 跨项目的技术约束（比如某个代理端口、某个平台的账号限制）
- 通用工作流习惯
不写什么：某个具体项目的细节（那是工作区记忆的事）。
篇幅控制在几千字符内，超了要精简。这是精准规则，不是流水账。
第三层：工作区记忆
Section titled “第三层：工作区记忆”.workbuddy/memory/├── 2026-09-08.md # 按天的日志，只追加不覆盖└── MEMORY.md # 沉淀的长期项目笔记日志写什么（完成实质工作后追加）：
- 建了什么、改了什么
- 选了什么技术方案、为什么
- 踩了什么坑、怎么解的
不写什么：临时的搜索结果、报错堆栈、临时路径。三个月后回头看没价值的东西都别写。
写入时机（硬性）
Section titled “写入时机（硬性）”完成以下任一事项后应当写入：
- 搭建或修改了网站/应用
- 修了一个 bug
- 写了报告或文档
- 完成重构或架构调整
- 确定了技术方案
- 用户说了项目约定或偏好
简单问答、打招呼、查资料不用写。
错误一：把日志当草稿 日志是给未来的自己看的。写“修了 bug”没用，写“修了 X 模块的 Y 问题，原因是 Z，解法是 W”才有用。
错误二：覆盖而不是追加 日志是 append-only。覆盖了昨天的记录就找不回来了。
错误三：该写不写 “下次再说”的结果就是下次重新踩一遍坑。
超过 30 天的日志，按主题蒸馏到 MEMORY.md，然后删掉原文件。目的是让记忆文件保持小而准——一个几万字符的记忆文件，AI 也读不过来。
一个判断标准
Section titled “一个判断标准”下次开新会话时，你希望 AI 已经知道什么？ 那些东西就该写进记忆。
进阶篇到此结束
Section titled “进阶篇到此结束”到这里你已经掌握了 WorkBuddy 的四大效率杠杆：技能、子代理、MCP、自动化，以及让它们跨会话连续的记忆系统。
下一步是 实战篇——用真实任务把这些组合起来。