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 四要素表

输出模板：

| 维度 | 我方（企业） | 典型目标客户（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

恶性循环输出模板：

### 恶性循环 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 冲突图模板：

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

互斥性校验（Agent 必须确认）：

• 如果 D1，则不能 D2
• 如果 D2，则不能 D1
• 只有 D1，才能 B1；如果 D1，则不能 B2
• 只有 D2，才能 B2；如果 D2，则不能 B1

合并冲突图模板：

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

---

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

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

Agent 动作：

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

因果假设分析模板：

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

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

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

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

---

步骤3：用例外激发方案

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

Agent 动作：

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

方案激发模板：

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

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

### 方向性提案总结

> 通过 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. 客户感受强

危害性筛选输出模板：

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

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

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

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

| 如果： | 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，除非……	新方案的副作用需要配套能力	协同复杂度增加 → 聚焦瓶颈问题

运营能力匹配输出模板：

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

产品说明书输出模板：

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

---

五、最终交付物模板

Agent 完成五步法后，必须输出以下完整 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