
# 打造你的专家团队
果办OfficeAce的专家是技能的组合，将特定岗位或业务流程的方法论封装为可复用的技能集合。当单一专家的能力边界不足以覆盖复杂任务时，就需要多个专家共同协作来完成任务的交付。
**专家团**通过角色分工、任务流转和质量门禁，将多个专家的能力组合为一条完整的工作流水线，从需求理解到方案产出，从交叉审查到交付确认，每个环节都有对应的专家负责，形成任务闭环。
#### 专家 vs 专家团
很多人对专家团的认知就是"多开几个对话框让AI互相聊天"。实际上，专家团是让不同的AI扮演不同的专业角色，组成分工明确的工作团队，共同处理复杂任务的不同环节。
| 维度  | 专家（单Agent）          | 专家团（多Agent）             |
|:---|:---|:---|
| 上下文 | 所有信息在一个任务中，上下文容易膨胀。 | 每个角色只接收必要上下文，上下文隔离、聚焦。  |
| 分工  | 一个角色串行完成所有环节。       | 多角色并行或接力完成不同环节，各司其职。    |
| 工具  | 同一组权限，无隔离。          | 可按角色隔离工具和权限（如审查者无修改权限）。 |
| 质量  | 自己生成、自己检查，无外部把关。    | 可设置独立评审者，产出 ≠ 审查。       |
| 成本  | 较低，单次模型调用。          | 较高，协调 + 多次模型和工具调用。      |
| 适用  | 单一领域、明确范围的任务。       | 跨领域、可拆解、需多视角验证的复杂任务。    |
   
#### 预置专家团 vs 自建专家团
果办OfficeAce内置了常用的几类专家团，开箱即用。当预置专家团无法覆盖任务需求时，可以自建专家团。
| 维度    | 预置专家团                  | 自建专家团                     |
|:---|:---|:---|
| 适用人群  | 入门用户、通用任务使用者、非技术用户。    | 进阶用户、特定行业从业者、技术用户。        |
| 可用专家团 | 限定于当前果办OfficeAce内置的团队。 | 按需创建任意专家组合。               |
| 上手门槛  | 低，@团队名即发起调用。           | 高，需定义角色、调试流程。             |
| 搭建速度  | 即时可用。                  | 取决于团队复杂度。                 |
| 能力边界  | 取决于预置团队的固有分工，无法深度定制。   | 可精确定义职责、输入输出契约、工具权限、文风偏好。 |
| 灵活性   | 低，只能选择"用或不用"，不能修改角色定义。 | 高，可随时调整职责、增删能力、迭代优化。      |
| 复用性   | 所有用户共享，无需维护。           | 仅创建者可用，需自行维护。             |
| 质量控制  | 依赖预置专家的既有能力水平，无法针对性调优。 | 可通过灵魂配置沉淀领域知识，持续提升专项产出质量。 |
   
#### 专家团设计三步法
可按如下三步来打造你的专家团。
#### 第一步：拆分时机------决定"什么时候该用专家团"
并不是所有任务都适合使用专家团。因此，专家团设计的第一步，就是判断任务是否需要使用专家团。
适合使用专家团的任务特征如下表所示，当命中3个及以上任务特征时，建议使用专家团。
| 任务特征       | 判断标准                               | 专家团 or 专家 |
|:---|:---|:---|
| 可拆解性       | 能写出"先做A，再做B，最后合并C"的步骤拆分。           | 专家团       |
| 多领域交叉      | 同时涉及文案+设计、或技术+市场、或法律+财务等多领域。       | 专家团       |
| 质量要求高      | "发出去就收不回来""客户会逐条核对"。               | 专家团       |
| 需多视角验证     | 涉及决策建议、风险评估等场景。                    | 专家团       |
| 有并行空间      | 拆解的子任务可以同时执行，如多个方向可同时调研、多个模块可同时开发。 | 专家团       |
| 需迭代改进      | 需要2-3轮修改才能定稿。                      | 专家团       |
| 任务有规模      | 预估单专家完成需2小时以上，或涉及3个及以上的交付件。        | 专家团       |
| 单一领域       | 单专家可覆盖。                            | 专家        |
| 纯信息转发或简单问答 | 无判断需求，无需多角色。                       | 专家        |
   
