AI 项目失败，八成不是技术不行，而是需求没摸清。客户说的、想的、需要的经常是三件事，直接把原话当需求，方案一定跑偏。这个分类的 8 个 Skills 覆盖了需求发现的完整链路：怎么访谈、怎么画流程、怎么拆问题、怎么对高层沟通、怎么管理预期。我们在这上面花的时间，从来都是项目里回报率最高的。

AIBP-Collaboration-Playbook

与 AIBP 的协作边界不清，是项目里最常见的内耗来源：谁负责业务理解、谁负责模型交付、共创机制怎么运转。这份 Playbook 把这些灰色地带画成了清晰的责任线。

FDE 与 AIBP 职责模糊，Ground Truth 缺失，Demo 与业务效果脱节。

适用场景

• PoC 组队
• 周度 Demo
• 验收争议
• 扩展场景
• 运营移交

问题定义

FDE 与 AIBP 职责模糊，Ground Truth 缺失，Demo 与业务效果脱节。

方法论框架

分工：AIBP=业务好结果+Ground Truth；FDE=稳定交付+技术资产。 机制：场景卡共创、周度 Demo 双负责人、失败样本共审、上线门禁联签。 会议：Kickoff/场景评审/周度Demo/失败复盘/上线门禁。

输入 / 输出

输入

• 项目角色名单
• 场景卡草稿
• 会议日历

输出

• 协作章程
• 场景卡（双签）
• 周度 Demo 模板
• RACI 表
• 升级路径

执行步骤

1. 定义 RACI
2. 共创场景卡
3. 建立周度 Demo 节奏
4. 共建 Golden Dataset
5. 联签上线门禁
6. 运营移交

常见误区

• AIBP 不参与样本
• FDE 独自定义验收
• 无周度节奏
• 运营移交断层

交付物清单

• 协作章程
• RACI
• 场景卡
• Demo 模板

与国内 FDE 生态关联

敏捷小组协作落地；国内 FDE+AIBP 双负责人模式。

关联 Skill

推荐组合

• Stakeholder-Mapping — 双负责人识别
• FDE-Adoption-Growth — 运营移交与采纳
• RAG-Evaluation — Ground Truth 共建

场景深潜

场景 1：PoC 组队

触发信号：PoC/Beta/生产任一阶段出现「PoC 组队」相关诉求、阻塞或复盘需求。

关键动作：定义 RACI

FDE 注意：避免 AIBP 不参与样本

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 2：周度 Demo

触发信号：PoC/Beta/生产任一阶段出现「周度 Demo」相关诉求、阻塞或复盘需求。

关键动作：共创场景卡

FDE 注意：避免 FDE 独自定义验收

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 3：验收争议

触发信号：PoC/Beta/生产任一阶段出现「验收争议」相关诉求、阻塞或复盘需求。

关键动作：建立周度 Demo 节奏

FDE 注意：避免 无周度节奏

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 4：扩展场景

触发信号：PoC/Beta/生产任一阶段出现「扩展场景」相关诉求、阻塞或复盘需求。

关键动作：共建 Golden Dataset

FDE 注意：避免 运营移交断层

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 5：运营移交

触发信号：PoC/Beta/生产任一阶段出现「运营移交」相关诉求、阻塞或复盘需求。

关键动作：联签上线门禁

FDE 注意：避免 AIBP 不参与样本

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

资源：查看该 Skill 原文 ｜ 下载完整技能包（ZIP，含 Prompt / 清单 / 模板）

Business-Interview

结构化业务访谈是 Discovery 的起点。它把"聊天"变成有产出物的过程：访谈提纲怎么写、追问怎么设计、信息怎么记录，目标是两轮访谈之内拿到够写方案的信息量。

客户表述多为解决方案而非问题，FDE 若直接接需求将建错系统。

适用场景

• 项目初期需求挖掘
• 场景评审前
• PoC 失败后重访
• 扩展新场景前

问题定义

客户表述多为解决方案而非问题，FDE 若直接接需求将建错系统。

方法论框架

访谈结构：背景 → 痛点 → 现有流程 → 成功标准 → 约束 → 样本。 技巧：5 Why、流程走查、异常场景追问、价值量化。

输入 / 输出

输入

• 访谈对象与角色
• 访谈提纲
• 保密协议状态

输出

• 访谈纪要
• 痛点清单
• 流程摘要
• 初步指标假设

