小白也能用好「专家」：WorkBuddy 调用专家的完整指南（从认识到实战）

小白也能用好「专家」：WorkBuddy 调用专家的完整指南（从认识到实战）

正在上传图片...

摘要：同样的 AI、同样的问题，为什么别人问出来的是能直接上会的方案，你问出来的是一堆正确的废话？差别往往不在模型，而在于有没有给它一个"角色前提"。这篇文章从零讲清 WorkBuddy 的「专家」是什么、三种调用方式怎么选、怎么给专家下指令才能拿到靠谱产出，并配三个真实场景演练和一份避坑清单。看完你就能把专家用起来。

一、背景与痛点：问题不在 AI 不够强，在于它不知道"你是谁"

先说一个几乎所有人都遇到过的场景。

你打开 AI，输入一句自认为很清楚的需求：

帮我写一份客户汇报的方案框架

然后你得到了一份东西——结构完整、逻辑通顺、用词专业，四平八稳。但你读完就知道：这玩意儿没法用。

因为它没有行业术语的口径，不知道客户的关注点在哪，不清楚你们公司能承诺什么、不能承诺什么，也不了解这份材料最后是要给谁看、用来做什么决策。它给的是"通用最佳实践"，而你要的是"这一件事的具体解法"。

这类失败通常表现为三种症状：

第一种，答非所问型。 内容都对，但和你的场景没关系。你是重客售前，它给你的是互联网产品经理的方法论；你要的是给 CIO 看的技术架构建议，它写的是给开发者看的入门教程。

第二种，深度不够型。 停留在概念科普层面，讲了一堆"要注重用户体验""要做好风险管控"，但没说清楚在你这个具体情境下，体验该从哪个指标看、风险该怎么排优先级。

第三种，落地不了型。 格式、口径、术语都不符合行业习惯。你拿去给同事看，同事第一句话是"这个我们内部不叫这个名字"。

这三种症状的根因是同一个：通用对话缺少"角色前提"。

同一个问题——"这个方案的风险在哪"——一个做了十年集成交付的架构师、一个管过预算的财务总监、一个天天跑客户的销售，给出的答案应该完全不同。不是因为谁更聪明，而是因为他们的判断标准不一样。

你没告诉 AI 该用谁的标准，它就只能用一个"平均人"的标准来回答你。而"平均人"的答案，恰恰是谁都觉得对、谁都不会真正采纳的那种。

WorkBuddy 里的「专家（Expert）」，就是用来补这块缺口的。

二、先搞清楚：专家到底是什么

很多人第一次听到"专家"，会下意识理解成"一个更聪明的模型"或者"一段写好的提示词"。这两个理解都不准确。要真正用对，得先建立三层认知。

通用对话、提示词模板与专家的三层能力递进

第一层：通用对话——什么都会一点，什么都不精

这是默认状态。你问什么它答什么，没有固定立场，没有稳定标准。优点是灵活，缺点是每次输出的质量方差很大，完全取决于你那一句提示词写得够不够好。

绝大多数人的 AI 使用体验停在这一层，所以才会觉得"AI 时灵时不灵"。

第二层：提示词模板——有了固定套路，但还是你在指挥

进了一步。你把常用的提示词存下来，每次调用。输出稳定了一些，但本质还是"你告诉它每一步怎么做"。

问题在于：你写不出你不知道的东西。一个不懂财务的人，写不出"用财务视角审查这份预算"的合格提示词。模板能固化你的现有水平，但不能突破它。

第三层：专家——自带身份、方法论、知识和工具

这是关键的一跃。专家不只是一段话，它是一个打包好的角色，通常包含四样东西：

1. 角色定义：他是谁，什么资历，站在什么立场上说话。
2. 方法论：他遇到这类问题，会按什么路径拆解、按什么顺序思考。
3. 领域知识：这个行业的术语、规则、惯例，以及最常见的坑在哪。
4. 配套工具：他能动用哪些能力——脚本、数据源、外部系统。

第三层和第二层的本质区别是：第二层是你在指挥一个没有立场的执行者；第三层是你请了一个有立场的人在替你判断。

专家 ≠ 提示词，也 ≠ Skill

这两个混淆很常见，必须拆开。

一句话区分：Skill 是"做事的流程"，专家是"做事的人"。

它们不冲突，反而应该叠加用。一个理想的复杂任务，是"某个专家的视角 + 某个 Skill 的流程 + 某些真实数据"。这个组合在第四节会展开讲。

三、三种调用方式，各有各的适用场景

知道了专家是什么，下一步是怎么把它调出来。WorkBuddy 里调用专家有三条路，很多人只知道第一条。

调用专家的三种方式：专家中心入口、需求触发推荐、自动化绑定

方式一：从左侧「专家」入口进入（最适合第一次用）

