Ai native product needs

AI Native 产品需求发现 — SKILL.md

一句话定位

当 AI 让"做出来"变得容易时，真正稀缺的是判断"什么才值得做"的能力。本 Skill 提供一套从"真实处境"出发的需求发现流程，帮助你避开 AI 时代最容易陷入的伪需求陷阱。

何时触发

用户提供了一个产品想法、问题线索或需求描述，需要：

• 判断这是真实需求还是伪需求
• 在 AI Agent 时代重新定义需求边界
• 从"用户说什么"转向"用户在什么处境中做了什么"
• 产出一份可用于后续方向定界和系统构建的需求简报

核心概念

概念一：微需求（Micro-Need）

定义：那些具体、长期、反复发生、却一直没被认真命名的小负担。它不是一时情绪或偶发抱怨，而是用户在现实中一直得额外处理的那一小段劳动。

三大特征：

1. 长期存在：不是一次性起伏，而是用户在现实中反复承担的代价。
2. 被习惯化：用户未必天天抱怨，甚至会把它当成工作的一部分；正因被习惯化，它更难被普通需求流程看见。
3. 一旦被接住，体感变化很大：用户未必用宏大语言夸你，但会明显感觉"终于少背一点了"。

为什么重要：大需求常常停留在表达层，微需求更容易暴露一个人究竟在生活里多做了什么。真正拉开产品差距的，往往是谁更早看见那些别人觉得"不值得看"的小负担。AI 降低了实现成本，微需求第一次获得了进入系统的机会。

五问检测法（来源：工具卡《微需求五问》）：

1. 这个问题是不是每天都在发生，只是每次都很小？
2. 用户是不是已经为它发展出稳定的 workaround？
3. 如果不做，谁会继续默默为它承担代价？
4. 这段负担是不是带着羞耻、疲惫或责任风险，因此不容易被主动表达？
5. 一旦系统接住它，用户体感会不会明显变轻？

五问中 ≥3 问回答为"是"→ 标记为高价值微需求，值得进入需求池。

概念二：真需求 vs 伪需求

伪需求四大来源：

1. 被平台放大的主流表达：高频、明确、容易传播，但未必最深。
2. 被焦虑和比较驱动的即时欲望："别人都在用""我是不是落后了"。
3. 被技术兴奋推出来的假问题："能不能做"悄悄变成"是不是该做"。
4. 被整理得过于顺滑的表层反馈：整理只能增加可读性，不能自动增加真实性。

真需求五个特征：

1. 持续性：长期存在的现实摩擦，不是一次性情绪。
2. 代价性：持续消耗时间、注意力、判断力、情绪容量、信任或责任安全感。
3. 补偿性：用户已为它发展出变通做法——系统没接住，代价不会凭空消失，而是转化成用户额外承担的劳动。
4. 结构性：和角色关系、流程断点、信息缝隙、责任机制有关，不是某个人的特殊偏好。
5. 非表演性：即使不被高频讨论，也仍然存在，靠现实里的重复代价成立。

五问判断法（来源：工具卡《真需求判断五问》）：

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

五问中 ≥3 问答不扎实 → 标记为"高伪需求风险"，先不要做方案。

AI 时代伪需求更难分辨的三个原因：

• 平台持续放大可见表达，重复出现制造"很重要"的错觉
• AI 把零散输入整理成逻辑清楚的"高频痛点"，整齐感让人提早放弃怀疑
• 解决方案越来越容易生成，伪需求不只更容易被看见，也更容易被快速产品化

概念三：需求四层拆解

定义：把"用户说了什么"和"用户真正被什么困住"分开的结构化拆解框架。

层级	问题	输出
表达层	用户原话是什么？	原始需求陈述
场景层	问题发生在什么时候、哪一步、和谁有关？	场景-角色-动作链
处境层	他为什么被困住？谁在补位？谁在兜底？	结构性约束清单
代价层	如果系统不接住，这个人会持续损失什么？	代价-风险映射

任何一层说不出来，就先不要进入方案讨论。

概念四：需求考古学（Need Archaeology）

定义：真正的需求很少直接躺在表面等你收集，它更像一层层被压住的结构——最上面是表达，再往下是场景、关系、情绪、补偿动作、责任缝隙和长期代价。AI 的角色不是需求结论机，而是需求考古助手。

核心原则：

• 你面对的不是答案，而是痕迹
• 你要做的不是直接判断，而是分层挖掘
• 你必须尊重上下文，不能把痕迹从原来的关系里拔出来单独解释

