p0-needs-orchestrator

---
name: p0-needs-orchestrator
version: 1.1.0
description: 需求发现编排器。协调微需求检测、真需求验证、需求拆解、需求考古、好问题生成、Agent 边界设计、多元推荐改写、AI 产品三重平衡八个工具卡，
  按顺序执行并输出完整的需求发现报告。自包含——八个工具卡的核心方法已内嵌。
  基于《AI rebuild product needs》读者工具箱。
author: Max
tags:
  - p0
  - 需求发现
  - 编排器
  - book-skill
  - needs-discovery
  - orchestrator
  - ai-product
requires: []
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p0-needs-orchestrator
stage: p0
source_book: AI rebuild product needs
source_chapter: 编排器
absorbed_skills:
  - p0a-micro-needs-detector
  - p0b-real-needs-validator
  - p0c-needs-decomposer
  - p0d-needs-archaeologist
  - p0e-good-question-generator
  - p0f-agent-boundary-designer
  - p0g-diverse-recommendation-rewriter
  - p0h-ai-product-triple-balance

---


# 需求发现编排器

## 一句话定位

从一个模糊的痛点线索出发，系统性地跑完六个工具卡，输出可直接进入方向定界的需求发现报告。

## 何时触发

- 你有一个产品想法或痛点线索，需要系统性验证
- 需要从需求发现到方向定界的完整过程
- 想要确保需求判断有结构化依据

## 输入

一个模糊的产品想法或痛点描述。

**示例输入**：
```
"我想做一个 AI 客服产品，帮企业自动回复客户问题"
```

## 编排流程

```
用户输入
  ↓
【Step 1: 微需求检测】p0a-micro-needs-detector
  → 输出: 是否存在被忽视的微需求
  ↓
【Step 2: 需求四层拆解】p0c-needs-decomposer
  → 输出: 表达层/场景层/处境层/代价层
  ↓
【Step 3: 真需求验证】p0b-real-needs-validator
  → 输出: 真/伪需求判断
  ↓
【Step 4: 需求考古】p0d-needs-archaeologist
  → 输出: 深层需求 + 历史约束
  ↓
【Step 5: 好问题生成】p0e-good-question-generator
  → 输出: 六维度研究问题
  ↓
【Step 6: Agent 边界设计】p0f-agent-boundary-designer
  → 输出: 完整边界文档
  ↓
输出: 需求发现报告
```

## 每个 Step 的输入输出

### Step 1: 微需求检测

**输入**：用户原始想法
**输出**：
```yaml
micro_needs:
  found: true/false
  needs: ["发现的微需求列表"]
  recommendation: "是否需要重新定义问题"
```

### Step 2: 需求四层拆解

**输入**：用户原始想法
**输出**：
```yaml
decomposition:
  layer1: "表达层"
  layer2: "场景层"
  layer3: "处境层"
  layer4: "代价层"
  reframed_problem: "重定义的问题"
```

### Step 3: 真需求验证

**输入**：重定义后的需求
**输出**：
```yaml
validation:
  is_real: true/false
  pass_count: "X/5"
  confidence: "high/medium/low"
  if_fake: "如果是伪需求，真正的问题可能是"
```

### Step 4: 需求考古

**输入**：已验证的需求
**输出**：
```yaml
archaeology:
  deep_need: "深层需求"
  constraints: ["约束条件"]
  historical_attempts: ["历史尝试"]
  productizable: "yes/no"
```

### Step 5: 好问题生成

**输入**：深层需求
**输出**：
```yaml
good_questions:
  dimensions: ["六个维度的问题"]
  best_question: "最佳研究问题"
  research_direction: "研究方向"
```

### Step 6: Agent 边界设计

**输入**：产品场景
**输出**：
```yaml
boundary:
  decision: "决策权边界"
  data: "数据边界"
  action: "行为边界"
  responsibility: "责任边界"
  human_ai: "人机协作边界"
```

## 工具卡方法详解（自包含）

以下八个工具卡已合并到编排器中，不再作为独立 Skill 存在。每个工具卡的核心方法浓缩为 1-2 句话，便于快速参考。

