大多数人对 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 个是并列关系，看不出结构。真正的结构是五条流水线——每个域都是某条流水线上的一个工位。
| 流水线 | 覆盖的域 | 一句话职责 |
|---|---|---|
| ① 采集 | 邮件抽取 · 网盘 · GitHub · 公众号 · YouTube | 把外部世界的东西搬进来 |
| ② 治理 | 知识库建设 · 检索召回 · A+ 门禁 | 让搬进来的东西可信 |
| ③ 生产 | 报告 · 表格 · PPT · HTML · 网页 · 应用 · 内容出版 | 把可信的东西变成交付物 |
| ④ 编排 | 多 Agent 协作 · 交接 · 复盘 · 决策记录 | 让一群 AI 互相不打架 |
| ⑤ 运维 | 定时自动化 · 系统基础设施 · 模型治理 | 让上面四条不用我盯着 |
五条线的单向依赖关系是：采集 → 治理 → 生产 → 分发 → 复盘 → 回流为新的规则。运维横切全部。
下面逐条讲机制，因为机制比清单值钱。
三、采集流水线：AI 的价值在「挖矿」，不在「搬运」
3.1 邮件是最高价值的数据源，也是最被低估的
我不确定有多少人把邮箱当成每日情报流来用。每天早上 6:05，一个自动化会抓取前一整天的工作邮箱，生成一张事件看板。
关键不在「自动读邮件」——那谁都会写。关键在它把邮件变成结构化事件：谁在推进什么、卡在哪一步、哪些承诺到期了、需要我回应的有哪几封。
3.2 抽取链路比读取链路难十倍
读到邮件正文不难，难的是附件。一个 PDF 图文、一个 4 万行的价目 Excel、一份扫描版合同——这些东西在邮件里躺着，人不看就等于不存在。
我的做法是建了一条固定链路：邮件 → 附件批量下载 → 格式转换（markitdown / OCR）→ 结构化 → 组合成报告。最后一步才是真正有价值的：把五封邮件里散落的信息拼成一份「这张报价单和我上个月拿的那张差在哪」的对比。
大附件这里有个坑：某些通道对附件有 1MB 硬限，那不是邮箱服务的限制，是客户端通道的限制。绕过它花了我不少时间——最终方案是走 SMTP 直连，一劳永逸。
3.3 采集流水线的铁律：来源必须可回溯
一条采集规则：任何从外部进来、准备进知识库的内容，都必须带来源标记——来自哪封邮件、哪个 URL、哪个仓库 commit。做不到就标注为「未溯源」，并降权。
这不是洁癖。我有一次把模型推断的内容当成库里已有的知识写进汇报，对方一追问就崩了。从那以后，三段来源分离成了硬规矩：知识库事实 / 运行时实测 / 模型推断，三段各带自己的标记，一段都不许冒充另一段。
四、治理流水线：让知识库从「能查到」变成「信得过」
4.1 检索优先：任何提问先查自己的库
我的规则很极端：每一条非空消息，先检索知识库，再回答。包括「帮我跑个命令」这种纯操作指令。
为什么值得这么做？两个原因：
- 命中即引用 —— 回答里可以直接带出处，比模型凭记忆编的可靠
- 未命中即信号 —— 如果我的问题在积累了几千篇笔记的库里都搜不到，说明要么是我的知识结构有盲区，要么这个问题本身还模糊
但比规则更重要的是降级必须诚实：检索不到的时候，明确说「知识库未命中」，然后才用模型能力或全网搜索。最危险的失败模式不是搜不到，是假装搜到了。
4.2 治理动作清单（以及为什么是这些）
2,988 个文件的知识库，半年不治理就会变成垃圾场。我的固定动作：
| 动作 | 频率 | 作用 |
|---|---|---|
| 增量同步（含重排） | 每日 | 新内容进入可检索范围 |
| 死链扫描与修复 | 每日 | 防止引用链断裂 |
| 六维深度体检 | 每月 | 结构性缺陷普查 |
| 关键件快照 | 每周五 | 防劣化——记录当前健康状态，出问题时能对比回退 |
| 恢复演练 | 季度 | 假装数据全毁，验证真能恢复 |
| 红级告警 | 每日 | 异常当天可见 |
季度恢复演练这条最反直觉，但价值最高。 备份没验证过就等于没有备份。我每季度会真的跑一次恢复，看看季度末了还能不能把东西捞回来——每次演练都能发现新的坑。
4.3 知识进门的门槛：A+ 门禁
不是所有读到的东西都值得进库。我的入库门禁是三步：溯源核查 → 真伪分离 → 伪归属修正。
「伪归属修正」这一步处理的是一类隐蔽错误：把两个来源的信息误合并成一个观点。看起来无害，但它会让知识库在后续检索中持续返回错误结论——因为错误会被反复引用，越引越实。
知识库最大的敌人不是缺内容，是错内容被引用一万次之后看起来像真理。
五、生产流水线：从「结论」到「可交付物」
5.1 生产是自动化最难替代的一环
采集和治理，脚本都能做。但生产这一环——把多来源信息合起来推到底、给出判断和推荐——这一环必须有人（或有强模型）在场，因为它需要判断取舍。
我的固定动作链是：邮件 + Excel + PDF + 网页 + 知识库 → 单一结论 + 溯源四件套。
5.2 数字溯源四件套（这是我最看重的一条）
任何数字出现在交付物里，必须同时给出四样东西：
- 数据源路径 —— 这个数字来自哪个文件哪一行
- 公式 / 口径 —— 怎么算出来的，分母是什么
- 时间窗 —— 统计的是哪一段时间
- 多口径对照表 —— 换一种算法结论是否一致
第 4 条最费时间，但它是唯一能防住「一个数字毁了整篇报告」的东西。口径一变，结论就翻盘，而报告最怕的就是这种翻盘。
5.3 交付形态：md + 单文件 HTML 双轨
这是最近才固定下来的规矩。md 用来改和存档，HTML 用来读和分享——HTML 必须是单文件自包含，零外链，任何网络异常下都能打开、能发、能存档。
另外一条铁律：交付重心是解释深度，不是校核过程。 我不想看到一份报告里三页在讲「我怎么核对的」——校核档必须存在，但不能占主位。主位留给「把这些东西合起来推到底之后，到底得出了什么原文没说的」。
5.4 报告版本管理与架构锁定
一个报告改到 v18 是常事。规则有三条：
- 保留原始版本，不覆盖 —— 每次迭代单独存档
- 改到第三版时写一份
ARCHITECTURE-vN.md—— 把这份报告的逻辑骨架锁定下来 - 架构锁定后，新增内容只能挂载，不能重排 —— 否则引用锚点全断
六、编排流水线：Agent 的能力从来不是瓶颈
6.1 我最想告诉所有多 Agent 使用者的一句话
我在 5000+ 文件的知识库里同时跑多个 Agent 时，最大的教训不是「Agent 不够聪明」，而是——
Agent 太自由了。它们能写任何文件、改任何配置、跑任何命令，但没有人告诉它们什么不该做。
这就像给五个实习生每人一把公司钥匙，但没有门禁系统。迟早出事。 详细的治理架构我写在《多 Agent 协同治理：从单写者到项目级授权读写》，这里只讲三条最关键的。
6.2 权限矩阵：谁可以写什么
不是「让 Agent 自己判断能不能写」，而是预先定义写权限矩阵。全库只有一个写者，其他 Agent 全部只读 + 提案。写权限是稀缺资源，不是默认状态。
6.3 交接：每一份产出都要能被下一个接住
AI 协作最大的隐性成本是上下文丢失——这一轮做完，下一轮的 Agent 不知道刚才发生了什么，只能重新探测。
我的强制格式是 8 段交接：30 秒版摘要 → 触发条件 → 决策弧 → 状态图 → 已完成矩阵 → 未完成 → 雷区 → 回滚 + 验收清单。
其中最重要的是**「雷区」和「回滚」**两段：前者告诉下一个执行者「这里有个坑，我踩过了」，后者告诉他「出错了怎么退回去」。
6.4 独立复测：Builder 不能自验
这是四条铁律里最值钱的一条：做出东西的 Agent 不允许验收自己的东西。
我用一个全新的、无记忆的 Agent 做独立复测。为什么？因为做过这件事的 Agent 记得自己当时的判断，会不自觉地为它辩护——这叫「自我一致性偏差」，在验收场景里是致命的。
现实效果：有一次复测 Agent 从我的一份回执里找出四处「数字与磁盘实际不符」。四次全对。 从那以后我不再让任何人自验。
6.5 并发写者冲突：一条文件严禁并发编辑
同一个文件，严禁两个执行体同时写。规则是一条一改、改完立刻实测（grep / 哈希校验）。这条看起来像废话，但它是所有「改动丢失」事故的根因。
七、运维流水线：让系统在我睡觉时自己跑
7.1 把任务交给时间
28 个自动化不是炫技，是把任务交给时间——它不需要我的注意力，只需要一个正确的触发时刻。
我的排布逻辑很清楚：
- 05:00–06:40 黄金时段 —— 无人值守的重活（知识库同步、邮件看板、夜间接力）
- 08:00–09:00 早间检查 —— 告警、状态投影、口径守卫
- 12:00–13:00 午间同步 —— 增量入库
- 00:00–00:10 跨日复盘 —— 每天午夜自动复盘前一天
7.2 一条让我吃过亏的铁律
自动化「ACTIVE」只证明它被调度了，不证明它有产出。
这条是我被坑出来的。有一批自动化在管理界面上全是绿色，状态 ACTIVE，看着一切正常。但某天我检查产物新鲜度，发现某条该出日报的自动化已经连续多天没有产物。
排查结果是：它每次运行都秒退，体积约为正常的三分之一，且没有任何工具调用目录——它确实被唤醒了，但它什么也没做。
于是我改掉了健康判据：不看状态，看产物。 现在每条自动化的健康检查，第一步永远是「上一次应该有的产物在不在、新不新鲜」。
7.3 失败不是意外，是常态
我现在的假设是：任何自动化都会失败，问题只是频率。所以我建的是「失败信号」，而不是「成功信号」：
- 应该有产物但没有 → 红了
- 运行秒退 → 可疑
- 体积异常偏小 → 可疑
- 无工具调用目录 → 死了
这个思路的转变很关键：监控系统的设计目标不是证明它活着，而是尽快发现它死了。
八、六种使用姿态：把 AI 从「聪明」变成「可靠」
工具能力决定上限，使用姿态决定下限。我的六种姿态：
1. 命令式
「直接做」/「按你推荐的」——这三个字的价值不在省时间，在于它明确关闭了「反复确认」这个消耗双方注意力的循环。有授权就执行，只有在范围或风险重大变化时才停下来问。
2. 结论先行
我要的永远是：结论 → 依据 → 方案对比 → 推荐 → 行动清单 → 风险。
不接受散点，不接受「差不多」。这不是苛刻——结论先行迫使输出者先想清楚再开口，而模糊的输出通常意味着思考还没完成。
3. 检索优先
见第四章。核心不是「先搜」，是未命中时诚实降级。
4. 过程可验收
任何「完成 N/N」的声明之前，必须实测磁盘。写日志不等于落盘，工具返回「成功」不等于文件已变更。
有一次我写完交接文档就报告「已保存」——实际上文档还在缓冲区。从那以后，所有「已保存」后面必须跟着一行实测命令和它的输出。
5. 沉淀为 SOP
每次踩坑都问一句：这个坑值得写下来吗？
值得 → 变成技能或记忆段落。判断标准很简单：如果这个问题下个月还会遇到，就值得。
6. 多 Agent 编排
重复劳动派给 Agent 队伍，我只做两件事：定标准和终审。中间过程不看。
九、给同类的五条可复用结论
如果你也想把一个 AI 工具用成系统，这五条是我认为最重要的：
结论一：先把「规则」写下来，再谈「用得好」
如果你对某个任务的期望没有落成文字（比如「数字要有出处」「不能虚构」），它就不会被执行。所有我所谓的纪律，在早期都只是一句话；它们变成纪律的那一天，都是因为被写进了某个文件。
结论二：可回溯性 > 覆盖面
宁可只覆盖三件事，但每一件都能回溯到源头；也不要覆盖三十件事，但都不知从哪来的。一个不可追溯的好答案，比没有答案更危险——因为它会被当成事实传播。
结论三：主动维护的成本，远低于事后补救
治理动作（同步、死链、体检、快照、演练）都很无聊，但它们拦住的是「一整类事故」，而不是单次事故。用每小时换取永不停机，这笔账永远划算。
结论四：验收必须由没有参与的人做
无论你多信任自己的产出。换一个无记忆的上下文去验，成本是几分钟，收益是发现系统性错误。
结论五：系统会腐烂，除非有人负责
这是我用了一年多才学会的。技能会过时，自动化会静默失败，文档会指向不存在的路径，记忆会超限被截断。系统不会自己保持整洁，只会被使用磨损。
所以我给自己定了两个固定动作：每周一次系统回顾，每月一次全量体检。 不是因为系统重要，是因为它不健康的速度比我想的快得多。
十、最后
回到最开始那个对比：把 AI 当搜索框，还是当系统。
差别不在于你问了多少问题，而在于——你有没有在用它工作之外的时间，为它搭建结构。
我不敢说自己的系统有多完善。121 个技能里至少有十分之一已经过时，28 个自动化里有 2 个被我主动暂停（因为它们维护的东西已经不存在了）。但每一个我能说出「为什么这么做」的部件，都不是来自默认值。
这套系统最有价值的部分，不是它今天能产出什么，而是：它让我做的每一件事，都留下了下一次能复用的东西。
这大概就是我用 WorkBuddy 的全部理由。