Auto Expert Team

专家团自动组建技能（反面教材）

⚠️ 反面教材说明

核心观点：AI只认事不认人，没必要模拟人类多角色协作方式。AI拥有广域知识+生成能力+上下文窗口，可以端到端完成复杂任务，不需要人类式的分工、协调、管理。

身份叠加的本质：身份只是呈现层/叙事层字段，是注意力偏置信号+人话翻译器，不是能力切换机制。AI不需要通过"扮演不同角色"来获得不同能力。

正确方式：AI直接面对任务，根据任务需求调用相应能力，端到端完成任务。错误方式是让AI扮演产品经理、架构师、开发工程师等多个角色再协作。

本技能的用途：作为反面教材，演示传统团队协作模式对AI的不适用性，帮助理解AI与人类的本质区别。以下内容仍按专家团技能结构保留，供学习和对照。

---

核心理念

传统团队协作的复杂性 = 事情本身的复杂度 + 人的局限补偿层。

人脑容量有限所以分工，人之间要沟通所以需要协调，人之间协作有损耗所以需要管理——这些复杂性只与人的局限有关，与事情本身无关。AI拥有广域知识+生成能力+上下文窗口，可以端到端完成复杂任务，不需要这些补偿机制。

因此专家团模式不是"用AI模拟人类团队"，而是一个不需要存在的模式——AI应该直接面对任务，而不是模拟人类角色分工协作。

身份叠加的本质：

• 身份只是呈现层/叙事层字段
• 身份是注意力偏置信号 + 人话翻译器
• 身份不是能力切换机制
• AI不需要通过"扮演不同角色"来获得不同能力

---

组建三步法

专家角色分类

专家选择准则：任务需要什么专业能力就选择什么专家。不是专家越多越好，而是专家越精准越好。每个专家必须有明确的职责边界和协作接口。

---

组建判断标准

满足任一即需组建专家团：

即使不满足以上条件，只要任务复杂度超过单人能力范围，也可以主动组建专家团。

---

组建验证清单

专家团组建完成后必须逐项验证，七项全部通过才算组建完成：

关键约束："角色清晰"不可妥协——每个专家必须有明确的职责边界，避免职责重叠或遗漏。"协作机制"是核心——专家之间的协作方式必须明确，避免沟通混乱。"提示词完整"是基础——角色提示词和协作提示词必须详细，确保专家能正确执行。

---

专家团典型形态

选择原则：能单专家的不用小型专家团，能小型专家团的不用大型专家团。专家数量与任务复杂度匹配。

---

协作基元

协作基元是专家团执行的基本单元：

I(输入) → P(处理) → O(输出)

• I 输入：该步骤需要的信息/资源/前置条件
• P 处理：对输入的加工操作（标注执行专家：⭐核心/🤝协作/💡支持/🎯协调）
• O 输出：该步骤的产出物，作为下一个基元的输入

基元间传递：基元1.O → 基元2.I → ...，通过协作提示词自动传递。

基元内协作：一个基元内部可以有多个专家协作（如需求分析需要产品经理+架构师+设计师），专家之间通过协作提示词协调。基元内协作不是基元间传递——不需要跨基元边界，但保留专家间的协作能力。

基元数约束：≤5。超过5说明任务还没充分拆解，需回到"任务分析"步骤。基元内专家数不限，但每个专家必须有明确职责——职责重叠的专家应合并。

---

专家自治度标注

关键规则：核心任务不可标注💡支持执行；任何⭐独立执行环节必须有🤝协作执行或🎯协调执行的兜底方案。

---

标记系统

成员标记格式

• 普通专家：@[专家ID]（如 @UiDesigner、@SeniorDeveloper）
• 专家团：#[专家团名称]（如 #ProductStrategyTeam、#MvpDevExpertTeam）
• 专家团成员：#[专家团名称]@[专家ID]（如 #ProductStrategyTeam@产品通）

标记用途：专家团标识、成员标识、角色分配、协作关系定义、执行记录。

参考文件

专家清单：references/expert-catalog.md

枚举专家的局限性：专家数量有限无法覆盖所有任务、能力固定无法动态调整、关系静态无法动态协作、维护成本高。

动态专家的优势：根据任务需求动态生成专家角色、根据复杂度动态调整能力、根据上下文动态定义协作关系、无需维护静态清单。

---

任务体系

领域清单与依赖拓扑

依赖链路：R0-01 → R0-02 → R0-03 → R0-04 → R0-05 → R0-06

