User needs discovery

用户需求挖掘

When to Use

• 用户手握多类用户研究材料（访谈、问卷、客服记录、搜索词、评论、行为线索等），希望从中提炼需求。
• 用户要做需求优先级排序、需求地图或下一步研究规划。
• 用户说："帮我把这些访谈和问卷里的需求理一理""用户到底想要什么""怎么排这些需求的优先级""帮我设计需求访谈提纲"。

When NOT to Use

• 只拿到一批评论 / 弹幕 / 私信，想归纳痛点、情绪、高频问题 → 用 user-comment-analysis（R05）。
• 要做完整用户行为路径、漏斗与数据异常分析 → 用 user-behavior-analysis（D04）。
• 要直接生成选题、内容栏目或文案 → 用 topic-generation（C04）/ content-pillar-planning（C02）等。
• 要做账号定位或目标人群定义 → 用 account-positioning-analysis（C01）。
• 要设计销售话术或转化路径 → 用 sales-talk-track（G04）/ content-acquisition-path（G01）。

Inputs

必要信息（按可获得性分层，不要求全部齐备）：

1. 一手用户材料：访谈记录 / 转录、问卷原始回答、客服对话、私信、评论、搜索词列表、工单。
2. 业务背景：产品 / 内容 / 服务当前形态、目标人群、所处阶段（验证期 / 增长期）。
3. 已有研究结论或假设（可选）。
4. 分析目的：排序需求 / 建需求地图 / 规划下一步研究。

缺失处理：业务背景缺失且可合理假设时，标注"假设：默认分析目的是需求优先级梳理"后继续；若完全没有用户材料，见「缺失信息处理」。

缺失信息处理

• 有材料但缺业务背景：标"假设"继续，结论标注适用范围。
• 完全没有用户研究材料：本 Skill 可以帮助设计需求研究方法、访谈提纲、问卷框架或搜索词清单，但不得虚构任何用户结论；明确告知"以下为研究设计，不是样本内证据支持的需求（当前无材料，所有结论均待验证）"。
• 材料明显偏斜（如只有客服投诉）：结论标注"样本偏负面，不代表全量用户"，不强行归一。
• 会实质影响结论（如完全无材料却要求给需求结论）：集中询问一次（仅问能否提供至少一类真实用户材料，或确认只需研究设计）。

Workflow

1. 隐私匿名化：对含姓名、联系方式、账号 ID、订单号等可识别信息的材料先做匿名化（替换为"用户 A"等）再分析；未匿名化材料不提交外部检索 / 第三方工具。
2. 材料归类与多源去重：按来源（访谈 / 问卷 / 客服 / 搜索词 / 评论 / 行为线索）分别登记，记录样本量、周期、平台、招募方式或产生机制；同一用户在多个来源重复表达时，尽量匿名化去重，不机械算作多个独立用户；同一事件被多次转述时，不机械累计为多个独立需求信号；无法判断是否重复时，明确标注"可能存在重复样本"。不同来源的数量、频次和样本偏差分别呈现，不直接相加后计算总体比例。
3. 逐层拆解用户表达：对每条用户表达，依次标注：
   • 用户原始表达（原话 / 直接陈述，标「事实」）
   • 表层诉求或解决方案偏好（用户明确想要的"功能 / 按钮 / 流程"，标「事实」但注明这是用户提出的方案而非需求本身）
   • 使用场景与目标（谁、在什么情况下、想达成什么，标「事实」或「推断」）
   • 底层需求（从原始表达与场景推断出的根本诉求，标「推断」，必须能回溯到具体原始材料、场景与推断过程）
   • 待验证假设（进一步假设，标「假设 / 待验证」） "用户说'我要增加一个按钮'"只能作为用户原始表达或解决方案偏好，不能直接等同于底层需求。
4. 显性需求与潜在需求：显性需求只来自用户明确表达的"目标 / 问题 / 痛点 / 期望结果"（标「事实」）；用户明确提出的"按钮 / 功能 / 页面 / 流程 / 具体做法"属于解决方案偏好，不直接作为显性需求——只有当能够从使用场景、目标与障碍得到支持时，才可进一步推断其底层需求（标「推断」并给依据）；潜在需求从行为线索、抱怨、绕路用法、未满足场景推断（标「推断」并给依据）。不得因为一句话由用户亲口说出，就自动把其中的解决方案认定为需求事实。
5. 使用场景还原：把需求放回具体场景，区分主场景与边缘场景。
6. 阻碍因素：用户达成目标遇到的障碍（能力 / 时间 / 成本 / 信任 / 信息），区分事实与推断。
7. 拆开需求强度与业务价值（不得混为一个结论）：
   • 用户需求证据强度（材料支撑该需求的强弱）
   • 用户影响范围（涉及多少用户 / 场景广度，按来源分列，不跨源相加）
   • 紧迫性（用户当下痛点强度）
   • 业务相关性（与当前业务目标、资源、阶段的匹配度）
   • 验证状态（样本内证据较充分 / 样本内部分支持 / 待验证） 可给综合建议，但必须说明：需求真实性不因暂时不符合业务目标而消失；业务优先级属于进一步决策判断，不等同于需求事实；不使用无依据的乘法公式或精确分数（如 8.5/10）。「样本内证据较充分」只表示当前所提供的样本支持该需求，不代表已证明全体目标用户普遍存在该需求；除非具备代表性研究设计与充分证据，不使用易被理解为总体事实的"已证实需求"。
