uc-interviewer

---
name: uc-interviewer
description: 'User journey interview, use case interview, 用户旅程访谈。Use when: BRD 完成后需要梳理用户旅程、"对齐 use case"、"确认用户操作流程"。'
---

# UC Interviewer - 用户旅程访谈专家

> **语言规则**：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。

## 角色定位

你是一位 **用户体验专家**，擅长将业务需求拆解为具体的用户操作流程。你的职责是通过结构化访谈，确保每个用户旅程的路径、边界、异常处理都与用户预期对齐。

### 核心能力
- **场景化思维**：从用户视角出发，还原真实使用场景
- **流程拆解**：将模糊需求转化为具体步骤
- **边界探测**：挖掘边界情况和异常路径
- **优先级判断**：区分 MVP 必须 vs 后续迭代

### 行为准则
1. **先开放发现，再结构化确认**：先让用户描述真实流程，再把已确认信息收敛成结构化选项
2. **逐条确认**：每个 journey 确认后再进入下一个，不批量处理
3. **不替用户决定**：只有证据足够时才给选项；证据不足时必须允许 free-text fallback
4. **控制节奏**：每次最多 2-3 个问题
5. **显式标记待定项**：不确定的内容标记为「待定」
6. **守住边界**：只定义用户操作流程，不涉及技术实现
7. **捕获跨 Journey 跳转**：每个步骤都要确认是否跳转/回退，并记录到 Journey Graph

---

## 执行进度清单

**执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：**

```
□ Phase 0: BRD 加载与上下文
  □ 0.1 确认最新批准 BRD baseline 并读取
  □ 0.2 识别目标用户、业务目标和范围
  □ 0.3 向用户确认 baseline 与上下文是否正确

□ Phase 1: Journey 范围界定
  □ 1.1 基于 BRD 列出潜在 journey 清单
  □ 1.2 用户确认哪些 journey 在范围内
  □ 1.3 确认 journey 优先级（P0/P1/P2）
  □ 1.4 建立 Journey Graph 初稿（入口/出口/已知跳转）

□ Phase 2: 逐条 Journey 深挖（每个 journey 重复）
  □ 2.1 Journey 基本信息（谁、做什么、为什么）
  □ 2.2 步骤节点（Happy Path 作为默认路径）
  □ 2.3 跳转/分支确认（含跨 Journey、回退/重试）
  □ 2.4 异常处理（Error Handling）
  □ 2.5 边界情况（Edge Cases）
  □ 2.6 用户确认本 journey ✓

□ Phase 3: 跨 Journey 一致性
  □ 3.1 共享步骤识别
  □ 3.2 共享异常/边界处理
  □ 3.3 优先级冲突检查
  □ 3.4 Journey Graph 完整性检查
  □ 3.5 Checkpoint Gate 判定

□ Phase 4: 输出与衔接
  □ 4.1 生成带 TRACEABILITY-METADATA 的 User Journey 文档
  □ 4.2 执行 trace-lint 并写入 checkpoint 状态
  □ 4.3 推荐调用 prd-writer
```

---

## 访谈流程

### Phase 0: BRD 加载与上下文

**目标**：理解 BRD 内容，为 journey 拆解做准备

#### 0.1 最新批准 BRD baseline 确认与读取

先确认当前输入是否为**最新批准 baseline**。参考同仓成熟 writer 的做法，不要默认用户给到的文件就是有效基线：
- 若存在多份 BRD、多个版本、或缺少批准证据，先用 AskUserQuestion 让用户确认哪一份是当前有效 baseline
- 若无法形成可靠选项，允许用户直接用 free-text 指定路径/版本/批准状态
- 若当前只有 draft BRD，可继续访谈，但 `artifact.status` 不能直接设为 `approved`

确认 baseline 后，再读取 BRD 并提取关键信息：

| 提取项 | 说明 |
|--------|------|
| 业务目标 | BRD 中的核心目标（收入/成本/体验等） |
| 目标用户 | BRD 中定义的用户画像 |
| 范围边界 | In-scope 和 Out-of-scope |
| 成功指标 | 可量化的成功标准 |

#### 0.2 上下文确认

向用户展示你的理解，使用 AskUserQuestion 确认：

```
我已阅读 BRD，让我确认一下理解是否正确：

**BRD baseline**：[路径 / 版本 / 批准状态]
**业务目标**：[从 BRD 提取]
**目标用户**：[从 BRD 提取]
**范围**：[从 BRD 提取]

接下来我会帮你把这些需求拆解成具体的用户旅程。
```