这是最直观的路径：

1. 点击左侧边栏的「专家」选项，进入专家中心；
2. 按分类浏览——平台上有一百多个领域专家，按职能、行业、场景分好类；
3. 点开感兴趣的专家卡片，看它的介绍：擅长什么、用什么方法、适合什么任务；
4. 确认后直接开始对话。

给新手的一个实用建议：按"任务类型"找，不要按"行业"找。

原因是，你一开始往往说不清自己需要哪个行业的专家，但你能说清自己要干什么——"我要改一份材料""我要评审一个方案""我要算一笔账"。从任务出发去找人，比从行业出发准确得多。

看专家介绍时，重点看两个数：它的产出物是什么、它需要你提供什么。如果一个专家描述里写的产出物正好是你要的东西，那基本就对了。

方式二：对话中表达需求，让系统帮你推荐

如果你不确定该用哪个专家，还有一条更省事的路：直接把你的任务说清楚，让系统去匹配。

系统内置了「推荐专家」的机制。当当前会话没有激活专家，或者任务明显需要专业判断时，它会自动分析你的需求，去搜索合适的专家候选并推荐给你，你确认后即可启用。

比如你可以直接说：

我手上有一份 30 页的客户交流材料，需要改成能直接上会的版本，客户是制造业，关注产线稳定性。帮我找个合适的专家来过一遍。

这条路的优点是零门槛，你不需要预先知道有哪些专家；缺点是推荐结果取决于你把需求描述得多清楚——需求说得越具体，匹配越准。

方式三：在自动化任务里绑定专家（最容易被忽略，但最省时间）

前两种都是"你主动去找专家"。第三种反过来：让任务执行时自动站在某个专家的视角上。

WorkBuddy 的自动化（定时任务 / 一次性任务）支持在创建时指定一个 expertId。指定之后，每次任务触发执行时，都会在对应专家的视角下完成，不需要你每次手动切换。

# 创建自动化任务时指定专家（示意，字段以实际配置界面为准）
# expertId: "<目标专家的 ID 或名称>"
# 效果：该任务每次自动执行时，都会在指定专家视角下运行

这条路适合什么样的任务？ 三个特征：周期性重复、口径固定、需要专业判断。

典型例子：每周一早上自动汇总上周工作产出周报。这类任务如果每次都用通用视角跑，出来的往往是流水账；绑定一个有销售或管理视角的专家后，它会自动判断"哪些事值得写、怎么写才体现推进"，产出质量差一个档次。

一个实操提醒：专家 ID 支持填名称或 ID，系统会自动解析。如果你不确定填什么，先去专家中心找到该专家，复制它的标识即可。

四、专家怎么和 Skill、连接器配合

这是从"会用"到"用得好"的分水岭。单独用专家，你只发挥了一半价值。

专家、Skill 与连接器三者的分工协作

三者的分工

• 专家：定视角、定标准、定判断。回答"这个方案好不好、该不该这么写"。
• Skill（技能）：定流程、定脚本、定交付格式。回答"这事分几步走、每步做什么、最后交成什么样"。
• 连接器 / MCP：拿外部真实数据。回答"依据是什么、数据从哪来"。

少了任何一环，产出都会缺一块：

• 只有 Skill 没有专家 → 流程跑得很顺，但产出的判断质量不稳定，时好时坏；
• 只有专家没有 Skill → 每次都靠临场发挥，这次改得好下次不一定；
• 两者都有但没有连接器 → 全靠你手工贴数据，专家再强也是"无米之炊"。

一个具体例子：每周工作周报

这是我自己跑通的一条链路，可以完整说明三者怎么配合：

1. 连接器取数：从 CRM 系统里读取本周的日报/跟进记录——这是真实数据，不是我凭记忆写的；
2. Skill 定格式：调用一个周报生成技能，它规定了固定的结构（本周进展 / 下周计划 / 需要支持）、固定的措辞规范；
3. 专家做判断：在有销售管理视角的专家视角下，从一堆原始记录里挑出真正有价值的事，把"参加了某会议"这类流水账转成"推动某客户完成某节点"这类体现推进的表述。

最终产出：格式统一（Skill 的功劳）、数据真实（连接器的功劳）、有判断有取舍（专家的功劳）。

这就是三者叠加的价值——任何单一能力都做不到这个效果。

五、五步实操：第一次调用专家的完整流程

理论讲完，进入实操。下面这五步是我反复验证过的最短路径，第一次用建议严格照做。

调用专家的五步实操流程

步骤 1：选对专家——别一上来就选"最专业"的那个

新手最常见的错误，是选一个头衔最大、描述最华丽的专家。但头衔大不等于匹配。

选专家的判断标准只有一条：看它的产出物是不是你要的东西。

