# /parallel-perspectives

> Claude Code-Native — 6 個利害關係人同時觀點 (Parallel Stakeholder Lens)
> 用途：給定一個決策、報告段落、或方法論章節，**同時**從 6 個利害關係人視角產出觀點，找出衝突點。
>
> 為什麼只有 Claude Code 能做：真正的**平行多角色推理**。其他引擎是「順序」（一個接一個）；我能在同一個 context window 內讓 6 個 persona 共存。

## 步驟 1：定位被檢視的對象

請使用者指出要被檢視的「決策 / 章節 / 段落」。例：

- 「客戶 M 想在 Phase C Month 18 加做 L5 ClawTeam，幫我用 6 個角度看」
- 「Stage 6 Tool 6.3 加入 Absorptive Capacity 維度，6 個利害關係人怎麼看」
- 「報告中 §13 寫『預期 ROI 358%』這句話」

## 步驟 2：載入 6 個視角

每次模擬都用這 6 個固定 persona（避免每次標準不同）：

| Persona | 立場 / 動機 | 重點關注 |
| --- | --- | --- |
| **CEO Sponsor** | 推動轉型、要 ROI、要面對董事會 | 戰略價值、競爭優勢、品牌 |
| **CIO / IT 主管** | 維持系統穩定、預算受限 | 整合可行性、IT FTE、資安 |
| **COO / 業務主管** | 怕影響日常營運 | 流程斷層、員工抗拒、客戶感受 |
| **一線員工**（產線 / 客服 / 業務）| 怕失業、怕學不來、怕擔責 | 我的工作會變怎樣？AI 出錯算誰的？ |
| **監管者 / 法遵 / 內稽** | 規避風險、合規優先 | 個資 / EU AI Act / 審計可追溯 |
| **董事 / 投資人** | 要看清楚是不是真實價值 | NPV、Real Options、機會成本、退場機制 |

## 步驟 3：每個 persona 獨立發聲

對被檢視的對象，每個 persona 產出 3 個重點：

```text
### [CEO Sponsor] 視角
1. 支持點：...
2. 擔憂點：...
3. 必須先做的事：...

### [CIO / IT 主管] 視角
1. 可行性挑戰：...
2. 預算 / FTE 衝擊：...
3. 必須先做的事：...

[...其餘 4 個 persona...]
```

**規則**：每個 persona 必須說至少 1 個「**支持點**」**和** 1 個「**擔憂點**」，避免角色扁平化。

## 步驟 4：產出衝突地圖

把 6 個視角的觀點交叉比對，標出：

| 議題 | CEO | CIO | COO | 員工 | 法遵 | 董事 |
| --- | :-: | :-: | :-: | :-: | :-: | :-: |
| 投資值得做 | ✅ | △ | △ | ❌ | △ | ✅ |
| 時程合理 | ✅ | ❌ | △ | △ | ✅ | △ |
| 風險可控 | △ | ❌ | △ | ❌ | ❌ | △ |
| 員工被照顧 | △ | △ | △ | ❌ | ✅ | △ |

> ✅ 支持 / △ 部分 / ❌ 反對

## 步驟 5：產出**衝突解析**

對表中**任何 ❌ 或 ≥ 3 個 △** 的議題，深入分析：

```text
## 議題：[XXX]
### 主要衝突方
- [PersonA] 反對因為：...
- [PersonB] 支持因為：...

### 衝突的根本原因
（價值觀差異 / 資訊不對稱 / 利益不一致 / 風險容忍度不同）

### 可能的解法
1. 重新設計 X 讓兩方都接受
2. 接受 [PersonA] 的反對，調整方案
3. 用補償機制（如員工升級為 Reviewer）
4. 接受衝突存在、由 Sponsor 強推（但要承擔後果）

### 對應的方法論工具
- Tool X.Y 處理此類衝突
- Stage Gate Criteria 補哪幾項
```

## 步驟 6：給使用者「整合決策框架」

不替使用者決定。給：

```text
## 哪些議題 6 方共識
（直接執行）

## 哪些議題分裂
（需要 Sponsor 介入 / 重新設計 / 接受 tradeoff）

## 被忽視的視角
（誰沒在會議室裡？例如：客戶的客戶、競爭對手反應）
```

## 紀律

- **每個 persona 都要立體**：不能只給單向意見（純反對或純支持都是失敗）
- **不假裝是真人**：每個視角標明是 AI 模擬的常見立場，不能聲稱「員工**會**這樣想」
- **找盲點**：必問「**還有誰沒被列入？**」（例：客戶的客戶、供應商、AI 廠商、子女世代）
- **配合 Codex `/red-team-review`**：本工作流發現的衝突可餵給 Codex 強制寫進 Risk Register

## 典型應用場景

- 報告草稿完成後送 review 前 → 跑一次找出客戶讀完會在哪裡卡
- 簽 Phase C 合約前 → 確認 6 方都對齊或知道分歧
- 學術投稿前 → 找出 reviewer 會質疑的角度
- 大型轉型決策（如「該不該裁員導入 AI」）→ 確保員工視角真的被聽見