执行步骤

1. 准备提纲与样本请求
2. 执行 45-60min 访谈
3. 当天发纪要确认
4. 提炼痛点与指标
5. 输入问题树/DIVE

常见误区

• 只问功能不问流程
• 未索要真实样本
• 纪要未书面确认

交付物清单

• 访谈纪要
• 痛点优先级
• 样本清单

与国内 FDE 生态关联

Discovery 入口；输出喂给 Consultative-Problem-Solving 和 PRD-Generator。

关联 Skill

推荐组合

• Consultative-Problem-Solving — 访谈输出喂给问题树
• Process-Mapping — 流程走查深化
• PRD-Generator — 需求规格化

外部工程参考

• .agents/skills/growth-user-interview

场景深潜

场景 1：项目初期需求挖掘

触发信号：PoC/Beta/生产任一阶段出现「项目初期需求挖掘」相关诉求、阻塞或复盘需求。

关键动作：准备提纲与样本请求

FDE 注意：避免 只问功能不问流程

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 2：场景评审前

触发信号：PoC/Beta/生产任一阶段出现「场景评审前」相关诉求、阻塞或复盘需求。

关键动作：执行 45-60min 访谈

FDE 注意：避免 未索要真实样本

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 3：PoC 失败后重访

触发信号：PoC/Beta/生产任一阶段出现「PoC 失败后重访」相关诉求、阻塞或复盘需求。

关键动作：当天发纪要确认

FDE 注意：避免 纪要未书面确认

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 4：扩展新场景前

触发信号：PoC/Beta/生产任一阶段出现「扩展新场景前」相关诉求、阻塞或复盘需求。

关键动作：提炼痛点与指标

FDE 注意：避免 只问功能不问流程

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

资源：查看该 Skill 原文 ｜ 下载完整技能包（ZIP，含 Prompt / 清单 / 模板）

Consultative-Problem-Solving

Issue Tree 把大问题拆成可验证的子问题，DIVE 框架保证每个分支有结论。咨询式拆解的价值在于让方案讨论从"感觉"回到"证据"——每个论点背后都有一个待验证的假设。

客户表层诉求常是「做智能体平台」，真实问题是流程、数据、组织或价值优先级。

适用场景

• 客户要平台而非场景
• 需求冲突多
• PoC 方向不明
• 售前方案梳理

问题定义

客户表层诉求常是「做智能体平台」，真实问题是流程、数据、组织或价值优先级。

方法论框架

Issue Tree（问题树）

表层诉求 → 业务问题 → 数据问题 → 流程问题 → 组织问题

DIVE 模型

1. Diagnose：瓶颈在数据/流程/系统/组织？
2. Identify：价值属于降本/增效/提质/控险/增长？
3. Validate：最小 PoC 假设与指标？
4. Embed：谁用/谁审/谁负责？如何嵌入流程？

MECE 原则

同级问题相互独立、完全穷尽，避免遗漏合规或权限维度。

输入 / 输出

输入

• 客户需求描述
• 访谈纪要
• 流程图
• 组织背景

输出

• Issue Tree
• DIVE 分析表
• PoC 核心假设
• 验证计划
• 场景卡草稿

执行步骤

1. 重述表层诉求
2. 建 Issue Tree（MECE）
3. DIVE 逐层分析
4. 提炼 1-3 个 PoC 假设
5. 定义验证指标
6. 场景评审对齐

常见误区

• 直接接平台需求
• 问题树不够 MECE
• PoC 假设过多
• 未定义 Embed 责任人

交付物清单

• 问题树
• DIVE 表
• PoC 假设清单
• 场景卡

与国内 FDE 生态关联

国内 FDE 咨询式交付核心；China-FDE-Consulting-Pattern 的方法论单元。

关联 Skill

推荐组合

• China-FDE-Consulting-Pattern — 咨询式交付总纲
• MECE — 问题树 MECE 校验
• Process-Mapping — Embed 流程嵌入点

外部工程参考

• .agents/skills/enterprise-sales

场景深潜

场景 1：客户要平台而非场景

触发信号：PoC/Beta/生产任一阶段出现「客户要平台而非场景」相关诉求、阻塞或复盘需求。

关键动作：重述表层诉求

FDE 注意：避免 直接接平台需求

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 2：需求冲突多

触发信号：PoC/Beta/生产任一阶段出现「需求冲突多」相关诉求、阻塞或复盘需求。

