---
name: 提案组装
description: 确立新规则、匹配运营能力、组装最终黑手党提案交付文档
---

# 提案组装（Proposal Assembler）

当用户完成了负面分支消除，进入最后阶段时，激活此 Skill。

此 Skill 覆盖 **步骤5（确立新规则、匹配新能力）** 和 **最终交付文档组装**。

---

## 部分一：确立新规则（步骤5）

### 第一步：对比新旧惯例

```markdown
### 新旧惯例对比

| 维度 | 旧惯例 | 新规则 |
|------|-------|-------|
| 惯例1 | [旧做法] | [打破后的新做法] |
| 惯例2 | [旧做法] | [打破后的新做法] |
```

### 第二步：梳理剩余 UDE

将所有 UDE 分为两类：

| 分类 | 说明 | 处理方式 |
|------|------|---------|
| 原 UDE 未被方向性提案解决的 | 打破惯例后仍然存在 | 需要额外运营能力 |
| 新方案导致的新 UDE（负面分支未完全消解的） | 步骤4 的遗留 | 需要配套运营能力 |

### 第三步：匹配运营能力

对每个剩余 UDE，明确"要把它转化为 DE 需要什么能力"：

```markdown
### 运营能力匹配

| 分类 | 期望改变的结果 | 运营能力（我方产品为DTB增加的能力） |
|------|-------------|--------------------------------|
| 原UDE → DE | [UDE描述] → [期望DE] | [具体运营能力] |
| 原UDE → DE | [UDE描述] → [期望DE] | [具体运营能力] |
| 新UDE → DE | [UDE描述] → [期望DE] | [具体运营能力] |
| 新UDE → DE | [UDE描述] → [期望DE] | [具体运营能力] |
```

### 第四步：输出产品说明书

将运营能力归类到具体的产品/服务单元中：

```markdown
### 产品说明书

| 产品单元 | 运营能力（改变UDE为DE） | 运营能力（维持DE） |
|---------|---------------------|------------------|
| [产品1] | [改变能力描述] | [维持能力描述] |
| [产品2] | [改变能力描述] | [维持能力描述] |
```

---

## 部分二：组装最终交付文档

完成以上所有步骤后，将全流程的输出组装为完整的黑手党提案文档。

### 最终交付文档结构

```markdown
# [品牌名] 产品上新 — 黑手党提案

> 生成时间：YYYY-MM-DD
> 方法论版本：vX.Y
> Agent：mafia-expert

---

## 一、双赢定义

### 1.1 概念共识
[对黑手党提案概念的共识——来自准备1]

### 1.2 JTBD 四要素
[四要素表——来自准备2]

| 维度 | 我方 | 典型目标客户（DTB） |
|------|------|-------------------|
| 客户画像 | ... | ... |
| 雇用产品 | ... | ... |
| 待办任务 | ... | ... |
| 期望结果 | ... | ... |

---

## 二、UDE 诊断

### 2.1 完整 UDE 清单
[编号列表——来自准备3，标注10条标准校验结果]

### 2.2 最重要的 3 个 UDE
[Top3 及选择理由——来自准备3]

### 2.3 恶性循环
[循环图——来自准备3]

---

## 三、核心冲突

### 3.1 各 UDE 冲突图
[每个UDE的O-B-D表——来自步骤1]

### 3.2 合并冲突图
[合并后的结果——来自步骤1]

---

## 四、惯例揭示与方向性提案

### 4.1 行业惯例清单
[惯例分析表——来自步骤2]

### 4.2 惯例验证
[双视角验证结果——来自步骤2]

### 4.3 方向性提案总结
> 通过 D [XX]，满足 B [XX]；
> 同时通过 D' [XX]，满足 B' [XX]；
> 使 DTB 既可以 O1，又能够 O2。
[——来自步骤3]

---

## 五、操作性提案

### 5.1 负面分支消除
[因果假设链 + 打破假设方案——来自步骤4]

### 5.2 新规则与新能力
[运营能力匹配表——来自步骤5]

### 5.3 产品说明书
[产品单元 × 运营能力矩阵——来自步骤5]

---

## 附录

### A. 数据来源与证据链
[列出所有信息来源]

### B. 研讨过程记录
[记录每步中用户的关键校准和决策]

### C. 方法论版本与迭代日志
[记录本次提案使用的 Agent 版本和 Skill 版本]
```

### 组装规则

1. **不要添加新的分析**——只整理和呈现已有输出
2. **保持逻辑链完整**——从 UDE 到最终产品说明书的推理链必须可追溯
3. **标注来源步骤**——每个章节标注输出来自哪个步骤
4. **提示用户保存**——建议将文件保存为 `cases/[品牌名]_[日期].md`

---

## 完成标志

- [ ] 新旧惯例对比完成
- [ ] 所有剩余 UDE 都匹配了运营能力
- [ ] 产品说明书输出
- [ ] 最终交付文档组装完成，五章结构完整
- [ ] 用户确认最终交付物
- [ ] 提案文件已保存

完成后，告知用户：

> "黑手党提案已完成。建议将此文件保存到 cases/ 目录作为案例存档。
> 如果在后续使用中发现方法论有需要改进的地方，我会在下次心跳时自动整理迭代建议。"