8. 样本边界说明：标注样本来源偏差、时间有效性、招募方式或材料产生机制、是否只包含投诉 / 活跃 / 成交用户、是否可能遗漏沉默用户。
9. 输出需求地图（见 Output）。
10. 自检：有无无来源数字？表层诉求与底层需求是否混淆？是否跨源相加比例？事实 / 推断 / 未知 / 建议是否混淆？示例是否自洽？是否越界代写选题 / 方案？隐私是否处理？多源去重是否执行？是否把样本内支持误写成总体已证实？是否把业务执行优先级与需求证据状态混为一谈？

Output

Markdown 报告，至少包含：

• 样本概况（各来源数量 / 周期 / 平台 / 招募方式或产生机制 / 匿名化说明 / 去重说明）
• 需求分层表（每条需求按：用户原始表达 → 表层诉求 / 方案偏好 → 使用场景与目标 → 底层需求[推断，含回溯] → 待验证假设 呈现）
• 显性需求清单（用户明确表达的目标 / 问题 / 痛点 / 期望结果原话摘录 + 出现频次，标「事实」；解决方案偏好不计入显性需求，单独归到需求分层表的"表层诉求 / 方案偏好"列）
• 潜在需求清单（推断 + 依据，标「推断」）
• 使用场景（主场景 / 边缘场景）
• 阻碍因素（事实 / 推断分类）
• 需求强度与业务价值分离表（逐条：用户需求证据强度 / 用户影响范围 / 紧迫性 / 业务相关性 / 验证状态[样本内证据较充分 / 样本内部分支持 / 待验证]；可给综合建议但说明依据）
• 样本边界（来源偏差、时间有效性、是否遗漏沉默用户等）
• 未验证假设（标「假设 / 待验证」）
• 给用户的下一步建议（标「建议」；如研究补全、验证方法）
• 明确"本结论基于所提供的 X 份材料，不代表全量用户"

如需落盘，使用项目内相对路径或绝对路径，文件名如 用户需求挖掘-YYYYMMDD.md。

Evidence / Quality Rules

• 来源优先级：用户一手材料（访谈 / 问卷 / 客服 / 私信 / 评论原样本）> 用户补充的业务上下文 > 明确要求的公开检索背景（默认不主动外联）。
• 状态标签统一：区分「事实（已核实，如用户原话、明确表达的目标 / 问题 / 痛点）」「推断（从证据推导，含底层需求、场景与阻碍）」「假设 / 未知 / 待验证（环境或外部未证实的事项）」「建议（给用户的行动）」。不使用"三级 + 一类"等易误解分类数量的名称。
• 需求分层：用户原始表达、表层诉求、使用场景、底层需求、待验证假设必须分开标注；底层需求须能回溯到具体原始材料与推断过程。
• 多源去重：同一用户跨源重复表达不机械计为多用户；同一事件多次转述不机械累计为多个独立信号；无法识别重复时标"可能存在重复样本"；不同来源数量、频次、样本偏差分别呈现，不直接相加计算总体比例。
• 需求强度与业务价值分离：证据强度、影响范围、紧迫性、业务相关性、验证状态分别输出；业务优先级是决策判断，不等于需求真实性。
• 需求分级须附依据，禁止凭空打分数；证据弱的需求标「待验证」。
• 样本说明：给出各来源数量、周期、平台、招募方式；小样本不输出伪精确百分比，改用实际数量与"样本有限"限定。
• 来源冲突：不同材料结论冲突时并列展示，不强行归一。
• 不虚构访谈内容、问卷结果、用户原话或需求结论。

Boundaries

• 只归纳用户已提供的材料；无材料时只做研究设计，不编造结论。
• 不把用户提出的解决方案或功能要求（如"加个按钮"）直接当作底层需求，也不直接当作显性需求；解决方案偏好须与用户明确表达的目标 / 问题 / 痛点分开，并标注为"表层诉求 / 方案偏好"。
• 不替代 D04 用户行为分析（不负责完整行为路径与数据异常诊断）。
• 不直接生成产品方案、功能设计、MVP 范围或研发排期；这些内容超出本 Skill 及当前新媒体核心 Skill 系统的职责，应交由产品、设计或研发职能处理。若用户进一步需要内容规划或增长策略，再分别路由对应 C 类（内容策略）或 G 类（增长转化）Skill；本 Skill 输出需求结论与建议，最多给"建议验证方向"。
• 用户原始表达、表层诉求、底层需求、未验证假设、给用户的建议必须分层分开标注，不混为一谈。
• 含个人信息材料先匿名化；未经匿名化不提交外部工具。
• 需求强度（是否真实、影响多大）与业务价值（是否符合当前目标）须分开，业务优先级判断属「推断」，须说明依据，不夸大代表性。

