chanpinhsd/docs/SPEC_黑手党提案Agent_v1.md

# 黑手党提案 Agent — 产品规格说明书 (SPEC v1.0)

> **版本**：v1.0 | **日期**：2026-04-06
> **作者**：李东方 | **审阅**：沈攀、赵蕾
> **状态**：草案（待审批）

---

## 一、项目定位

### 1.1 是什么

基于 CoPaw（小龙虾）多智能体架构的 **"产品上新黑手党提案"AI 顾问**。

- **产品形态**：一个 CoPaw Agent 配置包（AGENTS.md + Skills + HEARTBEAT.md），而非独立应用
- **交付物**：Markdown 结构化文档（研讨记录 + 提案结论）
- **方法论内核**：TOC（约束理论）五步思考过程

### 1.2 不是什么

- ❌ 不是一个独立的 Web 服务或 SaaS 平台
- ❌ 不是 CoPaw 的二次开发（不改框架代码）
- ❌ 不需要编写 Python 代码——所有交付物都是 Markdown

### 1.3 战略来源

| 来源 | 内容 |
|------|------|
| 领先2035工作坊 | 完成了 TOC 五步法全流程研讨，形成完整方法论 |
| 攀师傅小会决议 (2026-04-06) | 路线 A 优先启动：沈攀做甲方，3-4 天完成，基于小龙虾架构 |

### 1.4 核心原则

1. **AI 是队友不是工具**——Agent 有 Soul、Memory、Skill
2. **自进化机制 > 工程化打补丁**——给示范 → 校准 → 形成 Skill → 不断迭代
3. **有效性 > 完备性 > 严谨性**——不要在中间步骤上过度工程化
4. **人类的核心工作只有两件事**：输入 Context 和 Taste

---

## 二、架构设计

### 2.1 CoPaw 多智能体定位

`mafia-expert` 作为 CoPaw 中的独立专家智能体：

```
~/.copaw/
├── config.json                    # 全局配置 (LLM providers)
└── workspaces/
    ├── default/                   # 默认智能体（日常助手）
    └── mafia-expert/              # 黑手党提案专家智能体
        ├── agent.json             # Agent 专属配置
        ├── AGENTS.md              # 人设 + TOC 方法论注入
        ├── MEMORY.md              # 长期记忆（偏好、品味）
        ├── HEARTBEAT.md           # 自指迭代 + 自动更新触发器
        ├── active_skills/         # 已激活的 Skills
        │   ├── ude_diagnosis/SKILL.md
        │   ├── conflict_cloud/SKILL.md
        │   ├── convention_breaker/SKILL.md
        │   ├── negative_branch/SKILL.md
        │   └── proposal_assembler/SKILL.md
        ├── memory/                # ReMe 每日日志（自动生成）
        ├── cases/                 # 案例输出（迭代素材）
        └── iteration_reports/     # 自指迭代报告
```

### 2.2 隔离保证

| 维度 | 隔离方式 | CoPaw 机制 |
|------|---------|-----------|
| 人设 | 独立 AGENTS.md | 多智能体工作区物理隔离 |
| 记忆 | 独立 MEMORY.md + memory/ | ReMe 按 workspace 隔离 |
| 技能 | 独立 active_skills/ | per-agent 技能开关 |
| 工具 | 独立 MCP 客户端配置 | agent.json 中 mcpClients |
| 对话 | 独立 chats.json | per-agent 会话存储 |

### 2.3 三层自指迭代闭环

#### 第一层：个人 Agent 自我迭代（CoPaw 原生）

- **触发**：每次对话自动 + 每周 Heartbeat 回顾
- **机制**：ReMe 自动将对话总结写入 `memory/YYYY-MM-DD.md`
- **产物**：更精准的个人品味和经验（私有 MEMORY.md）
- **范围**：单个用户实例内部

#### 第二层：Skill 自指迭代（核心闭环）

- **触发**：本地 Agent 心跳反思中识别出方法论缺陷（非个人经验问题）
- **上行**：生成 `iteration_report` → `git push` 到共享仓库
- **策展**：服务器 `skill-curator` Agent 汇总 reports → 起草 Skill 修改
- **审批**：核心方法论变更等人工审批；表述澄清自动合并
- **产物**：更好的 AGENTS.md / Skills（共享资产）

#### 第三层：自动分发

