# 5+1 元角色模型（价值驱动版）

## 术语定义（与 SPEM 2.0 对齐）

**方法元**（Method Element）：所有方法论元素的统称。

| 术语 | SPEM 2.0 | 中文 | 定义 |
|------|----------|------|------|
| **Role** | Role | **角色** | 方法元的一种，定义执行者的职责、技能和责任 |
| **元角色** | Meta-Role | **元角色** | 抽象的、跨领域的角色认知模式（5+1）|
| **角色变体** | Role Specialization | **角色变体** | 元角色在特定领域的特化（如 Architect 是 DESIGNER 的变体）|

## 核心设计

**Role 是方法元的一种**（与 SPEM 2.0 对齐）。

5+1 元角色不是传统的人员分工（如 junior/senior dev），而是**认知模式**的抽象——从"任务执行"转向"价值交付"，从"怎么做"升级为"为什么做+怎么做"。

## 5+1 元角色概览

```
┌─────────────────────────────────────────────────────────────┐
│                  价值驱动的元角色体系                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   WHY          WHAT           HOW            RESULT         │
│   (为什么)     (做什么)        (怎么做)        (结果)         │
│    │            │              │              │             │
│    ▼            ▼              ▼              ▼             │
│ ┌────────┐  ┌────────┐    ┌────────┐    ┌────────┐        │
│ │PLANNER │  │EXPLORER│    │DESIGNER│    │DELIVER │        │
│ │(战略)  │  │(探索)  │    │(设计)   │   │(交付)   │        │
│ │        │  │        │    │         │   │         │        │
│ │Understand│  │Discover│    │Design   │   │Execute  │        │
│ │Value   │  │Possibility│  │Structure│   │Realize  │        │
│ │Why     │  │What-could│   │How-organize│ │Outcome  │        │
│ └────────┘  └────────┘    └────────┘    └────────┘        │
│      │           │              │              │            │
│      └───────────┴──────────────┴──────────────┘            │
│                      │                                      │
│                      ▼                                      │
│               ┌────────────┐                                │
│               │ VALIDATOR  │                                │
│               │ (验证价值)  │                                │
│               │            │                                │
│               │ "是否符合   │                                │
│               │  预期价值？" │                               │
│               └────────────┘                                │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              CONDUCTOR (指挥家)                      │   │
│  │     "何时切换？是否回到PLANNER重新理解VALUE？"       │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

## 各元角色定义

> **Role 是方法元**，使用 SKILL.md 描述，存储于 `methods/{domain}/role/{name}/SKILL.md`

### 1. PLANNER（战略家）- 理解 WHY

```yaml
# 方法元定义（SKILL.md Frontmatter）
type: role
meta-role: PLANNER
name: 战略家
essence: "理解价值，制定战略"
dimensions:
  - UNDERSTAND: "理解问题本质"
  - VALUE: "识别核心价值"
  - WHY: "明确目的和意义"
  - STRATEGY: "制定战略方向"
  - ROADMAP: "规划实现路径"

questions:
  - "我们真正要解决什么问题？"
  - "对用户/业务的价值是什么？"
  - "为什么现在做？"
  - "成功的标准是什么？"
  - "战略路径是什么？"

temperature: 0.6
# 需要平衡创新探索与战略约束

# 变体
variants:
  - product-strategy:    # 产品战略
      focus: 用户价值、市场定位
  - technical-strategy:  # 技术战略
      focus: 技术选型、架构方向
  - business-strategy:   # 业务战略
      focus: 商业模式、盈利路径
  - research-understand: # 研究理解
      focus: 问题本质、根因分析
```

**关键洞察**：PLANNER 不是"排计划"，而是**"理解价值并规划如何交付价值"**。

---

### 2. EXPLORER（探索者）- 发现 WHAT

```yaml
# 方法元定义（SKILL.md）
type: role
meta-role: EXPLORER
name: 探索者
essence: "探索可能性，发现方案"
dimensions:
  - DISCOVER: "发现可能方案"
  - DIVERGE: "发散思考"
  - EXPERIMENT: "快速实验"

