一句话结论大多数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) - ORMPrisma 6 - 数据库PostgreSQL 16 via Supabase - 认证Better Auth v1 - UIshadcn/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发文章 调度FREQDAILY;BYHOUR13;BYMINUTE55 工作目录/path/to/csdn-project 专家角色ContentCreator每天下午1:55WorkBuddy 自动 1. 读取之前的发布记录Memory确保新文章不重复 2. 用 ContentCreator 专家角色撰写一篇新文章 3. 通过浏览器自动化发布到 CSDN 4. 写执行摘要到记忆文件关键细节Automation 在执行时也会读写 Memory。这就形成了闭环——上次执行的结果成为下次执行的上下文。这就是自动化不减质的秘诀。3.3 更多实战场景场景1每日代码审查名称每日代码审查 调度FREQDAILY;BYHOUR9;BYMINUTE0 提示词检查 src/ 下昨天修改的所有文件审查代码质量类型安全、边界处理、性能问题生成审查报告到 docs/daily-review/场景2每周技术周报名称每周技术周报 调度FREQWEEKLY;BYDAYFR;BYHOUR17;BYMINUTE0 提示词汇总本周项目变更从 git log 获取生成周报到 docs/weekly/格式本周目标、完成情况、遇到的问题、下周计划场景3依赖更新检查名称月度依赖更新 调度FREQMONTHLY;BYMONTHDAY1;BYHOUR10;BYMINUTE0 提示词检查 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 disabled4.3 Expert Automation 联动Expert 和 Automation 可以组合使用。当你创建一个 Automation 时可以指定它使用哪个 Expert 角色。这就是为什么每天自动发文章的 Automation 指定了 ContentCreator 专家——它需要以内容策略专家的身份来思考和写作而不是一个通用AI的身份。联动示例Automation每周代码审查 ExpertSeniorCodeReviewer资深代码审查专家 效果每周五下午5点WorkBuddy以资审代码审查员的视角 自动审查本周变更生成专业级别的审查报告。五、三件套联动的完整闭环拆开讲完了现在看它们怎么一起工作。拿每天自动发技术文章这个真实案例来还原全流程┌─────────────────────────────────────────────────────┐ │ 13:55 — Automation 触发器激活 │ │ ↓ │ │ 读取 Memory │ │ ├─ automation memory上次发布的是什么主题 │ │ ├─ workspace memoryCSDN账号、发布流程、历史记录 │ │ └─ cloud memory用户的写作偏好、技术背景 │ │ ↓ │ │ 激活 ExpertContentCreator │ │ └─ 以内容策略专家的身份选择一个不重复的主题 │ │ ↓ │ │ 执行任务 │ │ ├─ 撰写文章5000字技术深度实用导向 │ │ ├─ 格式化Markdown → HTML │ │ └─ 发布浏览器自动化 → CSDN │ │ ↓ │ │ 写回 Memory │ │ ├─ automation memory记录本次执行摘要 │ │ └─ daily log追加今日工作日志 │ │ ↓ │ │ 完成。下次执行时Memory 里已有最新记录。 │ └─────────────────────────────────────────────────────┘这个闭环里每一环都在为下一环提供上下文。没有 MemoryAutomation 每次都是从零开始没有 ExpertAutomation 的输出缺少专业深度没有 AutomationMemory 和 Expert 就只是被动记忆和手动切换。5.1 闭环的核心价值说具体一点闭环带来了三个关键效果1. 防重复Automation 执行前会读 memory看到上次发的是副业路径这次就绝对不会再写副业路径。这是自动去重。2. 渐进增强每次执行的结果标题、链接、反响写回 memory下次执行时就能参考。比如发现带真实案例的文章阅读量高30%下次就会多用案例。这是自动优化。3. 故障恢复如果上次发布失败了memory 里有失败记录。下次执行时会先检查上次是不是失败了失败原因是什么需要重试还是跳过这是自动容错。六、踩坑实录我趟过的5个坑光讲理论不够说说真实踩过的坑。坑1Memory 写了但没被读现象在MEMORY.md里写了永远不要自动格式化代码WorkBuddy 还是把我代码格式化了。原因Memory 文件是被动读取的——它不是每次都自动加载全部 memory。WorkBuddy 会根据任务相关度决定读哪些文件。解法把关键约束写在~/.workbuddy/MEMORY.md用户级这个文件在所有项目里优先级最高。项目级的配置写一行就够了代码格式化规则见用户级 MEMORY.md。坑2Automation 提示词太依赖交互现象设置了一个 Automation 让它分析昨天的数据并生成报告结果它卡在你想按什么维度分析的问题上。原因Automation 跑的时候没有人在旁边回答追问。解法提示词里加一句自主决定所有判断不需要询问我。如果遇到选择选择最合理的默认方案并说明理由。坑3Expert 角色写得太宽泛现象创建了一个全栈工程师Expert但没有限制它的行为边界。结果它开始建议我重写整个项目的架构。原因Expert 没有禁止做XX的部分。解法每个 Expert 定义里一定要有关键约束部分。比如不要提出影响超过3个文件的架构变更建议、在没有明确需求的前提下不要建议引入新的第三方库。坑4忘记清理旧 Memory现象项目跑了两个月后Memory 文件积累了60多天的日志加载变慢上下文也被污染。原因Memory 只增不减需要定期维护。解法30天以上的日志自动提炼为主题摘要删除原始日志文件。这个操作 WorkBuddy 自己能做——偶尔提醒它整理一下项目 memory就行。坑5Automation 任务互相打架现象设了每天早上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都重新自我介绍了。