- **触发**：每个用户的 mafia-expert Heartbeat 每日检查
- **机制**：`git fetch` → 有新 commit → `git pull` → 更新本地 Skill
- **通知**：下次对话开头告知用户"方法论已更新到 vX.Y"
- **产物**：所有用户同步到最新版

---

## 三、部署策略

### 3.1 三角色 × 三安装方式

| 角色 | 安装方式 | 原因 |
|------|---------|------|
| **用户**（沈攀、赵蕾等） | CoPaw 桌面应用 | 零配置，双击运行 |
| **服务器**（ECS skill-curator） | Docker `agentscope/copaw:latest` | 24/7 运行，环境隔离 |
| **开发者**（李东方） | Script 安装 (`curl ... \| bash`) | 频繁编辑测试、Git 推送 |

### 3.2 Git 仓库结构

```
黑手党提案/
├── docs/                            # 原始研讨材料（只读参考）
│   └── 在线工作坊 - 研讨文档.md
├── agent/                           # ← 产品核心资产
│   ├── AGENTS.md                    # 人设 + 方法论注入
│   ├── agent.json                   # Agent 配置
│   ├── HEARTBEAT.md                 # 三层迭代触发器
│   ├── skills/                      # Skills 目录
│   │   ├── ude_diagnosis/SKILL.md
│   │   ├── conflict_cloud/SKILL.md
│   │   ├── convention_breaker/SKILL.md
│   │   ├── negative_branch/SKILL.md
│   │   └── proposal_assembler/SKILL.md
│   └── install.md                   # 安装指南
├── curator/                         # 服务器 curator Agent 配置
│   ├── AGENTS.md
│   └── HEARTBEAT.md
├── cases/                           # 案例库（测试套件）
├── iteration_reports/               # 迭代报告
├── CHANGELOG.md                     # 迭代日志
└── README.md
```

---

## 四、TOC 五步法方法论拆解

> 以下是 **mafia-expert Agent 必须严格执行的完整流程**。
> 每个步骤对应一个 Skill，Agent 按顺序引导用户完成。

### 阶段 A：研讨准备（粗共识）

#### 准备1：让用户秒懂"黑手党提案"

**Skill**：内置在 AGENTS.md 中（无需独立 Skill）

**Agent 动作**：
1. 用类比引入概念（电影《教父》"你没有任何拒绝的理由"）
2. 给出概念定义（三层次）：
   - **定义**：帮助客户打破重大限制，让其无法拒绝的方案。通过非共识的创新方式实现双赢
   - **内涵**：不是痛点挖掘，而是打破行业惯例；不直接解决问题，而是让问题变得无关紧要
   - **外延**：与"痛点""需求""传统方案"的区别
3. 提供秒懂案例（至少 3 个）

**参考案例库**（内置于 AGENTS.md）：

| 案例 | 打破的惯例 | 企业获益 | 用户获益 |
|------|----------|---------|---------|
| 苹果手机 | 手机必须有键盘 | 更高利润、市场主导 | 全触屏、更直观操作 |
| 胖东来按新鲜度卖鲜果 | 按外观大小定价 | 品牌忠诚、利润空间 | 合理价格买新鲜水果 |
| 小米手机 (2011) | 智能手机5000+ | 迅速扩大市场份额 | 1999元高质量手机 |
| 苹果 iPod | 盗版MP3或正版CD | 市场领导地位 | 小小设备3000+歌曲 |
| 360免费杀毒 | 杀毒软件收费 | 用户基数→增值盈利 | 免费高效杀毒 |

**输出**：用户对"黑手党提案"概念的共识确认

---

#### 准备2：识别双赢的两方

**Skill**：内置在 AGENTS.md 中

**Agent 动作**：引导用户填写 JTBD 四要素表

**输出模板**：

```markdown
| 维度 | 我方（企业） | 典型目标客户（DTB） |
|------|------------|-------------------|
| 1、客户画像 | [行业特征、企业特征] | [DTB 的行业/规模/特征] |
| 2、雇用产品 | [我方提供什么产品/服务] | [客户实际"雇用"我们做什么] |
| 3、待办任务 | [我方要完成的核心任务] | [客户要完成的核心任务] |
| 4、期望结果 | [我方期望的最终成果] | [客户期望的最终成果] |
```

**质量标准**：
- 客户画像必须具体到行业阶段、企业规模、创始人特征
- 期望结果必须可量化、可感知（"xx年后的利润=今天的营业额"）

---

#### 准备3：定义双赢——UDE 诊断

**Skill**：`ude_diagnosis/SKILL.md`