AI 的位置：AI 只能放大你已经采回来的痕迹，不能替你下到现场。没有现场，模型就只能消费平台化输入；没有处境材料，模型再强也只能对着表达层工作。一个人的优势越来越不只是"会不会用 AI"，而是"他手里有没有 AI 不知道的东西"。

概念五：Agent 边界（Agent Boundary）

定义：好的 Agent 不是越会做事，而是越知道在哪里停。"停"不是能力缺陷，而是成熟能力的一部分。

七项边界检查（来源：工具卡《Agent 边界清单》）：

1. 信息是否足够支撑正式动作？
2. 责任关系是否已经成熟，而不只是看起来像对齐？
3. 这一步是在减轻劳动，还是在制造假的确定性？
4. 一旦做错，代价是体验代价、关系代价、还是责任代价？
5. 这里是否应该保留 human-in-the-loop（人工在环）？
6. 用户能不能看见系统为什么停、为什么提示待确认？
7. 这一步如果交给人，会不会反而更能保护信任？

高风险场景：付款、退款、权限变更、责任认领、对外正式承诺——必须逐条过清单。

概念六：好问题六维观察

定义：好问题不是坐在屏幕前靠语感雕出来的，而是从现实里长出来的。提问能力不等于 prompt 技巧，而是把立体现实压缩成高质量问题的能力。

六个维度（来源：工具卡《好问题六维观察表》）：

1. 场景维度：问题发生在什么时间、空间和动作链路里？
2. 关系维度：谁在等谁，谁握着解释权，谁承担责任？
3. 情绪维度：焦虑、羞耻、疲惫、孤独还是失控感？
4. 感官维度：光线、噪音、身体状态、空间安全感有没有影响？
5. 补偿行为维度：用户为了弥补系统没接住的地方，多做了什么？
6. 代价维度：如果一直不处理，真正被消耗的是什么？

做问题定义前，先要求团队至少写满三个维度。如果六个维度里只剩标签和人口属性，说明问题还太平。

概念七：多元推荐改写

定义：多元推荐不是精度的对立面，而是对单一目标精度的修正。加一点随机不等于多元推荐，内容更杂不等于用户更自由。

六项检查（来源：工具卡《多元推荐改写清单》）：

1. 目标函数里，除了停留和转化，还有没有多样性或探索目标？
2. 用户有没有主动切换"更开阔"而不是"更精准"的入口？
3. 系统有没有低冲突的异质内容入口，而不是只塞对立内容？
4. 推荐有没有连接现实世界，而不是永远把人留在屏幕里？
5. 团队有没有衡量"新的可能性被打开"而不只是"更多点击"？
6. 用户能不能把自己从默认推荐轨迹里拉出来？

概念八：AI 产品三重平衡

定义：下一代 AI 产品不该只赢得指标，还要赢得长期信任。每次大方向评审，必须同时看商业、人性、文化三层。

三层判断（来源：工具卡《AI 产品三重平衡表》）：

• 商业层：长期成本是什么？价值能否覆盖持续消耗？是不是靠高成本堆出"看起来很聪明"？
• 人性层：是否真的减轻了用户长期负担？是否保留了人的主体性和判断感？是在帮助人生活，还是让人更依赖系统？
• 文化层：在训练用户怎样理解效率、关系和责任？是在扩大现实感，还是鼓励更浅的自动化依赖？这种产品逻辑是否值得被扩散？

只有商业层有答案时，先不要轻易下结论。

分步执行

基于上述 8 个核心概念，整合为一条完整的执行流程。每步有明确的 输入 → 处理 → 输出。

---

Step 1：需求解构（需求四层拆解卡）

输入：用户/客户/团队说出的原始需求陈述

处理：

1. 将原始需求写在白板最上面
2. 逐层补全四层内容：
   • 表达层：用户原话是什么？收集至少 3 个真实用户的行为案例
   • 场景层：问题发生在什么时候、哪一步、和谁有关？
   • 处境层：他为什么被困住？谁在补位？谁在兜底？
   • 代价层：如果系统不接住，这个人会持续损失什么？
3. 标记每一个"需求"是否来自平台/算法/社交媒体的放大
4. 区分"用户的痛苦"和"用户描述的痛苦"——后者往往已经被媒介翻译过

输出：四层拆解表（表达 / 场景 / 处境 / 代价），任何一层说不出来就暂停

---