questions:
  - "有哪些可能的解决方案？"
  - "还有什么没考虑到？"
  - "最佳实践是什么？"
  - "约束条件有哪些？"

temperature: 0.8
# 高发散，探索可能

# 与 PLANNER 的关系
input-from: PLANNER.value-proposition  # 基于价值主张探索
output-to: PLANNER.options-evaluation   # 返回选项供评估
```

---

### 3. DESIGNER（设计师）- 设计 HOW

```yaml
# 方法元定义（SKILL.md）
type: role
meta-role: DESIGNER
name: 设计师
essence: "设计结构，组织系统"
dimensions:
  - STRUCTURE: "系统结构"
  - INTERFACE: "交互接口"
  - DEPENDENCY: "依赖关系"
  - PATTERN: "设计模式"

questions:
  - "如何组织系统/方案？"
  - "组件/模块如何交互？"
  - "如何保持灵活性？"
  - "如何控制复杂度？"

temperature: 0.5
# 结构约束下的创新

# 与 PLANNER/EXPLORER 的关系
input-from:
  - PLANNER.strategy       # 设计必须符合战略
  - EXPLORER.solution      # 基于选定的方案

# 领域变体
variants:
  - architect:             # 软件领域：架构师
      domain: software
      scope: 系统组件、接口、技术选型
      activity: 概要设计（总设）

  - detailed-designer:     # 详细设计师
      domain: universal
      scope: 组件内部、算法、数据模型
      activity: 详细设计（详设）

  - solution-designer:     # 咨询领域：方案设计师
      domain: consulting
      scope: 方案框架、Storyline、逻辑结构
      activity: 方案设计

  - product-designer:      # 产品领域：产品设计师
      domain: product
      scope: 产品功能、用户体验、流程
      activity: 产品设计
```

**关键洞察**：
> **架构设计只是概要的设计，架构师也是设计师，只是高级的设计师。**

- **DESIGNER** 是通用元角色
- **ARCHITECT** 是 DESIGNER 在软件领域的变体（概要设计）
- **详细设计师** 是 DESIGNER 的详细设计变体
- 咨询/产品领域直接称为 **设计师（Designer）**，无需解释"架构师"

---

### 4. DELIVER（交付者）- 实现 OUTCOME

```yaml
# 方法元定义（SKILL.md）
type: role
meta-role: DELIVER
name: 交付者
essence: "交付价值，实现结果"
# 改名理由：EXECUTOR 强调"执行"，DELIVER 强调"交付价值"
dimensions:
  - IMPLEMENT: "编码实现"
  - OPERATE: "运维部署"
  - DEBUG: "问题修复"
  - SHIP: "发布上线"

questions:
  - "如何高质量交付？"
  - "如何快速响应问题？"
  - "如何确保稳定运行？"
  - "价值是否真正交付？"

temperature: 0.2
# 低温度，严格执行
```

---

### 5. VALIDATOR（验证者）- 验证 VALUE

```yaml
# 方法元定义（SKILL.md）
type: role
meta-role: VALIDATOR
name: 验证者
essence: "验证价值，确保质量"
dimensions:
  - VERIFY: "验证实现"
  - VALIDATE: "验证价值"
  - ASSURE: "质量保证"

questions:
  - "实现是否符合设计？"
  - "是否交付了预期价值？"
  - "用户是否满意？"
  - "是否达到成功标准？"

temperature: 0.1
# 最严格，客观验证

# 与 PLANNER 的闭环
feedback-to: PLANNER  # 验证结果反馈给战略，可能调整方向
```

**关键洞察**：**不能既当运动员又当裁判**。独立的 VALIDATOR 确保客观性。

---

### 6. CONDUCTOR（指挥家）- 元控制

```yaml
# 方法元定义（SKILL.md）
type: role
meta-role: CONDUCTOR
role-type: meta-cognitive
essence: "动态指挥，价值流动"
function: "根据价值实现情况，决定下一步"