### § p0a: 微需求五问检测器

用五个问题检测那些"太小不值得做"的问题是否是真正的产品起点：(1) 是否每天发生但每次很小？(2) 用户是否已发展出稳定 workaround？(3) 不做的话谁在默默承担代价？(4) 负担是否带着羞耻/疲惫/责任风险而不易表达？(5) 系统一旦接住，用户体感是否明显变轻？微需求靠重复出现的代价成立，不靠声量成立。

### § p0b: 真需求判断五问

五问给团队装刹车——三问答不扎实先不做方案：(1) 是否长期存在？(2) 让谁持续付出了什么代价？(3) 用户有没有为它发展出补偿行为？(4) 背后是不是有结构而不只是偏好？(5) 没人讨论它还会不会继续存在？真需求靠现实反复支付，伪需求靠热度和顺滑感成立。

### § p0c: 需求四层拆解

把用户原话逐层拆到表达层（用户原话是什么）、场景层（问题发生在何时何地与谁有关）、处境层（为什么被困住、谁在补位党底）、代价层（不接住会持续损失什么），最终重定义问题。任何一层说不清，先不进方案讨论。

### § p0d: 需求考古五步法

五步挖掘深层需求：(1) 现状层——描绘当前"正常"是什么；(2) 历史层——追溯"正常"是怎么来的；(3) 约束层——识别让大家不能做更好的约束条件；(4) 失败层——分析之前尝试过什么、为什么没成功、留下了什么遗产；(5) 深层需求层——提取真正要解决的问题。用户说出来的需求是最新的土壤层，真正的需求往往埋得更深。

### § p0e: 好问题六维观察表

从六个维度发现好问题：用户维度（用户在做什么/想什么/痛什么）、任务维度（任务流程哪里卡住）、系统维度（各系统怎么关联哪里是瓶颈）、组织维度（角色分工与权力分布）、时间维度（过去/现在/未来的变化）、对比维度（别人怎么做的有什么可借鉴）。好问题让正确的答案自然浮现。

### § p0f: Agent 边界清单

系统定义 AI 的五类边界：决策权边界（能不能做决定）、数据边界（能不能访问什么数据）、行为边界（能不能做什么行为）、责任边界（出了问题谁负责）、人机协作边界（什么时候停下来等人）。好的 Agent 边界不是限制 AI 能力，而是让 AI 在安全范围内发挥最大价值。

### § p0g: 多元推荐改写清单

从"猜你喜欢"进化到"帮你发现"：五个改写维度——推荐目标重定义（准确性→价值发现）、多元性引入（多算法混合七种推荐类型）、控制权交还用户（可切换/可解释/可关闭）、透明度设计（可解释推荐）、评估指标升级（准确率+多样性+用户成长）。附带审计六项检查：目标函数多样性、用户主动切换探索模式、低冲突异质内容入口、现实世界连接、新可能性衡量、跳出默认轨迹。多元推荐不是精度的对立面，而是对单一目标精度的修正。

### § p0h: AI 产品三重平衡表

评估商业（能不能创造价值）、人性（对人有没有侵害）、技术（能不能做到）三个维度的平衡。权衡规则：人性风险不可逆则人性优先；技术不成熟但商业机会重大可先 MVP 验证；技术能力不决定人性边界，人性边界决定技术能用多少。附带三层评估伴侣——商业层（长期成本 vs. 价值是否靠高成本堆出）、人性层（负担转移 vs. 主体性保留是否让人更依赖）、文化层（训练了什么价值观现实扩大还是缩小）。核心规则：如果只有商业层有答案，先不要推进。

## 综合输出格式

```yaml
needs_discovery_report:
  input: "原始想法"
  
  executive_summary:
    verdict: "需求是否成立"
    confidence: "high/medium/low"
    key_finding: "最重要的发现"
    recommendation: "建议动作"
  
  detailed_findings:
    micro_needs: "Step 1 结果"
    decomposition: "Step 2 结果"
    validation: "Step 3 结果"
    archaeology: "Step 4 结果"
    good_questions: "Step 5 结果"
    boundary: "Step 6 结果"
  
  next_steps:
    if_proceed: "如果继续，进入方向定界的准备"
    if_revisit: "如果需要回顾，重新定义的方向"
    if_stop: "如果停止，为什么"
  
  artifacts:
    direction_brief_input: "可以直接作为 ai-native-direction-framing 输入的内容"
```

