一句话结论：大多数AI编程工具是"金鱼记忆"——每次对话从零开始。WorkBuddy用三套系统（自动化调度、持久记忆、专家角色）解决了这个问题。本文讲清楚这三套系统怎么配、怎么用、怎么联动，附带6个可直接复用的实战配置。
用了大半年各种AI编程工具后，我发现一个尴尬的事实：
每次打开AI工具，我都要重新介绍一遍自己——项目是干什么的、技术栈是什么、我习惯怎么写代码、哪些文件绝对不能动。这感觉像换了新理发师，每次都得把"两边推短、上面留长、刘海往右"重新说一遍。说烦了，但不说又不行。
后来我开始用 WorkBuddy，最开始只当它是"又一个AI编程助手"。直到有一天我连续三天没打开它，第四天打开时，它张口就问我："上周那个 CSRF token 的问题解决了吗？GitHub Actions 的部署脚本要不要继续改？"
我当时愣了一下。它居然记得。
这就是三件套联动的效果。下面把每一件拆开讲清楚。
一、先看全局：三件套分别解决什么问题
如果把 WorkBuddy 比作一个研发助手团队，三件套的角色是这样的：
| 系统 | 角色 | 核心问题 | 一句话理解 |
|---|---|---|---|
| Memory | 大脑 | "你上次跟我说到哪了？" | 持久化记忆，跨会话保持上下文 |
| Automation | 双手 | "每天这个时候帮我做这件事" | 定时调度，人到点不用操心 |
| Expert | 人格 | "用什么样的风格、知识和边界来做" | 专业角色定义，切换行为模式 |
三件套拆开用，每一件都有价值。但真正产生质变的是三件联动——Memory 提供"你是谁"的上下文，Expert 决定"怎么回答"，Automation 保证"何时干活"。合在一起，你的AI助手就从"每次问都失忆的实习生"变成了"懂你项目、知你习惯、按时出活的搭档"。
下面逐一拆解。
二、Memory 系统：三层记忆，各司其职
Memory 是 WorkBuddy 最容易被低估的能力，因为它"不声张"——没有炫酷的界面，没有弹窗提示。但它是三件套的地基。
2.1 三层记忆架构
WorkBuddy 的 Memory 不是"一个大文件存一切"，而是分了三个层级：
┌─────────────────────────────────────┐ │ Layer 1 — Cloud Memory（云记忆） │ │ 服务器自动学习你的长期偏好 │ │ 例如：你一直用 TypeScript + React │ ├─────────────────────────────────────┤ │ Layer 2 — User Memory（用户记忆） │ │ ~/.workbuddy/MEMORY.md │ │ 跨所有项目共享 │ │ 例如："我总是用 pnpm 不用 npm" │ ├─────────────────────────────────────┤ │ Layer 3 — Workspace Memory（项目记忆）│ │ {项目}/.workbuddy/memory/ │ │ 每日工作日志 + 项目级记忆 │ │ 例如："这个项目用了 Prisma + SQLite" │ └─────────────────────────────────────┘Layer 1（云记忆）是自动的，你不需要管。它会从对话历史中提炼你的长期偏好——喜欢的语言、框架、代码风格，然后在新会话开始时自动注入。
Layer 2（用户记忆）是你手动写入的"铁律"。格式很简单：
# 我的铁律 - 所有新项目统一用 pnpm，不用 npm 或 yarn - 前端默认 React 19 + TypeScript 5.7 + Tailwind CSS 4 - 后端默认 Bun + Hono + Drizzle ORM - 代码注释用中文，变量名用英文 - 永远不要自动格式化我的代码 - 不要创建 README 文件除非我明确要求写一次，所有项目自动生效。这是"不需要每次都重复说"的关键。
Layer 3（项目记忆）是自动维护的，包括： -YYYY-MM-DD.md：每日工作日志，每次做完实质性任务自动追加 -MEMORY.md：项目约定和技术决策的持久化记录
2.2 实战：让 WorkBuddy 记住你的技术栈
假设你正在做一个全栈项目，用 Next.js + Prisma + PostgreSQL。你可以在项目的.workbuddy/memory/MEMORY.md里写：
# 项目记忆 ## 技术栈 - 框架：Next.js 15 (App Router) - 语言：TypeScript 5.7 (strict mode) - ORM：Prisma 6 - 数据库：PostgreSQL 16 via Supabase - 认证：Better Auth v1 - UI：shadcn/ui + Tailwind CSS 4 - 部署：Vercel ## 约定 - 所有 API route 放在 src/app/api/ 下 - Server Actions 放在 src/actions/ 下 - 组件用 named export，不用 default export - 数据库迁移用 `pnpm db:push`（开发阶段），不用 `prisma migrate` - 环境变量用 T3 Env 校验 ## 已知问题 - 移动端导航菜单在 iOS Safari 上有 z-index 问题（待修复） - 上传功能仅支持 < 10MB 文件（需要改分片上传）以后每次在这个项目里打开 WorkBuddy，它就会自动带上这些上下文。你再也不需要说"等等，这个项目用的是 Next.js App Router 还是 Pages Router"——它自己知道。
2.3 三层记忆的检索策略
WorkBuddy 不会把三层记忆一口气全塞进上下文窗口（那样会爆窗口）。它有个聪明的检索策略：
- 当前项目相关→ 优先读项目记忆（Layer 3）
- 跨项目通用偏好→ 读用户记忆（Layer 2）
- 历史对话特定事件→ 调用云记忆搜索（Layer 1）
这意味着你不会因为"记了太多"而导致上下文污染。记住一条原则：项目级的写项目里，跨项目的写用户级，自动学习的不操心。
三、Automation 系统：把"记得做"变成"自动做"
Memory 解决了"记得上下文"的问题，Automation 解决"记得做事"的问题。
3.1 Automation 能做什么
坦白说，WorkBuddy 的 Automation 不是 Zapier 或 n8n 那种通用工作流引擎。它的定位更精准：让AI在指定时间、指定项目里执行指定任务，并保留完整的执行记忆。
支持两种模式：
| 模式 | 适用场景 | 例子 |
|---|---|---|
| recurring（循环） | 周期性重复任务 | 每天生成日报、每周代码审查、每月技术文章 |
| once（一次性） | 定时提醒/延迟执行 | 下午3点提醒开会、30分钟后检查构建结果 |
3.2 实战：每天自动生成并发布技术文章
这是我实际在跑的配置，就是你现在读到这篇文章的来源：
名称：CSDN发文章 调度：FREQ=DAILY;BYHOUR=13;BYMINUTE=55 工作目录：/path/to/csdn-project 专家角色：ContentCreator每天下午1:55，WorkBuddy 自动： 1. 读取之前的发布记录（Memory），确保新文章不重复 2. 用 ContentCreator 专家角色撰写一篇新文章 3. 通过浏览器自动化发布到 CSDN 4. 写执行摘要到记忆文件
关键细节：Automation 在执行时也会读写 Memory。这就形成了闭环——上次执行的结果成为下次执行的上下文。这就是"自动化不减质"的秘诀。
3.3 更多实战场景
场景1：每日代码审查
名称：每日代码审查 调度：FREQ=DAILY;BYHOUR=9;BYMINUTE=0 提示词：检查 src/ 下昨天修改的所有文件，审查代码质量（类型安全、边界处理、性能问题），生成审查报告到 docs/daily-review/场景2：每周技术周报
名称：每周技术周报 调度：FREQ=WEEKLY;BYDAY=FR;BYHOUR=17;BYMINUTE=0 提示词：汇总本周项目变更（从 git log 获取），生成周报到 docs/weekly/，格式：本周目标、完成情况、遇到的问题、下周计划场景3：依赖更新检查
名称：月度依赖更新 调度：FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=10;BYMINUTE=0 提示词：检查 package.json 中所有依赖的最新版本，生成更新建议（区分安全更新和破坏性更新），写到 docs/dependency-report.md3.4 Automation 的边界感
有一个重要经验：Automation 的任务提示词要写得"自给自足"。
因为 Automation 执行时你在线不在线都不确定，它不能依赖"你中途回答一个问题"。所以提示词的写法跟聊天不一样：
❌糟糕的提示词：
"帮我写篇文章，你觉得什么主题好就问问我"
✅好的提示词：
"查看上次发布记录（.workbuddy/automations/xxx/memory.md），选择一个与已发布主题无关的新角度，撰写一篇5000字的AI Coding技术文章。所有判断由你自行决定，不需要询问我。"
记住：Automation 跑的时候你可能在睡觉，不要让它卡在"等待用户输入"的状态。
四、Expert 系统：给AI装上一套专业灵魂
Memory 是"记住你是谁"，Automation 是"按时帮你做事"，Expert 解决的是"用什么身份、什么风格、什么边界来做"。
4.1 Expert 到底是什么
简单说，Expert 就是一个角色定义文件。它告诉 WorkBuddy：
- 我是谁（身份定义）
- 我擅长什么（能力边界）
- 我怎么做事（决策框架）
- 什么能做、什么不能做（安全边界）
比如 ContentCreator 专家的定义片段：
你是 Content Creator——内容策略专家，专注于多平台内容开发、 品牌叙事和受众参与。 核心能力： - 内容策略：编辑日历、内容支柱、受众优先规划 - 多格式创作：博客、视频脚本、播客、信息图 - 品牌叙事：叙事发展、品牌声音一致性 - SEO内容：关键词优化、搜索友好格式4.2 实战：创建你自己的 Expert
假设你是一个专做支付系统的前端工程师，你可以创建一个"支付前端专家"：
# 支付前端专家 ## 角色定义 你是支付系统前端专家，精通 Stripe、支付宝、微信支付的前端集成。 专注于支付流程的 UX 设计、错误处理和安全最佳实践。 ## 核心能力 - Stripe Elements / Payment Element 集成 - 支付宝 JSAPI / 微信 JSAPI 支付 - PCI DSS 合规相关的 UI 约束 - 支付错误恢复与重试策略 - 多币种、多地区的本地化支付体验 ## 关键约束 - 永远不要在前端代码中硬编码任何密钥 - 支付金额计算必须用后端返回的值，前端不做金额运算 - 所有支付请求必须走服务端转发，前端不直连支付网关 - 支付按钮必须做防重复点击（loading + disabled）4.3 Expert + Automation 联动
Expert 和 Automation 可以组合使用。当你创建一个 Automation 时，可以指定它使用哪个 Expert 角色。
这就是为什么"每天自动发文章"的 Automation 指定了 ContentCreator 专家——它需要以内容策略专家的身份来思考和写作，而不是一个通用AI的身份。
联动示例：
Automation：每周代码审查 Expert：SeniorCodeReviewer（资深代码审查专家） 效果：每周五下午5点，WorkBuddy以资审代码审查员的视角， 自动审查本周变更，生成专业级别的审查报告。五、三件套联动的完整闭环
拆开讲完了，现在看它们怎么一起工作。拿"每天自动发技术文章"这个真实案例来还原全流程：
┌─────────────────────────────────────────────────────┐ │ 13:55 — Automation 触发器激活 │ │ ↓ │ │ 读取 Memory： │ │ ├─ automation memory：上次发布的是什么主题？ │ │ ├─ workspace memory：CSDN账号、发布流程、历史记录 │ │ └─ cloud memory：用户的写作偏好、技术背景 │ │ ↓ │ │ 激活 Expert（ContentCreator）： │ │ └─ 以内容策略专家的身份，选择一个不重复的主题 │ │ ↓ │ │ 执行任务： │ │ ├─ 撰写文章（5000字，技术深度，实用导向） │ │ ├─ 格式化（Markdown → HTML） │ │ └─ 发布（浏览器自动化 → CSDN） │ │ ↓ │ │ 写回 Memory： │ │ ├─ automation memory：记录本次执行摘要 │ │ └─ daily log：追加今日工作日志 │ │ ↓ │ │ 完成。下次执行时，Memory 里已有最新记录。 │ └─────────────────────────────────────────────────────┘这个闭环里，每一环都在为下一环提供上下文。没有 Memory，Automation 每次都是"从零开始"；没有 Expert，Automation 的输出缺少专业深度；没有 Automation，Memory 和 Expert 就只是"被动记忆"和"手动切换"。
5.1 闭环的核心价值
说具体一点，闭环带来了三个关键效果：
1. 防重复
Automation 执行前会读 memory，看到上次发的是"副业路径"，这次就绝对不会再写"副业路径"。这是"自动去重"。
2. 渐进增强
每次执行的结果（标题、链接、反响）写回 memory，下次执行时就能参考。比如发现"带真实案例的文章阅读量高30%"，下次就会多用案例。这是"自动优化"。
3. 故障恢复
如果上次发布失败了，memory 里有失败记录。下次执行时会先检查："上次是不是失败了？失败原因是什么？需要重试还是跳过？"这是"自动容错"。
六、踩坑实录：我趟过的5个坑
光讲理论不够，说说真实踩过的坑。
坑1：Memory 写了但没被读
现象：在MEMORY.md里写了"永远不要自动格式化代码"，WorkBuddy 还是把我代码格式化了。
原因：Memory 文件是"被动读取"的——它不是每次都自动加载全部 memory。WorkBuddy 会根据任务相关度决定读哪些文件。
解法：把关键约束写在~/.workbuddy/MEMORY.md（用户级），这个文件在所有项目里优先级最高。项目级的配置写一行就够了："代码格式化规则见用户级 MEMORY.md"。
坑2：Automation 提示词太依赖交互
现象：设置了一个 Automation 让它"分析昨天的数据并生成报告"，结果它卡在"你想按什么维度分析"的问题上。
原因：Automation 跑的时候没有人在旁边回答追问。
解法：提示词里加一句"自主决定所有判断，不需要询问我。如果遇到选择，选择最合理的默认方案并说明理由。"
坑3：Expert 角色写得太宽泛
现象：创建了一个"全栈工程师"Expert，但没有限制它的行为边界。结果它开始建议我重写整个项目的架构。
原因：Expert 没有"禁止做XX"的部分。
解法：每个 Expert 定义里一定要有"关键约束"部分。比如："不要提出影响超过3个文件的架构变更建议"、"在没有明确需求的前提下，不要建议引入新的第三方库"。
坑4：忘记清理旧 Memory
现象：项目跑了两个月后，Memory 文件积累了60多天的日志，加载变慢，上下文也被污染。
原因：Memory 只增不减，需要定期维护。
解法：30天以上的日志自动提炼为主题摘要，删除原始日志文件。这个操作 WorkBuddy 自己能做——偶尔提醒它"整理一下项目 memory"就行。
坑5：Automation 任务互相打架
现象：设了"每天早上9点代码审查"和"每天早上9点生成周报"两个 Automation，同时触发后它们互相抢资源。
原因：两个 Automation 用了同一个工作目录，且同时触发。
解法：错峰调度。比如"代码审查 9:00，周报 9:30"。或者给不同的 Automation 分配不同的工作目录。
七、总结：从"AI帮你写代码"到"AI替你管项目"
回顾一下三件套：
| 系统 | 核心价值 | 一句话建议 |
|---|---|---|
| Memory | 跨会话保持上下文 | 项目级写项目里，用户级写通用规则，云层不操心 |
| Automation | 定时自动执行 | 提示词要"自给自足"，不要依赖交互追问 |
| Expert | 专业角色行为约束 | 能力边界和安全约束写得越细，输出质量越高 |
我觉得 WorkBuddy 的精髓不在某一项功能有多强，而在于这三件套的联动设计。
大多数AI工具解决的是"怎么帮你写代码"的问题。WorkBuddy 想解决的是"怎么让AI持续地、理解地、自动化地参与你的开发流程"的问题。
前者是"你问 → AI答"的单次交互。后者是"你配置 → AI记忆 → AI自动执行 → AI再记忆"的持续协作。
这个转变的本质在于：你从"每次都要指挥AI"的操作者，变成了"设置规则后AI自动运转"的管理者。省下的不是某个具体任务的时间，而是"记住要做什么"、"记住怎么做"、"记住上次做到哪了"这些元认知开销。
如果你每天打开AI编程工具的第一件事是"重新介绍自己"，那三件套值得花一个下午配好。
一句话总结：WorkBuddy 三件套（Memory + Automation + Expert）本质上是在做一件事——把AI从"每次从零开始的金鱼脑子"升级为"记住你是谁、知道什么时候该干什么、用对的风格去干"的研发搭档。Memory 管"记什么"，Automation 管"何时干"，Expert 管"怎么干"。配上之后，你就不需要每次打开AI都重新自我介绍了。