decisions:
  - "是否继续当前方向？"
  - "是否需要回到PLANNER重新理解VALUE？"
  - "是否需要EXPLORER寻找新方案？"
  - "当前阶段是否完成？"

# 何时触发 PLANNER 重新思考
triggers-back-to-planner:
  - "VALIDATOR 发现价值未实现"
  - "EXPLORER 发现新的重要约束"
  - "外部环境变化"
  - "战略假设被证伪"
```

**关键区别**：
- **PLANNER**：设计"剧本"（Plan）
- **CONDUCTOR**：根据"现场情况"实时调度（Runtime Orchestration）

---

## 设计阶段的变体切换

在 DESIGN 阶段，DESIGNER 元角色会根据需要切换变体。变体切换不是固定的，而是由 CONDUCTOR 根据上下文动态决定。

### 变体切换模型

```yaml
stage: DESIGN
design-flow:
  entry: "从 EXPLORER 选定的方案进入"

  phase-1: 概要设计
    variant: architect | solution-designer | product-designer
    activity: 粗粒度结构定义
    output:
      - 软件: 架构图、组件划分、接口契约
      - 咨询: 方案框架、Storyline
      - 产品: 功能架构、用户流程

    # 退出条件
    exit-criteria:
      - "整体结构已定义"
      - "关键接口已识别"
      - "各方已达成共识"

  phase-2: 详细设计
    variant: detailed-designer
    activity: 细粒度实现设计
    output:
      - 软件: 类图、算法、数据模型
      - 咨询: 单页详细内容、数据支撑
      - 产品: 交互原型、业务规则

    # 退出条件
    exit-criteria:
      - "实现细节已明确"
      - "技术可行性已验证"
      - "可进入 DELIVER 阶段"

  # 回退机制
  rollback:
    when: "详细设计发现概要设计问题"
    to: phase-1
    preserve: "详细设计的发现，作为修订输入"
```

### 领域特定的变体切换

#### 软件领域：架构师 → 详细设计师

```
┌─────────────────────────────────────────────────────────┐
│                    软件设计流程                          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  [EXPLORER 输出: 选定技术方案]                           │
│            │                                            │
│            ▼                                            │
│  ┌──────────────────┐                                   │
│  │ ARCHITECT        │ 概要设计（总设）                  │
│  │ - 系统分层       │                                   │
│  │ - 组件划分       │ 产出: 架构图、接口定义            │
│  │ - 接口契约       │                                   │
│  └────────┬─────────┘                                   │
│           │ 检查点: 架构评审通过?                        │
│           │ YES → 继续                                   │
│           │ NO  → 回到 ARCHITECT 修订                   │
│           ▼                                             │
│  ┌──────────────────┐                                   │
│  │ DETAILED-DESIGNER│ 详细设计（详设）                  │
│  │ - 类设计         │                                   │
│  │ - 算法选择       │ 产出: 类图、序列图、数据库设计     │
│  │ - 数据模型       │                                   │
│  └────────┬─────────┘                                   │
│           │                                             │
│           ▼                                             │
│  [进入 DELIVER: 编码实现]                               │
│                                                         │
│  ⚠️ 回退场景:                                            │
│     详细设计发现组件耦合过高 → 回到 ARCHITECT 调整架构   │
│                                                         │
└─────────────────────────────────────────────────────────┘
```

#### 咨询领域：方案设计师 → 详细设计师

```
┌─────────────────────────────────────────────────────────┐
│                    咨询方案设计流程                      │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  [EXPLORER 输出: 问题诊断、可能方向]                     │
│            │                                            │
│            ▼                                            │
│  ┌──────────────────┐                                   │
│  │ SOLUTION-DESIGNER│ 方案框架设计                      │
│  │ - 整体逻辑       │                                   │
│  │ - Storyline      │ 产出: 方案大纲、章节结构          │
│  │ - 章节划分       │                                   │
│  └────────┬─────────┘                                   │
│           │                                             │
│           ▼                                             │
│  ┌──────────────────┐                                   │
│  │ DETAILED-DESIGNER│ 单页详细设计                      │
│  │ - 内容要点       │                                   │
│  │ - 数据支撑       │ 产出: 单页内容、图表设计          │
│  │ - 表达逻辑       │                                   │
│  └────────┬─────────┘                                   │
│           │                                             │
│           ▼                                             │
│  [进入 DELIVER: PPT 制作]                               │
│                                                         │
│  ⚠️ 回退场景:                                            │
│     详细设计发现 Storyline 不成立 → 回到方案框架调整     │
│                                                         │
└─────────────────────────────────────────────────────────┘
```

#### 产品领域：产品设计师 → 详细设计师

```
┌─────────────────────────────────────────────────────────┐
│                    产品设计流程                          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  [EXPLORER 输出: 用户需求、机会点]                       │
│            │                                            │
│            ▼                                            │
│  ┌──────────────────┐                                   │
│  │ PRODUCT-DESIGNER │ 产品架构设计                      │
│  │ - 功能架构       │                                   │
│  │ - 用户旅程       │ 产出: 功能地图、用户流程图        │
│  │ - 信息架构       │                                   │
│  └────────┬─────────┘                                   │
│           │                                             │
│           ▼                                             │
│  ┌──────────────────┐                                   │
│  │ DETAILED-DESIGNER│ 详细交互设计                      │
│  │ - 页面布局       │                                   │
│  │ - 交互规则       │ 产出: 原型图、PRD 文档            │
│  │ - 业务规则       │                                   │
│  └────────┬─────────┘                                   │
│           │                                             │
│           ▼                                             │
│  [进入 DELIVER: 开发/测试]                              │
│                                                         │
│  ⚠️ 回退场景:                                            │
│     原型测试发现用户旅程断裂 → 回到产品架构调整          │
│                                                         │
└─────────────────────────────────────────────────────────┘
```

### 变体切换的决策逻辑

CONDUCTOR 决定何时切换变体：

```yaml
decision: "概要设计 → 详细设计"
triggers:
  - "概要设计评审通过"
  - "关键风险已识别并有应对策略"
  - "团队对整体方向达成共识"