## 使用方式

### 方式一：完整流程

```
我有一个想法: [描述]
帮我跑完需求发现流程
```

### 方式二：单独调用某个工具卡

```
帮我用微需求五问检测这个场景: [描述]
帮我做需求四层拆解: [需求]
帮我验证这个需求是不是真需求: [需求]
```

### 方式三：跳过某些步骤

```
需求已经验证过了，直接进入需求考古
边界设计已经有了，跳过 Step 6
```

## 与其他 Skill 的关系

- **上游输入**：用户的灵感、痛点、市场观察
- **下游输出**：ai-native-direction-framing（方向定界）
- **并行使用**：可以在 p1 过程中反复调用验证

## 一句判断

> 需求发现不是一次性活动，而是持续验证的过程。每个工具卡都是一个检查点，而不是最终答案。

## 核心概念

### 概念一：编排的本质——不是串行执行，而是构建判断链

需求发现编排器不是简单地把六个工具卡串起来跑一遍。它的核心价值在于：每一步的输出改变下一步的输入，形成一条不断收紧的判断链。

```
模糊想法 → 微需求检测（是否有被忽视的小问题）
         → 四层拆解（问题到底在哪一层）
         → 真需求验证（这个问题值不值得做）
         → 需求考古（深层需求是什么）
         → 好问题生成（怎么研究这个问题）
         → 边界设计（AI 能做到哪里）
```

> 编排器的价值不是"帮你跑完六个步骤"，而是"在每一步告诉你该不该继续"。

### 概念二：六步之间的依赖关系

步骤之间不是平等的——前面的步骤决定后面的步骤是否有意义：

| 依赖关系 | 含义 |
|----------|------|
| Step 1 → Step 2 | 如果微需求检测发现需要重新定义问题，Step 2 应该基于新定义 |
| Step 2 → Step 3 | 四层拆解不清楚时，真需求验证没有意义 |
| Step 3 → Step 4 | 伪需求不需要考古——先验证再深挖 |
| Step 4 → Step 5 | 深层需求不清楚时，好问题无的放矢 |
| Step 5 → Step 6 | 问题方向不确定时，边界设计缺乏依据 |

**关键规则**：任何一步输出 confidence < 50%，应该停下来重新审视，而不是继续往下跑。

### 概念三：八张工具卡的自包含方法

编排器已内嵌八张工具卡的核心方法，无需外部依赖：

1. **p0a 微需求五问**：用五个问题检测"太小不值得做"的问题是否是真正的产品起点
2. **p0b 真需求五问**：五问给团队装刹车——三问答不扎实先不做方案
3. **p0c 四层拆解**：表达层→场景层→处境层→代价层
4. **p0d 需求考古五步**：现状→历史→约束→失败→深层需求
5. **p0e 好问题六维**：用户/任务/系统/组织/时间/对比
6. **p0f Agent 边界**：决策/数据/行为/责任/人机协作五类边界
7. **p0g 多元推荐改写**：五维度改写 + 六项检查
8. **p0h 三重平衡**：商业/人性/文化三层评估

> 编排器是自包含的——即使没有单独的工具卡 Skill，编排器也能独立完成完整的需求发现。

### 概念四：输出物的下游价值

编排器的最终输出不是"一份报告"，而是可以直接喂给下一个阶段的结构化输入：

- **Direction Brief 输入**：问题定义 + 场景切入 + 资料条件
- **风险预判**：Agent 边界 + 三重平衡评估
- **研究方向**：好问题列表 + 建议的研究方法

> 好的需求发现报告，应该让方向定界阶段的人读完就知道"该怎么做实验"。

### 概念五：何时跳步、何时回头

编排器不是死板的流水线。以下情况应该灵活处理：