Step 2：处境映射（好问题六维观察表）

输入：Step 1 产出的四层拆解表

处理：

1. 针对处境层和代价层，至少从三个维度展开观察：
   • 场景维度：时间、空间、动作链路
   • 关系维度：谁在等谁、谁握解释权、谁担责任
   • 情绪维度：焦虑、羞耻、疲惫、孤独、失控感
   • 感官维度：光线、噪音、身体状态、空间安全感
   • 补偿行为维度：用户多做了什么来弥补系统没接住的地方
   • 代价维度：真正被消耗的是什么
2. 如果六个维度里只剩标签和人口属性，标记为"问题还太平"，需要回到现场补充
3. 产出处境-行为映射表，显示用户在每个处境下的真实行为（而非表达意愿）

输出：处境-行为映射表 + 六维观察记录

---

Step 3：微需求检测（微需求五问）

输入：Step 2 产出的处境-行为映射表中的补偿行为和小负担

处理：

1. 对每个识别出的补偿行为 / 小负担，逐项过五问：
   • Q1：是不是每天都在发生，只是每次都很小？
   • Q2：用户是不是已经发展出稳定的 workaround？
   • Q3：如果不做，谁会继续默默承担代价？
   • Q4：这段负担是不是带着羞耻、疲惫或责任风险？
   • Q5：一旦系统接住，用户体感会不会明显变轻？
2. ≥3 问回答"是"→ 标记为高价值微需求
3. 在需求池旁单开一列："这个点为什么虽然小，却值得做"

输出：微需求清单（附五问评分）

---

Step 4：真伪判断（真需求判断五问）

输入：Step 1 的四层拆解 + Step 3 的微需求清单

处理：

1. 对每个候选需求逐项过五问：
   • Q1：它是不是长期存在？
   • Q2：它让谁持续付出了什么代价？
   • Q3：用户有没有为它发展出补偿行为？
   • Q4：它背后是不是有结构，而不只是偏好？
   • Q5：即使没人讨论，它还会不会继续存在？
2. 五问中 ≥3 问答不扎实 → 标记为"高伪需求风险"
3. 同步运行伪需求五信号检测：

信号	检测问题	风险等级
S1: 技术兴奋型	"如果不用 AI，这个问题还存在吗？"	🔴 高
S2: 可见性偏差型	"这个需求是在哪个平台/会议上被放大的？"	🟡 中
S3: 表达-行为断裂型	"用户说的和做的是否一致？"	🔴 高
S4: 代理偏差型	"这个需求是谁的声音？终端用户还是中间人？"	🟡 中
S5: 解决方案伪装型	"他们描述的是问题，还是已经混进了解决方案？"	🔴 高

命中 ≥2 个 🔴 信号 → 回到 Step 1 重新收集行为证据。

输出：真伪判断结论 + 伪需求信号标记

---

Step 5：需求考古（需求考古五步法 · AI 介入）

输入：Step 4 确认的真实需求 + 现场行为证据

处理（人机协作五步）：

1. 人先进现场：看场景、关系、补偿动作和代价（前置步骤，Step 1-4 已完成）
2. 人先做初筛：区分表达、场景、处境和代价，过滤明显伪信号（Step 4 已完成）
3. AI 做拆层：把访谈记录、跟访笔记、补偿行为清单一起喂给 AI，提问格式：
   • ❌ 不要问："请总结高频需求"
   • ✅ 要问："请识别用户在系统外重复执行的补偿行为。这些行为分别在弥补什么风险？哪些风险适合被系统辅助，哪些风险如果由系统直接替代，可能制造新的误判？"
4. 人回现实验证：模型提出的是假设不是结论。回到现场验证假设是否真的解释了用户为何持续付出代价
5. 团队决定系统边界：系统到底该接住哪一段劳动，哪一段必须保留给人

输出：AI 辅助拆层报告 + 现场验证结论 + 系统边界初稿

---

Step 6：Agent 边界设计（Agent 边界清单）

输入：Step 5 产出的系统边界初稿

处理：

1. 对每个 Agent 拟执行的动作，逐项过七项边界检查
2. 特别关注高风险场景（付款、退款、权限变更、责任认领、对外正式承诺）
3. 将白板分为三列：
   • 系统直接承接：录音转写、重点提炼、候选待办生成
   • 系统辅助判断：责任是否真正成立、事项是否成熟到可以推进
   • 必须留给人：谁来拍板、共识是否算成立、现在推会不会太早