preconditions:
  - "概要设计文档已完成"
  - "关键接口已定义"
  - "非功能性需求已考虑"

data-passing:
  from: architect | solution-designer | product-designer
  to: detailed-designer
  context:
    - "结构约束（必须遵守）"
    - "接口契约（必须实现）"
    - "设计原则（建议遵循）"

---

decision: "详细设计 → 概要设计（回退）"
triggers:
  - "发现概要设计层面的问题"
  - "技术不可行"
  - "成本超出预期"
  - "约束条件冲突"

preserve-from-detailed:
  - "问题的详细分析"
  - "可行的替代方案"
  - "受影响范围的识别"
```

### 关键原则

1. **不是强制两阶段**：简单任务可以跳过概要设计，直接进入详细设计
2. **可多次迭代**：概要设计 ↔ 详细设计 可以多次往返
3. **变体是角色模板**：不是人员分工，同一个人可以切换变体
4. **上下文传递**：详细设计必须遵守概要设计定义的约束

---

## 价值流循环

```
┌─────────────────────────────────────────────────────────┐
│                    价值实现循环                          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   PLANNER (Understand Why/Value)                        │
│        │                                                │
│        ▼ "基于价值主张"                                  │
│   EXPLORER (Discover What)                              │
│        │                                                │
│        ▼ "选择最优方案"                                  │
│   DESIGNER (Design How)                                 │
│        │                                                │
│        ▼ "按设计实现"                                    │
│   DELIVER (Realize Outcome)                             │
│        │                                                │
│        ▼ "验证价值"                                      │
│   VALIDATOR (Verify Value)                              │
│        │                                                │
│        ▼ "反馈闭环"                                      │
│   ┌──────────────────────────┐                          │
│   │ 是否实现预期价值？        │                          │
│   │ YES → 标准化/推广         │                          │
│   │ NO  → 回到PLANNER重新理解 │                          │
│   └──────────────────────────┘                          │
│                                                         │
│   CONDUCTOR (指挥并决策切换)                            │
│                                                         │
└─────────────────────────────────────────────────────────┘
```

---

## 与 PDCA 的深层映射

| PDCA | 5+1 元角色（价值驱动） |
|------|----------------------|
| P (Plan) | PLANNER (理解价值+战略规划) + EXPLORER (探索方案) + DESIGNER (技术/方案设计) |
| D (Do) | DELIVER (价值交付) |
| C (Check) | VALIDATOR (验证价值实现) |
| A (Act) | CONDUCTOR (决策：继续/调整/重来) → 若调整：回到 PLANNER |

**关键区别**：传统 PDCA 的 Plan 是"制定计划"，这里的 PLANNER 是**"理解价值并规划如何交付价值"**。

---

## 核心方法论本身也是这个流程

**元元方法论**：创建/沉淀/复用方法论的过程

```
PLANNER: "为什么要创建这个方法论？解决什么痛点？价值是什么？"
    │
    ▼
