lidf
4ddd6ef2b1
- AGENTS.md: TOC 五步法方法论注入 - 5 个 Skills: UDE诊断/冲突图/惯例打破/负面分支/提案组装 - HEARTBEAT.md: 每日自动更新 + 每周方法论回顾 - install.sh: 一键安装脚本 - 完整 SPEC 文档
184 lines
4.6 KiB
Markdown
184 lines
4.6 KiB
Markdown
---
|
||
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/ 目录作为案例存档。
|
||
> 如果在后续使用中发现方法论有需要改进的地方，我会在下次心跳时自动整理迭代建议。"
|