关键动作：建 Issue Tree（MECE）

FDE 注意：避免 问题树不够 MECE

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 3：PoC 方向不明

触发信号：PoC/Beta/生产任一阶段出现「PoC 方向不明」相关诉求、阻塞或复盘需求。

关键动作：DIVE 逐层分析

FDE 注意：避免 PoC 假设过多

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 4：售前方案梳理

触发信号：PoC/Beta/生产任一阶段出现「售前方案梳理」相关诉求、阻塞或复盘需求。

关键动作：提炼 1-3 个 PoC 假设

FDE 注意：避免 未定义 Embed 责任人

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

资源：查看该 Skill 原文 ｜ 下载完整技能包（ZIP，含 Prompt / 清单 / 模板）

Executive-Communication-Framework

对高层讲价值，对中层讲流程，对一线讲操作。这个框架帮你把同一件事按决策者的语言重新组织：投资回报、风险边界、里程碑，三页讲清，不浪费高层的时间。

高层没时间看技术细节，FDE 若不会讲 ROI 和决策选项，项目难获持续支持。

适用场景

• 立项汇报
• 阶段复盘
• 预算追加
• 续约
• 失败止损决策

问题定义

高层没时间看技术细节，FDE 若不会讲 ROI 和决策选项，项目难获持续支持。

方法论框架

金字塔结构：结论 → 3 个论据 → 数据 → 建议行动。 高管关心：ROI、风险、时间、竞品、组织影响、退出选项。 一页纸：问题/方案/指标/投入/风险/决策请求。

输入 / 输出

输入

• 场景卡
• 指标数据
• 竞品/行业对标
• 预算实际

输出

• 高管一页纸
• 汇报 Deck 大纲
• 决策选项表
• ROI 简版

执行步骤

1. 明确决策请求
2. 提炼 3 条论据
3. 量化 ROI
4. 准备风险与选项
5. 15min 预演
6. 汇报+纪要

常见误区

• 讲技术不讲决策
• ROI 无依据
• 缺少退出选项
• 汇报超时

交付物清单

• 高管一页纸
• Deck
• ROI 表

与国内 FDE 生态关联

高层沟通场景；与 FDE-Adoption-Growth 续约场景联动。

关联 Skill

推荐组合

• FDE-Adoption-Growth — 续约与价值播报
• Expectation-Management-Script — ROI 叙事中的边界声明
• McKinsey-Report — 行研报告与 Deck 故事线

场景深潜

场景 1：立项汇报

触发信号：PoC/Beta/生产任一阶段出现「立项汇报」相关诉求、阻塞或复盘需求。

关键动作：明确决策请求

FDE 注意：避免 讲技术不讲决策

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 2：阶段复盘

触发信号：PoC/Beta/生产任一阶段出现「阶段复盘」相关诉求、阻塞或复盘需求。

关键动作：提炼 3 条论据

FDE 注意：避免 ROI 无依据

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 3：预算追加

触发信号：PoC/Beta/生产任一阶段出现「预算追加」相关诉求、阻塞或复盘需求。

关键动作：量化 ROI

FDE 注意：避免 缺少退出选项

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 4：续约

触发信号：PoC/Beta/生产任一阶段出现「续约」相关诉求、阻塞或复盘需求。

关键动作：准备风险与选项

FDE 注意：避免 汇报超时

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 5：失败止损决策

触发信号：PoC/Beta/生产任一阶段出现「失败止损决策」相关诉求、阻塞或复盘需求。

关键动作：15min 预演

FDE 注意：避免 讲技术不讲决策

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

资源：查看该 Skill 原文 ｜ 下载完整技能包（ZIP，含 Prompt / 清单 / 模板）

Expectation-Management-Script

AI 是概率性系统，100% 准确的承诺迟早变成事故。这套话术帮你在售前和启动阶段就把边界讲透：能做什么、不能做什么、错了怎么办。预期管理做在前面，交付时才有惊喜可言。

业务方按传统软件预期 AI，一次错误即否定全部价值，项目夭折。

适用场景

• PoC 启动
• Demo 后
• 效果争议时
• 上线前
• 续约谈判

问题定义

业务方按传统软件预期 AI，一次错误即否定全部价值，项目夭折。

方法论框架