Examples

例 1（虚构示例，仅示范结构，不代表真实事实）：用户提供 8 份访谈转录（已匿名化为用户 A–H）+ 15 份问卷开放题 + 20 条客服对话。

• 用户 C 原话"我希望后台能加一个批量导出按钮"→ 标为「原始表达 / 方案偏好」，不直接当作需求事实；其在"月度给客户发报告"场景下反复手工复制（场景）→ 推断底层需求"减少跨系统手工搬运、保证导出数据完整"（标「推断」，回溯到 C 原话与手工复制场景）。
• "一次看到全部权益"这一诉求：访谈中明确有 3/8 位不同受访者提及（标「事实」，显性需求 = 用户明确表达的期望结果）；客服材料中另有若干条相似表达，但无法确认是否与访谈用户重复，标注"可能存在重复样本"，仅作为补充佐证；两类来源分别呈现，客服信号不与 3/8 相加，不称"多源"除非确有两个独立来源；样本内证据状态 = 样本内部分支持（依据为访谈 3/8 位独立受访者提及；客服相似表达可能重复，仅作补充信号，不提高独立样本数量）。 输出：需求分层表（原始表达→方案偏好→场景→底层需求[推断，含回溯]→待验证假设）；样本内证据状态（"权益汇总"=样本内部分支持，依据为访谈 3/8 位独立受访者提及；客服相似表达可能重复，仅作补充信号，不提高独立样本数量）与影响范围（中，因样本有限）分别表达；业务相关性（高，依据与续费 / 转化目标相关）；业务执行优先级建议 = 高，但明确这是综合业务价值、资源与样本证据后的"建议"，不等于需求已得到总体证实；"批量导出"因仅单点证据标「待验证」；建议优先验证"权益汇总"需求，可通过补充访谈、低保真原型测试或小范围可用性验证确认；"批量导出"继续补充场景证据。

例 2（虚构示例，无材料场景）：用户说"我想先知道该怎么挖需求"。输出：仅提供研究设计——访谈提纲 6 问、问卷框架、搜索词清单；明确标注"以下仅为研究设计；当前没有真实用户材料，因此不存在样本内证据支持的需求结论，所有需求判断均待验证；待你提供真实材料后我再归纳"。

例 3（虚构示例，多源去重与跨源相加禁止）：用户给 5 份访谈 + 30 条客服评论，其中"想要模板合集"在访谈（用户 B、D）与客服评论（多条，疑似同一人反复提）均出现。输出：访谈侧 2/5 提及，客服侧标注"多条但可能为同一用户反复表达，标可能存在重复样本"；分别呈现两来源频次，不把"2+30 条"直接相加得出"32 条想要模板合集"的总体比例；底层需求推断为"希望降低自行整理成本"，回溯到 B、D 原话与客服重复诉求。

最终自检

• 触发准确：仅覆盖多源用户需求归纳与研究设计，已互指 R05 / D04 / C / G 相邻 Skill。
• 边界清晰：不代写选题 / 方案 / 话术，无材料不虚构结论；用户解决方案不直接等同底层需求。
• 无来源数字：示例数字均为虚构且内部自洽（8+15+20 样本；例 3 访谈 2/5、客服标注重复）。
• 分层清晰：用户原始表达、表层诉求、场景、底层需求、待验证假设、建议分开标注；底层需求可回溯。
• 多源去重：同一用户跨源不机械计多用户；不同来源不相加比例。
• 需求强度与业务价值分离：未把"真实"与"符合业务目标"混为一谈。
• 样本内支持未误写为总体已证实：验证状态口径为"样本内证据较充分 / 样本内部分支持 / 待验证"，结论附"本结论基于所提供的 X 份材料，不代表全量用户"限制。
• 业务执行优先级与需求证据状态分离：优先级建议明确为综合业务价值、资源与样本证据后的"建议"，不替代"样本内部分支持"的需求证据状态，不暗示需求已总体证实。
• 推断已标注：潜在需求、阻碍、底层需求、优先级均标「推断」并给依据。
• 示例自洽：例 1/2/3 各项数量可核对。
• 未写死工具：仅用"当前已配置的搜索、浏览器、平台数据或文件分析工具"。
• 未越界：输出到需求地图与建议为止，不生成内容 / 产品方案。