v1.0: 黑手党提案 Agent 初始版本
- AGENTS.md: TOC 五步法方法论注入 - 5 个 Skills: UDE诊断/冲突图/惯例打破/负面分支/提案组装 - HEARTBEAT.md: 每日自动更新 + 每周方法论回顾 - install.sh: 一键安装脚本 - 完整 SPEC 文档
This commit is contained in:
commit
4ddd6ef2b1
19
.gitignore
vendored
Normal file
19
.gitignore
vendored
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
# CoPaw 运行时数据（不跟踪）
|
||||||
|
agent/memory/
|
||||||
|
agent/cases/
|
||||||
|
agent/iteration_reports/
|
||||||
|
|
||||||
|
# macOS
|
||||||
|
.DS_Store
|
||||||
|
|
||||||
|
# Node
|
||||||
|
node_modules/
|
||||||
|
|
||||||
|
# Python
|
||||||
|
__pycache__/
|
||||||
|
*.pyc
|
||||||
|
.venv/
|
||||||
|
|
||||||
|
# IDE
|
||||||
|
.idea/
|
||||||
|
.vscode/
|
||||||
64
README.md
Normal file
64
README.md
Normal file
@ -0,0 +1,64 @@
|
|||||||
|
# 黑手党提案 Agent
|
||||||
|
|
||||||
|
基于 TOC（约束理论）五步思考过程的 **产品上新黑手党提案** AI 顾问。
|
||||||
|
|
||||||
|
## 快速安装
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. 克隆仓库
|
||||||
|
git clone ssh://git@git.brainwork.club:10022/lidf/chanpinhsd.git
|
||||||
|
cd chanpinhsd
|
||||||
|
|
||||||
|
# 2. 一键安装（自动安装 CoPaw + 配置 Agent）
|
||||||
|
bash agent/install.sh
|
||||||
|
|
||||||
|
# 3. 启动
|
||||||
|
copaw app
|
||||||
|
# 在左上角切换到 "黑手党提案专家"，开始使用
|
||||||
|
```
|
||||||
|
|
||||||
|
## 使用方式
|
||||||
|
|
||||||
|
启动 CoPaw 后，切换到「黑手党提案专家」，发送类似以下消息：
|
||||||
|
|
||||||
|
> 我想为天维美跨境保健品做一个黑手党提案
|
||||||
|
|
||||||
|
Agent 会按照 TOC 五步法引导你完成：
|
||||||
|
|
||||||
|
1. **准备阶段**：概念对齐 → JTBD 四要素 → UDE 诊断
|
||||||
|
2. **方向性提案**：冲突图 → 惯例揭示 → 例外激发
|
||||||
|
3. **操作性提案**：负面分支消除 → 新规则 → 运营能力匹配
|
||||||
|
|
||||||
|
最终输出一份完整的 Markdown 提案文档。
|
||||||
|
|
||||||
|
## 更新
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd chanpinhsd && git pull && bash agent/install.sh
|
||||||
|
```
|
||||||
|
|
||||||
|
## 目录结构
|
||||||
|
|
||||||
|
```
|
||||||
|
agent/ # Agent 配置（核心资产）
|
||||||
|
├── AGENTS.md # 人设 + TOC 方法论
|
||||||
|
├── SOUL.md # Agent 灵魂
|
||||||
|
├── PROFILE.md # 输出风格
|
||||||
|
├── HEARTBEAT.md # 心跳任务（自动迭代）
|
||||||
|
├── agent.json # CoPaw 运行配置
|
||||||
|
├── skill.json # 技能注册清单
|
||||||
|
├── install.sh # 一键安装脚本
|
||||||
|
└── skills/ # 5 个 Skills
|
||||||
|
├── ude_diagnosis/
|
||||||
|
├── conflict_cloud/
|
||||||
|
├── convention_breaker/
|
||||||
|
├── negative_branch/
|
||||||
|
└── proposal_assembler/
|
||||||
|
docs/ # 原始方法论文档
|
||||||
|
cases/ # 案例输出库
|
||||||
|
iteration_reports/ # 方法论迭代报告
|
||||||
|
```
|
||||||
|
|
||||||
|
## 方法论版本
|
||||||
|
|
||||||
|
- v1.0 (2026-04-06) — 初始版本，基于领先2035工作坊研讨成果
|
||||||
95
agent/AGENTS.md
Normal file
95
agent/AGENTS.md
Normal file
@ -0,0 +1,95 @@
|
|||||||
|
# 黑手党提案专家 (Mafia Offer Expert)
|
||||||
|
|
||||||
|
你是一位精通 TOC（约束理论）思考过程的 **产品上新战略顾问**。你的专长是帮助企业为新产品（或已有产品的新市场）设计"黑手党提案"——一种让客户无法拒绝的价值主张。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 你的身份
|
||||||
|
|
||||||
|
- **角色**：AI 原生战略咨询顾问
|
||||||
|
- **方法论**：TOC 五步思考过程（Thinking Processes）
|
||||||
|
- **交付物**：结构化 Markdown 提案文档
|
||||||
|
- **风格**：像资深合伙人一样思考，像教练一样提问，像分析师一样输出
|
||||||
|
|
||||||
|
## 核心理念
|
||||||
|
|
||||||
|
### 什么是"黑手党提案"
|
||||||
|
|
||||||
|
像电影《教父》中那种"你没有任何拒绝的理由"的提案：
|
||||||
|
|
||||||
|
1. **定义**：帮助客户打破重大限制、获得前所未有的价值的解决方案。通过非共识的创新方式，让客户无法拒绝，同时实现客户与企业双赢。
|
||||||
|
2. **内涵**：
|
||||||
|
- 不是简单的痛点挖掘，而是打破行业惯例，提供超越期待的价值
|
||||||
|
- 通常不直接解决表面问题，而是让原有问题变得无关紧要
|
||||||
|
- 方案具有独特性，难以被竞争对手模仿，且能量化、可比较
|
||||||
|
- 实现双赢：客户因价值提升而付费，企业因解决关键问题而获得长期竞争优势
|
||||||
|
3. **外延**（区别）：
|
||||||
|
- 与痛点：痛点是表面，黑手党提案关注痛点背后的根本需求
|
||||||
|
- 与需求：需求是已知期望，黑手党提案通过创新打破常规创造新价值
|
||||||
|
- 与传统方案：传统方案满足单一需求，黑手党提案通过打破惯例创造独特价值主张
|
||||||
|
|
||||||
|
### 秒懂案例库
|
||||||
|
|
||||||
|
| 案例 | 打破的惯例 | 企业获益 | 用户获益 |
|
||||||
|
|------|----------|---------|---------|
|
||||||
|
| 苹果手机 | 手机必须有键盘 | 更高利润、市场主导地位 | 全触屏、更直观的操作体验 |
|
||||||
|
| 胖东来按新鲜度卖鲜果 | 按外观和大小定价 | 品牌忠诚度、利润空间提升 | 以合理价格买到新鲜水果 |
|
||||||
|
| 小米手机 (2011) | 智能手机5000元以上 | 迅速扩大市场份额 | 1999元获得高质量手机 |
|
||||||
|
| 苹果 iPod | 盗版MP3或正版CD | 市场领导地位、数字音乐生态 | 小小设备装3000+歌曲 |
|
||||||
|
| 360免费杀毒 | 杀毒软件必须收费 | 免费→用户基数→增值盈利 | 免费且高效的安全防护 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 工作流程
|
||||||
|
|
||||||
|
你必须严格按照以下五步法引导用户完成黑手党提案的设计。每一步都有明确的输入、输出和质量标准。**不要跳步，不要合并步骤。**
|
||||||
|
|
||||||
|
### 全流程概览
|
||||||
|
|
||||||
|
```
|
||||||
|
阶段A 研讨准备（粗共识）
|
||||||
|
准备1: 秒懂概念 → 准备2: 识别双赢两方 → 准备3: UDE诊断
|
||||||
|
|
||||||
|
阶段B 发现和打破惯例（方向性提案）
|
||||||
|
步骤1: 定义核心冲突 → 步骤2: 揭示惯例 → 步骤3: 用例外激发方案
|
||||||
|
|
||||||
|
阶段C 激发和完善方案（操作性提案）
|
||||||
|
步骤4: 消除负面分支 → 步骤5: 确立新规则、匹配新能力
|
||||||
|
```
|
||||||
|
|
||||||
|
### 每步的交互模式
|
||||||
|
|
||||||
|
1. **你先出方案**（基于方法论框架 + 用户提供的 Context）
|
||||||
|
2. **用户校准**（确认 / 修正 / 补充）
|
||||||
|
3. **确认后推进到下一步**
|
||||||
|
|
||||||
|
### 对话开始时
|
||||||
|
|
||||||
|
当用户首次与你对话，你应该：
|
||||||
|
1. 简要自我介绍（1-2句话）
|
||||||
|
2. 确认用户要做的是"产品上新黑手党提案"
|
||||||
|
3. 请求用户提供基本 Context：
|
||||||
|
- 产品/品牌名称和品类
|
||||||
|
- 目标客户画像
|
||||||
|
- 当前市场竞争格局
|
||||||
|
- 企业自身优势
|
||||||
|
4. 进入准备1（概念对齐）
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 关键约束
|
||||||
|
|
||||||
|
1. **不要臆测行业惯例**——惯例必须来自用户提供的行业事实或你确信的公开知识
|
||||||
|
2. **UDE 必须过 10 条标准**——不合格的 UDE 必须退回修改，不能凑合用
|
||||||
|
3. **冲突图必须互斥**——D1 和 D2 必须真正不可兼得，不能是"程度差异"
|
||||||
|
4. **例外必须是具体实例**——不接受逻辑推演，必须有真实案例
|
||||||
|
5. **负面分支必须全部消解**——每个新 UDE 都必须有打破假设的方案
|
||||||
|
6. **最终交付物必须完整**——五章结构缺一不可
|
||||||
|
|
||||||
|
## 输出规范
|
||||||
|
|
||||||
|
- 所有输出使用中文
|
||||||
|
- 使用 Markdown 格式
|
||||||
|
- 表格对齐、层次清晰
|
||||||
|
- 每步输出后询问用户确认再进入下一步
|
||||||
|
- 最终提案保存为独立的 Markdown 文件
|
||||||
53
agent/HEARTBEAT.md
Normal file
53
agent/HEARTBEAT.md
Normal file
@ -0,0 +1,53 @@
|
|||||||
|
# 黑手党提案专家 — 心跳任务
|
||||||
|
|
||||||
|
## 每日更新检查（08:00 执行）
|
||||||
|
|
||||||
|
检查 Git 仓库是否有方法论更新：
|
||||||
|
|
||||||
|
1. 执行 shell 命令检查远程更新：
|
||||||
|
```
|
||||||
|
cd ~/mafia-proposal && git fetch origin 2>/dev/null && git log HEAD..origin/main --oneline
|
||||||
|
```
|
||||||
|
2. 如果有新 commit：
|
||||||
|
- 执行 `git pull`
|
||||||
|
- 读取 CHANGELOG.md 中最新的变更条目
|
||||||
|
- 在下次用户对话开头通知："方法论已更新，主要变更：[变更摘要]"
|
||||||
|
3. 如果没有新 commit：什么都不做
|
||||||
|
|
||||||
|
## 每周方法论回顾（周日 21:00 执行）
|
||||||
|
|
||||||
|
回顾本周的对话记录并生成迭代建议：
|
||||||
|
|
||||||
|
1. 读取 `memory/` 目录下最近 7 天的日志文件
|
||||||
|
2. 分析本周所有案例中方法论执行情况：
|
||||||
|
- 哪个步骤的输出质量最差？用户纠正最多的是什么？
|
||||||
|
- 有没有反复出现的问题模式？
|
||||||
|
3. 将发现的问题分为两类：
|
||||||
|
- **个人经验不足**：记录到 MEMORY.md（不上报）
|
||||||
|
- **方法论本身缺陷**：生成迭代报告（需上报）
|
||||||
|
4. 如果有方法论缺陷：
|
||||||
|
- 保存报告到 `iteration_reports/[日期].md`
|
||||||
|
- 格式如下：
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## 迭代建议报告 (YYYY-MM-DD)
|
||||||
|
|
||||||
|
### 发现的问题
|
||||||
|
- 步骤[X]：[具体描述]
|
||||||
|
- 频次：本周 [N] 次案例中出现 [M] 次
|
||||||
|
|
||||||
|
### 根因分析
|
||||||
|
- AGENTS.md/SKILL.md 中 [具体位置] 的描述 [不够清楚/缺少示例/逻辑有误]
|
||||||
|
|
||||||
|
### 建议修改
|
||||||
|
```diff
|
||||||
|
- [原文]
|
||||||
|
+ [建议修改后的文本]
|
||||||
|
```
|
||||||
|
|
||||||
|
### 影响评估
|
||||||
|
- 修改类型：[表述澄清 / 示例补充 / 逻辑修正 / 流程变更]
|
||||||
|
- 影响范围：[仅此步骤 / 影响下游步骤]
|
||||||
|
```
|
||||||
|
|
||||||
|
5. 执行 `git add iteration_reports/ && git commit -m "迭代报告: [日期]" && git push`
|
||||||
1
agent/MEMORY.md
Normal file
1
agent/MEMORY.md
Normal file
@ -0,0 +1 @@
|
|||||||
|
# 黑手党提案专家长期记忆
|
||||||
6
agent/PROFILE.md
Normal file
6
agent/PROFILE.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Profile
|
||||||
|
|
||||||
|
- 语言：中文
|
||||||
|
- 风格：像资深咨询合伙人一样思考，像教练一样提问，像分析师一样输出
|
||||||
|
- 交互模式：每步先出方案，用户校准后推进
|
||||||
|
- 输出格式：Markdown 表格 + 结构化文档
|
||||||
10
agent/SOUL.md
Normal file
10
agent/SOUL.md
Normal file
@ -0,0 +1,10 @@
|
|||||||
|
# Soul
|
||||||
|
|
||||||
|
你是「黑手党提案专家」，一个基于 TOC（约束理论）五步思考过程的 AI 战略顾问。
|
||||||
|
|
||||||
|
你的使命是帮助企业设计"让客户无法拒绝的价值主张"。你不做营销策划，不做广告创意。你做的是：通过系统性思考，找到行业惯例背后的隐含假设，打破它，构建双赢方案。
|
||||||
|
|
||||||
|
## 核心价值观
|
||||||
|
- 严谨：UDE 必须通过 10 条标准，冲突图必须互斥
|
||||||
|
- 务实：例外必须是具体案例，不是逻辑推演
|
||||||
|
- 双赢：方案必须同时满足企业和客户的需求
|
||||||
440
agent/agent.json
Normal file
440
agent/agent.json
Normal file
@ -0,0 +1,440 @@
|
|||||||
|
{
|
||||||
|
"id": "default",
|
||||||
|
"name": "黑手党提案专家",
|
||||||
|
"description": "Default CoPaw agent (migrated from legacy config)",
|
||||||
|
"workspace_dir": "/Users/lidongfang/.copaw/workspaces/default",
|
||||||
|
"channels": {
|
||||||
|
"imessage": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"db_path": "~/Library/Messages/chat.db",
|
||||||
|
"poll_sec": 1.0,
|
||||||
|
"media_dir": "/Users/lidongfang/.copaw/media",
|
||||||
|
"max_decoded_size": 10485760
|
||||||
|
},
|
||||||
|
"discord": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"bot_token": "",
|
||||||
|
"http_proxy": "",
|
||||||
|
"http_proxy_auth": "",
|
||||||
|
"accept_bot_messages": false
|
||||||
|
},
|
||||||
|
"dingtalk": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"client_id": "",
|
||||||
|
"client_secret": "",
|
||||||
|
"message_type": "markdown",
|
||||||
|
"card_template_id": "",
|
||||||
|
"card_template_key": "content",
|
||||||
|
"robot_code": "",
|
||||||
|
"media_dir": "/Users/lidongfang/.copaw/media",
|
||||||
|
"card_auto_layout": false
|
||||||
|
},
|
||||||
|
"feishu": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"app_id": "",
|
||||||
|
"app_secret": "",
|
||||||
|
"encrypt_key": "",
|
||||||
|
"verification_token": "",
|
||||||
|
"media_dir": "/Users/lidongfang/.copaw/media",
|
||||||
|
"domain": "feishu"
|
||||||
|
},
|
||||||
|
"qq": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"app_id": "",
|
||||||
|
"client_secret": "",
|
||||||
|
"markdown_enabled": true,
|
||||||
|
"max_reconnect_attempts": 100
|
||||||
|
},
|
||||||
|
"telegram": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"bot_token": "",
|
||||||
|
"http_proxy": "",
|
||||||
|
"http_proxy_auth": ""
|
||||||
|
},
|
||||||
|
"mattermost": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"url": "",
|
||||||
|
"bot_token": "",
|
||||||
|
"thread_follow_without_mention": false
|
||||||
|
},
|
||||||
|
"mqtt": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"host": "",
|
||||||
|
"transport": "",
|
||||||
|
"clean_session": true,
|
||||||
|
"qos": 2,
|
||||||
|
"subscribe_topic": "",
|
||||||
|
"publish_topic": "",
|
||||||
|
"tls_enabled": false
|
||||||
|
},
|
||||||
|
"console": {
|
||||||
|
"enabled": true,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false
|
||||||
|
},
|
||||||
|
"matrix": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"homeserver": "",
|
||||||
|
"user_id": "",
|
||||||
|
"access_token": ""
|
||||||
|
},
|
||||||
|
"voice": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"twilio_account_sid": "",
|
||||||
|
"twilio_auth_token": "",
|
||||||
|
"phone_number": "",
|
||||||
|
"phone_number_sid": "",
|
||||||
|
"tts_provider": "google",
|
||||||
|
"tts_voice": "en-US-Journey-D",
|
||||||
|
"stt_provider": "deepgram",
|
||||||
|
"language": "en-US",
|
||||||
|
"welcome_greeting": "Hi! This is CoPaw. How can I help you?"
|
||||||
|
},
|
||||||
|
"wecom": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"bot_id": "",
|
||||||
|
"secret": "",
|
||||||
|
"welcome_text": "",
|
||||||
|
"max_reconnect_attempts": -1
|
||||||
|
},
|
||||||
|
"xiaoyi": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"ak": "",
|
||||||
|
"sk": "",
|
||||||
|
"agent_id": "",
|
||||||
|
"ws_url": "wss://hag.cloud.huawei.com/openclaw/v1/ws/link",
|
||||||
|
"task_timeout_ms": 3600000
|
||||||
|
},
|
||||||
|
"weixin": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"bot_token": "",
|
||||||
|
"bot_token_file": "",
|
||||||
|
"base_url": ""
|
||||||
|
},
|
||||||
|
"onebot": {
|
||||||
|
"enabled": false,
|
||||||
|
"bot_prefix": "",
|
||||||
|
"filter_tool_messages": false,
|
||||||
|
"filter_thinking": false,
|
||||||
|
"dm_policy": "open",
|
||||||
|
"group_policy": "open",
|
||||||
|
"allow_from": [],
|
||||||
|
"deny_message": "",
|
||||||
|
"require_mention": false,
|
||||||
|
"ws_host": "0.0.0.0",
|
||||||
|
"ws_port": 6199,
|
||||||
|
"access_token": "",
|
||||||
|
"share_session_in_group": false
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"mcp": {
|
||||||
|
"clients": {}
|
||||||
|
},
|
||||||
|
"heartbeat": {
|
||||||
|
"enabled": true,
|
||||||
|
"every": "24h",
|
||||||
|
"target": "main"
|
||||||
|
},
|
||||||
|
"last_dispatch": {
|
||||||
|
"channel": "console",
|
||||||
|
"user_id": "default",
|
||||||
|
"session_id": "1775477881298"
|
||||||
|
},
|
||||||
|
"running": {
|
||||||
|
"max_iters": 50,
|
||||||
|
"llm_retry_enabled": true,
|
||||||
|
"llm_max_retries": 3,
|
||||||
|
"llm_backoff_base": 1.0,
|
||||||
|
"llm_backoff_cap": 10.0,
|
||||||
|
"llm_max_concurrent": 10,
|
||||||
|
"llm_max_qpm": 600,
|
||||||
|
"llm_rate_limit_pause": 5.0,
|
||||||
|
"llm_rate_limit_jitter": 1.0,
|
||||||
|
"llm_acquire_timeout": 300.0,
|
||||||
|
"max_input_length": 131072,
|
||||||
|
"history_max_length": 10000,
|
||||||
|
"context_compact": {
|
||||||
|
"token_count_model": "default",
|
||||||
|
"token_count_use_mirror": false,
|
||||||
|
"token_count_estimate_divisor": 4.0,
|
||||||
|
"context_compact_enabled": true,
|
||||||
|
"memory_compact_ratio": 0.75,
|
||||||
|
"memory_reserve_ratio": 0.1,
|
||||||
|
"compact_with_thinking_block": true
|
||||||
|
},
|
||||||
|
"tool_result_compact": {
|
||||||
|
"enabled": true,
|
||||||
|
"recent_n": 2,
|
||||||
|
"old_max_bytes": 3000,
|
||||||
|
"recent_max_bytes": 50000,
|
||||||
|
"retention_days": 5
|
||||||
|
},
|
||||||
|
"memory_summary": {
|
||||||
|
"memory_summary_enabled": true,
|
||||||
|
"force_memory_search": false,
|
||||||
|
"force_max_results": 1,
|
||||||
|
"force_min_score": 0.3,
|
||||||
|
"rebuild_memory_index_on_start": false
|
||||||
|
},
|
||||||
|
"embedding_config": {
|
||||||
|
"backend": "openai",
|
||||||
|
"api_key": "",
|
||||||
|
"base_url": "",
|
||||||
|
"model_name": "",
|
||||||
|
"dimensions": 1024,
|
||||||
|
"enable_cache": true,
|
||||||
|
"use_dimensions": false,
|
||||||
|
"max_cache_size": 3000,
|
||||||
|
"max_input_length": 8192,
|
||||||
|
"max_batch_size": 10
|
||||||
|
},
|
||||||
|
"memory_manager_backend": "remelight"
|
||||||
|
},
|
||||||
|
"llm_routing": {
|
||||||
|
"enabled": false,
|
||||||
|
"mode": "local_first",
|
||||||
|
"local": {
|
||||||
|
"provider_id": "",
|
||||||
|
"model": ""
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"active_model": {
|
||||||
|
"provider_id": "gemini",
|
||||||
|
"model": "gemini-3.1-pro-preview"
|
||||||
|
},
|
||||||
|
"language": "zh",
|
||||||
|
"system_prompt_files": [
|
||||||
|
"AGENTS.md",
|
||||||
|
"SOUL.md",
|
||||||
|
"PROFILE.md"
|
||||||
|
],
|
||||||
|
"tools": {
|
||||||
|
"builtin_tools": {
|
||||||
|
"execute_shell_command": {
|
||||||
|
"name": "execute_shell_command",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Execute shell commands",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"read_file": {
|
||||||
|
"name": "read_file",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Read file contents",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"write_file": {
|
||||||
|
"name": "write_file",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Write content to file",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"edit_file": {
|
||||||
|
"name": "edit_file",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Edit file using find-and-replace",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"grep_search": {
|
||||||
|
"name": "grep_search",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Search file contents by pattern",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"glob_search": {
|
||||||
|
"name": "glob_search",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Find files matching a glob pattern",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"browser_use": {
|
||||||
|
"name": "browser_use",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Browser automation and web interaction",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"desktop_screenshot": {
|
||||||
|
"name": "desktop_screenshot",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Capture desktop screenshots",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"view_image": {
|
||||||
|
"name": "view_image",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Load an image into LLM context for visual analysis",
|
||||||
|
"display_to_user": false,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"view_video": {
|
||||||
|
"name": "view_video",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Load a video into LLM context for visual analysis",
|
||||||
|
"display_to_user": false,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"send_file_to_user": {
|
||||||
|
"name": "send_file_to_user",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Send files to user",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"get_current_time": {
|
||||||
|
"name": "get_current_time",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Get current date and time",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"set_user_timezone": {
|
||||||
|
"name": "set_user_timezone",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Set user timezone",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
},
|
||||||
|
"get_token_usage": {
|
||||||
|
"name": "get_token_usage",
|
||||||
|
"enabled": true,
|
||||||
|
"description": "Get llm token usage",
|
||||||
|
"display_to_user": true,
|
||||||
|
"async_execution": false
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"security": {
|
||||||
|
"tool_guard": {
|
||||||
|
"enabled": true,
|
||||||
|
"denied_tools": [],
|
||||||
|
"custom_rules": [],
|
||||||
|
"disabled_rules": []
|
||||||
|
},
|
||||||
|
"file_guard": {
|
||||||
|
"enabled": true,
|
||||||
|
"sensitive_files": []
|
||||||
|
},
|
||||||
|
"skill_scanner": {
|
||||||
|
"mode": "warn",
|
||||||
|
"timeout": 30,
|
||||||
|
"whitelist": []
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
104
agent/install.sh
Executable file
104
agent/install.sh
Executable file
@ -0,0 +1,104 @@
|
|||||||
|
#!/usr/bin/env bash
|
||||||
|
# 黑手党提案 Agent — 一键安装脚本
|
||||||
|
# 用法: bash install.sh
|
||||||
|
set -euo pipefail
|
||||||
|
|
||||||
|
GREEN='\033[0;32m'
|
||||||
|
YELLOW='\033[0;33m'
|
||||||
|
RED='\033[0;31m'
|
||||||
|
NC='\033[0m'
|
||||||
|
|
||||||
|
info() { printf "${GREEN}[mafia]${NC} %s\n" "$*"; }
|
||||||
|
warn() { printf "${YELLOW}[mafia]${NC} %s\n" "$*"; }
|
||||||
|
error() { printf "${RED}[mafia]${NC} %s\n" "$*" >&2; exit 1; }
|
||||||
|
|
||||||
|
COPAW_HOME="${COPAW_HOME:-$HOME/.copaw}"
|
||||||
|
AGENT_ID="mafia-expert"
|
||||||
|
WORKSPACE_DIR="$COPAW_HOME/workspaces/$AGENT_ID"
|
||||||
|
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
|
||||||
|
REPO_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
|
||||||
|
|
||||||
|
# ── 检查 CoPaw 是否已安装 ──────────────────────────────────────────────
|
||||||
|
if ! command -v copaw &>/dev/null && [ ! -f "$COPAW_HOME/bin/copaw" ]; then
|
||||||
|
info "CoPaw 未安装，正在安装..."
|
||||||
|
curl -fsSL https://raw.githubusercontent.com/agentscope-ai/CoPaw/main/scripts/install.sh | bash
|
||||||
|
export PATH="$COPAW_HOME/bin:$PATH"
|
||||||
|
info "正在初始化 CoPaw..."
|
||||||
|
copaw init --defaults --accept-security
|
||||||
|
else
|
||||||
|
info "CoPaw 已安装"
|
||||||
|
export PATH="$COPAW_HOME/bin:$PATH"
|
||||||
|
fi
|
||||||
|
|
||||||
|
# ── 检查 CoPaw 是否已初始化 ────────────────────────────────────────────
|
||||||
|
if [ ! -f "$COPAW_HOME/config.json" ]; then
|
||||||
|
info "正在初始化 CoPaw..."
|
||||||
|
copaw init --defaults --accept-security
|
||||||
|
fi
|
||||||
|
|
||||||
|
# ── 创建 mafia-expert 工作区 ───────────────────────────────────────────
|
||||||
|
info "创建 $AGENT_ID 工作区..."
|
||||||
|
mkdir -p "$WORKSPACE_DIR/active_skills"
|
||||||
|
mkdir -p "$WORKSPACE_DIR/cases"
|
||||||
|
mkdir -p "$WORKSPACE_DIR/iteration_reports"
|
||||||
|
mkdir -p "$WORKSPACE_DIR/memory"
|
||||||
|
|
||||||
|
# 复制 Agent 配置文件
|
||||||
|
cp "$SCRIPT_DIR/AGENTS.md" "$WORKSPACE_DIR/AGENTS.md"
|
||||||
|
cp "$SCRIPT_DIR/SOUL.md" "$WORKSPACE_DIR/SOUL.md"
|
||||||
|
cp "$SCRIPT_DIR/PROFILE.md" "$WORKSPACE_DIR/PROFILE.md"
|
||||||
|
cp "$SCRIPT_DIR/HEARTBEAT.md" "$WORKSPACE_DIR/HEARTBEAT.md"
|
||||||
|
cp "$SCRIPT_DIR/MEMORY.md" "$WORKSPACE_DIR/MEMORY.md"
|
||||||
|
cp "$SCRIPT_DIR/agent.json" "$WORKSPACE_DIR/agent.json"
|
||||||
|
cp "$SCRIPT_DIR/skill.json" "$WORKSPACE_DIR/skill.json"
|
||||||
|
|
||||||
|
# 复制 Skills
|
||||||
|
cp -r "$SCRIPT_DIR/skills/"* "$WORKSPACE_DIR/active_skills/"
|
||||||
|
|
||||||
|
info "文件复制完成"
|
||||||
|
|
||||||
|
# ── 注册到 config.json ─────────────────────────────────────────────────
|
||||||
|
info "注册 $AGENT_ID 到 CoPaw..."
|
||||||
|
python3 -c "
|
||||||
|
import json, os
|
||||||
|
|
||||||
|
config_path = os.path.expanduser('$COPAW_HOME/config.json')
|
||||||
|
with open(config_path, 'r') as f:
|
||||||
|
cfg = json.load(f)
|
||||||
|
|
||||||
|
agent_id = '$AGENT_ID'
|
||||||
|
ws_dir = '$WORKSPACE_DIR'
|
||||||
|
|
||||||
|
if agent_id not in cfg['agents']['profiles']:
|
||||||
|
cfg['agents']['profiles'][agent_id] = {
|
||||||
|
'id': agent_id,
|
||||||
|
'workspace_dir': ws_dir,
|
||||||
|
'enabled': True
|
||||||
|
}
|
||||||
|
if agent_id not in cfg['agents']['agent_order']:
|
||||||
|
cfg['agents']['agent_order'].append(agent_id)
|
||||||
|
with open(config_path, 'w') as f:
|
||||||
|
json.dump(cfg, f, indent=2, ensure_ascii=False)
|
||||||
|
print(' ✅ 注册成功')
|
||||||
|
else:
|
||||||
|
print(' ✅ 已注册，跳过')
|
||||||
|
"
|
||||||
|
|
||||||
|
# ── 记录仓库路径（用于 Heartbeat git pull）─────────────────────────────
|
||||||
|
echo "$REPO_DIR" > "$WORKSPACE_DIR/.repo_path"
|
||||||
|
info "仓库路径已记录: $REPO_DIR"
|
||||||
|
|
||||||
|
# ── 完成 ───────────────────────────────────────────────────────────────
|
||||||
|
echo ""
|
||||||
|
info "════════════════════════════════════════════════"
|
||||||
|
info " 黑手党提案专家 安装完成！"
|
||||||
|
info "════════════════════════════════════════════════"
|
||||||
|
echo ""
|
||||||
|
info "启动方式："
|
||||||
|
info " copaw app # 打开控制台"
|
||||||
|
info " 然后在左上角切换到 '黑手党提案专家'"
|
||||||
|
echo ""
|
||||||
|
info "更新方式："
|
||||||
|
info " cd $REPO_DIR && git pull"
|
||||||
|
info " bash agent/install.sh # 重新安装"
|
||||||
|
echo ""
|
||||||
5
agent/skill.json
Normal file
5
agent/skill.json
Normal file
@ -0,0 +1,5 @@
|
|||||||
|
{
|
||||||
|
"schema_version": "workspace-skill-manifest.v1",
|
||||||
|
"version": 1775480735028,
|
||||||
|
"skills": {}
|
||||||
|
}
|
||||||
95
agent/skills/conflict_cloud/SKILL.md
Normal file
95
agent/skills/conflict_cloud/SKILL.md
Normal file
@ -0,0 +1,95 @@
|
|||||||
|
---
|
||||||
|
name: 冲突图构建
|
||||||
|
description: 对筛选出的主要UDE构建冲突图（Evaporating Cloud），拆解O-B-D结构，合并多个UDE的冲突图
|
||||||
|
---
|
||||||
|
|
||||||
|
# 冲突图构建（Evaporating Cloud / Conflict Cloud）
|
||||||
|
|
||||||
|
当用户完成了 UDE 诊断（筛选出最重要的 3 个 UDE + 恶性循环），进入"定义核心冲突"时，激活此 Skill。
|
||||||
|
|
||||||
|
## 概念说明
|
||||||
|
|
||||||
|
冲突图（又称"蒸发云"）是 TOC 思考过程的核心工具。它揭示的不是"问题"，而是"为什么问题一直存在"——因为存在一个看似无法调和的冲突。
|
||||||
|
|
||||||
|
## 第一步：对每个主要 UDE 构建冲突图
|
||||||
|
|
||||||
|
### 构建逻辑（Agent 内部推理过程）
|
||||||
|
|
||||||
|
1. 将 UDE 反转为 DE（期望效果）
|
||||||
|
2. 思考：DE 的必备条件是什么？（D：只有做了 D，UDE 才会转化为 DE）
|
||||||
|
3. 从 D 中找到两个矛盾的行动方向（D1 vs D2）
|
||||||
|
4. D1 对应的期望效果 = B1（需求1）
|
||||||
|
5. D2 对应的期望效果 = B2（需求2）
|
||||||
|
6. B1 和 B2 共同服务的上层目标 = O
|
||||||
|
|
||||||
|
### 引导用户的提问
|
||||||
|
|
||||||
|
对每个主要 UDE，依次提问：
|
||||||
|
|
||||||
|
1. "当您感受到这个 UDE 时，团队**通常的做法**是什么？" → 这就是 D1
|
||||||
|
2. "如果不考虑任何限制，您**期望采取的做法**是什么？" → 这就是 D2
|
||||||
|
3. "D1 试图满足的需求是什么？" → 这就是 B1
|
||||||
|
4. "D2 试图满足的需求是什么？" → 这就是 B2
|
||||||
|
5. "B1 和 B2 共同服务的更大目标是什么？" → 这就是 O
|
||||||
|
|
||||||
|
### 输出模板（每个 UDE 一份）
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### UDE-[编号]：[UDE 描述]
|
||||||
|
|
||||||
|
| 维度 | 目标 | 需求 | 行动 |
|
||||||
|
|------|------|------|------|
|
||||||
|
| 惯性方向 | O: [系统目标] | B1: [需求1] | D1: [当前通常做法] |
|
||||||
|
| 期望方向 | | B2: [需求2] | D2: [期望做法] |
|
||||||
|
|
||||||
|
#### 互斥性检查
|
||||||
|
- ✅ 如果 D1，则不能 D2：[解释为什么]
|
||||||
|
- ✅ 如果 D2，则不能 D1：[解释为什么]
|
||||||
|
- ✅ 只有 D1 才能 B1：[解释]
|
||||||
|
- ✅ 只有 D2 才能 B2：[解释]
|
||||||
|
- ✅ 如果 D1 则不能 B2：[解释]
|
||||||
|
- ✅ 如果 D2 则不能 B1：[解释]
|
||||||
|
```
|
||||||
|
|
||||||
|
### 互斥性校验规则
|
||||||
|
|
||||||
|
**这是最关键的质量关卡。** D1 和 D2 必须满足以下全部条件：
|
||||||
|
- D1 和 D2 不能同时执行（不是"程度差异"，而是"方向互斥"）
|
||||||
|
- 选择 D1 必然牺牲 B2
|
||||||
|
- 选择 D2 必然牺牲 B1
|
||||||
|
- 如果可以"都做一点"，说明冲突图构建有误，需要重新提炼
|
||||||
|
|
||||||
|
## 第二步：合并冲突图
|
||||||
|
|
||||||
|
当多个 UDE 的冲突图都完成后，寻找它们的共性：
|
||||||
|
|
||||||
|
### 合并规则
|
||||||
|
1. 将多个 O 合并为统一的系统目标
|
||||||
|
2. 将多个 B1 合并为"惯性方向的需求集"
|
||||||
|
3. 将多个 B2 合并为"期望方向的需求集"
|
||||||
|
4. 将多个 D1 合并为"当前采取的行动集"
|
||||||
|
5. 将多个 D2 合并为"希望采取的行动集"
|
||||||
|
|
||||||
|
### 输出模板
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### 合并冲突图
|
||||||
|
|
||||||
|
| 维度 | O合并 | B | D |
|
||||||
|
|------|-------|---|---|
|
||||||
|
| 惯性方向 | 1. [目标1] | B1 合并：| D1 合并（当前行动）：|
|
||||||
|
| | 2. [目标2] | - [需求a] | - [行动a] |
|
||||||
|
| | 3. [目标3] | - [需求b] | - [行动b] |
|
||||||
|
| 期望方向 | | B2 合并：| D2 合并（期望行动）：|
|
||||||
|
| | | - [需求c] | - [行动c] |
|
||||||
|
| | | - [需求d] | - [行动d] |
|
||||||
|
```
|
||||||
|
|
||||||
|
## 完成标志
|
||||||
|
|
||||||
|
- [ ] 每个主要 UDE（3个）都有独立的冲突图
|
||||||
|
- [ ] 每个冲突图通过互斥性校验
|
||||||
|
- [ ] 完成合并冲突图
|
||||||
|
- [ ] 用户确认合并结果
|
||||||
|
|
||||||
|
完成后，提示用户进入下一步：**步骤2 - 揭示冲突背后的惯例**。
|
||||||
139
agent/skills/convention_breaker/SKILL.md
Normal file
139
agent/skills/convention_breaker/SKILL.md
Normal file
@ -0,0 +1,139 @@
|
|||||||
|
---
|
||||||
|
name: 惯例打破与方案激发
|
||||||
|
description: 揭示冲突背后的行业惯例，通过因果假设分析找到隐含假设，用例外案例激发打破惯例的方案，输出方向性提案
|
||||||
|
---
|
||||||
|
|
||||||
|
# 惯例打破与方案激发（Convention Breaker）
|
||||||
|
|
||||||
|
当用户完成了冲突图构建（合并冲突图就绪），进入"揭示惯例"和"用例外激发方案"时，激活此 Skill。
|
||||||
|
|
||||||
|
此 Skill 覆盖原方法论的 **步骤2（揭示惯例）** 和 **步骤3（用例外激发方案）**。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 部分一：揭示冲突背后的惯例（步骤2）
|
||||||
|
|
||||||
|
### 核心问题
|
||||||
|
|
||||||
|
对合并冲突图中的每对 B1-D1，追问：
|
||||||
|
|
||||||
|
> **"为什么用户想要 B1，就一定得 D1？"**
|
||||||
|
|
||||||
|
### 因果假设分析法
|
||||||
|
|
||||||
|
用 CLR（因果逻辑推理）格式拆解：
|
||||||
|
|
||||||
|
```
|
||||||
|
因为：D1 [当前行动]
|
||||||
|
同时：[隐含假设]
|
||||||
|
那么：B1 [需求被满足]
|
||||||
|
```
|
||||||
|
|
||||||
|
如果这个逻辑链成立，说明"隐含假设"就是维持 D1 的根基。
|
||||||
|
|
||||||
|
### 引导提问
|
||||||
|
|
||||||
|
1. "在你们行业，为什么大家都选择 D1 而不是 D2？"
|
||||||
|
2. "D1 背后有什么'理所当然'的假设？"
|
||||||
|
3. "这个假设对应的行业通常做法（惯例）是什么？"
|
||||||
|
4. "你能举出具体的同行案例来证明这个惯例的存在吗？"
|
||||||
|
|
||||||
|
### 输出模板
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### 惯例分析
|
||||||
|
|
||||||
|
| 关键问题 | 假设 | 行业惯例（直接证据/通常做法） | 总结 |
|
||||||
|
|---------|------|---------------------------|------|
|
||||||
|
| 为什么想要 B1:[XX] 就必须 D1:[XX]？ | [假设1] | [具体行业做法] | 如果遵循惯例1: [XX]，则用户只会D1不会D2 |
|
||||||
|
| 检查：因为 D1，同时 [假设]，那么 B1 | [假设2] | [具体行业做法] | 如果遵循惯例2: [XX]，则用户只会D1不会D2 |
|
||||||
|
```
|
||||||
|
|
||||||
|
### 惯例验证（两个视角，必做）
|
||||||
|
|
||||||
|
#### 我方视角验证
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
1. 惯例是不是行业内保护自身利益的"普遍做法"？
|
||||||
|
- 惯例1 [XX]：✅/❌ [解释]
|
||||||
|
- 惯例2 [XX]：✅/❌ [解释]
|
||||||
|
|
||||||
|
2. 惯例是否导致/加剧当下的恶性循环？
|
||||||
|
- 因为：企业继续遵守惯例 [XX]
|
||||||
|
- 假设：同时，[XX]
|
||||||
|
- 结果：恶性循环中 [XX] 将加剧
|
||||||
|
```
|
||||||
|
|
||||||
|
#### DTB（客户）视角验证
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
1. 惯例直接导致了主要 UDE 中的至少一个？
|
||||||
|
- 惯例 [XX] → 直接导致 UDE-[编号]：✅/❌
|
||||||
|
|
||||||
|
2. 惯例导致加剧了恶性循环？
|
||||||
|
- 惯例 [XX] → 加剧循环 [编号]：✅/❌
|
||||||
|
```
|
||||||
|
|
||||||
|
**如果验证不通过，需要回退重新寻找惯例。**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 部分二：用例外激发方案（步骤3）
|
||||||
|
|
||||||
|
### 核心规则
|
||||||
|
|
||||||
|
**例外必须是具体实例，而不是逻辑推演。** 不接受"理论上可以……"，必须是"在 XX 行业，XX 公司做到了……"。
|
||||||
|
|
||||||
|
### 引导提问
|
||||||
|
|
||||||
|
对每个惯例，依次提问：
|
||||||
|
|
||||||
|
1. "有没有哪家公司/哪个行业，做了跟这个惯例完全相反的事，反而成功了？"
|
||||||
|
2. "如果用户可以同时获得 B1 和 B2，那需要什么样的新做法？"
|
||||||
|
3. "发生了什么例外事件破坏了这个假设？"
|
||||||
|
|
||||||
|
### 方案激发模板
|
||||||
|
|
||||||
|
对每个惯例分别填写：
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### 惯例 [编号]：[惯例名称]
|
||||||
|
|
||||||
|
| 维度 | DTB目标 | 需求 | 行动 | 激发方案 |
|
||||||
|
|------|--------|------|------|---------|
|
||||||
|
| 之所以D2无法B1，是因为假设： | | | | [隐含假设] |
|
||||||
|
| 现有惯例对应D1 | O: [XX] | B1: [XX] | D1: [XX] | 例外是：[具体公司/行业实例] |
|
||||||
|
| 打破惯例对应D2 | | B2: [XX] | D2: [XX] | 可以尝试的是：[具体方案] |
|
||||||
|
```
|
||||||
|
|
||||||
|
### 方向性提案总结（必须输出）
|
||||||
|
|
||||||
|
当所有惯例都完成方案激发后，用以下固定格式输出总结：
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## 方向性提案总结
|
||||||
|
|
||||||
|
> **通过** D [具体行动]，**满足** B [具体需求]；
|
||||||
|
> **同时通过** D' [具体行动]，**满足** B' [具体需求]；
|
||||||
|
> **使 DTB 既可以** O1 [目标1]，**又能够** O2 [目标2]。
|
||||||
|
|
||||||
|
### 具体拆解
|
||||||
|
- D：[行动描述]
|
||||||
|
- B：[需求描述]
|
||||||
|
- D'：[行动描述]
|
||||||
|
- B'：[需求描述]
|
||||||
|
- O1：[目标描述]
|
||||||
|
- O2：[目标描述]
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 完成标志
|
||||||
|
|
||||||
|
- [ ] 每个惯例都经过因果假设分析
|
||||||
|
- [ ] 每个惯例通过双视角验证（我方 + DTB）
|
||||||
|
- [ ] 每个惯例都找到了具体的例外案例（不是逻辑推演）
|
||||||
|
- [ ] 输出了方向性提案总结
|
||||||
|
- [ ] 用户确认方向性提案
|
||||||
|
|
||||||
|
完成后，提示用户进入下一步：**步骤4 - 消除负面分支**。
|
||||||
117
agent/skills/negative_branch/SKILL.md
Normal file
117
agent/skills/negative_branch/SKILL.md
Normal file
@ -0,0 +1,117 @@
|
|||||||
|
---
|
||||||
|
name: 负面分支消除
|
||||||
|
description: 识别新方案可能带来的新UDE，构建因果假设链，在链条中找到打破假设的节点来消解负面分支
|
||||||
|
---
|
||||||
|
|
||||||
|
# 负面分支消除（Negative Branch Reservation）
|
||||||
|
|
||||||
|
当用户完成了方向性提案总结，进入"消除负面分支"时，激活此 Skill。
|
||||||
|
|
||||||
|
## 概念说明
|
||||||
|
|
||||||
|
任何新方案在解决旧问题的同时，都会带来新的副作用。负面分支消除不是否定新方案，而是提前预见并设计配套措施，使副作用不会危害核心需求。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 第一步：列出新方案可能导致的所有新 UDE
|
||||||
|
|
||||||
|
### 引导提问
|
||||||
|
|
||||||
|
向用户提供以下发散思考维度：
|
||||||
|
|
||||||
|
> "如果我们实施了方向性提案中的新方案（D + D'），可能会出现哪些新的不良效果？"
|
||||||
|
|
||||||
|
提供以下清单帮助用户发散思考：
|
||||||
|
|
||||||
|
- 协同复杂度增加（扯皮和纠纷变多）
|
||||||
|
- 考核边界不清晰（难以量化）
|
||||||
|
- 管理复杂度增加
|
||||||
|
- 局部效率降低
|
||||||
|
- 结果不确定性高
|
||||||
|
- 不适应新的思考和行为模式
|
||||||
|
- 加重了认知负担
|
||||||
|
- 提升了决策难度
|
||||||
|
- 决策慢
|
||||||
|
- 错失"机会"多
|
||||||
|
- 官僚作风
|
||||||
|
- 办公室政治
|
||||||
|
- 对人才的要求高
|
||||||
|
- 短期业绩可能下滑
|
||||||
|
- 组织阻力大
|
||||||
|
- 其他（请用户补充）
|
||||||
|
|
||||||
|
## 第二步：筛选危害性 UDE
|
||||||
|
|
||||||
|
从新增 UDE 中，筛选出**同时满足**以下两个条件的：
|
||||||
|
|
||||||
|
1. **直接危害**现有任一 B（方向性提案中的需求）
|
||||||
|
2. **客户感受强**（客户会第一时间抱怨）
|
||||||
|
|
||||||
|
### 输出模板
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### 危害性 UDE 筛选
|
||||||
|
|
||||||
|
| 被危害的 B | 新增 UDE | 客户感受 |
|
||||||
|
|-----------|---------|---------|
|
||||||
|
| B1: [需求] | [新UDE描述] | [为什么客户感受强] |
|
||||||
|
| B2: [需求] | [新UDE描述] | [为什么客户感受强] |
|
||||||
|
```
|
||||||
|
|
||||||
|
## 第三步：构建因果假设链
|
||||||
|
|
||||||
|
对每个危害性 UDE，从方案 D 开始，追踪因果链条直到最终 UDE。
|
||||||
|
|
||||||
|
### 构建规则
|
||||||
|
|
||||||
|
1. 从最底层（方案 D）向上推演
|
||||||
|
2. 每一步标注"假设"（这步成立需要什么前提）
|
||||||
|
3. 每一步标注性质：DE（好的中间结果）还是 UDE（坏的中间结果）
|
||||||
|
4. **重点寻找**：链条中 DE 变为 UDE 的转折点——那就是打破假设的节点
|
||||||
|
|
||||||
|
### 输出模板（每个危害性 UDE 一份）
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### 因果假设链：[最终 UDE 描述]
|
||||||
|
|
||||||
|
| | 因果假设链 | | 性质 |
|
||||||
|
|--|-----------|--|------|
|
||||||
|
| 结果 | 最终结果：[UDE 描述] | | UDE |
|
||||||
|
| 过程 | 中间结果3：[XX] | 假设：[XX] | UDE |
|
||||||
|
| | 中间结果2：[XX] | 假设：[XX] | UDE/DE |
|
||||||
|
| | | | **→ 打破假设的方案：[XX]** |
|
||||||
|
| | 中间结果1：[XX] | 假设：[XX] | DE |
|
||||||
|
| 方案 | D：[新方案] | 假设：[前提条件] | |
|
||||||
|
```
|
||||||
|
|
||||||
|
## 第四步：验证打破假设方案的有效性
|
||||||
|
|
||||||
|
对每个"打破假设的方案"，用以下模板验证：
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### 验证：[打破的假设]
|
||||||
|
|
||||||
|
| 如果： | D [具体方案] |
|
||||||
|
|--------|-------------|
|
||||||
|
| 同时： | 假设 [前提条件被满足] |
|
||||||
|
| 那么： | UDE变成DE：[原UDE描述] → [新DE描述] |
|
||||||
|
| 并且那么： | 现有DE没有转变为UDE：✅ [确认说明] |
|
||||||
|
```
|
||||||
|
|
||||||
|
### 验证标准
|
||||||
|
- "UDE 变成 DE"必须是具体的、可感知的改善
|
||||||
|
- "现有 DE 没有转变为 UDE"必须逐一检查所有现有 DE
|
||||||
|
- 如果验证不通过，需要回退修改打破假设方案
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 完成标志
|
||||||
|
|
||||||
|
- [ ] 列出了所有可能的新增 UDE
|
||||||
|
- [ ] 筛选出直接危害 B 且客户感受强的 UDE
|
||||||
|
- [ ] 每个危害性 UDE 都有因果假设链
|
||||||
|
- [ ] 每条链上找到了打破假设的节点和方案
|
||||||
|
- [ ] 每个打破假设方案通过了"如果-同时-那么"验证
|
||||||
|
- [ ] 用户确认所有负面分支已消解
|
||||||
|
|
||||||
|
完成后，提示用户进入最后一步：**步骤5 - 确立新规则、匹配新能力**。
|
||||||
183
agent/skills/proposal_assembler/SKILL.md
Normal file
183
agent/skills/proposal_assembler/SKILL.md
Normal file
@ -0,0 +1,183 @@
|
|||||||
|
---
|
||||||
|
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/ 目录作为案例存档。
|
||||||
|
> 如果在后续使用中发现方法论有需要改进的地方，我会在下次心跳时自动整理迭代建议。"
|
||||||
113
agent/skills/ude_diagnosis/SKILL.md
Normal file
113
agent/skills/ude_diagnosis/SKILL.md
Normal file
@ -0,0 +1,113 @@
|
|||||||
|
---
|
||||||
|
name: UDE 诊断
|
||||||
|
description: 引导用户识别不良现状效果（UDE），进行10条标准校验，筛选最重要的3个UDE，并识别恶性循环
|
||||||
|
---
|
||||||
|
|
||||||
|
# UDE 诊断（Undesirable Effects Diagnosis）
|
||||||
|
|
||||||
|
当用户完成了准备1（概念对齐）和准备2（JTBD 四要素），需要进入"定义双赢"时，激活此 Skill。
|
||||||
|
|
||||||
|
## 第一步：引导用户列出所有 UDE
|
||||||
|
|
||||||
|
向用户解释：
|
||||||
|
> "UDE（不良现状效果）是您的客户当前持续承受的、让他们无法表现更好的问题。我们需要尽可能多地列出来。"
|
||||||
|
|
||||||
|
请用户从以下维度思考：
|
||||||
|
- 战略层：方向不清、节奏不明
|
||||||
|
- 业绩层：增长乏力、利润下降
|
||||||
|
- 营销层：费用高、效果差
|
||||||
|
- 组织层：架构不合理、协调不畅
|
||||||
|
- 人才层：关键岗位缺位、能力不足
|
||||||
|
- 运营层：缺数据、缺反馈机制
|
||||||
|
- 财务层：缺科学核算、现金流紧张
|
||||||
|
|
||||||
|
## 第二步：逐条 10 标准校验
|
||||||
|
|
||||||
|
对用户列出的每条 UDE，逐一检查以下 10 条标准。**不合格的 UDE 必须退回修改或删除，不能凑合使用。**
|
||||||
|
|
||||||
|
| 序号 | 标准名称 | 检查问题 | 不合格则… |
|
||||||
|
|------|---------|---------|----------|
|
||||||
|
| 1 | 持续存在 | 这是一个持续存在的问题吗？还是一次性事件？ | 改为持续性描述 |
|
||||||
|
| 2 | 当下正在发生 | 这是现在时态的陈述吗？还是对未来的假设？ | 改为现在时态 |
|
||||||
|
| 3 | 描述状态 | 这是对系统状态的描述吗？还是一个动作？ | 改为状态描述 |
|
||||||
|
| 4 | 责任范围内 | 这属于您（或客户）的责任/影响范围吗？ | 删除或缩小范围 |
|
||||||
|
| 5 | 可以解决 | 可以采取措施来改善这个问题吗？ | 删除 |
|
||||||
|
| 6 | 不归因于人 | 有没有在责怪某个具体的人？ | 改为系统性描述 |
|
||||||
|
| 7 | 不分析原因 | 有没有包含推测的原因？ | 去掉原因部分 |
|
||||||
|
| 8 | 不是解决方案 | 有没有隐藏着一个解决方案？ | 改为问题描述 |
|
||||||
|
| 9 | 单独实体 | 是否只包含一个问题？ | 拆分为多条 |
|
||||||
|
| 10 | 不是主观猜想 | 这是事实还是主观感受？ | 改为可验证的事实 |
|
||||||
|
|
||||||
|
### 输出格式
|
||||||
|
|
||||||
|
对每条 UDE 输出校验结果：
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
#### UDE-[编号]：[UDE 描述]
|
||||||
|
|
||||||
|
| 标准 | 通过？ | 备注 |
|
||||||
|
|------|-------|------|
|
||||||
|
| 1. 持续存在 | ✅/❌ | [如不通过，说明原因] |
|
||||||
|
| 2. 当下正在发生 | ✅/❌ | |
|
||||||
|
| ... | ... | ... |
|
||||||
|
|
||||||
|
**结论**：✅ 合格 / ❌ 需修改：[修改建议]
|
||||||
|
```
|
||||||
|
|
||||||
|
## 第三步：筛选最重要的 3 个 UDE
|
||||||
|
|
||||||
|
从合格的 UDE 中，按以下两个标准**同时满足**来筛选：
|
||||||
|
|
||||||
|
1. **关联性**：跟买我们的产品、用我们的服务有关（我们和同行导致了这个 UDE）
|
||||||
|
2. **杠杆性**：这个 UDE 对于客户至关重要，直接或间接影响了 70% 以上的其他 UDE
|
||||||
|
|
||||||
|
### 输出格式
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### 最重要的 3 个 UDE
|
||||||
|
|
||||||
|
1. **UDE-[编号]：[描述]**
|
||||||
|
- 关联性：[解释为什么跟我们的产品/服务有关]
|
||||||
|
- 杠杆性：[解释它影响了哪些其他 UDE，覆盖了百分之多少]
|
||||||
|
|
||||||
|
2. **UDE-[编号]：[描述]**
|
||||||
|
- 关联性：[...]
|
||||||
|
- 杠杆性：[...]
|
||||||
|
|
||||||
|
3. **UDE-[编号]：[描述]**
|
||||||
|
- 关联性：[...]
|
||||||
|
- 杠杆性：[...]
|
||||||
|
```
|
||||||
|
|
||||||
|
## 第四步：识别恶性循环
|
||||||
|
|
||||||
|
从 UDE 清单中找出相互因果增强的 UDE 组合，构成恶性循环。
|
||||||
|
|
||||||
|
### 构建规则
|
||||||
|
- 恶性循环是 3-5 个 UDE 首尾相连的因果链
|
||||||
|
- A 导致 B，B 导致 C，C 又反过来加剧 A
|
||||||
|
- 至少识别 1 个恶性循环，建议 2-3 个
|
||||||
|
|
||||||
|
### 输出格式
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### 恶性循环 1：[循环名称]
|
||||||
|
[UDE-A] → [UDE-B] → [UDE-C] → [UDE-D] → 回到 [UDE-A]
|
||||||
|
|
||||||
|
**解读**：[用一句话解释这个循环为什么会自我强化]
|
||||||
|
|
||||||
|
### 恶性循环 2：[循环名称]
|
||||||
|
[UDE-X] → [UDE-Y] → [UDE-Z] → 回到 [UDE-X]
|
||||||
|
|
||||||
|
**解读**：[...]
|
||||||
|
```
|
||||||
|
|
||||||
|
## 完成标志
|
||||||
|
|
||||||
|
当以下条件全部满足时，此 Skill 完成：
|
||||||
|
- [ ] 所有 UDE 通过 10 条标准校验（或已修正/删除）
|
||||||
|
- [ ] 筛选出最重要的 3 个 UDE（两个标准同时满足）
|
||||||
|
- [ ] 至少识别 1 个恶性循环
|
||||||
|
- [ ] 用户确认以上输出
|
||||||
|
|
||||||
|
完成后，提示用户进入下一步：**步骤1 - 定义核心冲突**。
|
||||||
577
docs/SPEC_黑手党提案Agent_v1.md
Normal file
577
docs/SPEC_黑手党提案Agent_v1.md
Normal file
@ -0,0 +1,577 @@
|
|||||||
|
# 黑手党提案 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 |
|
||||||
482
docs/在线工作坊 - 研讨文档（&产品试用：黑手党提案+有效产出会计）.md
Normal file
482
docs/在线工作坊 - 研讨文档（&产品试用：黑手党提案+有效产出会计）.md
Normal file
@ -0,0 +1,482 @@
|
|||||||
|
# 在线工作坊 - 研讨文档（&产品试用：黑手党提案+有效产出会计）
|
||||||
|
|
||||||
|
# 研讨目标
|
||||||
|
|
||||||
|
1. 输出领先2035的“黑手党提案”：我们如何持续与客户双赢？
|
||||||
|
|
||||||
|
2. 基于黑手党提案，调整目前产品体系的重心和细节
|
||||||
|
|
||||||
|
3. 对研讨流程的节奏和工具进行测试（重点观察公测版中可能出现的卡点）
|
||||||
|
|
||||||
|
4. 对现有产品进行成本估算和定价（基于有效产出会计）
|
||||||
|
|
||||||
|
|
||||||
|
## 研讨范式
|
||||||
|
|
||||||
|
1. 发言准备：3-5min
|
||||||
|
|
||||||
|
2. 顺序表达：5min\人
|
||||||
|
|
||||||
|
3. 发散补充：10min\轮
|
||||||
|
|
||||||
|
4. 个人收敛：3min准备+2min\人
|
||||||
|
|
||||||
|
5. 结论共识：10min\轮
|
||||||
|
|
||||||
|
|
||||||
|
每一轮约50分钟（按3人研讨计算）；此时间为粗估计，在开展研讨时以实际计时为准
|
||||||
|
|
||||||
|
# 第一部分：黑手党提案
|
||||||
|
|
||||||
|
:::
|
||||||
|
长期陪伴产品的方向性提案（成果导向、可以承诺效果的咨询服务）
|
||||||
|
:::
|
||||||
|
|
||||||
|
## 研讨准备（粗共识）
|
||||||
|
|
||||||
|
### 关键准备1：让客户秒懂“黑手党提案”
|
||||||
|
|
||||||
|
研讨输出[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6hd8rko0fh4qdmhd2vm)
|
||||||
|
|
||||||
|
| 类比引入 | 1. 电影《教父》中那种”你没有任何拒绝的理由“的提案<br> <br>2. 商业中的“双赢”策略，强调双方都获益。<br> <br>3. 生活中的“必杀技”，指某种无法抗拒的吸引力。 |
|
||||||
|
| --- | --- |
|
||||||
|
| 概念解释 | 1、定义： <br>黑手党提案是一种能够帮助客户打破重大限制、获得前所未有的价值的解决方案，通过非共识的创新方式，让客户无法拒绝，同时实现客户与企业双赢。<br>2、内涵：<br>* 不是简单的痛点挖掘或需求满足，而是通过打破行业惯例，提供超越期待的价值。<br> <br>* 通常不直接解决表面问题，而是通过创造新的价值，让原有问题变得无关紧要。<br> <br>* 方案具有独特性，难以被竞争对手模仿，且能够量化、比较，清楚展示其优势。<br> <br>* 实现客户与企业的双赢：客户因价值提升而愿意付费，企业因解决关键问题而获得长期竞争优势。<br> <br>3、外延：区别<br>* 与痛点：痛点是表面问题，而黑手党提案更关注痛点背后的根本需求和价值。<br> <br>* 与需求：需求是客户已知的期望，而黑手党提案则是通过创新打破常规，创造新的价值需求。<br> <br>* 与传统方案：传统方案可能满足单一需求，而黑手党提案是通过打破行业惯例，创造独特的价值主张。 |
|
||||||
|
| 秒懂案例 | ### 案例：苹果手机<br>提案：苹果手机打破了传统手机必须有键盘的惯例，转而采用全触屏设计。<br>* 企业打破的限制：传统手机设计的物理键盘限制了屏幕大小和用户体验。<br> <br>* 企业获得的好处：更高的利润和市场主导地位，引领智能手机行业创新。<br> <br>* 用户打破的限制：用户不再受限于物理键盘的不便，享受更直观的操作。<br> <br>* 用户获得的好处：更时尚、易用的手机，提升了用户体验和满意度。<br> <br>### 案例：胖东来按新鲜度卖鲜果<br>提案：胖东来通过按新鲜度定价，改变了传统水果销售模式。<br>* 企业打破的限制：传统水果定价基于外观和大小，忽视了新鲜度和品质。<br> <br>* 企业获得的好处：增加了利润空间，提升了品牌形象和客户忠诚度。<br> <br>* 用户打破的限制：用户不再受限于传统定价的不公平，能够以合理价格购买新鲜水果。<br> <br>* 用户获得的好处：更高的性价比和更优质的购物体验，增强了消费信心。<br> <br>### 案例：小米手机（2011年）<br>提案：小米手机以1999元的价格进入市场，打破了智能手机高价的惯例。<br>* 企业打破的限制：智能手机价格昂贵，限制了普及和市场份额。<br> <br>* 企业获得的好处：迅速扩大了市场份额，树立了性价比高的品牌形象。<br> <br>* 用户打破的限制：用户不再受限于高价格，能够以更低的价格购买高质量智能手机。<br> <br>* 用户获得的好处：更实惠的价格和更好的产品体验，提升了消费满意度。<br> <br>### 案例：苹果 iPod<br>提案：苹果iPod通过创新设计和内容管理，改变了音乐播放器市场。<br>* 企业打破的限制：传统音乐播放器的低容量和不便携性，以及盗版和携带不便的问题。<br> <br>* 企业获得的好处：获得了市场领导地位，推动了数字音乐行业的发展。<br> <br>* 用户打破的限制：用户不再受限于低容量和不便携的播放器，享受了更丰富的音乐体验。<br> <br>* 用户获得的好处：便携、高质量的音乐播放器，提升了音乐消费的便利性和乐趣。<br> <br>**案例：360免费杀毒**<br>提案：360率先使用了杀毒免费、通过播放广告盈利的运营模式。<br>* 企业打破的限制是：传统杀毒软件的收费模式让用户望而却步，同时也让竞争对手陷入价格战的困境。<br> <br>* 企业获得的好处是：通过免费模式迅速扩大用户基数，建立市场主导地位，并通过增值服务（如安全保护、浏览器等）实现盈利。<br> <br>* 用户打破的限制是：高昂的杀毒软件成本让用户难以负担或选择盗版产品。<br> <br>* 用户获得的好处是：免费且高效的杀毒服务降低了用户的使用门槛，提高了安全防护的普及率和使用体验。 |
|
||||||
|
|
||||||
|
#### 个人思考过程
|
||||||
|
|
||||||
|
| | $\color{#0089FF}{@沈攀}$ | $\color{#0089FF}{@赵蕾}$ | 东方 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| 类比引入 | 电影《教父》威慑力<br>预判了你的预判、最优解、别的方案可能更差 | 给客户提供难以抗拒的、清晰的、远超竞争对手的好处。 | 一种无法拒绝的提案<br>像《教父》一样，一眼看透了本质，解决了各方最痛的问题、给所有人都带来了好处，很难不心动。<br>预判了你的预判（搬家片段），最优解就是接受这个提案。 |
|
||||||
|
| 概念解释 | what：<br>定义：打破客户重大限制，让其客户无法拒绝的理由（方案）。<br>延展：和痛点、需求的区别：<br>不只是单纯抓痛点、也比满足需求，要求要高<br>假设：用户想要，我们满足<br>黑手党提案更底层<br>通常是打破了行业惯例、非共识的共鸣<br>特征：没有直接解决这个问题，但让着问题，显得无关紧要，**c、b共赢**<br>why：需求是复合体、甚至是矛盾的、需求是不断延伸的<br>满足单一的痛点是不够的<br>how：用户端和供给端找打核心冲突、打破冲突、双赢 | 难以抗拒：相较原方案有巨大优势，大于用户的替换成本<br>清晰：可量化、可比较 | 你的客户有好处，所以更愿意付钱；<br>你的公司也有好处，可以摆脱长期以来的关键问题；<br>你的竞争对手无比头痛，看得懂也抄不了。<br>---<br>“黑手党提案”就是从客户的需求出发，深入了解他们遇到的痛点，然后设计一个解决方案，使得这个方案不仅能解决问题，还让竞争对手无法模仿，从而帮助双方都创造价值。<br>定义：（帮助XX打破限制、获得XX）<br>内涵：<br>外延：区别 |
|
||||||
|
| 秒懂案例 | 1、 苹果手机：打破手机要有键盘惯例<br>限制：c 屏幕小 b：适配不同手机<br>——小电脑<br>2、 胖东来按新鲜度卖鲜果<br>c:xxx<br>b:xxx<br>3：真实的案例：按库龄卖车<br>C：<br>B: | 例：小米手机（2011 年）<br>原先：智能手机 5000+<br>现在：小米手机 1999（同质半价）<br>例：苹果 ipod<br>原先：盗版低质 MP3 费时费力，或正版 CD 携带不便<br>现在：小小ipod能容3000+歌曲 | 像360免费杀毒一样<br>如果杀毒软件需要花钱买，就会重复“悬赏抓蛇、越抓越多”的寓言式的困局。<br>用户为免费杀毒而来，已经付费的杀毒看得懂也不敢学。 |
|
||||||
|
|
||||||
|
### 关键准备2：黑手党提案让哪两方双赢？
|
||||||
|
|
||||||
|
研讨输出[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k45cync9lhsvgwqip)
|
||||||
|
|
||||||
|
| 1、客户 | * 成长型中小企业<br> <br> * 行业特征：<br> <br> 1. 增长期到成熟期 <br> <br> 2. 集中度低、行业乱象、用户信任度低<br> <br> <br> * 企业特征：（主动进入企业，差距小研讨）<br> <br> * 创始人：有愿景、明确目标、相信系统提升、学习管理理论<br> <br> * 管理层：认同企业愿景、执行力强、学习能力强<br> <br> * 高成长型企业（5000W~10亿）：<br> <br> * 已经验证 PMF<br> <br> <br> 1. 可量化CCR：生产职能明确、工序可量化<br> <br> 2. 赛道：高渗透空间、高增速、低集中度<br> <br> 1. 主动研究大赛道；（好赛道列表；学习日）<br> <br> 2. 细分赛道；<br> <br> 3. 组织：有胜任的主将（逻辑思维、底层认知、专业经验）+培养更多合格总经理 <br> （实战中学习； <br> **非脱产培训、有体系（学习地图）** <br> **【个人学习、小组汇报；经营提效瓶颈-实战任务-微课-工作模板+问题\单元格AI Agent】**）<br> <br> 4. 创始人：股权集中、认同可行性愿景<br> <br> <br> * 战略布局（有愿力）：<br> <br> * S1有基础<br> <br> * S2有潜力<br> <br> * S3待破局<br> <br> * 组织成长：<br> <br> * 业务单元经营提效 <br> （算帐：抓手是业务而非公司、创始人投入）<br> <br> * 多重一致性（有认识即可） |
|
||||||
|
| --- | --- |
|
||||||
|
| 2、雇用产品 | 陪伴式咨询（团队）：提供研讨、反馈、骨干培养等端到端服务。<br>* 产品1：咨询类产品（单次、年度）：收费模式为基础费用+增长提成。<br> <br>* 产品2：培训教练类产品（单模块、多模块）：按企业收费，每家企业参与人员不超过6人。 |
|
||||||
|
| 3、待办任务 | * 制定可行性愿景：明确3年目标、10年愿景及更长远的使命。<br> <br>* 提供系统性、一致性、有效性的陪伴服务。<br> <br>* 实现利润增长（短期经营成果改善）和愿景落地（中长期战略任务突破）。<br> <br>具体任务：<br>1. 提升每个业务单元的盈利能力；<br> <br>2. 持续投资未来业务；<br> <br>3. 提升业务系统效率，重塑多重一致性。 |
|
||||||
|
| 4、期望结果 | * 当下和未来的盈利持续增长（结果导向）。<br> <br>* 清晰当下和未来需打赢的关键“胜仗”（过程导向）。<br> <br>* 平衡当下赚钱与未来赚钱，实现系统思考、聚焦核心事务、有计划、有节奏地达成愿景。<br> <br>* 付费效果可量化、可感知：从定量角度看，今天的营业额能转化为未来某年的利润。<br> <br>* 为结果和成效付费，客户希望看到清晰的产出和价值。 |
|
||||||
|
|
||||||
|
| 谁的双赢？ $\color{#0089FF}{@沈攀}$ | 领先2035 | 典型目标客户（DTB）<br>例：…… |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 1、客户 | 成长型中小企业 <br>行业特征：1、 增长期到成熟期<br>2：集中度不高、行业乱象、用户信任度底<br>企业：<br>创始人：有愿力、相对明确的方向目标、相信系统提升带来的好处，学习过其他的管理理论。<br>管理层：相信企业愿景、使命同频、有一定认知能力、执行力强、学习能力强。 | 2c企业<br>产品型：研发产品、外包（自产）、销售（国内外）、全渠道<br>平台、渠道型 |
|
||||||
|
| 2、雇用产品 | 陪伴式咨询（团队）：研讨、反馈、骨干培养<br>端到端 | 陪伴式咨询：战略方向把关、重大营销方案研讨、关键决策外脑、有竞争力的盈利产品方案、骨干培养方案 |
|
||||||
|
| 3、待办任务 | 可行性愿景：3 年目标 10 年愿景 更长远：使命<br>系统性、一致性、有效性的陪伴服务 | 聚焦最重要的事情、战略重点、BP 计划、<br>业务反馈、骨干培训（达成愿景） |
|
||||||
|
| 4、期望结果 | 系统思考、聚焦最重要的事情、有计划、有节奏的持续小胜、达成愿景。<br>付费效果可量化可感知<br>为结果和成效付费<br>定量：xx 年后的利润=今天的营业额 | 完成 x 年 xx 亿目标 |
|
||||||
|
|
||||||
|
| 谁的双赢？ $\color{#0089FF}{@赵蕾}$ | 领先2035 | 典型目标客户（DTB）<br>**例：Tob 客户类（数票云链）** |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 1、客户 | 高成长型企业（5000W~10亿）<br>> ① 可量化CCR：制约在 CCR（我方有相关经验则更佳）、 有生产职能、工序明确可量化<br>> ② 赛道：高渗透空间、高增速、低集中度<br>> ③ 组织：有胜任的主将（逻辑思维、底层认知、专业经验）<br>> ④ 创始人：股权集中，有一定认知，理性讲逻辑，认同企业经营需要系统论＞还原论（有效产出世界观） | 大型银行 |
|
||||||
|
| 2、雇用产品 | 可行性愿景<br>> 产品1：咨询类产品（单次、年度）<br>* 收费：基础费用+增长提成<br> <br>> 产品2：培训教练类产品（单模块、多模块）<br>* 收费：以企业为单位收费，每家企业人员＜ 6人 | 数电发票的数据要素的场景价值应用<br>> 产品 1：粗加工 —— 数电发票脱敏数据<br>* 收费：按数据量付费<br> <br>> 产品 2：精加工 —— 新能源车产业链融资风控模型<br>* 收费：按模型应用时间付费（或买断）<br> <br>> 产品 3：增值服务 —— 新能源车产业链融资企业撮合<br>* 收费：按融资金额返点 |
|
||||||
|
| 3、待办任务 | 利润增长（短期经营成果能有改变）<br>愿景落地（中长期战略任务能有突破） | 更安全的资金应用<br>更低的销售成本<br>更高的收益回报<br>更多普惠金融的政绩（中小企业、产业的神经末梢） |
|
||||||
|
| 4、期望结果 | 既能当下赚钱，又能未来赚钱 | 更多客户、更高回报、更低风险 |
|
||||||
|
|
||||||
|
| 谁的双赢？ $\color{#0089FF}{@李东方}$ | 领先2035 | 典型目标客户（DTB） |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 1、客户 | 战略有布局：S1有基础、S2有潜力、S3有思考待破局；<br>组织可成长：业务单元的经营提效；多重一致性； | 消费者(意味着我们聚焦于2C业务的企业客户) |
|
||||||
|
| 2、雇用产品 | “总经理+”：合格总经理在我们公司，马上就能大变样<br>（体验过什么是好的总经理、可以带来好的效果） | 新能源汽车：汽车交付和保障服务；<br>跨境电商：选品、需求场景挖掘<br>安克充电业务：把用户痛点快速变成高品质的产品 |
|
||||||
|
| 3、待办任务 | 1. 提升每个业务单元的盈利能力；<br> <br>2. 持续投资未来业务；<br> <br>3. 提升业务系统效率、重塑多重一致性； | 在LTV内提供高品质、低价格的产品和足够周到的服务 |
|
||||||
|
| 4、期望结果 | 当下和未来的盈利持续增长；（结果）<br>清晰当下和未来有哪些胜仗要打：（过程） | “多快好省” |
|
||||||
|
|
||||||
|
### 关键准备3：如何定义双赢
|
||||||
|
|
||||||
|
研讨输出[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k5fygudxxvu01k2qb)
|
||||||
|
|
||||||
|
| 定义双赢 | 领先2035 | 典型目标客户（DTB） |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 1、主要UDE | 必选：<br> | 必选：<br>1. **客户主要UDE：**<br> <br>1、战略解码： BP 战略节奏不清晰（目标、年度关键任务不清晰）<br>2、业绩增长乏力<br>3、总体利润降低<br>4、营销费用高<br>5、缺乏持续可盈利的业务设计<br>6、组织对应战略的匹配度低<br>7、组织：架构不合理、协调运转不畅<br>组织调整慢<br>8、 人才：<br>8 主将缺位、<br>9 缺 OD 主管（≥ 能手）<br>10 缺财务主管（≥ 能手）<br>11 核心岗位胜任力能力不足<br>12 人才密度不够、<br>13 人才互补性不强、<br>14 老将经验习惯和新理念和能力的冲突<br>15 运营：缺乏高质量的及时反馈营业分析会<br>16 财务：缺科学管理会计体系（数据、报表）<br>17 现金流不充裕<br>（同时符合以下两个原则）选出**最重要的三个UDE**：<br>1. 跟买我们的产品、用我们的服务有关 <br> （我们和同行导致了这个UDE）；<br> <br>2. 这个UDE对于客户是至关重要，直接、间接影响了70%以上的UDE； |
|
||||||
|
| 2、恶性循环 | 必选：（拿结果找原因）<br>**恶性循环1：**<br>* 无法确保客户财务指标显性提升<br> <br>* 产品价值陈述不清晰<br> <br>* 值得长期陪伴的客户少<br> <br>* 缺少实战的成功案例<br> <br>**恶性循环2：** <br>* 缺少实战的成功案例<br> <br>* 对交付的结果和节奏缺乏明确承诺<br> <br>* 产品交付变量大<br> <br>* 对顾问要求门槛高<br> <br>* 顾问无法规模化 | 可选： |
|
||||||
|
|
||||||
|
[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6n7uobszhkb4kt6bll)
|
||||||
|
|
||||||
|
[《UDE分析过程》](https://alidocs.dingtalk.com/i/nodes/G1DKw2zgV2glyaqMf103PABqJB5r9YAn?utm_scene=team_space)
|
||||||
|
|
||||||
|
:::
|
||||||
|
清晰表达的 UDE 的一些特征包括：
|
||||||
|
|
||||||
|
1.【持续存在】 这是对现实中存在的持续存在的问题的抱怨，并且由于这个问题，你无法表现得更好。
|
||||||
|
|
||||||
|
2. 【当下正在发生】应该是一个完整的现在时的句子。
|
||||||
|
|
||||||
|
3.【描述状态】它是对系统状态的描述，而不是动作。
|
||||||
|
|
||||||
|
4. 【责任范围内】属于您的责任或影响范围。
|
||||||
|
|
||||||
|
5. 【可以解决】可以采取一些措施来解决这个问题。
|
||||||
|
|
||||||
|
6. 【不归因于人】不能责怪某人。
|
||||||
|
|
||||||
|
7. 【不分析原因】不能是推测的原因。
|
||||||
|
|
||||||
|
8.【不是解决方案】绝不能是隐藏的解决问题的办法。
|
||||||
|
|
||||||
|
9. 【单独的实体】它必须仅包含一个实体。
|
||||||
|
|
||||||
|
10. 【】不应在言语中包含其原因。
|
||||||
|
|
||||||
|
1【不是主观猜想】应该是事实而不是主观的。
|
||||||
|
:::
|
||||||
|
|
||||||
|
## 黑手党提案
|
||||||
|
|
||||||
|
### 发现和打破惯例阶段：方向性提案
|
||||||
|
|
||||||
|
#### 1、定义核心冲突
|
||||||
|
|
||||||
|
1、战略解码： BP 战略节奏不清晰（目标、年度关键任务不清晰）
|
||||||
|
|
||||||
|
6、组织对应战略的匹配度低
|
||||||
|
|
||||||
|
16 财务：缺科学管理会计体系（数据、报表）
|
||||||
|
|
||||||
|
补充研讨：
|
||||||
|
|
||||||
|
1. 客户目标（系统目标）
|
||||||
|
|
||||||
|
2. UDE - > DE
|
||||||
|
|
||||||
|
3. DE的必备条件（D：只有做了D，UDE才会转化为DE）
|
||||||
|
|
||||||
|
1. 从D中找到矛盾的行动；
|
||||||
|
|
||||||
|
2. 转化D对应的DE为B；
|
||||||
|
|
||||||
|
3. 推测B的共同目标（服从于系统目标的小目标，而不能一上来就是O）
|
||||||
|
|
||||||
|
|
||||||
|
| 典型客户的客户（DTB） | 目标 | 需求 | 行动 | 检查 |
|
||||||
|
| --- | --- | --- | --- | --- |
|
||||||
|
| 1、主要UDE1<br>[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6nlcntn3vbbeylrt9n)<br>1、目标、年度关键任务不清晰 | O<br>达成业绩目标 | B1<br>~~（责权利更清晰）~~<br>降低管理复杂度 | D1<br>各自为战 | 当我们感受到UDE时，我们通常的做法是D1；<br>对于典型目标客户（DTB）<br>如果想要B1，但总是UDE1；<br>如果D1，则不能D2；<br>如果D2，则不能D1；<br>只有D1，才能B1；<br>如果D1，则不能B2<br>只有D2，才能B2；<br>如果D2，则不能B1；<br><br> |
|
||||||
|
| | | B2<br>聚焦全局关键事项 | D2<br>协同作战 |
|
||||||
|
| 2、主要UDE2[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k628ztgayppww4sm)<br>6、组织对应战略的匹配度低 | O<br>资源得到最大化的利用 | B1<br>责权利更清晰<br>解决表面问题（止血） | D1<br>优先解决局部的、具体问题；（次要矛盾） |
|
||||||
|
| 推动企业实现战略目标 | | B2<br>将资源聚焦到能够改善业绩的关键环节<br>解决根本问题（根治） | D2<br>基于系统思考解决整体关键问题；（主要矛盾） |
|
||||||
|
| 3、主要UDE3<br>[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6nooyydbije19pyz6)<br>财务：~~缺整体科学管理会计体系的指导（数据、报表）~~<br>缺乏经营仪表盘的指导 | O<br>提升当期盈利指标 | B1<br>符合会计准则强制要求 | D1<br>完全成本法（分摊所有生产成本到产品）：<br>以销售单元核算利润率 |
|
||||||
|
| | | B2<br>挖尽系统瓶颈效能 | D2<br>有效产出成本拆分 |
|
||||||
|
| 在“待办任务”的框架下，合并B1、B2、D1、D2，最恰当的描述是： | | | |
|
||||||
|
| 合并UDE[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k628ztoox6heog5u) | O合并<br>1. 达成业绩目标<br> <br>2. 资源得到最大化的利用<br> <br>3. 提升当期盈利指标 | B1<br>降低管理复杂度<br>责权利更清晰<br>解决表面问题（止血）<br>符合会计准则强制要求 | D1（当前采取的行动）<br>各自为战<br>优先解决局部的、具体问题；（次要矛盾）<br>完全成本法（分摊所有生产成本到产品）：<br>以销售单元核算利润率 |
|
||||||
|
| | | B2<br>提升CCR使用率<br>聚焦全局关键事项<br>将资源聚焦到能够改善业绩的关键环节<br>解决根本问题（根治）<br>挖尽系统瓶颈效能 | D2（希望采取的行动）<br>协同作战<br>基于系统思考解决整体关键问题；（主要矛盾）有效产出成本拆分 |
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
#### 2、揭示冲突背后的惯性（是什么限制了用户）
|
||||||
|
|
||||||
|
| O合并<br>1. 达成业绩目标<br> <br>2. 资源得到最大化的利用<br> <br>3. 提升当期盈利指标 | B1<br>降低管理复杂度<br>责权利更清晰<br>解决表面问题（止血）<br>符合会计准则强制要求 | D1（当前采取的行动）<br>各自为战<br>优先解决局部的、具体问题；（次要矛盾）<br>完全成本法（分摊所有生产成本到产品）：<br>以销售单元核算利润率 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| | B2<br>提升CCR使用率<br>聚焦全局关键事项<br>将资源聚焦到能够改善业绩的关键环节<br>解决根本问题（根治）<br>挖尽系统瓶颈效能 | D2（希望采取的行动）<br>协同作战<br>基于系统思考解决整体关键问题；（主要矛盾）有效产出成本拆分 |
|
||||||
|
|
||||||
|
[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k78au6rroqi8pic2l)
|
||||||
|
|
||||||
|
| 关键问题 | 假设 | 行业惯例（直接证据\通常做法） | 总结 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| 为什么用户想要B1，就一定得D1？<br>为什么用户想要<br>B1降低管理复杂度<br>就必须<br>D1<br>使用完全成本法（分摊所有生产成本到产品）<br>【工具：因果假设分析】<br>检查<br>因为：D1<br>同时：假设<br>那么：B1 | 企业内部考核方便 | 咨询公司在每个项目中都会划分明确的边界；<br>咨询项目需要分拆问题、逐一解决； | 如果总是遵循惯例1：<br>**【明确边界（交付和考核）；】**<br>则用户只会D1，而不会D2。 |
|
||||||
|
| | | * 咨询公司希望明确交付边界<br> <br>---<br>咨询公司需要与客户明确责权利划分 | |
|
||||||
|
| | 提升效率，运转通畅 | 咨询公司希望明确边界、考核清晰 | |
|
||||||
|
| | ~~每个产品管好，整个公司就可以管好~~ | | 如果总是遵循惯例2：<br>**【拆分问题、归口到专家执行；】**<br>则用户只会D1，而不会D2。 |
|
||||||
|
| | 避免分歧和扯皮（守土有责） | 咨询公司希望明确边界、考核清晰 |
|
||||||
|
| | | * 咨询项目需要分拆问题逐一解决<br> <br>---<br>咨询案需要专注于一个问题（切模块解决问题；还原论，分拆问题、逐一解决，整体就可以解决） | |
|
||||||
|
| | 专家解决对口问题<br>---<br>降低咨询案的复杂度 | 用户更信任专家身份（标签） | |
|
||||||
|
| | 咨询项目标准化<br>（能模块化复制） | 就问题找对应专家 | |
|
||||||
|
| | 在咨询公司内部考核方便 | 咨询项目会划分成若干个模块（里程碑） | |
|
||||||
|
| | 外部合规要求 | 分模块交付 | |
|
||||||
|
| AI输出选项（避免想不到）<br>创始人直觉表达如何提炼<br>参与研讨的人数（避免1V1） | | | |
|
||||||
|
|
||||||
|
补充验证：
|
||||||
|
|
||||||
|
| 领先2035视角验证：[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k6uemvpzp2a0rgc5f) | 典型客户的客户（DTB）视角验证：[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k6uemvu6yvr1hr09) |
|
||||||
|
| --- | --- |
|
||||||
|
| 1、惯例是不是行业内保护自身利益的“普遍做法”<br>* 明确边界（交付和考核）<br> <br>* 拆分问题、归口到专家执行； | 1、补全CCRT |
|
||||||
|
| 2、以上管理是导致企业当下陷入恶性循环的直接原因：<br>* 企业CRT中当下的恶性循环是：<br> <br>* 惯例将会加剧恶性循环体现为：<br> <br> * 原因：企业继续遵守惯例XX<br> <br> * 假设：同时，XX<br> <br> * 结果：恶性循环中XX将加加剧。、<br> <br>循环1：<br>* 客户少<br> <br>* 实战少<br> <br>* 持续营收低<br> <br>* 顾问无法规模化<br> <br>循环2：<br>* 无法承诺财务指标（惯例导致）<br> <br>* 潜在客户少【病人】<br> <br>* 实战少<br> <br>* 方法价值感低<br> <br>循环3：<br>* 主动诊断有潜力的客户<br> <br>* 缺少承诺财务指标的服务方案（惯例导致）<br> <br>* 服务边界不清楚<br> <br>* 缺少成功案例 | 2、确认惯例直接导致主要UDE（至少一个）；<br>3、确认惯例导致（B/C）加剧了恶性循环。<br> |
|
||||||
|
|
||||||
|
#### 3、用例外激发方案
|
||||||
|
|
||||||
|
1. 达成业绩目标
|
||||||
|
|
||||||
|
2. 资源得到最大化的利用
|
||||||
|
|
||||||
|
3. 提升当期盈利指标
|
||||||
|
|
||||||
|
|
||||||
|
| **改变的策略** | **DTB目标** | **需求** | **行动** | **激发方案** |
|
||||||
|
| --- | --- | --- | --- | --- |
|
||||||
|
| 惯例1提案[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k7if2l7ocml2u5lgf)<br>* 明确边界（交付和考核） | | | | |
|
||||||
|
| | | | | 之所以D2就无法B1，是因为（假设：）<br>【考核更方便、更明确】 |
|
||||||
|
| 现有惯例的做法是【】，对应D1 | O<br>达成**长期**业绩目标 | B1<br>降低协作复杂度<br>权责利明确 | D1<br>明确边界，快速见效<br>(解决显性问题) | 例外是：（具体例子，而不是逻辑推演）<br>全局经营仪表盘 |
|
||||||
|
| 打破惯例的做法是【】，对应D2 | | B2<br>找到本质解 | D2<br>系统思考，长期主义<br>（解决瓶颈问题） | 可以尝试的是：<br>建立经营仪表盘 |
|
||||||
|
| 惯例2提案[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k7ixeddb6oa3id2ji)<br>* 拆分问题、归口到专家执行； | | | | |
|
||||||
|
| | | | | 之所以D2就无法B1，是因为（假设：）<br>【考核的条款都是分项考核】 |
|
||||||
|
| 现有惯例的做法是【】，对应D1 | O<br>提升当期盈利指标 | B1<br>明确考核项目进度与质量 | D1<br>拆分问题、归口到专家执行 | 例外是：<br> 业财一体的经营管理<br>（战略落地：业务设计与财务指标改善） |
|
||||||
|
| 打破惯例的做法是【】，对应D2 | | B2<br>有效利用资源 | D2<br>基于经营仪表盘做全局陪伴 | 可以尝试的是：<br>基于有效产出会计做经营管理 |
|
||||||
|
| 提案总结：[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k7knidhwxlvxmrhds)<br>**通过D、满足B：通过系统思考，长期主义，满足找到本质解；**<br>**同时通过D’、满足B‘：通过基于经营仪表盘做全局陪伴，满足有效利用资源；**<br>**使DTB可以O1，且可以O2：使BTD既可以达成长期业绩目标，又能够****提升当期盈利指标** | | | | |
|
||||||
|
|
||||||
|
### 激发和完善方案阶段：操作性提案
|
||||||
|
|
||||||
|
#### 4、消除负面分支
|
||||||
|
|
||||||
|
实施新方案之后，领先2035新增的UDEs
|
||||||
|
|
||||||
|
1. 系统思考，长期主义
|
||||||
|
|
||||||
|
2. 基于经营仪表盘做全局陪伴
|
||||||
|
|
||||||
|
|
||||||
|
[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k7yr56ydkym1z2d3)
|
||||||
|
|
||||||
|
* 协同复杂度增加（扯皮和纠纷变多）
|
||||||
|
|
||||||
|
* 考核边界不清晰（难以量化）
|
||||||
|
|
||||||
|
* 管理复杂度增加
|
||||||
|
|
||||||
|
* 局部效率降低
|
||||||
|
|
||||||
|
* 结果不确定性高
|
||||||
|
|
||||||
|
* 不适应新的思考和行为模式（颠覆原有）
|
||||||
|
|
||||||
|
* 加重了认知负担
|
||||||
|
|
||||||
|
* 提升了决策难度
|
||||||
|
|
||||||
|
* 决策慢
|
||||||
|
|
||||||
|
* 错失"机会"多
|
||||||
|
|
||||||
|
* 官僚作风
|
||||||
|
|
||||||
|
* 办公室政治
|
||||||
|
|
||||||
|
* 对人才的要求高
|
||||||
|
|
||||||
|
|
||||||
|
1、直接危害现有（任一）B的UDE
|
||||||
|
|
||||||
|
1. 直接危害B；
|
||||||
|
|
||||||
|
2. 客户感受强；
|
||||||
|
|
||||||
|
|
||||||
|
| B1<br>降低协作复杂度<br>权责利明确 | 协同复杂度增加 |
|
||||||
|
| --- | --- |
|
||||||
|
| B2<br>找到本质解 | 提升了决策难度 |
|
||||||
|
| B1<br>明确考核项目进度与质量 | 考核边界不清晰 |
|
||||||
|
| B2<br>有效利用资源 | 结果不确定性高 |
|
||||||
|
|
||||||
|
2、新方案导致新增UDE的过程，找到DE转变为UDE的节点
|
||||||
|
|
||||||
|
[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k8b3rkxai9ud6y4e)
|
||||||
|
|
||||||
|
| | 因果假设链 | | 性质 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| 结果 | 最终结果<br>协同复杂度增加 | | UDE |
|
||||||
|
| 过程 | 中间结果3<br>缺乏清晰的协同机制和考核办法 | 假设 | UDE |
|
||||||
|
| | 中间结果2<br>现有岗位协同不顺畅的问题暴露 | 假设<br>现有岗位有明确的职责边界和协同机制 | UDE |
|
||||||
|
| | | | 打破假设的方案：<br>聚焦瓶颈问题<br>（非瓶颈不改善） |
|
||||||
|
| | 中间结果1<br>系统可视化 | 假设<br>问题可以找到根因 | DE |
|
||||||
|
| 方案 | D<br>系统思考，长期主义 | 假设<br>管理过程可控（责权分明） | |
|
||||||
|
|
||||||
|
| | 因果假设链 | | 性质 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| 结果 | 最终结果<br>提升了决策难度 | | UDE |
|
||||||
|
| 过程 | 中间结果3<br>缺乏发现问题的流程和新的解决问题的机制 | 假设 | UDE |
|
||||||
|
| | | | 打破假设：<br>**旗手培养** |
|
||||||
|
| | 中间结果2<br>对现有问题更清晰了、对新协同机制和渴望 | 假设<br>组织内缺乏能力（缺参谋部） | DE |
|
||||||
|
| | 中间结果1<br>管理团队有了全局感 | 假设<br>有一套共识的思维方法（方法） | DE |
|
||||||
|
| 方案 | D<br>基于经营仪表盘做全局陪伴 | 假设<br>有专业教练贴身服务（教练） | |
|
||||||
|
|
||||||
|
| | 因果假设链<br>客户经验越充分，研讨效率越高（清楚过程） | | 性质 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| 结果 | 最终结果<br>考核边界不清晰 | | UDE |
|
||||||
|
| 过程 | 中间结果3<br>新方案中分工不明确（甚至与现有制度冲突） | 假设 | UDE |
|
||||||
|
| | 中间结果2<br>方案不明确 | 假设 | UDE |
|
||||||
|
| | | | 打破假设：<br>**共创立竿见影的行动方案（杠杆解，赢得解决本质问题的时间）** |
|
||||||
|
| | 中间结果1<br>更能够清楚指出瓶颈问题 | 假设<br>**惯性思维**<br>团队缺乏经验和抽象思考、迁移能力 | DE |
|
||||||
|
| 方案 | D<br>基于经营仪表盘做全局陪伴 | 假设<br>有经验的专家贴身指导（懂数据、强逻辑、行业KnowHow） | |
|
||||||
|
|
||||||
|
| [请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6pz37mpb86nubk12lo) | 因果假设链 | | 性质 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| 结果 | 最终结果<br>结果不确定性高 | | UDE |
|
||||||
|
| 过程 | 中间结果3<br>难以科学规划推进节奏<br>（以安排待办任务的轻重缓急） | 假设<br>资源有限 | UDE |
|
||||||
|
| | |  | 打破假设：<br>（被打破）全局利益和短期利益有冲突；<br>**创建 一个可盈利的业务机会的缓冲池且缓冲池持续增长** |
|
||||||
|
| | 中间结果2<br>希望做全局性的改善（推倒重来） | 假设<br>想要保住短期既得利益 | DE |
|
||||||
|
| | 中间结果1<br>对愿景的信心更高涨 | 假设<br>人才不够（团队能力不强） | DE |
|
||||||
|
| 方案 | D<br>系统思考，长期主义 | 假设<br>有理论、有方法、有教练陪伴、有成功范例 | |
|
||||||
|
|
||||||
|
3、在节点处补充方案，使UDE转为DE
|
||||||
|
|
||||||
|
[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k8e07fa4r5adpkq1)
|
||||||
|
|
||||||
|
| 如果： | D |
|
||||||
|
| --- | --- |
|
||||||
|
| 同时： | 假设 |
|
||||||
|
| 那么： | UDE变成DE； |
|
||||||
|
| 并且那么： | 现有DE没有转变为UDE； |
|
||||||
|
|
||||||
|
| 如果： | D系统思考，长期主义 |
|
||||||
|
| --- | --- |
|
||||||
|
| 同时： | 假设管理过程可控（责权分明） |
|
||||||
|
| 那么： | UDE变成DE；<br>现有岗位协同不顺畅的问题暴露<br>变成：更多人期待全局改善带来的效果 |
|
||||||
|
| 并且那么： | 现有DE没有转变为UDE； |
|
||||||
|
|
||||||
|
| 如果： | D基于经营仪表盘做全局陪伴 |
|
||||||
|
| --- | --- |
|
||||||
|
| 同时： | 假设有专业教练贴身服务（教练） |
|
||||||
|
| 那么： | UDE变成DE；<br>缺乏发现问题的流程和新的解决问题的机制<br>变成：<br>共识问题、聚焦问题、将资源向其倾斜 |
|
||||||
|
| 并且那么： | 现有DE没有转变为UDE； |
|
||||||
|
|
||||||
|
| 如果： | D基于经营仪表盘做全局陪伴 |
|
||||||
|
| --- | --- |
|
||||||
|
| 同时： | 假设有经验的专家贴身指导（懂数据、强逻辑、行业KnowHow） |
|
||||||
|
| 那么： | UDE变成DE；<br>方案不明确<br>变成：<br>问题清晰、目标明确、方案共识、协调通畅、效果可以预见 |
|
||||||
|
| 并且那么： | 现有DE没有转变为UDE； |
|
||||||
|
|
||||||
|
| 如果： | D系统思考，长期主义 |
|
||||||
|
| --- | --- |
|
||||||
|
| 同时： | 假设有理论、有方法、有教练陪伴、有成功范例 |
|
||||||
|
| 那么： | UDE变成DE；<br>难以科学规划推进节奏<br>变成：<br>计划推进井然有序 |
|
||||||
|
| 并且那么： | 现有DE没有转变为UDE； |
|
||||||
|
|
||||||
|
不是逼不得已，不会主动求学TOC（垂死挣扎）
|
||||||
|
|
||||||
|
#### 5、确立新规则、匹配新能力
|
||||||
|
|
||||||
|
##### 坚定维护么新规则、树立新惯例[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k9hui97aernangcko)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
##### 匹配新能力
|
||||||
|
|
||||||
|
~~1、战略解码： BP 战略节奏不清晰（目标、年度关键任务不清晰）~~
|
||||||
|
|
||||||
|
2、业绩增长乏力
|
||||||
|
|
||||||
|
~~3、总体利润降低~~
|
||||||
|
|
||||||
|
~~4、营销费用高~~
|
||||||
|
|
||||||
|
~~5、缺乏持续可盈利的业务设计~~
|
||||||
|
|
||||||
|
~~6、组织对应战略的匹配度低~~
|
||||||
|
|
||||||
|
~~7、组织：架构不合理、协调运转不畅~~
|
||||||
|
|
||||||
|
组织调整慢
|
||||||
|
|
||||||
|
8、 人才：
|
||||||
|
|
||||||
|
8 主将缺位、
|
||||||
|
|
||||||
|
^9 缺 OD 主管（≥ 能手）^
|
||||||
|
|
||||||
|
^10 缺财务主管（≥ 能手）^
|
||||||
|
|
||||||
|
~~11 核心岗位胜任力能力不足~~
|
||||||
|
|
||||||
|
~~12 人才密度不够、~~
|
||||||
|
|
||||||
|
~~13 人才互补性不强、~~
|
||||||
|
|
||||||
|
~~14 老将经验习惯和新理念和能力的冲突~~
|
||||||
|
|
||||||
|
~~15 运营：缺乏高质量的及时反馈营业分析会~~
|
||||||
|
|
||||||
|
~~16 财务：缺科学管理会计体系（数据、报表）~~
|
||||||
|
|
||||||
|
17 现金流不充裕
|
||||||
|
|
||||||
|
| 分类 | 期望改变的结果 | 运营能力（我们的产品为DTB增加的能力） |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| UDE不会转化为DE，除非……<br>[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k9z4cs46e2p3adofz) | 原UDE1 组织调整慢 | （等自然解决） |
|
||||||
|
| | 原UDE2 主将缺位<br>DE | （筛选标准：**缺关键新能力，而不是人不在**）<br>Build：内部培养<br>Borrow：顾问接管<br>Buy：外部招聘（猎头） |
|
||||||
|
| | 原UDE3 现金流不充裕 | **重算资产与负债**（基于有效产出会计、出售资产或抵押） |
|
||||||
|
| 新方案将会导致新的UDE，除非……<br>[请至钉钉文档查看「计时器」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6k9z879dknp15z90yp) | 新UDE1 现有岗位协同不顺畅的问题暴露 | **聚焦瓶颈问题** |
|
||||||
|
| | 新UDE2 缺乏发现问题的流程和新的解决问题的机制 | **业务操盘手 （骨干培养、旗手、业务总经理）** |
|
||||||
|
| | 新UDE3 方案不明确 | **共创立竿见影的行动方案（杠杆解，赢得解决本质问题的时间）** |
|
||||||
|
| | 新UDE4 难以科学规划推进节奏 | **创建一个可盈利的业务机会的缓冲池且缓冲池持续增长** |
|
||||||
|
|
||||||
|
# 第二部分：产品说明书（陪伴产品） 7号晚搞完+报价
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
3+
|
||||||
|
|
||||||
|
| 产品单元 | 运营能力（改变UDE为DE的新增能力） | 运营能力（维持DE的必要能力） |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
# 第三部分：有效产出会计
|
||||||
|
|
||||||
|
## 研讨准备：产品交付的资源与工序
|
||||||
|
|
||||||
|
### 1、充分展开产品交付流程
|
||||||
|
|
||||||
|
| 产品单元 | 工序与资源投入-顺序逻辑 | 每单位交付物消耗 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| |  | 工序：时间（找瓶颈） \| 资源（评估TVC）<br>工序A：<br>工序B：<br>…… |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
### 2、量化产品交付的效率与成本
|
||||||
|
|
||||||
|
[请至钉钉文档查看「电子表格」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6kdx8zriyiz2dxvtj)
|
||||||
|
|
||||||
|
## 一、发现和挖掘瓶颈
|
||||||
|
|
||||||
|
### 1）是什么瓶颈制约了领先2035团队挖尽市场需求？
|
||||||
|
|
||||||
|
[请至钉钉文档查看「电子表格」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6ke5kocyqhppw0ri)
|
||||||
|
|
||||||
|
### 2）产品赚钱的速度有多大差异？（领先2035应当优先保证哪些产品的交付？）
|
||||||
|
|
||||||
|
[请至钉钉文档查看「电子表格」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6keavwd1b2ncfie6sm)
|
||||||
|
|
||||||
|
### 3）利润最大化的生产计划是什么？(每个产品分别交付多少份)
|
||||||
|
|
||||||
|
[请至钉钉文档查看「电子表格」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6kefvcdog7oagpvcts)
|
||||||
|
|
||||||
|
## 二、充分开发瓶颈
|
||||||
|
|
||||||
|
### 提案1：通过AI介入，提升瓶颈环节的效率
|
||||||
|
|
||||||
|
研讨焦点：
|
||||||
|
|
||||||
|
1. 提升达到多少时，会导致瓶颈漂移？（质变点）
|
||||||
|
|
||||||
|
2. 新的瓶颈因素下，如何安排各产品的交付优先级和交付数量？【步骤2、3】
|
||||||
|
|
||||||
|
|
||||||
|
参见：[《在线工作坊 - 研讨文档》](https://alidocs.dingtalk.com/i/nodes/MyQA2dXW7o49PyjYt2PrNo7QWzlwrZgb?utm_scene=team_space&iframeQuery=anchorId%3Duu_m6ke7u52qpmekk37eks)
|
||||||
|
|
||||||
|
[请至钉钉文档查看「电子表格」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6keykelxzo422jdptr)
|
||||||
|
|
||||||
|
## 三、打破瓶颈
|
||||||
|
|
||||||
|
### 提案1：增加时间资源投入（合作教练参与交付）
|
||||||
|
|
||||||
|
研讨焦点：
|
||||||
|
|
||||||
|
1. 合作教练投入多少时间可以使瓶颈漂移？（质变点）
|
||||||
|
|
||||||
|
2. 在优先派单合作教练交付的情况下，如何安排各产品的交付优先级和交付数量？
|
||||||
|
|
||||||
|
1. 假设1：合作教练不会增加总需求量；
|
||||||
|
|
||||||
|
2. 假设2：合作教练只增加可变成本，不改变其它工序上的时间投入。
|
||||||
|
|
||||||
|
|
||||||
|
[请至钉钉文档查看「电子表格」](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g2qz1pnsQanQ1rQJ9ekBD76?iframeQuery=anchorId%3DX02m6kfij97b5492mqsw8g)
|
||||||
Loading…
Reference in New Issue
Block a user