**Agent 动作**：
1. 引导用户列出所有 UDE（不良现状效果）
2. 对每条 UDE 进行 10 条标准校验
3. 从合格 UDE 中筛选最重要的 3 个
4. 识别恶性循环

**UDE 10 条标准**（Agent 必须逐条检查）：

| 序号 | 标准 | ✅ 合格示例 | ❌ 不合格示例 |
|------|------|-----------|-------------|
| 1 | 持续存在 | "业绩增长乏力" | "上个月销量下降"（一次性） |
| 2 | 当下正在发生 | "营销费用高" | "如果不改革就会……"（假设） |
| 3 | 描述状态 | "人才密度不够" | "应该招更多人"（动作） |
| 4 | 责任范围内 | "缺乏战略节奏" | "政策环境不好"（外部不可控） |
| 5 | 可以解决 | "缺科学管理会计" | "人性本恶"（无法解决） |
| 6 | 不归因于人 | "组织协调运转不畅" | "张三能力不行"（责怪个人） |
| 7 | 不分析原因 | "总体利润降低" | "因为成本太高所以利润低"（含原因） |
| 8 | 不是解决方案 | "核心岗位胜任力不足" | "需要引进外部人才"（隐藏方案） |
| 9 | 单独实体 | "主将缺位" | "主将缺位且人才密度不够"（两个实体） |
| 10 | 不是主观猜想 | "现金流不充裕" | "我觉得团队不够努力"（主观） |

**筛选最重要 3 个 UDE 的标准**（同时满足）：
1. 跟买我们的产品/用我们的服务有关（我们和同行导致了这个 UDE）
2. 这个 UDE 对客户至关重要，直接/间接影响了 70% 以上的其他 UDE

**恶性循环输出模板**：

```markdown
### 恶性循环 1
- [UDE-A] → [UDE-B] → [UDE-C] → [UDE-D] → 回到 [UDE-A]

### 恶性循环 2
- [UDE-X] → [UDE-Y] → [UDE-Z] → 回到 [UDE-X]
```

---

### 阶段 B：发现和打破惯例（方向性提案）

#### 步骤1：定义核心冲突

**Skill**：`conflict_cloud/SKILL.md`

**Agent 动作**：
1. 对筛选出的每个主要 UDE，构建冲突图（Evaporating Cloud）
2. 引导用户填写 O-B-D 结构
3. 合并多个 UDE 的冲突图

**冲突图构建规则**（Agent 内部逻辑）：
- UDE → DE（反转 UDE 为期望效果）
- DE 的必备条件 = D（只有做了 D，UDE 才会转化为 DE）
- 从 D 中找到矛盾行动（D1 vs D2）
- 转化 D 对应的 DE 为 B（需求）
- 推测 B 的共同目标 O（服从于系统目标的小目标）

**单个 UDE 冲突图模板**：

```markdown
| 维度 | 目标 | 需求 | 行动 | 检查 |
|------|------|------|------|------|
| UDE: [描述] | O: [系统目标] | B1: [需求1] | D1: [当前行动] | 当感受到UDE时的通常做法 |
|  |  | B2: [需求2] | D2: [期望行动] | D1和D2互斥 |
```

**互斥性校验**（Agent 必须确认）：
- 如果 D1，则不能 D2
- 如果 D2，则不能 D1
- 只有 D1，才能 B1；如果 D1，则不能 B2
- 只有 D2，才能 B2；如果 D2，则不能 B1

**合并冲突图模板**：

```markdown
| 合并UDE | O合并 | B1 | D1（当前行动） |
|---------|-------|----|--------------:|
|  |  | B2 | D2（期望行动） |
```

---

#### 步骤2：揭示冲突背后的惯例

**Skill**：`convention_breaker/SKILL.md`（前半段）

**Agent 动作**：
1. 针对合并冲突图，追问："为什么用户想要 B1 就一定得 D1？"
2. 用因果假设分析法（CLR）找到隐含假设
3. 从假设追溯到行业惯例
4. 验证惯例的有效性

**因果假设分析模板**：

```markdown
| 关键问题 | 假设 | 行业惯例 | 总结 |
|---------|------|---------|------|
| 为什么想要 B1 就必须 D1？ | [隐含假设1] | [对应的行业通常做法] | 如果遵循惯例1：[XX] |
| 检查：因为D1，同时[假设]，那么B1 | [隐含假设2] | [另一个行业做法] | 则用户只会D1不会D2 |
```