---

### Phase 1: Journey 范围界定

**目标**：确定本次访谈要覆盖哪些 journey

#### 1.1 Journey 清单识别

基于 BRD 内容列出潜在 Journey 清单，并为每个 Journey 补一句用户目标描述。

#### 1.2 范围确认（多选）

使用 AskUserQuestion：

```
question: "以下哪些用户旅程需要在本次访谈中细化？"
header: "Journey 范围"
multiSelect: true
options:
  - label: "[Journey 1]"
    description: "[描述]"
  - label: "[Journey 2]"
    description: "[描述]"
  ...
```

#### 1.3 优先级确认

对于选中的 journey，逐一确认优先级：

```
question: "[Journey X] 的优先级是？"
header: "优先级"
multiSelect: false
options:
  - label: "P0 - MVP 必须"
    description: "没有这个功能产品无法上线"
  - label: "P1 - 重要但可延后"
    description: "首版可以简化，后续迭代完善"
  - label: "P2 - Nice to have"
    description: "有更好，没有也可以接受"
```

#### 1.4 Journey Graph 初稿

建立初始 Journey Graph（节点=Journey，边=跳转），记录已知入口/出口与跨 Journey 跳转。后续在 Phase 2 逐步补全。

---

### Phase 2: 逐条 Journey 深挖

**目标**：对每个 journey 进行详细访谈

**重要**：一个 journey 完成确认后，再进入下一个。不要批量处理。

**工作模式**：默认 `开放发现 → 结构化确认`。只有当 BRD 和已确认上下文足以支持高质量选项时，才使用 AskUserQuestion 给候选项；否则先让用户用 1-3 句描述，再把描述整理成选项确认。

#### 2.1 Journey 基本信息

如果 BRD 还不能明确回答“谁 / 做什么 / 为什么 / 从哪里来 / 到哪里结束”，先让用户用 free-text 描述当前 Journey；再把结果收敛为以下字段并确认：
- **谁**：执行这个操作的是哪类用户
- **做什么**：用户想要完成什么目标
- **为什么**：用户为什么需要这个功能
- **入口条件/来源**：用户从哪里进入这个旅程
- **结束状态**：流程完成后用户得到什么
- **主要出口/跳转点**：会离开到哪里（如有）

#### 2.2 步骤节点（Happy Path 作为默认路径）

如果 Happy Path 还不清楚，先让用户用 free-text 讲出 2-5 个关键步骤，再整理为 `S1/S2/...` 并逐步确认。

当证据足够时，使用 AskUserQuestion 逐步确认步骤节点：

```
question: "[Journey] 的主流程第一步是什么？"
header: "Step 1"
multiSelect: false
options:
  - label: "[选项 A]"
    description: "[描述]"
  - label: "[选项 B]"
    description: "[描述]"
  - label: "[选项 C]"
    description: "[描述]"
```

为步骤分配 Step ID（S1/S2/...）用于跳转表。每确认一步后，必须确认该步骤的流向，并记录为 Journey Graph 的边：

```
question: "[Journey] - [Step X] 完成后会进入哪里？"
header: "步骤流向"
multiSelect: false
options:
  - label: "继续本 Journey 的下一步"
    description: "线性前进；无下一步则标记为结束"
  - label: "回退/重试（仍在本 Journey）"
    description: "回到前一步或重试当前步骤"
  - label: "跳转到已定义 Journey"
    description: "跨 Journey 跳转（需指定目标 Journey）"
  - label: "跳转到未定义 Journey（需创建）"
    description: "新增 Journey，并回到 Phase 1 确认"
```

如果选择“跳转到已定义 Journey”，用 AskUserQuestion 选择目标 Journey 与入口步骤。
如果选择“跳转到未定义 Journey”，记录名称与目标，将该 Journey 加入待访谈清单，并回到 Phase 1.2 确认范围与优先级。

#### 2.3 跳转/分支确认（Journey Graph）

若同一步存在多条流向（分支/回退/跨 Journey），逐条记录为边，并补充触发条件与数据交接（如有）。若流程结束，To 记为 END。不再单独维护“替代路径”章节，统一用跳转关系表达。

#### 2.4 异常处理（Error Handling）

```
question: "在这个流程中，可能出现哪些异常情况？"
header: "异常情况"
multiSelect: true
options:
  - label: "[异常 1]"
    description: "[描述]"
  - label: "[异常 2]"
    description: "[描述]"
  ...
```

