我怎样把 WorkBuddy 用成一套常驻系统：20 个任务域背后的五条流水线
大多数人对 AI 工具的使用，停在「问答」这一层：想到什么问什么，问完就关。这个用法的问题不是效率低，而是它把 AI 降级成了一个更快的搜索引擎——你每次都在重新建立上下文，而 AI 每次都从零开始。 我用了 WorkBuddy 足够久，久到它不再是一个工具，而是我数字工作的一部分。这篇文章不复述我做了多少事，而是回答一个更有用的问题：这些事是怎么被组织起来的？ 下面的底账全部来自本次实测，不是凭印象回忆： 维度 实测值 用户级技能 121 个 定时自动化 28 个（26 个在跑 / 2 个暂停） 已绑定外部连接器 6 个 知识库规模 约 2,988 个 md 文件 · 56k 个 RAG 切片 这四个数字背后，是五条常年同时运行的流水线。 一、你不是在使用工具，你是在运营一个系统 先说一个被普遍低估的事实：AI 工具的产出质量，取决于你为它设计的结构，而不是你提问的水平。 同样一个人用同一个 AI 工具，有人的用法是「一个文件夹、一堆 md、一句 prompt」；有人的用法是—— 121 个技能，每个技能是一个被验证过的流程，不是一段提示词 28 个定时任务，按黄金时段排布，凌晨干活、白天只看结果 4 层记忆：身份档案、用户偏好、项目日志、每日复盘 一套验收机制：任何「完成」声明前必须实测磁盘 这两种用法的产出差距，不是 10 倍，是两个量级。原因很简单：前者每次都在重新发明轮子，后者把轮子的制造过程本身沉淀成了资产。 我把这 121 个技能理解为流程的固化层——每一次踩坑之后问自己一句「这个坑值得写下来吗」，如果值得，它就变成一个技能，下次不用再踩。 所以判断你有没有在「用系统」，有一个简单的测试：你的 AI 工具里，有多少东西是你自己写的规则，而不是别人的默认值。 二、五条流水线：把 20 个任务域归并后的骨架 我原本列了 20 个任务域（知识库治理、邮件抽取、AIMR 治理、GPO 季度跟踪……）。但 20 个是并列关系，看不出结构。真正的结构是五条流水线——每个域都是某条流水线上的一个工位。 ...