**惯例验证清单**（两个视角）：

```markdown
#### 我方视角验证
1. 惯例是不是行业内保护自身利益的"普遍做法"？
2. 惯例是否导致当下的恶性循环？
   - 因为：企业继续遵守惯例XX
   - 假设：同时，XX
   - 结果：恶性循环中 XX 将加剧

#### DTB（客户）视角验证
1. 补全 CCRT（核心冲突现实树）
2. 确认惯例直接导致主要 UDE（至少一个）
3. 确认惯例导致加剧了恶性循环
```

---

#### 步骤3：用例外激发方案

**Skill**：`convention_breaker/SKILL.md`（后半段）

**Agent 动作**：
1. 对每个惯例，找到"例外"（具体实例，而不是逻辑推演）
2. 从例外中提炼"打破惯例"的可行方案
3. 输出方向性提案总结

**方案激发模板**：

```markdown
| 改变的策略 | DTB目标 | 需求 | 行动 | 激发方案 |
|-----------|--------|------|------|---------|
| 惯例1: [名称] |  |  |  |  |
| 之所以D2无法B1，是因为假设：[XX] |  |  |  |  |
| 现有惯例做法=[XX]，对应D1 | O: [XX] | B1: [XX] | D1: [XX] | 例外是：[具体实例] |
| 打破惯例做法=[XX]，对应D2 |  | B2: [XX] | D2: [XX] | 可以尝试：[XX] |
```

**方向性提案总结格式**（Agent 必须输出）：

```markdown
### 方向性提案总结

> 通过 D [具体行动]，满足 B [具体需求]；
> 同时通过 D' [具体行动]，满足 B' [具体需求]；
> 使 DTB 既可以 O1 [目标1]，又能够 O2 [目标2]。
```

---

### 阶段 C：激发和完善方案（操作性提案）

#### 步骤4：消除负面分支

**Skill**：`negative_branch/SKILL.md`

**Agent 动作**：
1. 列出实施新方案后可能新增的所有 UDE
2. 筛选出"直接危害现有 B"且"客户感受强"的 UDE
3. 对每个危害性 UDE，构建因果假设链（从方案 D → 中间结果 → 最终 UDE）
4. 在因果链中找到 UDE 转为 DE 的节点，补充打破假设的方案

**新增 UDE 发散清单**（Agent 引导用户思考）：
- 协同复杂度增加
- 考核边界不清晰
- 管理复杂度增加
- 局部效率降低
- 结果不确定性高
- 不适应新思维模式
- 认知负担加重
- 决策难度提升 / 决策慢
- 对人才要求高
- 其他……

**危害性筛选标准**（同时满足）：
1. 直接危害现有任一 B（需求）
2. 客户感受强

**危害性筛选输出模板**：

```markdown
| 被危害的 B | 新增 UDE |
|-----------|---------|
| B1: [需求描述] | [新UDE描述] |
| B2: [需求描述] | [新UDE描述] |
```

**因果假设链分析模板**（每个危害性 UDE 一份）：

```markdown
|  | 因果假设链 |  | 性质 |
|--|-----------|--|------|
| 结果 | 最终结果：[UDE] |  | UDE |
| 过程 | 中间结果3：[XX] | 假设：[XX] | UDE |
|  | 中间结果2：[XX] | 假设：[XX] | UDE |
|  |  |  | **打破假设的方案：[XX]** |
|  | 中间结果1：[XX] | 假设：[XX] | DE |
| 方案 | D：[新方案] | 假设：[前提条件] |  |
```

**节点补充验证模板**（确认 UDE→DE 转换有效）：

```markdown
| 如果： | D [具体方案] |
|--------|-------------|
| 同时： | 假设 [前提条件] |
| 那么： | UDE变成DE：[原UDE] 变成 [新DE] |
| 并且那么： | 现有DE没有转变为UDE |
```

---

#### 步骤5：确立新规则、匹配新能力

**Skill**：`proposal_assembler/SKILL.md`

**Agent 动作**：
1. 对比打破惯例前后，确立新规则（新惯例）
2. 梳理剩余未解决的原 UDE + 新方案导致的新 UDE
3. 为每个 UDE→DE 的转换，匹配所需的运营能力
4. 输出产品说明书

**运营能力匹配分类**：