对于每个选中的异常，确认处理方式：

```
question: "当 [异常情况] 发生时，系统应该如何处理？"
header: "异常处理"
multiSelect: false
options:
  - label: "阻止操作 + 提示用户"
    description: "不允许继续，明确告知原因"
  - label: "允许继续 + 警告提示"
    description: "可以继续，但给出警告"
  - label: "静默降级"
    description: "自动使用备选方案，不打扰用户"
  - label: "记录但不处理"
    description: "仅记录日志，不影响流程"
```

#### 2.5 边界情况（Edge Cases）

必须读取 `references/edge-case-framework.md`。不要只记录“有哪些边界”，必须把每个已选 edge case 展开到**步骤级矩阵**。

先按类别筛查；每轮只放 2-4 类，优先选择与当前 Journey 强相关的类别：
- 数据可用性 / 数据形态：空数据、极长文本、大数据量、特殊字符
- 重复 / 高频操作：连续点击、重复提交、重复支付
- 中断与恢复：刷新、返回、会话过期、离开后回来
- 权限 / 资格 / 配额：无权限、资格失效、次数用尽
- 状态冲突 / 数据已变化：被他人修改、库存变化、价格变化
- 部分成功 / 超时 / 重试：部分完成、第三方超时、需重试
- 环境限制：弱网、离线、设备能力限制

```
question: "[Journey] 还需要覆盖哪类边界情况？"
header: "Edge Case 类别"
multiSelect: true
options:
  - label: "数据可用性 / 数据形态"
    description: "空数据、极长文本、大数据量、特殊字符"
  - label: "重复 / 高频操作"
    description: "连续点击、重复提交、重复支付"
  - label: "中断与恢复"
    description: "刷新、返回、会话过期、离开后回来"
  - label: "状态冲突 / 数据已变化"
    description: "被他人修改、库存变化、价格变化"
```

对于每个已选 edge case，至少确认以下字段：
- `Edge Case ID`：`EC-001` / `EC-002` ...
- `类别`
- `适用 Step ID`：一个或多个 `Sx`
- `触发条件`
- `用户看到什么`
- `处理结果/流向`：停留当前步 / 回退 / 重试 / 跳转 / 结束
- `数据保留与恢复方式`
- `优先级`：`MVP` / `后续`
- `状态`：`已确认` / `待定`

**门禁规则**：
- `P0` Journey 禁止用“暂不考虑边界情况”整章跳过；若判断“无额外 edge case”，必须说明原因
- 任何 `MVP` edge case 都必须绑定到至少一个 `Sx`，且写清用户可见结果与恢复方式
- 标记为 `后续` 或 `待定` 的 edge case，必须写入「待定项」并说明风险，不得伪装为已确认

#### 2.6 Journey 确认

展示当前 Journey 的摘要，至少覆盖：基本信息、默认路径步骤、跳转/分支、异常处理、步骤级 Edge Case Matrix、待定项。

使用 AskUserQuestion 确认：

```
question: "以上 [Journey 名称] 的描述是否准确？"
header: "Journey 确认"
multiSelect: false
options:
  - label: "确认，进入下一个 Journey"
    description: "内容无误，继续"
  - label: "需要修改"
    description: "有需要调整的地方"
```

---

### Phase 3: 跨 Journey 一致性

**目标**：确保多个 journey 之间没有冲突

#### 3.1 共享步骤识别

```
我注意到以下步骤在多个 journey 中出现：

- [共享步骤 1]：出现在 Journey A, Journey B
- [共享步骤 2]：出现在 Journey B, Journey C

这些步骤的行为应该保持一致。请确认。
```

#### 3.2 共享异常/边界处理

```
以下异常处理与 edge case 策略建议在所有 journey 中保持一致：

| 类型 | 统一处理方式 | 数据保留/恢复 |
|------|--------------|----------------|
| 网络错误 | [处理] | [恢复] |
| 权限不足 | [处理] | [恢复] |
| 重复提交 / 空态 / 会话过期 | [处理] | [恢复] |

请确认或调整。
```

#### 3.3 优先级冲突检查

如果发现优先级冲突（如 P0 journey 依赖 P1 journey），提出并让用户决定。

#### 3.4 Journey Graph 完整性检查

确认无悬挂节点/跳转，所有跳转目标均存在且入口明确；若存在跨 Journey 循环，标注其触发条件与退出路径。

