agentsclimarketplace

P0 needs orchestrator

Skill gmaxxxie/ai-native-product-agent-skills/skills/p0-needs-orchestrator

AI Native Product Methodology — 80 executable skills across P0-P14 stages, covering needs discovery to aesthetic authority. From 8 books.

Install
npx -y skills add gmaxxxie/ai-native-product-agent-skills --skill p0-needs-orchestrator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

需求发现编排器。协调微需求检测、真需求验证、需求拆解、需求考古、好问题生成、Agent 边界设计、多元推荐改写、AI 产品三重平衡八个工具卡, 按顺序执行并输出完整的需求发现报告。自包含——八个工具卡的核心方法已内嵌。 基于《AI rebuild product needs》读者工具箱。

SKILL.md

19.3 KB, as published. Nobody here has run it

需求发现编排器

一句话定位

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

何时触发

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

输入

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

示例输入

"我想做一个 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,重新定义问题为'考研执行过程中的智能反馈系统'"

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.