| 场景 | 建议动作 |
|------|----------|
| 需求已经验证过 | 跳过 Step 3，直接进入 Step 4 |
| 边界设计已有 | 跳过 Step 6 |
| Step 3 判定为伪需求 | 回到 Step 1 重新定义问题 |
| Step 4 发现深层需求与原需求不同 | 回到 Step 2 重新拆解 |
| 用户只想快速验证 | 只跑 Step 1 + Step 3 |

> 编排器的价值在于"知道该跑哪几步"，而不是"每次都跑完全部六步"。

## 分步执行

### Step 1：初始化——接收用户输入并建立上下文

**输入**：用户原始想法或痛点描述

**处理**：
1. 记录原始输入（保留用户原话，不翻译）
2. 判断输入的模糊程度：灵感级 / 场景级 / 需求级
3. 根据模糊程度决定后续步骤的详略程度
4. 初始化 Product Context

**输出**：输入记录 + 模糊度评估 + 初始上下文

---

### Step 2：微需求检测——是否存在被忽视的小问题

**输入**：用户原始想法

**处理**：
1. 用五问检测微需求：(1) 每天发生但每次很小？(2) 用户有稳定 workaround？(3) 谁在默默承担代价？(4) 代价带着羞耻/疲惫？(5) 系统接住后体感变轻？
2. 如果发现微需求，标记并建议重新定义问题
3. 如果没有微需求，继续

**输出**：微需求检测结果 + 问题重定义建议（如有）

---

### Step 3：需求四层拆解——从表达到代价

**输入**：用户原始想法（或 Step 2 重定义后的问题）

**处理**：
1. 表达层：用户原话是什么
2. 场景层：问题发生在何时何地与谁有关
3. 处境层：为什么被困住、谁在补位兜底
4. 代价层：不接住会持续损失什么
5. 任何一层说不清，先不进方案讨论

**输出**：四层拆解结果 + 重定义的问题

---

### Step 4：真需求验证——五问判断

**输入**：Step 3 重定义后的需求

**处理**：
1. 是否长期存在？
2. 让谁持续付出了什么代价？
3. 用户有没有为它发展出补偿行为？
4. 背后是不是有结构而不只是偏好？
5. 没人讨论它还会不会继续存在？

**输出**：真/伪需求判定 + 置信度 + 如果是伪需求的真正问题推测

---

### Step 5：需求考古——挖掘深层需求

**输入**：已验证的需求

**处理**：
1. 现状层：描绘当前"正常"是什么
2. 历史层：追溯"正常"是怎么来的
3. 约束层：识别让大家不能做更好的约束条件
4. 失败层：分析之前尝试过什么、为什么没成功
5. 深层需求层：提取真正要解决的问题

**输出**：深层需求 + 约束条件 + 历史尝试

---

### Step 6：好问题生成 + 边界设计

**输入**：深层需求 + 产品场景

**处理**：
1. 从六维度生成研究问题（用户/任务/系统/组织/时间/对比）
2. 设计 Agent 五类边界（决策/数据/行为/责任/人机协作）
3. 评估是否需要多元推荐改写或三重平衡评估
4. 综合输出需求发现报告

**输出**：需求发现报告（含好问题列表、边界文档、方向定界输入）

### 示例 1：AI 客服产品的完整需求发现

**场景描述**：用户说"我想做一个 AI 客服产品，帮企业自动回复客户问题"。

**Step 1 初始化**：
- 原始输入："AI 客服产品，帮企业自动回复客户问题"
- 模糊度：灵感级（功能描述，不是问题描述）
- 建议：需要从功能语言转换为问题语言

**Step 2 微需求检测**：
- 五问结果：
  - (1) 每天发生？✅ 客服每天处理大量咨询
  - (2) 有 workaround？✅ 资深客服凭经验快速回复，新人靠问老同事
  - (3) 谁在承担代价？⚠️ 新人客服在承担"不知道怎么回"的压力
  - (4) 代价带着羞耻？✅ 新人不好意思总问老同事
  - (5) 系统接住后变轻？✅ 如果有标准回复库，新人压力大减