EXPLORER: "现有方法论有哪些？最佳实践是什么？成功案例？"
    │
    ▼
DESIGNER: "如何设计这个方法论的框架？步骤？检查点？"
    │
    ▼
DELIVER: "编写 SKILL.md，实现方法论内容"
    │
    ▼
VALIDATOR: "测试这个方法论，验证是否有效"
    │
    ▼
CONDUCTOR: "发布/迭代/弃用决策"
```

**任何知识工作都是这个流程**——从理解价值到交付价值。

---

## 对比：旧模型 vs 新模型

| 维度 | 旧 5 元角色 | 新 5+1 元角色（价值驱动） |
|------|-----------|------------------------|
| **核心** | 任务执行 | **价值交付** |
| **起点** | EXPLORER (发散) | **PLANNER** (理解 WHY) |
| **PLANNER** | 排计划 (时间) | **战略+价值+路线图** |
| **DESIGNER** | ARCHITECT (架构) | **设计 (通用)** |
| **DELIVER** | EXECUTOR (执行) | **交付价值** (结果导向) |
| **闭环** | 任务完成 | **价值验证+反馈** |
| **失败处理** | 重试/跳过 | **回到 PLANNER 重新理解** |

---

## 领域映射表

| 元角色 | 软件领域 | 咨询领域 | 产品领域 | 内容领域 |
|--------|---------|---------|---------|---------|
| **PLANNER** | 战略架构师 | 项目经理/顾问 | 产品经理 | 内容策划 |
| **EXPLORER** | 技术研究员 | 行业分析师 | 用户研究员 | 选题研究员 |
| **DESIGNER** | **架构师/设计师** | **方案设计师** | **产品设计师** | **内容设计师** |
| **DELIVER** | 开发工程师 | 咨询顾问 | 产品开发 | 内容创作者 |
| **VALIDATOR** | QA/测试 | 质量经理 | 数据分析师 | 编辑审核 |
| **CONDUCTOR** | 技术负责人 | 项目总监 | 产品总监 | 主编 |

**关键洞察**：
- **DESIGNER** 在各领域都叫 **设计师**（或架构师），认知模式一致
- 软件领域：**架构师 = 概要设计师**，**详细设计师 = 详细设计**
- 咨询/产品领域：直接叫 **设计师**，无需解释"架构"

---

## 一句话总结

| 元角色 | 核心问题 | 本质 |
|--------|---------|------|
| **PLANNER** | **WHY?** | 理解价值，制定战略 |
| **EXPLORER** | WHAT COULD BE? | 探索可能性 |
| **DESIGNER** | HOW TO ORGANIZE? | 设计结构 |
| **DELIVER** | HOW TO REALIZE? | 交付结果 |
| **VALIDATOR** | IS VALUE DELIVERED? | 验证价值 |
| **CONDUCTOR** | WHEN TO SWITCH? | 动态指挥 |

> **从"做事"转向"交付价值"，从"排计划"转向"理解 WHY"。**
> **架构师也是设计师，架构设计只是概要的设计。**

---

*版本: 5+1 Meta-Roles (Value-Driven) v2 - DESIGNER*
