// 微需求五问检测器。团队天然偏爱"大需求"，这个 Skill 把看起来很小、但可能压得很深的问题重新看见。 基于《AI rebuild product
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p0a-micro-needs-detector |
| description | 微需求五问检测器。团队天然偏爱"大需求"，这个 Skill 把看起来很小、但可能压得很深的问题重新看见。 基于《AI rebuild product |
需求池里全是大词时，用这五个问题检测那些"太小不值得做"的问题，是不是真正的产品起点。
一个具体场景描述（不要抽象需求，要具体事件）。
示例输入：
"项目负责人总要在会后再追一遍责任确认"
五问检测结果 + 判断建议。
检测方法：
输出格式：
频率评估: [high/medium/low]
证据: [ju体观察/数据/访谈结果]
检测方法：
输出格式：
workaround 列表:
1. [workaround 描述] - 频率: [x次/天/周]
2. ...
隐性成本: [时间/精力/情绪代价]
检测方法：
输出格式：
承担角色: [角色名称]
承担内容: [具体代价]
机会成本: [因此错过的更重要事项]
检测方法：
输出格式：
情绪负担: [shame/fatigue/anxiety/none]
表达障碍: [用户主动提出频率 low/medium/high]
潜台词: [用户实际会说什么来描述这个问题]
检测方法：
输出格式：
体感变化: [dramatic/moderate/subtle/none]
关键见证: [用户可能会说的话]
价值密度: [high/medium/low]
micro_needs_assessment:
input: "原始场景描述"
q1_frequency:
score: "high/medium/low"
evidence: "证据"
q2_workaround:
workarounds: ["列表"]
hidden_cost: "隐性成本"
q3_bearer:
role: "承担角色"
cost: "具体代价"
opportunity_cost: "机会成本"
q4_emotion:
burden: "shame/fatigue/anxiety/none"
expression_barrier: "low/medium/high"
q5_relief:
体感_change: "dramatic/moderate/subtle/none"
value_density: "high/medium/low"
verdict:
is_micro_need: true/false
confidence: "high/medium/low"
reasoning: "判断理由"
recommendation:
action: "建议动作"
priority: "P0/P1/P2"
next_step: "下一步"
微需求不靠声量成立，靠重复出现的代价成立。
微需求不是情绪波动，也不是偶发抱怨。它是用户在现实中反复承担的一小段劳动——具体、长期、反复发生，却一直没被认真命名。
三大特征：
来源：《AI rebuild product needs》第20章——微需求才是产品真正的起点。
产品团队长期被训练依赖"可见性"做判断——大词、大人群、大场景、大指标。微需求不具备这些特征：
真正拉开产品差距的，往往是谁更早看见那些别人觉得"不值得看"的小负担。
来源：《AI rebuild product needs》第20章第1节——为什么团队系统性低估微需求。
过去即使看见微需求，团队也会犹豫——实现成本太高。AI 降低了原型、流程和功能实现的门槛，那些"值得理解但不值得建造"的问题第一次获得了进入系统的机会。
如果 AI 只用来放大已可见的大需求，产品只会更快进入同质化竞争。但如果 AI 降低了处理微需求的门槛，它反而成为产品重新接近现实的机会。
来源：《AI rebuild product needs》第20章第4节——AI 时代微需求更值得做。
系统没接住的代价不会凭空消失，而是转化成用户额外承担的劳动——这就是补偿行为（workaround）。补偿行为是微需求最可靠的信号来源：
这些行为的存在说明：问题不只是抱怨，而是现实里已经在持续支付代价。
来源：《AI rebuild product needs》第19章——用户说出来的未必是需求，用户活出来的才是。
不是每个微需求都值得建造。小不自动等于深，隐蔽不自动等于高价值。微需求也可能是偶发偏好、局部习惯、或某一小群用户的便利。五问法的核心不是"找到更多微需求"，而是"分辨哪些小负担真正值得进入系统"。
来源：《AI rebuild product needs》第20章第6节——微需求是起点，不是终点。
输入：一个具体场景描述（不要抽象需求，要具体事件）
处理：
输出：补偿行为清单（附频率和触发场景）
输入：Step 1 产出的补偿行为清单
处理： 对每个识别出的补偿行为/小负担，逐项过五问：
输出：五问评估结果（每项标注 yes/no + 证据）
输入：Step 2 产出的五问评估结果
处理：
输出：高价值微需求清单（附五问评分 + 体感变化等级）
输入：Step 3 产出的高价值微需求清单
处理：
输出：代价量化报告
输入：Step 3 的高价值清单 + Step 4 的代价量化
处理：
输出：微需求产品化方案（附优先级和验证标准）
输入：已上线的微需求解决方案
处理：
输出：验证报告 + 迭代建议
背景：一家内部协作工具的产品团队，大需求很明确：自动笔记、自动任务拆解、自动同步、自动提醒。讨论时间自然都集中在这些"大功能"上。
微需求发现：
产品经理跟访一位项目负责人一整天后，发现一个非常小的动作：每次会议快结束时，她都会低头看一眼笔记，然后在大家开始收电脑的间隙，随口加一句："我一会儿再发个总结，大家到时候看一下。"
语气很轻，像是只加一个例行备注。
五问检测：
| 问题 | 回答 | 证据 |
|---|---|---|
| Q1：每天都在发生？ | ✅ 是 | 几乎每次会议结束她都会加这句话 |
| Q2：有稳定 workaround？ | ✅ 是 | 固定动作：会后再发一遍、再戳一遍人、再加一句背景 |
| Q3：谁在默默承担？ | ✅ 是 | 项目负责人自己——一旦没人加这层保险，出问题最先被追责的是她 |
| Q4：带着责任风险？ | ✅ 是 | 太碎了，不会被说成正式需求；"我多做一点就好了" |
| Q5：接住后体感变轻？ | ✅ 是 | 真正想摆脱的不是"多发一条消息"，而是"总觉得需要再加一层保险"的紧张感 |
五问得分 5/5 → 高价值微需求
产品动作：
团队没有把它包装成大功能。他们只在系统生成会后内容时，增加了一层非常轻的接受反馈：谁看到了、谁明确确认了、谁还没回复、哪些事项仍然是"发出去但没被真正接住"的状态。
结果：
项目负责人说了一句话："终于不用每次我自己再加那句话了。"
背景：一个远程会议产品，团队在做大功能升级。有一个非常小、很容易被忽略的投诉：
"我分享完屏幕后，总得再确认一下大家是不是真的看到了我刚才讲的那个页面。"
微需求分析：
这听起来小得可笑——不值得放进策略文档，也不值得单独上线关注。但持续观察后发现：
五问检测：
| 问题 | 回答 | 证据 |
|---|---|---|
| Q1：每天都在发生？ | ✅ 是 | 每次分享屏幕后都会发生 |
| Q2：有稳定 workaround？ | ✅ 是 | 分享者会口头问"大家看到了吗"，或者切换回上一页再问一次 |
| Q3：谁在默默承担？ | ✅ 是 | 分享者——承担"可能没讲清楚"的责任风险 |
| Q4：带着责任风险？ | ✅ 是 | 如果后续出问题，"当时分享时你没说清楚"会指向分享者 |
| Q5：接住后体感变轻？ | ✅ 是 | 不用反复确认，少一层"不知道大家有没有看到"的焦虑 |
五问得分 5/5 → 高价值微需求
产品方向：
值得解决的不是"做一个更酷的演示功能"，而是让共享状态、视图焦点、页面位置和理解确认——那些过去完全依赖人不断补位的微小动作——被系统更早接住。
启示：
大需求更容易表达、更容易被竞品复制、更容易快速跟进。但藏在补偿动作、微表情、犹豫和小负担里的问题，往往不会同时出现在每个团队的视野里。谁先看见，谁就有更大机会做出看起来不同、且更难被复制的产品。