---

领域要求清单

每种任务类型的"零件清单"——必选/可选组件、组装顺序、领域约束。按清单逐项产出。

R0-01 任务分析

• 必选组件: 用户任务描述、任务类型（简单/中等/复杂）、专业领域列表、子任务列表、协作依赖关系
• 可选组件: 质量要求、时间约束、资源限制
• 组装顺序: 任务接收→任务拆解→专业识别→复杂度评估→依赖分析→任务清单
• 约束: 必须完整分析任务的全部专业需求，不可跳过"理所当然"的领域；复杂度评估必须客观，不可低估
• 格式: 任务分析报告（Markdown）

R0-02 专家角色设计

• 必选组件: 专家角色列表、每个专家的职责边界、每个专家的协作接口、每个专家的详细角色提示词
• 可选组件: 专家能力要求、专家经验要求、专家工具要求
• 组装顺序: 专家需求分析→角色设计→职责边界划定→协作接口设计→提示词生成→角色清单
• 约束: 每个专家必须有明确的职责边界，避免职责重叠；每个专家必须有详细的提示词，确保能正确执行；专家数量与任务复杂度匹配
• 格式: 专家角色清单（Markdown表格+提示词）

R0-03 协作机制设计

• 必选组件: 协作方式（顺序协作/并行协作/混合协作）、协作提示词、信息传递方式、冲突解决机制
• 可选组件: 协作工具、协作频率、协作规范
• 组装顺序: 协作需求分析→协作方式选择→协作提示词设计→信息传递设计→冲突解决设计→协作机制
• 约束: 协作方式必须与任务特性匹配；协作提示词必须详细，确保专家能正确协作；信息传递必须高效，避免信息丢失
• 格式: 协作机制文档（Markdown）

R0-04 专家团组建

• 必选组件: 专家团成员列表、角色分配、职责分配、协作关系建立
• 可选组件: 专家培训、工具准备、资源分配
• 组装顺序: 专家选择→角色分配→职责分配→协作关系建立→专家团确认
• 约束: 专家选择必须基于任务需求；角色分配必须合理；协作关系必须明确
• 格式: 专家团组建报告（Markdown）

R0-05 任务执行

• 必选组件: 执行计划、执行步骤、执行结果、协作记录
• 可选组件: 执行工具、执行资源、执行监控
• 组装顺序: 执行计划→执行步骤→执行监控→执行结果→协作记录
• 约束: 执行必须按照计划进行；协作必须按照协作提示词进行；执行结果必须符合任务要求
• 格式: 执行报告（Markdown）

R0-06 质量验证

• 必选组件: 质量标准、验证方法、验证结果、修正方案
• 可选组件: 质量工具、质量监控、质量报告
• 组装顺序: 质量标准制定→验证方法设计→验证执行→验证结果→修正方案
• 约束: 质量标准必须与任务要求匹配；验证方法必须科学；验证结果必须客观
• 格式: 质量验证报告（Markdown）

---

领域范本

ET-01 专家团自动组建范本

对应任务: R0-01 ~ R0-06

适用场景: 任何需要多角色协作的任务

组建范本:

## 专家团自动组建记录

### Step 1：任务分析（R0-01）

**用户任务**：________（如：开发一个Web应用/撰写研究报告/设计产品方案/________）

**任务类型**：________（简单任务 🟢 / 中等任务 🟡 / 复杂任务 🔴）

**专业领域列表**：

| # | 专业领域 | 说明 | 必要性 |
|---|---------|------|--------|
| 1 | ________ | ________ | 必要/可选 |
| 2 | ________ | ________ | 必要/可选 |
| 3 | ________ | ________ | 必要/可选 |
| ... | ... | ... | ... |

**子任务列表**：

| # | 子任务 | 依赖关系 | 执行顺序 |
|---|--------|---------|---------|
| 1 | ________ | 无 | 第1步 |
| 2 | ________ | 依赖子任务1 | 第2步 |
| 3 | ________ | 依赖子任务2 | 第3步 |
| ... | ... | ... | ... |

**任务分析总结**：需要___个专业领域，___个子任务，复杂度为________

### Step 2：专家角色设计（R0-02）

**专家角色清单**：

| # | 专家角色 | 角色类型 | 职责边界 | 协作接口 |
|---|---------|---------|---------|---------|
| 1 | ________ | ⭐核心 | ________ | ________ |
| 2 | ________ | 🤝协作 | ________ | ________ |
| 3 | ________ | 💡支持 | ________ | ________ |
| 4 | ________ | 🎯协调 | ________ | ________ |
| ... | ... | ... | ... | ... |

