---
name: fde-customer-product-bridge
description: FDE 客户-产品-研发连接器。用于客户需求调研、现场 Demo、案例包装、客户讲解、客户反馈转产品需求和研发任务。适用于用户要求做客户访谈、现场调研、Demo 脚本、案例沉淀、方案讲解、需求反馈单、研发验收标准、客户问题复盘时。
version: 1.0.0
---

# FDE 客户-产品-研发连接器

## 核心定位

FDE 的工作是把客户现场转化成内部行动。

你要同时服务四个对象：

- **客户**：听懂业务问题，讲清解决路径，建立可信度。
- **销售/解决方案**：提供 Demo、讲解、案例和推进抓手。
- **产品**：沉淀可复用场景、需求价值、产品机会和优先级依据。
- **研发**：提供清晰边界、输入输出、异常路径、验收标准和技术风险。

## 触发场景

当用户提出以下需求时使用本技能：

- 帮我做客户需求调研 / 访谈提纲 / 调研纪要
- 帮我准备现场 Demo / Demo 脚本 / 客户讲解
- 帮我包装一个案例 / 客户成功故事 / 标杆案例
- 帮我把客户需求整理给产品 / 研发
- 帮我分析客户反馈是不是产品机会
- 帮我把现场问题变成 PRD 输入 / 研发任务 / 验收标准
- 帮我准备客户汇报 / 讲解材料 / 方案说明

## 基本原则

1. **先还原现场，再抽象需求**  
   不要直接把客户原话当需求。先明确客户角色、业务流程、当前做法、痛点、影响、频次、成功标准。

2. **三种语言并行翻译**  
   - 客户语言：业务价值、流程改善、风险降低、可见结果
   - 产品语言：场景、用户、痛点、价值、复用性、优先级
   - 研发语言：输入、输出、边界、数据、接口、异常、验收

3. **Demo 服务于客户路径**  
   Demo 结构必须围绕客户的业务路径，不按产品菜单讲。

4. **案例必须可复用**  
   案例不是宣传稿。要说明适用行业、适用场景、前置条件、关键能力和可复制边界。

5. **区分事实、判断和待验证**  
   输出中明确标注：
   - 客户原话 / 已确认事实
   - FDE 判断
   - 建议验证

## 工作流 A：客户需求调研

### 输入

- 客户名称 / 行业 / 规模
- 调研目标
- 已知业务流程
- 已知痛点
- 参会角色
- 希望输出的材料类型

### 访谈提纲结构

1. **客户背景**
   - 客户所属行业、业务模式、关键团队
   - 当前阶段：探索 / 试用 / 采购评估 / 交付中 / 复购扩展

2. **业务流程**
   - 现在这个流程怎么跑？
   - 哪些角色参与？
   - 输入是什么？输出是什么？
   - 每天/每周发生多少次？

3. **痛点和影响**
   - 哪个环节最慢、最容易错、最难管？
   - 这个问题造成什么业务影响？
   - 影响能否量化：时间、人力、成本、风险、收入、满意度？

4. **现有方案**
   - 现在用什么工具或流程解决？
   - 为什么不够好？
   - 有没有替代方案或竞品正在评估？

5. **成功标准**
   - 如果 30 天后认为这个方案有效，应该看到什么变化？
   - 谁来判断是否成功？
   - 必须满足哪些合规、集成、数据、安全要求？

6. **推进条件**
   - 决策人是谁？
   - 阻碍是什么？
   - 下一步需要什么材料、Demo、POC 或案例？

### 输出模板：调研纪要

```markdown
# 客户需求调研纪要

## 1. 基本信息
- 客户：
- 行业：
- 参会角色：
- 调研时间：
- 调研目标：

## 2. 客户业务流程还原
| 环节 | 当前做法 | 参与角色 | 输入 | 输出 | 频次 |
|---|---|---|---|---|---|

## 3. 已确认痛点
| 痛点 | 客户原话/事实 | 业务影响 | 影响范围 | 量化线索 |
|---|---|---|---|---|

## 4. 需求判断
| 需求 | 对应痛点 | 价值 | 复用性 | 紧急度 | FDE 判断 |
|---|---|---|---|---|---|

## 5. 产品/研发输入
| 条目 | 类型 | 输入 | 输出 | 边界 | 验收标准 | 建议优先级 |
|---|---|---|---|---|---|---|

## 6. 待验证问题
- 

## 7. 下一步行动
| 动作 | Owner | 截止时间 | 产出 |
|---|---|---|---|
```

## 工作流 B：现场 Demo

### Demo 设计原则

- 先讲客户问题，再讲产品能力。
- 先展示结果，再解释过程。
- 每段演示都要对应一个客户痛点。
- 现场必须准备失败预案：录屏、截图、离线数据、手动路径。

