别再裸用workbuddy了，我把八类专家，拉成了一条生产线

很多人用 AI 工具，停在"对话框里问一句、复制一段答案"。我换了个玩法：把 WorkBuddy 当成一个带专家编制的团队来用。

为了证明这不是吹牛，我直接扒了自己本地 3899 条操作审计日志——用数据说话。

这篇文章不堆参数、不编故事。所有数字来自本人工作区真实日志；对比"不用专家"的部分，是通用模型裸用模式与专家模式的方法论/产出差异，不虚构任何对照文件。文末附 4 张我自己跑出来的分析图。

隐私声明：全文不出现任何客户名称、项目代号与内部方案名。图表仅统计公开信息源域名与能力类别，已通过脱敏处理。

我是怎么"分析"自己的

DATA EXPLORATION WORKFLOW

作为数据探索者，我没有"凭感觉"，而是走了一遍标准流程：

先亮底牌：1 个月，我到底干了多少

效率侧佐证：平台侧统计本月累计调用 8 亿+ tokens，缓存命中率 93.9%。长上下文复用把单位成本压到极低——用得越狠，边际越便宜。

不是"聊天"，是"动手"

ACTION, NOT CHAT

把 3899 条事件按动作分类：本地命令/脚本执行 2134 次、文件创建修改删除 1434 次、联网检索 281 次。前两者合计 92%。

这说明一件事——我大部分时间不是"问 AI 一句话"，而是让 AI 真的去建文件、跑代码、改项目。它在我这儿是"能落地的执行体"，不是问答机。

1 个月，我实际调用了 8+ 类专家

>5 EXPERTS, CONFIRMED BY LOGS

日志里明确出现专家激活信号：wechat-official-account-expert、travel-solution-expert（14 次）、expert-manager；技能调用信号出现 1451 次。叠加工作区产物，至少覆盖了下面 8 类：

281 次联网检索里，近 7 成指向政府公开采招平台与行业技术官网，其余分布在公众号文章库、开源社区、企业技术博客。这说明专家模式下的 AI，干的是带溯源的研究活，而不只是编文案。

四个我最常叫的"专家同事"

FOUR FRONT-LINE EXPERTS

一张表看懂：专家模式 vs 裸用模式

THE GAP

关键洞察：专家不是"更会聊天的模型"，而是把某个领域的方法论、规范、工作流预置进了上下文。你省下的，是每次从零把专家"教出来"的那份心力。

为什么"请专家"比"练 prompt"更划算

WHY IT WORKS

我把人和 AI 的协作归纳成四种姿态——而专家，是把这四种姿态都"提效"的杠杆：

无论哪种姿态，专家都让你少说废话、少走弯路。

大实话：取代你的不是 AI，是"用 AI 的人"。而当这个人还懂得把专家叫上场，差距就不是一倍两倍，而是结构性的一——同样地儿，有人还在调 prompt，有人已经把 1 个月用出了别人 3 个月的产出密度。

我的产出密度，大约是纯手工时代的 5–10 倍；单位成本又因为缓存在持续下降。这不是我多努力，是我踩在了专家这根杠杆上。