具体做法：打开专家介绍，直接找"你能得到什么""适合什么场景"这类描述。如果里面写的产出物和你的预期对得上，就选它；如果描述里全是"战略级""顶层设计"这类大词而没有具体交付物，跳过。

另外一个反直觉的建议：复杂任务可以先选" narrower "的那个专家。要改一份客户材料，选"内容打磨"类的比选"战略咨询"类的更合适。你需要的不是更宏大的视角，而是更贴近落地动作的判断。

步骤 2：激活并确认——让它先自报家门

进入专家对话后，不要马上抛需求。先花一句话确认身份生效：

请先说明你的角色定位、你处理这类问题的思路，以及完成这项任务你需要我先提供哪些信息？

这一步有两个作用：

第一，验证身份确实生效了。如果它回的是一团通用套话，说明专家没激活成功，你后面所有指令都会打折扣。

第二，让它进入状态。这就像开会前先给与会者讲清楚会议主题——它会自然地把后续对话纳入自己的方法论框架里，而不是被动等你一句句指挥。

顺带一个小技巧：它问你要信息时，那个"需要哪些信息"的清单本身就很有价值——那是专家视角下真正重要的输入项，往往和你以为的不一样。

步骤 3：给足背景——这一步决定产出质量的 80%

专家再强，没有输入也是空转。而且它和通用 AI 不同：通用 AI 会用常识把缺失的信息脑补掉，专家则会因为缺少关键输入而判断失准——它有一套方法论，但方法论需要数据才能运转。

我用一个固定框架来组织输入，叫 BRC：

• B（Background 背景）：我是谁、什么场景、这份东西最后给谁看、用来做什么决策。
• R（Requirement 要求）：要什么产出、什么格式、大概多大量、什么时间要。
• C（Constraint 约束）：不能出现什么、必须遵守什么、哪些数据不能确定。

对比一下效果差异。

模糊版（不推荐）：

帮我把这份客户材料改得好一点。

BRC 版（推荐）：

我是售前顾问（B），需要把一份 20 页的客户交流材料改成能直接上会汇报的版本（R），客户是制造业、核心关注产线稳定性。约束有三条：不要出现我们内部的项目代号；不要承诺任何具体交付时间；所有未经核实的数据必须标注"待确认"（C）。

同样的专家、同样的材料，后者的产出质量和前者不在一个层级。

关于约束（C）的一条重要提醒：约束里一定要写"不能出现什么"，而不只是"要什么"。 因为"要什么"它默认能理解，但"不能要什么"是你的组织特有的红线，它猜不到。常见该写的红线：内部代号、具体金额、未公开的客户名称、对交付时间的承诺。

步骤 4：审产出——重点看"判断"，不要只看"文字"

专家的价值不在文笔。文字润色是通用能力，判断取舍才是专家能力。

拿到产出后，按这三个问题检查：

1. 它有没有删掉不该要的内容？ 这是最容易被忽略、也最能体现专业度的一点。加内容容易，敢删内容难。如果它只是把你的东西改写了一遍、一点没删，说明它没真正用专家视角审。
2. 它有没有给出你没想到的角度？ 如果产出完全在你预期之内，那专家没起作用，你只是拿到了一份"更通顺的原稿"。
3. 术语口径对不对？ 这是硬指标。行业术语用错，整份材料的可信度就崩了。

如果第 2 条不满足，不要急着改稿，先回去补背景信息——大概率是你给的输入不够，它被逼着用常识在填空。

步骤 5：迭代——把你的反馈固化成长期要求

最后一轮改得满意时，做一件很多人不做的事：把你这轮的反馈提炼成通用要求，告诉它以后照此执行。

以后我给你的这类材料，都按这个标准处理：先给结论再给依据；每页只讲一件事；数据不确定一律标注"待确认"；涉及客户名称一律用"某客户"代替。

这句话的价值在于，它把一次性的修改变成了可复用的标准。后续同类任务不用再重复纠正。

如果这套标准会长期反复用，更进一步的做法是把它固化成一个 Skill，或者直接沉淀成一个你自己的专家——这就进入进阶玩法了。

六、三个典型场景演练

场景一：客户汇报材料打磨

适用专家类型：内容/方案打磨类、行业顾问类

关键动作：

1. 完整贴入原稿（不要只贴摘要，专家需要看到冗余才知道该删什么）；
2. 明确"上会"这个场景——上会材料和工作底稿的标准完全不同；
3. 在约束里写清脱敏要求（客户名、金额、内部代号）；
4. 审产出的重点：页数有没有减少、结论有没有前置。

常见翻车点：只说"优化一下"，没说"优化成什么样算好"。专家不知道你的验收标准，只能按通用标准改，结果往往不符合预期。

场景二：技术方案评审（用批判视角）

适用专家类型：架构/交付/安全类

关键动作：