需要专家团还是专家的**典型场景举例**：
| 场景        | 命中特征                                | 建议  |
|:---|:---|:---|
| 写一封日常邮件   | 无                                   | 专家  |
| 生成一份汇报材料  | 可拆解性                                | 专家  |
| 代码审查      | 质量要求高、需多视角验证                        | 专家  |
| 产品宣传彩页设计  | 可拆解性、多领域交叉、质量要求高、有并行空间、需迭代改进        | 专家团 |
| 全行业竞品分析报告 | 可拆解性、多领域交叉、质量要求高、需多视角验证、有并行空间、任务有规模 | 专家团 |
| 季度经营复盘报告  | 可拆解性、多领域交叉、质量要求高、有并行空间、需迭代改进、任务有规模  | 专家团 |
| 从0到1的产品方案 | 可拆解性、多领域交叉、质量要求高、需多视角验证、需迭代改进、任务有规模 | 专家团 |
   
#### 第二步：角色定义------决定"谁做什么"
在明确需要专家团后，接下来就是为专家团"招募"成员。专家团中每个专家必须具备唯一标识、明确职责及输入输出契约，避免因功能重叠导致指令冲突。
专家团成员主要可划分如下三类角色：
| 角色  | 职责定义                    | 输入         | 输出            |
|:---|:---|:---|:---|
| 统筹者 | 拆解任务、分配角色、把控进度、输出最终交付件。 | 用户原始需求     | 任务清单 + 验收标准   |
| 执行者 | 按方法论输出交付件。              | 任务清单 + 上下文 | 交付件（文档/代码/方案） |
| 审查者 | 把关交付件质量，放行或打回。          | 交付件 + 验收标准 | 审查意见（通过/打回）   |
   
专家准入的**关键原则：**
- 每个专家只负责一个具体、单一的任务，能力聚焦在一个点上。
- 产出与审查不由同一专家完成，这是质量闭环的基本前提。
- 一个专家可兼任多个角色，但同一任务中不能既产出又审查。
 
#### 第三步：产物串联------决定"上下游如何交接"
专家之间的任务交接不是"做完了你接上"，而是携带完整上下文的结构化传递。
**交接协议模板：**
```
【任务交接】
- 任务目标：<本环节要达成什么目标>
- 已完成部分：<上一步产出了什么>
- 未完成部分：<还剩什么没做>
- 已知风险：<需要注意的风险和问题>
- 建议下一步：<推荐接手者做什么>
- 交付件路径：<文件/链接>
```
根据任务的拆解情况，不同环节之间有如下串联方式。
| 串联方式 | 特点                           | 适用场景         |
|:---|:---|:---|
| 串行接力 | A完成 \> 交给B \> B完成 \> 交给C     | 有严格先后依赖的流水线。 |
| 并行汇总 | A/B/C同时开始 \> 统筹者合并           | 无依赖的独立子任务。   |
| 条件分支 | A完成 \> 根据结果决定交给B还是交给C        | 有需要判断的决策点。   |
| 审查回环 | A产出 \> B审 \> 通过（下行）/不通过（返回A） | 有需要质量把关的环节。  |
   
#### 实战案例：产品宣传彩页专家团
公司需要为某个展会设计制作一份果办OfficeAce的宣传彩页，涉及卖点提炼、营销文案、版面规划、视觉元素选取、品牌规范审查等多个环节，单一专家无法覆盖全部专业能力，因此需要专家团。
#### 组建团队
产品宣传彩页专家团的团队组成如下：
| 角色                                                     | 分工                | 输入             | 输出                     |
|:---|:---|:---|:---|
| 统筹者（组长） @coordinator | 负责拆解任务、分配角色、合并交付。 | 用户需求           | 任务拆解、验收标准、彩页设计方案、最终交付件 |
| 文案专家 @writer         | 负责提炼卖点、撰写文案。      | 子任务、产品白皮书、官方文档 | 彩页文案方案                 |
| 设计专家 @designer     | 负责版面规划和设计、合成彩页。   | 子任务、品牌规范       | 版面设计方案、彩页成品图           |
| 审查专家 @reviewer      | 负责设计方案质量审查。       | 彩页设计方案、验收标准    | 审查意见                   |
   