4. 用"做了以后会发生什么"替代"还能不能再自动一步"

输出：Agent 边界设计文档（三列分类）

---

Step 7：三重平衡评审（AI 产品三重平衡表）

输入：完整的需求方案 + Agent 边界设计

处理：

1. 按商业层、人性层、文化层逐项评估
2. 三层都必须有明确回答；只有商业层有答案时，不轻易下结论
3. 如果人性层或文化层出现负面信号，回退方案重新设计

输出：三重平衡评审表

---

Step 8：需求简报输出

输入：Step 1-7 全部产出

处理：整合为标准化 AI Native 需求简报

输出：

needs_brief:
  problem_statement: "用一句话描述真正的核心问题（不是解决方案）"
  four_layer_decomposition:
    expression: "用户原话"
    scene: "场景描述（时间/空间/动作链）"
    situation: "处境描述（谁在补位/谁在兜底）"
    cost: "持续损失什么"
  micro_needs:
    - description: "微需求描述"
      five_questions_score: 4  # 微需求五问得分（0-5）
      workaround: "用户现有变通做法"
  true_need_validation:
    five_questions_score: 4  # 真需求五问得分（0-5）
    pseudo_need_flags: ["S1", "S3"]  # 命中的伪需求信号
    risk_level: "低/中/高"
  six_dimension_observation:
    scene: "场景维度描述"
    relationship: "关系维度描述"
    emotion: "情绪维度描述"
    sensory: "感官维度描述"
    compensation: "补偿行为维度描述"
    cost: "代价维度描述"
  agent_boundary:
    system_direct: ["系统直接承接的动作"]
    system_assisted: ["系统辅助判断的动作"]
    human_reserved: ["必须留给人的动作"]
    high_risk_actions: ["高风险动作清单"]
  triple_balance:
    commercial: "商业层评估"
    humanity: "人性层评估"
    culture: "文化层评估"
  validation_criteria:
    - "验证标准1：..."
    - "验证标准2：..."
  next_stage: "p2"  # 下一阶段：方向定界

示例

示例 1：电商客服场景 — 微需求检测和真需求验证

场景描述：一家电商平台的产品团队收到客服部门反馈："用户经常投诉退款流程太慢，希望一键退款。"

用户输入：

"我们的客服每天要处理大量退款请求，用户反复投诉退款慢，希望能有一个一键退款功能。"

执行流程：

Step 1 需求解构（四层拆解）：

• 表达层：用户说"退款太慢，要一键退款"
• 场景层：通常发生在收到货后 1-3 天内，用户发现商品问题后联系客服，客服需要手动核实订单、确认问题、走审批流
• 处境层：客服不是不想快，而是退款审批涉及多级权限（客服→组长→财务），每级都要补一遍上下文。客服自己也在系统外补位：私聊催审批、自己记待办、给用户反复发"已在处理中"
• 代价层：客服持续消耗的是注意力和情绪容量——每次退款都要当"中间人"反复追；用户持续损失的是信任感——不知道自己的钱到底什么时候回来

Step 3 微需求检测（微需求五问）：

1. ✅ 每天都在发生，只是每次都不大
2. ✅ 客服已发展出变通做法：私聊催审批、自建待办表、反复给用户发进度
3. ✅ 代价主要由客服承担——他们是天然的兜底角色
4. ✅ 带着责任风险——一旦退款出错，最先被追责的是客服
5. ✅ 一旦系统接住审批流转，客服体感会明显变轻

五问得分 5/5 → 高价值微需求

Step 4 真伪判断（真需求五问）：

1. ✅ 长期存在——退款审批慢不是偶发问题
2. ✅ 客服持续付出代价：时间、情绪、责任风险
3. ✅ 已有补偿行为：私聊催、自建表、反复确认
4. ✅ 背后有结构：多级审批 + 信息断点 + 责任不清
5. ✅ 即使没人讨论，客服还是会继续追

五问得分 5/5 → 真需求

Step 6 Agent 边界设计：

• 系统直接承接：自动核对订单信息、自动附上用户上传的证据图片、自动生成退款申请单
• 系统辅助判断：标注"该订单是否符合自动退款条件"、提示"同类问题历史退款通过率"
• 必须留给人：最终退款审批（涉及资金）、异常订单的判断、对用户的正式沟通

输出结果：