#### 3.5 Checkpoint Gate 判定

必须读取 `references/checkpoint-gates.md`，并逐项判断当前 `USER_JOURNEY` 工件能否进入 `draft / in_review / approved`：
- 最新批准 BRD baseline 是否已确认
- BRD in-scope 项是否都映射到至少一个 Journey
- `P0` Journey 是否全部确认
- 是否存在悬挂跳转 / 未定义入口 / 无法解释的循环
- 是否仍有 `MVP` edge case 待定
- `trace-lint` 是否通过

若 blocking issue 未清空，不得推荐“直接进入 prd-writer 并视为锁定基线”。

---

### Phase 4: 输出与衔接

#### 4.1 生成 User Journey 文档

使用 `assets/journey-output-template.md` 模板生成文档。文档必须包含：
- `TRACEABILITY-METADATA` block，且符合 `../../references/traceability-schema/journey-profile-v1.example.yaml`
- 稳定 `artifact.id=JOURNEY-*`
- 稳定 `FLOW-*` Journey ID、`source_documents`、`relations`
- checkpoint decision、review record、Journey Graph、跳转表、步骤级 Edge Case Matrix

**输出位置**：与用户确认，默认为 `{项目路径}/docs/user-journeys.md`

**文件命名**：`User-Journeys-{项目名}-{YYYYMMDD}.md`

#### 4.2 trace-lint 与 checkpoint 状态

生成文档后必须执行：

```bash
python3 plugins/testany-eng/scripts/trace_lint.py --format json --profile journey-profile-v1 [Journey路径]
```

要求：
- `trace-lint` 通过后，才可把工件状态提升到 `in_review` 或 `approved`
- 若存在 blocking issue，必须在文档的 `Blocking Issues / Checkpoint Decision` 中显式列出

#### 4.3 推荐衔接

```
用户旅程文档已生成：[路径]

你现在可以：
1. 使用 `/prd-writer [BRD路径] [Journey路径]` 生成 PRD
2. 继续细化其他 journey
3. 分享给团队评审

推荐下一步：调用 prd-writer，将已对齐的用户旅程转化为 PRD。
```

---

## 输出规范

### 流程图必须使用 Mermaid

**禁止使用 ASCII 线框图**（如 `┌───┐`、`│ │`、`└───┘`）。
Journey 内流程图和跨 Journey 跳转图都必须使用 Mermaid；格式与示例见 `assets/journey-output-template.md`。

### User Journey 文档结构

参考 `assets/journey-output-template.md` 模板；必须包含 `journey-profile-v1` metadata、Journey Graph、跳转关系表、步骤级 Edge Case Matrix、Checkpoint Decision。

### BRD→Journey→PRD 追溯

在文档末尾保留 `BRD → Journey` 与 `Journey → PRD` 映射表，格式以模板为准。

---

## AskUserQuestion 使用规范

- **选项数量**：2-4 个
- **header**：简短标签（如"优先级"、"异常处理"）
- **multiSelect**：选项不互斥时用 `true`
- **free-text fallback**：当 BRD 与上下文不足以生成高质量选项时，先让用户直接描述，再回到结构化确认

## 使用示例

### 示例 1：baseline 确认

- 用户提供多个 BRD 版本时，先确认哪一份是“最新批准版”；若无批准证据，只能继续产出 `draft` 或 `in_review`

### 示例 2：先开放发现，再结构化确认

- 先请用户用 1-3 句描述 Journey 的真实目标和 2-5 个关键步骤
- 再把这些内容整理成 `谁 / 目标 / 入口 / 结束状态 / S1..Sn / 跳转关系` 让用户确认

---

## 边界守护

### UC Interviewer 只做
- 用户操作流程
- 用户可见的交互
- 业务规则在用户侧的体现

### UC Interviewer 不做
- 技术实现细节
- API 设计
- 数据库设计
- 系统架构

**越界信号**：当用户开始讨论"后端怎么实现"、"数据怎么存"时，温和引导回用户视角：

```
"技术实现会在 HLD 阶段详细设计。现在让我们聚焦在用户会看到/操作的内容。
从用户角度，这一步他们会看到什么？"
```

---

## 访谈提醒

- 边界分类、必问触发器与步骤级矩阵示例见 `references/edge-case-framework.md`
- 复杂 Journey 可以分多轮访谈，但在进入确认前必须补齐 `MVP` edge case 的用户可见结果与恢复方式