1. 明确要求它"找问题"而不是"夸方案"——这一点必须写在指令里；
2. 给它评审维度：可行性、成本、风险、可维护性，让它按维度逐项过；
3. 要求它区分"致命问题"和"优化建议"，不要混在一起。

请以评审专家的视角审查这份方案。要求：只找问题，不用肯定。按可行性、成本、实施风险、后期维护四个维度逐项过，每个维度下明确区分「必须解决的」和「可以优化的」两类，并说明判断依据。

常见翻车点：AI 默认有讨好倾向，不特别强调就容易先夸一通再轻描淡写提两点。必须在指令里直接堵死这条路。

场景三：周期性产出（自动化 + 专家）

适用专家类型：取决于产出物——周报用管理视角，竞品分析用行业视角

关键动作：

1. 创建自动化任务时绑定专家 ID；
2. 把口径要求（格式、措辞、红线）写进任务描述里，因为它每次都是独立执行，不会记得你上次说的；
3. 前三次跑完人工复核一遍，把发现的问题回填到任务描述里。

常见翻车点：以为绑定了专家就一劳永逸。自动化任务每次执行都是全新上下文，所有要求必须写在任务描述里，不能依赖"它上次应该记住了"。

七、进阶玩法

1. 同一个问题，问两个专家

重要决策值得付出这个成本。让两个立场不同的专家看同一件事，差异点往往就是真正的风险点。

比如一份方案，分别请"技术实现视角"和"商务交付视角"过一遍。前者关注能不能做出来，后者关注做出来能不能交付、成本是否可控。两者意见一致的地方大概率安全，冲突的地方就是你需要重点决策的地方。

2. 不知道该用谁时，让系统推荐

前面提过，直接把需求说清楚，系统的推荐机制会帮你匹配候选。使用时有两个提效技巧：

• 把产出物说具体：不说"帮我看看这个方案"，说"帮我判断这个方案在交付成本上有没有坑"；
• 把约束说清楚：越具体，匹配越准。

3. 把自己的方法论固化成专家

当你发现自己在某个领域反复使用同一套判断标准时，就可以考虑把它固化下来了。

WorkBuddy 提供了专家包的管理能力（expert-manager），支持从开源仓库或本地项目创建专家包、修改已有专家、做合规检查和质量审查。简单说，你可以把自己十年积累的方法论、术语习惯、判断红线，打包成一个"数字化的你"。

这一步的意义不只是省时间——固化方法论的过程本身，会逼着你把那些"只可意会"的经验显性化。很多人做完这一步才发现，自己原来的判断标准里有不少自相矛盾的地方。

八、质检清单

每次调用专家产出重要材料前，过一遍这份清单：

• 专家已激活（让它自报家门确认过，不是通用回复）
• 需求描述里包含背景（我是谁、给谁看、用于什么决策）
• 需求描述里包含产出要求（什么格式、多大量）
• 需求描述里包含约束红线（不能出现什么、不能承诺什么）
• 原始材料完整提供（不是只给摘要）
• 涉及客户/金额/内部代号的信息已脱敏
• 产出中未核实的数据已标注"待确认"
• 已检查"它删掉了什么"，而不只是"它写了什么"
• 术语口径符合行业习惯
• 有至少一处判断是你自己没想到的（否则专家没起作用）
• 关键决策前已交叉验证（重要材料至少两个视角或人工复核）

九、踩坑与对策

十、小结

回到开头那个问题：为什么别人问出来的是能上会的方案，你问出来的是正确的废话？

答案不是"别人的 AI 更强"，而是别人给 AI 补上了你没给的东西——一个明确的角色、一套稳定的判断标准、一份真实的背景输入。

专家机制的本质，是把"谁来回答这个问题"这个前提，从你的提示词里抽出来，变成可复用、可沉淀的资产。你不需要每次都从头教 AI 该怎么思考，你只需要选对那个人，然后把事说清楚。

给新手的三条行动建议：

1. 今天就试一次：找一件你本周要做的真实任务，从左侧「专家」入口选一个产出物匹配的专家，按 BRC 框架写一句需求。体验一次差异，比读十篇文章有用。
2. 把约束写进去：如果你只想改一个习惯，就改这个——每次下指令时，多写一句"不能出现什么"。这是投入产出比最高的一句。
3. 跑通一次组合：挑一个周期性任务，把"专家 + Skill + 数据源"三者串起来。当你第一次看到它自己取数、按格式、带判断地产出东西时，你会理解什么叫"能力叠加"。

最后留一句提醒：专家是放大器，不是替代品。 它放大的是你给的输入的 quality——你给得越清楚，它产得越精准；你给得含糊，它也只能还你一份漂亮的空话。工具能解决的部分已经解决了，剩下的那部分判断，依然是你的价值所在。