#### 执行流程
**阶段一：需求拆解（统筹者）**
```
用户需求：制作一份A4三折页产品宣传彩页，推广果办OfficeAce智能办公产品。
统筹者@coordinator把需求拆解为：
- 子任务1：提炼核心卖点 + 撰写各版面营销文案 → @writer
- 子任务2：规划三折页版面布局 + 选取视觉元素 → @designer（与子任务1并行）
- 验收标准：6个版面内容完整、文案与版面对应、符合品牌规范、CTA（Call To Action，行动号召）明确
```
**阶段二：并行执行（文案专家 + 设计专家）**
```
文案专家@writer收到子任务1：为果办OfficeAce提炼5大核心卖点，按三折页6个版面撰写营销文案，含主标题/副标题/正文/CTA。
- 输入：产品白皮书、官方文档。
- 产出：彩页文案方案v1（含每个版面的文案内容 + 卖点优先级排序 + 各卖点的信息来源标注）。
设计专家@designer收到子任务2：规划A4三折页版面布局（6面），选取配图风格、配色方案、视觉层次。
- 输入：品牌规范。
- 产出：版面设计方案v1（含各版面尺寸、图文比例、配色规范、视觉元素清单）。
```
**阶段三：用户确认（用户）**
```
统筹者@coordinator将文案方案v1和版面设计方案v1提交用户确认：
1.确认项1：产品定位与核心卖点。
  向用户展示提炼的5大核心卖点及其信息来源、产品定位描述。
  - 用户确认卖点是否准确、定位是否恰当。
  - 若有异议：用户标注修改意见 → @writer根据反馈调整 → 重新提交确认。
  - 确认通过：进入下一确认项。
2.确认项2：版面风格与配色方案。
  向用户展示版面布局方案、配图风格、配色方案。
  - 用户确认版面风格和配色是否符合品牌调性和预期。
  - 若有异议：用户标注修改意见 → @designer根据反馈调整 → 重新提交确认。
  - 确认通过：文案方案v1和版面设计方案v1定稿，进入产物串联 。
```
**阶段四：产物串联（统筹者）**
```
@coordinator将经用户确认的文案方案与版面设计方案合并为统一的彩页设计方案：
- 检查文案字数是否适配版面容量、卖点排序与视觉重点是否一致。
- 发现封面文案过长，超出版面预留空间 → 退回@writer精简封面文案。
- @writer提交文案方案v2 → @coordinator重新合并。
- 产出：彩页设计方案v1（文案与版面设计合并后的统一方案，含各版面文案+布局+配色+视觉元素）。
```
**阶段五：质量审查（审查专家）**
```
审查专家@reviewer收到审查彩页设计方案v1（文案与版面设计合并版）和验收标准（品牌规范、文案版面匹配、CTA明确）。
@reviewer审查意见：
√ 品牌一致性：配色/字体/Logo使用符合品牌规范。
√ 文案版面匹配：各版面文案字数均在容量范围内。
√ CTA明确：每个版面均有清晰行动引导。
！ 卖点排序：第3版面卖点“协同效率”与封面主卖点“AI自动化”关联度低，建议调整顺序 → 打回 @coordinator调整后重新合并。
```
**阶段六：合成彩页成品图（设计专家）**
```
@coordinator根据审查意见修改并重新合并 → @reviewer复审通过。
- @designer将彩页设计方案合成为彩页成品图。
- 产出：产品宣传彩页成品图（A4三折页，6个版面完整设计稿，含文案/配图/配色/Logo/CTA）。
```
**阶段七：最终交付（统筹者）**
```
@coordinator汇总最终交付件：
- 产品宣传彩页成品图（A4三折页，6个版面完整设计稿，含文案/配图/配色/Logo/CTA）。
- 彩页设计源文件（可编辑的设计源文件，便于后续修改迭代）。
```
#### 常见问题与解决方案
专家团用得好是利器，用不好反而比单专家效率更低。以下是自建专家团过程中最容易出现的几个问题，建议在专家团组建和设计过程中对照排查。
| 常见问题  | 典型症状                   | 解决方案                       |
|:---|:---|:---|
| 职责重叠  | 两个专家做了同一件事，结果冲突。       | 每个专家职责唯一，输入输出契约明确。         |
| 过度拆分  | 简单任务拆成5个专家，导致协调成本大于收益。 | 从2-3个专家起步，验证后再扩展。          |
| 上下文丢失 | 交接时只说"做完了"，接手者不了解任务背景。 | 使用结构化交接协议模板。               |
| 审查疲劳  | 同一个审查者检查所有产出，导致后期质量下降。 | 审查轮换：A产B审 \> B产C审 \> C产A审。 |
| 阻塞卡断  | 某专家卡住，导致整个任务流程停滞。      | 10分钟原则：阻塞超10分钟即升级统筹者处理。    |
| 无验收标准 | 审查者不知道"怎么算通过"。         | 统筹者在分派时必须附带验收标准。           |
| 并行失控  | 同时启动太多专家，导致结果混乱。       | 从2-3个并行开始，验证协调机制后扩展。       |
   