- 微需求发现：新人客服的"不敢问"问题是被忽视的微需求

**Step 3 四层拆解**：
- 表达层："帮企业自动回复客户问题"
- 场景层：客服工作台，高峰时段，新人面对复杂咨询
- 处境层：新人不敢问老同事（怕显得不行），又怕回错客户
- 代价层：回复质量不稳定 → 客户流失 → 新人离职率高

**Step 4 真需求验证**：
- 长期存在？✅ 客服培训是永恒问题
- 代价持续？✅ 每月都有新人入职
- 补偿行为？✅ 新人偷偷看老同事的历史对话记录
- 有结构？✅ 不只是"不够聪明"，而是知识传递机制缺失
- 自然存续？✅ 即使没人讨论，问题依然存在
- **判定：真需求**（5/5 通过，置信度 high）

**Step 5 需求考古**：
- 深层需求：不是"自动回复"，而是"让新人也能给出资深水平的回复"
- 约束条件：企业知识分散在各处（FAQ、工单、内部群）
- 历史尝试：试过知识库搜索，但新人不知道搜什么关键词

**Step 6 好问题 + 边界**：
- 最佳研究问题："新人客服在什么场景下最需要帮助？他们目前是怎么解决的？"
- Agent 边界：AI 提供候选回复（数据边界：FAQ + 历史工单），人工确认后发送（决策边界），高风险承诺必须人工（责任边界）

**输出摘要**：
```yaml
needs_discovery_report:
  verdict: "需求成立"
  confidence: "high"
  key_finding: "核心问题不是'自动回复'，而是'知识传递'——新人无法快速获得资深客服的判断力"
  recommendation: "进入方向定界，聚焦'新人客服知识辅助'场景"
```

---

### 示例 2：AI 学习计划产品的伪需求识别

**场景描述**：用户说"我想做一个 AI 学习计划产品，帮大学生自动制定考研复习计划"。

**Step 1 初始化**：
- 原始输入："AI 学习计划产品，帮大学生自动制定考研复习计划"
- 模糊度：灵感级
- 建议：需要验证这是否是真需求

**Step 2 微需求检测**：
- 五问结果：
  - (1) 每天发生？⚠️ 制定计划只发生一次
  - (2) 有 workaround？✅ 学长学姐的经验帖、考研论坛
  - (3) 谁在承担代价？⚠️ 学生自己在承担"不知道怎么规划"的焦虑
  - (4) 代价带着羞耻？❌ 不羞耻，只是焦虑
  - (5) 系统接住后变轻？⚠️ 计划给出来之后，执行才是真正的痛
- 微需求发现：没有明显的微需求信号

**Step 3 四层拆解**：
- 表达层："帮大学生自动制定考研复习计划"
- 场景层：考研备考初期，学生感到迷茫
- 处境层：信息过载（太多经验帖、太多教材推荐），不知道哪个适合自己
- 代价层：如果规划错了，浪费时间 → 考研失败

**Step 4 真需求验证**：
- 长期存在？✅ 每年都有考研季
- 代价持续？⚠️ 制定计划只是一次性事件
- 补偿行为？✅ 看学长学姐经验帖、加入考研群
- 有结构？⚠️ 问题可能不是"缺计划"，而是"缺执行力和反馈"
- 自然存续？✅ 问题存在，但表达方式可能有误
- **判定：伪需求风险**（3/5 通过，置信度 medium）
- 真正问题推测：学生真正缺的不是计划，而是"执行过程中的反馈和调整"

**决策**：需要回到 Step 1 重新定义问题。建议聚焦"考研执行过程中的实时反馈和调整"，而非"制定计划"。

**输出摘要**：
```yaml
needs_discovery_report:
  verdict: "伪需求（需要重新定义）"
  confidence: "medium"
  key_finding: "用户表达的是'制定计划'，但真正的痛点是'执行过程中的反馈缺失'"
  recommendation: "回到 Step 1，重新定义问题为'考研执行过程中的智能反馈系统'"
```

> 需求发现的价值不在于"帮你确认想法是对的"，而在于"在你投入资源之前告诉你真正的方向"。