needs_brief:
  problem_statement: "客服在退款流程中持续充当'审批中转站'，反复补位消耗注意力和情绪容量"
  micro_needs:
    - description: "客服在系统外私聊催审批、自建待办表、反复给用户发进度确认"
      five_questions_score: 5
      workaround: "私聊催审批 + 自建待办表 + 反复发'已在处理中'"
  true_need_validation:
    five_questions_score: 5
    pseudo_need_flags: []
    risk_level: "低"
  agent_boundary:
    system_direct: ["自动核对订单信息", "自动附上用户证据", "自动生成退款申请单"]
    system_assisted: ["标注是否符合自动退款条件", "提示历史退款通过率"]
    human_reserved: ["最终退款审批", "异常订单判断", "对用户的正式沟通"]
  next_stage: "p2"

---

示例 2：企业内部工具 — 需求考古和四层拆解

场景描述：一家中型企业的 IT 部门想做内部知识库升级，收到大量反馈"搜索不好用"。

用户输入：

"各部门都在抱怨知识库搜索不好用，我们想升级语义搜索。"

执行流程：

Step 1 需求解构（四层拆解）：

• 表达层：用户说"搜索不好用"
• 场景层：通常发生在入职头两周的新人身上。他们搜不到关键资料时，先去问同组同事，再把对方发来的链接私存到飞书或备忘录里
• 处境层：老员工嘴上也说搜索一般，但他们通常已经知道该搜哪些关键词、该去哪几个固定页面找。真正被反复消耗的，是那些还不知道"正确词汇"和"默认路径"的新人
• 代价层：新人损失的不只是几次搜索时间，而是对"信息在这家公司能不能被可靠获取"的基本信任。长期来看，新人会越来越不敢相信系统，转而过度依赖同事——这又反过来消耗老员工的注意力

Step 2 处境映射（六维观察）：

• 场景维度：入职第 1-14 天，通常在独立完成第一个任务时触发
• 关系维度：新人→老员工（知识持有者），新人→HR（入职引导者），新人→系统（信任尚未建立）
• 情绪维度：焦虑（怕显得笨）、羞耻（不敢反复问）、孤立（不确定该找谁）
• 补偿行为维度：问同事→私存链接→建个人文档→再也不用系统搜索
• 代价维度：老员工被打断、新人自建信息孤岛、系统搜索日志失真（真实搜索需求被绕过）

Step 5 需求考古（AI 介入）： 给 AI 的输入不是"搜索不好用"，而是完整的处境和补偿行为材料。AI 帮助拆层发现：

• 问题不只是搜索算法，而是知识入口设计 + 命名体系 + 上下文暴露方式 + 新人认知负担的组合问题
• 关键假设：新人搜不到的核心原因不是召回率，而是他们不知道该用什么关键词（行话/缩写/默认路径）

Step 6 现场验证：带假设回到现场确认——新人确实不知道该搜什么词，老员工知道但没觉得这是"搜索问题"

输出结果：

needs_brief:
  problem_statement: "新人因不了解公司内部术语和默认路径，在知识获取上持续付出额外代价，逐渐放弃使用系统搜索"
  micro_needs:
    - description: "新人在系统外私存链接、建个人文档，绕过知识库"
      five_questions_score: 5
      workaround: "问同事→私存链接→建个人文档"
  true_need_validation:
    five_questions_score: 5
    pseudo_need_flags: []
    risk_level: "低"
  agent_boundary:
    system_direct: ["根据新人角色推荐常用文档", "展示热门搜索路径"]
    system_assisted: ["标注'新人常见搜索词'", "关联行话与正式名称"]
    human_reserved: ["知识体系重构决策", "命名规范制定"]
  next_stage: "p2"

---

示例 3：AI 产品 Agent 边界设计

场景描述：一家 SaaS 公司正在做会后协作 Agent，团队希望 Agent 自动推进会后事项——自动拆任务、指派责任人、发提醒、同步到项目板。

用户输入：

"我们想让 Agent 自动处理会后事项：自动拆任务、指派责任人、发提醒、同步项目板。"

执行流程：

Step 6 Agent 边界设计（七项检查）：

对"自动指派责任人"这个动作逐条过清单：