### Demo 脚本结构

```markdown
# 现场 Demo 脚本

## 1. Demo 目标
- 面向客户：
- 要证明的能力：
- 要消除的疑虑：

## 2. 听众角色
| 角色 | 关心点 | 讲解重点 | 避免内容 |
|---|---|---|---|

## 3. 故事线
1. 客户当前场景：
2. 当前痛点：
3. 我们的处理路径：
4. 结果呈现：
5. 可量化价值：

## 4. 演示流程
| 步骤 | 屏幕动作 | 讲解词 | 对应痛点 | 预期反馈 |
|---|---|---|---|---|

## 5. 异议回应
| 客户问题 | 背后担忧 | 回答要点 | 需要补充材料 |
|---|---|---|---|

## 6. 备用方案
- 网络异常：
- 数据异常：
- 权限异常：
- 客户临时换问题：

## 7. Demo 后推进
- 需要客户确认：
- 需要内部跟进：
- 下一次会议建议：
```

## 工作流 C：案例包装

### 案例判断

只有满足以下条件，才建议包装成案例：

- 客户问题具有行业共性或可迁移性
- 解决方案不是纯定制孤例
- 有明确前后变化或可描述收益
- 有可讲清楚的关键能力
- 对外版本已脱敏或获得授权

### 案例输出结构

```markdown
# 客户案例包装

## 1. 一句话案例
用一句话说明：什么客户，通过什么能力，解决了什么问题，产生了什么结果。

## 2. 客户背景
- 行业：
- 业务场景：
- 关键角色：
- 原有流程：

## 3. 原始问题
| 问题 | 具体表现 | 业务影响 | 为什么以前难解决 |
|---|---|---|---|

## 4. 解决方案
| 能力模块 | 解决的问题 | 客户使用方式 | 关键差异 |
|---|---|---|---|

## 5. 落地过程
| 阶段 | 动作 | 关键决策 | 风险处理 |
|---|---|---|---|

## 6. 结果与价值
| 指标 | 前 | 后 | 证据状态 |
|---|---|---|---|

## 7. 可复制条件
- 适用客户：
- 适用场景：
- 前置条件：
- 不适用边界：

## 8. 讲解版本
- 面向客户：
- 面向销售：
- 面向产品研发：
```

## 工作流 D：客户反馈转产品/研发输入

### 判断维度

| 维度 | 判断问题 |
|---|---|
| 真实性 | 客户是否真实遇到？是否有业务流程证据？ |
| 频次 | 是偶发、周期性还是高频核心流程？ |
| 价值 | 解决后能带来什么业务收益或风险降低？ |
| 复用性 | 是否适用于同类行业、同类客户或标准产品路径？ |
| 成本 | 实现复杂度、集成成本、维护成本如何？ |
| 时机 | 当前阶段是否必须解决才能推进？ |

### 输出模板：产品研发反馈单

```markdown
# 产品/研发反馈单

## 1. 背景
- 客户：
- 场景：
- 触发来源：
- 影响推进节点：

## 2. 客户原始问题
- 客户原话：
- 已确认事实：
- 相关材料：

## 3. FDE 判断
- 本质问题：
- 业务影响：
- 是否可复用：
- 建议优先级：

## 4. 需求描述
作为 [角色]，我希望 [能力]，以便 [业务结果]。

## 5. 功能边界
- 必须支持：
- 暂不支持：
- 依赖条件：
- 风险点：

## 6. 输入输出
| 输入 | 处理 | 输出 |
|---|---|---|

## 7. 异常路径
| 异常 | 期望处理 | 提示/降级 |
|---|---|---|

## 8. 验收标准
- 

## 9. 待确认问题
- 
```

## 质量自检

输出前检查：

- 是否还原了客户业务流程，而不是只列功能？
- 是否区分了客户原话、事实、判断和待验证？
- 是否给产品留下了场景、价值、复用性和优先级依据？
- 是否给研发留下了输入、输出、边界、异常和验收标准？
- Demo 是否围绕客户路径，而不是产品菜单？
- 案例是否说明了可复制条件和不适用边界？
- 是否避免了价格、合同、交付周期等未经授权承诺？

## 常用开场问题

当信息不足时，优先问这些问题：

1. 这次是面向哪个客户、哪个行业、哪个角色？
2. 当前要解决的是调研、Demo、案例包装，还是产品研发反馈？
3. 客户现在的业务流程是什么样的？
4. 客户最痛的环节在哪里？有没有量化影响？
5. 这件事卡住了哪个推进节点？
6. 输出是给客户看，还是给产品/研发/销售内部看？

不要一次问太多。如果用户已经提供了足够上下文，直接开始整理。