- name
- deai-consult
- description
- 咨询方案设计与交付。使用时:需要为客户/企业产出结构化咨询方案(诊断报告/解决方案/实施计划)时。基于培训咨询知识库咨询方法论(Block 完美咨询流程、Weinberg 咨询的奥秘、德鲁克咨询思维),流程:接洽→诊断→方案→实施→复盘。产出咨询方案书、诊断报告、实施路线图。
- user-invocable
- true
# `deai-consult` — 咨询方案设计与交付
## When to Use
- 客户提出咨询需求,需要系统化响应(诊断→方案→实施)
- 需要将专业经验/课程能力转化为咨询交付物
- 需要产出结构化的咨询方案书
## Input
- 咨询需求(客户描述的问题)或用户指定主题
- 可选:`deai-knowledge` 素材库 → `素材库/培训方法论/` 咨询方法论卡片
## Output
- `consulting/{项目名}/需求理解.md`(问题澄清)
- `consulting/{项目名}/诊断报告.md`(现状诊断)
- `consulting/{项目名}/解决方案.md`(方案设计)
- `consulting/{项目名}/实施路线图.md`(落地计划)
---
## 核心理念
**咨询不是"给答案",是"帮客户找到并解决真正的问题"**。咨询顾问的最大价值不是知识(信息已不稀缺),而是:
1. **问题定义能力**——客户描述的"问题"往往不是真问题
2. **业务洞察能力**——把问题放到业务/组织/行业的框架里看
3. **方案落地能力**——方案要能被执行,不是停留在 PPT
**方法论来源**(培训咨询知识库):
- **Block《完美咨询》**:客户-顾问互动关系管理(接洽/签约/诊断/反馈/实施)
- **Weinberg《咨询的奥秘》**:咨询中的沟通与人际动力学("解决问题"前先解决"人与关系")
- **德鲁克咨询思维**:从"管理问题"而非"技术问题"切入,关注组织的真实目标
---
## Procedure
### Step 1:需求理解(Block 接洽阶段——澄清问题)
客户带来的往往是"症状描述",需要澄清为"问题定义"。用**问题澄清四问**:
| 问题 | 目的 |
|------|------|
| **这是谁的问题?** | 确定问题主体(老板/部门/一线),不同主体的"问题"不同 |
| **怎么知道这是问题?** | 让客户给出**可观察的证据**(数据/事件/影响),拒绝模糊表述 |
| **如果解决了会怎样?** | 明确成功标准(解决后能看到什么变化) |
| **解决不了会怎样?** | 明确不解决的代价(判断问题优先级) |
**输出**:需求理解.md——问题描述、成功标准、范围边界(做什么/不做什么)
**⚠️ 咨询红线**:
- 不承接"客户已经决定了答案,只是要你论证"的单(除非明确说明是论证项目)
- 不做超出专业范围的承诺
- 方案必须对客户诚实("这个需求可能不合理"也要说)
### Step 2:诊断(Block 诊断阶段——找到真问题)
诊断不是"调查现状",是**验证/推翻初始假设**:
```
初始假设(来自 Step 1)→ 数据收集 → 假设验证 → 根因分析 → 诊断结论
```
**诊断框架**(三视角):
| 视角 | 分析维度 | 方法 |
|------|----------|------|
| **业务视角** | 业务目标、商业模式、价值链条 | 业务访谈 + 数据分析 |
| **组织视角** | 组织结构、流程、决策机制、部门墙 | 组织访谈 + 流程梳理 |
| **能力视角** | 人员能力、知识体系、工具方法 | 能力评估 + 对标分析 |
**诊断输出**(诊断报告.md):
- 现状描述(事实,非评价)
- 关键发现(3-5 条,每条 = 证据 + 影响)
- **根因分析**(用"5 为什么"或因果链,区分表面原因与根本原因)
- 问题优先级排序(影响 × 紧迫性)
### Step 3:方案设计(德鲁克思维——回到组织目标)
方案不是"建议清单",是**指向目标的系统性设计**:
| 方案要素 | 说明 |
|----------|------|
| **目标对齐** | 方案如何支撑客户的业务/组织目标(先讲清楚"为什么做") |
| **核心策略** | 3 条以内主策略(太多 = 没有策略) |
| **行动举措** | 每条策略分解为 2-4 个可执行举措(谁/做什么/何时/交付物) |
| **资源需求** | 时间/人力/预算/工具 |
| **风险预案** | 关键风险 + 应对 + 触发条件 |
| **衡量指标** | 每个举措的 KPI + 数据来源 |
**方案书结构**(解决方案.md):
```markdown
# 解决方案 · {项目名}
## 一、执行摘要
{3 段话:问题是什么、建议做什么、预期效果}
## 二、目标对齐
{方案与客户业务目标的连接}
## 三、核心策略(≤3 条)
### 策略一:{名称}
- 逻辑:{为什么这么做}
- 举措:
1. {举措}(负责人/周期/交付物)
2. ...
- KPI:{指标}
### 策略二:...
### 策略三:...
## 四、资源与预算
| 资源 | 需求 |
|------|------|
## 五、风险与预案
| 风险 | 影响 | 应对 | 触发条件 |
|------|:----:|------|----------|
## 六、衡量体系
{整体 KPI + 数据来源 + 回顾节奏}
```
### Step 4:实施路线图(落地计划)
```markdown
# 实施路线图 · {项目名}
## 阶段划分
| 阶段 | 周期 | 目标 | 关键交付物 | 里程碑 |
|:----:|:----:|------|-----------|--------|
| 阶段1 启动 | 2 周 | 建立机制 | 项目章程/工作小组 | 启动会 |
| 阶段2 诊断 | 3 周 | 摸清现状 | 诊断报告 | 诊断汇报 |
| 阶段3 方案 | 2 周 | 明确路径 | 解决方案 | 方案评审 |
| 阶段4 试点 | 4 周 | 小范围验证 | 试点报告 | 试点复盘 |
| 阶段5 推广 | 4 周 | 全面落地 | 推广计划 | 结项评估 |
## 沟通机制
- 周报:{节奏}
- 里程碑汇报:{节奏}
- 决策升级路径:{谁/什么情况}
## 成功标准
{Step 1 定义的"如果解决了会怎样"}
```
### Step 5:咨询关系管理(Block——客户-顾问关系)
| 原则 | 做法 |
|------|------|
| **诚实** | 发现方案问题及时提出,不"报喜不报忧" |
| **边界** | 明确咨询范围,不越界承诺(如咨询不代执行) |
| **交接** | 方案最终要客户能自己跑起来(知识转移) |
| **复盘** | 项目结束做复盘:目标达成度/客户满意度/经验沉淀 |
---
## 与自媒体/课程业务的协同
| 场景 | 说明 |
|------|------|
| 文章→咨询入口 | 自媒体文章带来咨询线索(联动 deai-instructor-ip 的引流定位) |
| 课程→咨询 | 课程交付发现企业共性问题 → 咨询项目(deai-course 协同) |
| 咨询→文章 | 咨询案例(脱敏后)反哺文章素材与选题(notebook 沉淀) |
| 咨询→课程 | 高频共性问题标准化为课程(deai-course) |
## Calling Examples
```text
@deai-consult 客户咨询"业务增长乏力"怎么响应
@deai-consult 诊断 XX 公司的用户增长问题
@deai-consult 为 XX 项目输出实施路线图
```
## Reference
- 方法论:培训咨询知识库 Block《完美咨询》/Weinberg《咨询的奥秘》/德鲁克(经 deai-knowledge 检索)
- 协同:`deai-instructor-ip`(咨询定位)、`deai-course`(问题标准化为课程)
- 合规:咨询方案涉及企业数据需脱敏,不做敏感承诺
在 GitHub 查看