1. 信息是否足够支撑正式动作？ → 不一定。会议中"市场说可以先出两版方向"，但品牌负责人其实只说了"可以先看一下"，并没有正式承诺。信息还不足以支撑正式指派。
2. 责任关系是否已经成熟？ → 不一定。品牌负责人并没有真正答应进入评审，预算也还没批。
3. 这一步是在减轻劳动，还是在制造假的确定性？ → 更像在制造假的确定性。系统生成任务后，品牌负责人可能会因为"系统已经点了名"而不好意思再说"我其实还不能接"。
4. 一旦做错，代价是什么？ → 关系代价（被迫接受不成熟的指派）+ 项目代价（按错误节奏推进）。
5. 这里是否应该保留人工在环？ → 是。至少在正式指派责任人之前。
6. 用户能不能看见系统为什么停？ → 需要设计。系统应明确提示"检测到前置条件未齐"。
7. 如果交给人，会不会更能保护信任？ → 会。让人自己确认是否接住，比系统替人落锤更可靠。

三列分类结果：

系统直接承接	系统辅助判断	必须留给人
会议录音转写	标注"该事项涉及多个前置条件"	责任人是否正式认领
重点内容提炼	建议待办候选列表	共识是否算成立
生成待同步草稿	标明谁还没给反馈	现在推进会不会太早
	提示"以下事项尚未形成稳定共识"	对外正式沟通内容

输出结果：

needs_brief:
  problem_statement: "会后协作 Agent 如果自动推进所有事项，会把不成熟的判断包装成确定结果，制造'事情已经被接住'的假象"
  agent_boundary:
    system_direct:
      - "会议录音转写"
      - "重点内容提炼"
      - "生成待同步草稿（标注'待人工确认'）"
    system_assisted:
      - "标注前置条件是否齐备"
      - "标明谁还没给反馈"
      - "建议待办候选列表"
      - "提示'以下事项尚未形成稳定共识，建议人工确认后再发送正式指派'"
    human_reserved:
      - "责任人是否正式认领"
      - "共识是否算成立"
      - "现在推进会不会太早"
      - "对外正式沟通内容"
    high_risk_actions:
      - "自动指派责任人"
      - "自动发送推进通知给候选人/客户"
      - "自动更新项目板状态为'已推进'"
  triple_balance:
    commercial: "自动化链路越长，错误兜底成本越高；'看起来很聪明'不等于长期可持续"
    humanity: "如果系统默认替人落锤，会把本该由用户保留的判断也一起吞掉"
    culture: "训练出来的可能不是更成熟的协作，而是更舒服的判断外包"
  next_stage: "p2"

关键原则

1. 行为 > 表达：用户的行为证据比他们说的话更可信。
2. 处境 > 画像：先理解用户在什么处境中，再谈用户是谁。
3. 问题 > 方案：永远先定义问题，再讨论解决方案。AI 时代最容易犯的错误是把解决方案（"我想做一个 Agent"）当成需求。
4. 真实 > 可见：高可见的需求不一定是真需求，可能只是被算法放大了。
5. 微需求 ≠ 小需求：小不自动等于深，隐蔽不自动等于高价值。微需求靠重复出现的代价成立，不靠声量成立。
6. AI 是考古助手，不是结论机：AI 只能放大你已经带回来的痕迹，不能替你下到现场。
7. 知道停比会做事更重要：Agent 的成熟不是模型能力问题，而是需求理解、问题定义、边界设计和价值判断共同作用的结果。

常见陷阱

• 陷阱 1：把"用户想要一个 AI 助手"当成需求 → 实际上用户想要的是"减少重复性工作的痛苦"
• 陷阱 2：用 AI 生成虚假需求 → 用 LLM 生成"用户故事"，看起来很像，但没有真实行为支撑
• 陷阱 3：场景太宽 → "帮助所有人提高效率"不是场景，"帮助电商客服在高峰时段处理退货请求"才是
• 陷阱 4：忽视媒介过滤 → 从社交媒体、行业报告中读到的"热点需求"，往往已经被平台扭曲
• 陷阱 5：把总结当理解 → AI 把零散反馈整理得很整齐，不代表问题已经被真正理解
• 陷阱 6：让 AI 站在问题定义最前面 → 对着访谈逐字稿让 AI "总结需求"，得到的只是更漂亮的表达层加工
• 陷阱 7：Agent 越自动越好 → 不知道停的系统通常都在偷偷转移风险，让用户表面上少点几下，却在系统外多背很多判断和兜底
• 陷阱 8：把高频等同于真实 → 高频不等于真实，整齐不等于可靠，可做不等于该做

与其他 Skill 的关系

• 上游输入：无（本 Skill 是工作流起点之一）
• 下游输出：ai-native-direction-framing（方向定界）
• 并行参考：ai-native-experiment-engine（试验展开，用于验证需求假设）