需求发现编排器

一句话定位

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

何时触发

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

输入

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

示例输入：

"我想做一个 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: 微需求检测

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

micro_needs:
  found: true/false
  needs: ["发现的微需求列表"]
  recommendation: "是否需要重新定义问题"

Step 2: 需求四层拆解

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

decomposition:
  layer1: "表达层"
  layer2: "场景层"
  layer3: "处境层"
  layer4: "代价层"
  reframed_problem: "重定义的问题"

Step 3: 真需求验证

输入：重定义后的需求 输出：

validation:
  is_real: true/false
  pass_count: "X/5"
  confidence: "high/medium/low"
  if_fake: "如果是伪需求，真正的问题可能是"

Step 4: 需求考古

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

archaeology:
  deep_need: "深层需求"
  constraints: ["约束条件"]
  historical_attempts: ["历史尝试"]
  productizable: "yes/no"

Step 5: 好问题生成

输入：深层需求 输出：

good_questions:
  dimensions: ["六个维度的问题"]
  best_question: "最佳研究问题"
  research_direction: "研究方向"

Step 6: Agent 边界设计

输入：产品场景 输出：

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. 主体性保留是否让人更依赖）、文化层（训练了什么价值观现实扩大还是缩小）。核心规则：如果只有商业层有答案，先不要推进。

综合输出格式

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 + 历史工单），人工确认后发送（决策边界），高风险承诺必须人工（责任边界）

输出摘要：

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 重新定义问题。建议聚焦"考研执行过程中的实时反馈和调整"，而非"制定计划"。

输出摘要：

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

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