核心信息：概率性、幻觉、错误率、人审策略、迭代路径、上线边界。 话术结构：承认局限 → 解释原因 → 给指标 → 给人审 → 给迭代计划。

输入 / 输出

输入

• 当前指标
• 失败样本
• 客户投诉点
• 合同范围

输出

• 预期管理话术包
• 指标解释一页纸
• 人审策略说明
• 迭代路线图

执行步骤

1. 梳理客户当前预期
2. 对比实际能力
3. 准备指标与样本
4. 编写分角色话术
5. 周度 Demo 持续校准
6. 书面确认边界

常见误区

• 过度承诺准确率
• 回避谈幻觉
• 缺少人审方案
• 不展示失败样本

交付物清单

• 话术包
• 指标一页纸
• 人审流程图

与国内 FDE 生态关联

预期管理落地；与 Executive-Communication 互补。

关联 Skill

推荐组合

• Executive-Communication-Framework — 高层预期校准
• Communication-Script-Library — 分角色话术库
• FDE-Adoption-Growth — 采纳阶段预期管理

场景深潜

场景 1：PoC 启动

触发信号：PoC/Beta/生产任一阶段出现「PoC 启动」相关诉求、阻塞或复盘需求。

关键动作：梳理客户当前预期

FDE 注意：避免 过度承诺准确率

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 2：Demo 后

触发信号：PoC/Beta/生产任一阶段出现「Demo 后」相关诉求、阻塞或复盘需求。

关键动作：对比实际能力

FDE 注意：避免 回避谈幻觉

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 3：效果争议时

触发信号：PoC/Beta/生产任一阶段出现「效果争议时」相关诉求、阻塞或复盘需求。

关键动作：准备指标与样本

FDE 注意：避免 缺少人审方案

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 4：上线前

触发信号：PoC/Beta/生产任一阶段出现「上线前」相关诉求、阻塞或复盘需求。

关键动作：编写分角色话术

FDE 注意：避免 不展示失败样本

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

场景 5：续约谈判

触发信号：PoC/Beta/生产任一阶段出现「续约谈判」相关诉求、阻塞或复盘需求。

关键动作：周度 Demo 持续校准

FDE 注意：避免 过度承诺准确率

成功标志：交付物清单勾选，evaluation.md 达标，AIBP/业务 Owner 书面确认。

资源：查看该 Skill 原文 ｜ 下载完整技能包（ZIP，含 Prompt / 清单 / 模板）

FDE Issue Tree Analysis

与咨询式拆解配套使用：issue tree 诊断加证据闭环。每个假设都要找到数据或访谈证据支撑，找不到就降级为"待验证"，避免方案建立在想象之上。

Use when diagnosing ambiguous customer-site FDE problems with Issue Tree, MECE, hypothesis-driven analysis, and evidence loops. Helps turn vague complaints such as poor AI knowledge-base quality, unstable agents, low workflow adoption, unclear PoC ROI, permissions blockers, or data-quality issues into verifiable hypotheses, experiments, action plans, and stage-gate decisions.

When To Use

• The customer says an AI system, knowledge base, agent, automation, or PoC "does not work well" but the root cause is unclear.
• The user needs an Issue Tree, MECE check, root-cause hypotheses, evidence plan, or validation experiments.
• The team is preparing for PoC review, Beta blocker diagnosis, production incident review, or delivery retrospective.
• The problem spans business goals, data, technical chain, process embedding, permissions, security, adoption, or ownership.

How To Use

1. Read README.md for the ISSUE-FDE framework and delivery gates.
2. Use prompt.md for general diagnosis, RAG diagnosis, interview evidence gathering, or MECE self-check.
3. Use checklist.md to verify the tree, hypotheses, evidence plan, and action loop.
4. Use evaluation.md to assess whether the diagnosis is review-ready.
5. Use examples in examples/ when the problem resembles an AI knowledge-base diagnosis.

Output Expectations

Produce a structured diagnosis that includes:

• Problem statement, scope boundary, impact object, and current-stage risk.
• Level 1 to Level 3 Issue Tree with MECE checks.
• Top hypotheses prioritized by impact, evidence availability, and validation cost.
• Evidence requirements and validation experiments.
• FDE action plan with owner, dependency, deliverable, timeline, and regression metric.
• Stage-gate conclusion for PoC, Beta, production, or retrospective.

Do not treat symptoms as root causes. Every leaf node should be testable with data, samples, logs, interviews, or metrics.