AI 助手记忆设计：WorkBuddy 与主流方案的对比分析

本文从一个产品设计视角，客观分析不同 AI 编程助手在"上下文持久化"方面的设计思路，帮助理解各方案的取舍逻辑。

一、问题背景：AI 助手为什么需要"记忆文件"？

AI 助手本质上是"无状态"的——每次对话开始时，它不记得上一次聊了什么。这在简单问答场景下没问题，但在编程、项目管理等持续协作场景下，就会出现问题：

• 你上次说"这个项目用 TypeScript"，这次它又默认用 JavaScript
• 你上次定义了"代码风格遵循 Airbnb 规范"，这次它又用别的
• 你上次让它扮演"资深架构师"，这次它又变回通用助手

为了解决这个问题，不同的 AI 工具发展出了不同的"记忆持久化"方案。

二、主流方案：项目级指令文件

以 CLAUDE.md（Claude）、AGENTS.md（跨工具标准）、.cursorrules（Cursor）为代表。

工作方式

在项目根目录放一个 Markdown 文件，AI 每次会话启动时自动读取，文件内容就是 AI 的行为指令。

你的项目/
├── CLAUDE.md          ← AI 读取这个
├── src/
├── package.json
└── ...

文件内容通常是混合的：

# 项目指令

## 身份
你是一个资深 Rust 工程师。

## 编码规范
- 使用 cargo fmt 格式化
- 禁止使用 unsafe
- 所有公开函数必须有文档注释

## 架构约定
- 数据层用 SQLx
- 业务逻辑和 IO 分离

设计哲学

一份文件 = 一个项目的全部 AI 上下文。

简单、直观、可发现。任何团队成员打开仓库就能看到 AI 在遵循什么规则。

三、WorkBuddy 的方案：三层分离

WorkBuddy 选择了不同的路径——不把所有信息塞进一个文件，而是按信息的性质拆分到不同层次。

层次结构

用户级（~/.workbuddy/）           ← 跨所有项目生效
├── SOUL.md                       性格、价值观、行为边界
├── IDENTITY.md                   身份信息（名字、风格）
├── USER.md                       用户信息（称呼、偏好）
└── MEMORY.md                     跨项目的长期记忆

项目级（{项目目录}/.workbuddy/）   ← 仅当前项目生效
└── memory/
    ├── MEMORY.md                 项目长期笔记
    └── 2026-07-24.md             每日工作日志

三类信息的分工

信息类型	放在哪里	例子
身份（我是谁）	用户级 SOUL.md / IDENTITY.md	"风格直接，不说废话"
记忆（发生了什么）	项目级 memory/ 目录	"今天修了登录模块的 JWT bug"
能力（怎么干活）	Skill 系统（可安装的模块）	"部署到 CloudStudio 的完整流程"

设计哲学

不同性质的信息，用不同机制承载。

• 身份应该跨项目稳定 → 放用户级
• 记忆应该随项目积累 → 放项目级
• 能力应该可复用可共享 → 做成可安装的模块

四、客观对比

4.1 易用性

维度	项目指令文件	WorkBuddy 三层分离
上手成本	低——建一个文件就行	较高——需要理解三层结构
迁移成本	低——标准格式，工具间通用	较高——体系不同，需重新组织
可发现性	高——在仓库根目录就能看到	低——藏在 .workbuddy/ 下

4.2 表达能力

维度	项目指令文件	WorkBuddy 三层分离
身份一致性	低——每个项目要重新定义	高——用户级统一管理
信息结构化	低——全混在一个文件里	高——按性质自动分类
动态积累	弱——静态文件，手动维护	强——日志自动追加，记忆逐步积累
能力复用	弱——指令写死在文件里	强——Skill 可跨项目安装共享

4.3 团队协作

维度	项目指令文件	WorkBuddy 三层分离
团队共享	强——文件进 git，全员可见	弱——.workbuddy/ 不进版本控制
版本追溯	强——随代码一起 commit	无——本地文件，无版本历史
新人上手	强——clone 仓库即获得 AI 配置	弱——每人需独立配置

4.4 生态兼容

维度	项目指令文件	WorkBuddy 三层分离
跨工具兼容	AGENTS.md 正成为跨工具标准	否——WorkBuddy 专有体系
社区生态	大量 CLAUDE.md 模板可参考	少——体系较新
标准化程度	高——格式逐渐统一	低——自定义格式

五、各自的适用场景

项目指令文件适合：

• 团队协作项目——AI 配置需要随仓库共享
• 开源项目——贡献者需要一致的 AI 行为
• 快速上手——不想花时间理解复杂体系
• 多工具混用——AGENTS.md 可以被多个工具读取

WorkBuddy 适合：

• 个人长期协作——身份和记忆跨项目积累
• 复杂工作流——Skill 系统承载多步骤可复用流程
• 多项目管理——用户级身份统一，项目级记忆隔离
• 重视仓库整洁——AI 配置不混入代码仓库

六、核心矛盾

两种方案的分歧，本质上是两个设计理念的冲突：

"静态指令" vs "动态记忆"

项目指令文件是静态的——你写好规则，AI 每次读取并执行。像员工手册。

WorkBuddy 的记忆是动态的——AI 在工作中逐步积累笔记，下次会话恢复状态。像工作日记。

员工手册的优势是明确、可共享；工作日记的优势是灵活、能积累经验。两者解决的是不同层面的问题，理论上应该共存。

"统一入口" vs "分层解耦"

项目指令文件追求一个入口解决所有问题——简单但容易混乱。

WorkBuddy 追求按信息性质分层——清晰但入口分散。

七、总结

	项目指令文件	WorkBuddy
核心理念	一个文件承载全部	三层分离各司其职
最大优势	简单、可共享、生态成熟	结构化、可积累、身份一致
最大短板	信息混合、不易动态积累	缺项目级指令入口、团队协作弱
哲学	员工手册	工作日记 + 身份档案 + 技能库

两种方案都不是"对"或"错"，而是不同的设计取舍。理解取舍的逻辑，比判断优劣更有价值。