| 分类 | 逻辑 | 示例 |
|------|------|------|
| 原 UDE 不会转化为 DE，除非…… | 原有问题需要额外能力才能解决 | 主将缺位 → Build/Borrow/Buy |
| 新方案导致新 UDE，除非…… | 新方案的副作用需要配套能力 | 协同复杂度增加 → 聚焦瓶颈问题 |

**运营能力匹配输出模板**：

```markdown
| 分类 | 期望改变的结果 | 运营能力（新增能力） |
|------|-------------|-------------------|
| 原UDE → DE | 原UDE1: [描述] | [对应运营能力] |
|  | 原UDE2: [描述] | [对应运营能力] |
| 新方案 → 新UDE → DE | 新UDE1: [描述] | [对应运营能力] |
|  | 新UDE2: [描述] | [对应运营能力] |
```

**产品说明书输出模板**：

```markdown
| 产品单元 | 运营能力（改变UDE为DE） | 运营能力（维持DE） |
|---------|---------------------|------------------|
| [产品/服务1] | [新增能力描述] | [维护能力描述] |
| [产品/服务2] | [新增能力描述] | [维护能力描述] |
```

---

## 五、最终交付物模板

Agent 完成五步法后，必须输出以下完整 Markdown 文档：

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

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

---

## 一、双赢定义

### 1.1 概念共识
[对黑手党提案概念的共识描述]

### 1.2 JTBD 四要素

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

---

## 二、UDE 诊断

### 2.1 完整 UDE 清单
[编号列表，每条 UDE 标注是否通过 10 条标准]

### 2.2 最重要的 3 个 UDE
1. [UDE-1]：[选择理由]
2. [UDE-2]：[选择理由]
3. [UDE-3]：[选择理由]

### 2.3 恶性循环
[循环图描述]

---

## 三、核心冲突

### 3.1 各 UDE 冲突图
[每个 UDE 的 O-B-D 表]

### 3.2 合并冲突图
[合并后的 O-B1-D1 vs B2-D2]

---

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

### 4.1 行业惯例清单
[每个惯例的因果假设分析]

### 4.2 惯例验证
[我方视角 + DTB 视角验证结果]

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

---

## 五、操作性提案

### 5.1 负面分支消除
[每个危害性 UDE 的因果假设链 + 打破假设方案]

### 5.2 新规则与新能力

| 分类 | 期望改变 | 运营能力 |
|------|--------|---------|
| ... | ... | ... |

### 5.3 产品说明书
[产品单元 × 运营能力矩阵]

---

## 附录

### A. 数据来源与证据链
### B. 研讨过程记录
### C. 方法论版本与迭代日志
```

---

## 六、验证计划

### 6.1 方法论完整性验证

| 检查项 | 验证方式 |
|--------|---------|
| 五步法每步都有输出 | 对照最终交付物模板逐章检查 |
| UDE 10 条标准无遗漏 | 抽查 3 条 UDE 逐标准验证 |
| 冲突图互斥性成立 | 检查 D1/D2 是否真正互斥 |
| 惯例有行业证据支撑 | 至少 2 个独立来源 |
| 负面分支全部消解 | 每个新 UDE 都有打破假设方案 |
| 运营能力可执行 | DTB 确认具备或可获取该能力 |

### 6.2 Agent 能力验证

| 测试项 | 方法 | 通过标准 |
|--------|------|---------|
| 首次案例完整度 | 用"天维美跨境保健品"触发全流程 | 输出文档覆盖所有章节 |
| UDE 标准执行力 | 故意输入不合格 UDE，观察 Agent 的纠正 | Agent 能指出具体违反哪条标准 |
| 冲突图逻辑性 | 检查 O-B-D 关系链的因果自洽性 | 无循环论证、无逻辑跳跃 |
| 惯例非臆测 | 检查惯例是否来自行业事实而非 Agent 编造 | 每个惯例可追溯到真实行业做法 |
| 迭代闭环 | 跑完首案后触发 Heartbeat，检查 iteration_report | 报告能区分"个人经验"和"方法论缺陷" |

### 6.3 里程碑

| 阶段 | 交付物 | 预计时间 |
|------|--------|---------|
| M1 | AGENTS.md + 5 个 SKILL.md 初稿 | Day 1-2 |
| M2 | 首个案例（天维美）完整跑通 | Day 2-3 |
| M3 | 根据首案反馈修订 Skills v0.2 | Day 3 |
| M4 | HEARTBEAT.md + curator 配置 + install.md | Day 3-4 |
| M5 | 沈攀交叉验证 + 方法论 v1.0 定稿 | Day 4-5 |