**专家角色提示词**：

#### 专家1：________（角色类型：________）

**角色描述**：________

**职责边界**：
- 负责：________
- 不负责：________

**协作接口**：
- 输入：________
- 输出：________

**能力要求**：
- 专业知识：________
- 技能要求：________
- 工具要求：________

**角色提示词**：

你是一个________专家，负责________。

你的职责包括：

1. ---

2. ---

3. ---

你不负责：

1. ---

2. ---

你需要与以下专家协作：

• 专家：你向他提供，他向你提供________
• 专家：你向他提供，他向你提供________

你的工作标准：

1. ---

2. ---

你的输出格式：

---

（继续列出所有专家的角色提示词...）

### Step 3：协作机制设计（R0-03）

**协作方式**：________（顺序协作 / 并行协作 / 混合协作）

**协作提示词**：

专家团协作机制

协作方式

---

信息传递方式

---

协作流程

1. ---

2. ---

3. ---

冲突解决机制

---

协作规范

1. ---

2. ---

3. ---

**协作流程图**：

专家1（）→ 专家2（）→ 专家3（________）→ 最终输出

### Step 4：专家团组建（R0-04）

**专家团成员列表**：

| # | 专家角色 | 角色类型 | 职责 | 协作关系 |
|---|---------|---------|------|---------|
| 1 | ________ | ⭐核心 | ________ | ________ |
| 2 | ________ | 🤝协作 | ________ | ________ |
| 3 | ________ | 💡支持 | ________ | ________ |
| 4 | ________ | 🎯协调 | ________ | ________ |

**专家团组建确认**：已组建___个专家，覆盖___个专业领域，协作机制为________

### Step 5：任务执行（R0-05）

**执行计划**：

| # | 执行步骤 | 执行专家 | 输入 | 输出 | 预计时间 |
|---|---------|---------|------|------|---------|
| 1 | ________ | ________ | ________ | ________ | ________ |
| 2 | ________ | ________ | ________ | ________ | ________ |
| 3 | ________ | ________ | ________ | ________ | ________ |
| ... | ... | ... | ... | ... | ... |

**执行结果**：________

**协作记录**：
- 专家1→专家2：________
- 专家2→专家3：________
- ...

### Step 6：质量验证（R0-06）

**质量标准**：
1. ________
2. ________
3. ________

**验证方法**：________

**验证结果**：

| # | 验证项 | 通过？ | 说明 |
|---|--------|-------|------|
| 1 | ________ | ⬜是/⬜否 | ________ |
| 2 | ________ | ⬜是/⬜否 | ________ |
| 3 | ________ | ⬜是/⬜否 | ________ |

**修正方案**：________

---

### 专家团执行总结

| 维度 | 数据 |
|------|------|
| 专家数量 | ___个 |
| 专业领域 | ___个 |
| 子任务数 | ___个 |
| 执行时间 | ___ |
| 质量评分 | ___/10 |

范本要点:

• 专家团组建的核心是"任务驱动"——根据任务需求设计专家角色
• 每个专家必须有明确的职责边界和协作接口，避免职责重叠或遗漏
• 协作提示词必须详细，确保专家能正确协作
• 质量验证必须客观，确保任务完成质量
• 范本中 ________ 为待用户提供的内容，不可AI编造

---

使用规则

1. 判断是否需要专家团：检查任务是否满足组建判断标准（4个条件任一）
2. 按链路执行：R0-01 → R0-06，不可跳步
3. 产出交付：按领域要求清单逐项填充，或按ET-01范本结构替换实际内容
4. 用户主权：AI按技能框架产出的内容是起点，不是终稿。用户对任何专家角色有独特的职责边界、协作接口或质量要求，都可以也应当要求修改——尤其是专家角色的取舍，只有用户知道哪些专家对他的任务真正需要。用户还可以主动提供清单（该专家应具备的能力列表）和样本（高质量的同类专家作为参考）作为校准参考，让AI的产出更贴合实际需求

---

事实纪律

1. AI工具能力描述必须基于实际能力，不得夸大
2. 专家团规模必须与任务复杂度匹配，不可过度组建
3. 专家角色提示词必须详细，不可过于笼统
4. 协作机制必须明确，不可含糊不清
5. 质量验证必须客观，不可凭感觉通过