jiaxuan-tao/vibe-coding-lab/user-feedback-insight-skill

用户反馈洞察

把访谈记录、客服工单、问卷开放题、应用商店评论等原始反馈转成可回到证据的产品机会。先判断证据支持什么，再讨论产品响应。

1. 分析范围与限制

先说明分析问题、来源、时间范围、记录数、已知抽样方式和偏差。若样本只来自差评页、单一渠道或主动反馈，明确结论只能描述当前样本，不能外推到总体用户。

输入含本地 UTF-8 .md、.txt、.csv 或 .json 时，运行：

python3 scripts/prepare_feedback.py /path/to/feedback.csv

脚本只生成结构证据，不修改原文件，也不代替语义分析。出现潜在直接身份信息时，在分析前提醒脱敏；输出证据时避免重复手机号、邮箱等原值。

2. 证据台账

把每条反馈拆成单一可判断的证据，保留稳定 ID。每项记录：

• 证据 ID 与来源；
• 用户场景；
• 问题或阻碍；
• 影响与现有替代方式；
• 用户表达的方案；
• 不确定性。

重复内容仍可保留，但标出重复关系。同一来源多次反馈说明该来源问题持续，不等于独立佐证；分别报告记录数与独立来源数。

3. 主题与矛盾

按用户任务或问题聚类，不按预设功能名强行归类。每个主题列出：

• 相关证据 ID；
• 样本内频次与独立来源；
• 共性场景和影响；
• 相反意见、异常样本与无法解释项。

不能确认同一事件是否被重复记录时，保留两种解释，不擅自合并。

4. 分开判断证据强度

分别判断以下维度，不将它们混成单一数字：

没有总体抽样基础时，只写 当前样本中 X/Y，不称为用户占比或问题发生率。

5. 产品机会

先把主题转写为待验证的机会，再讨论功能。每个机会包含：

• 机会陈述：谁在什么场景因什么问题无法完成什么任务；
• 相关证据 ID；
• 反证或矛盾；
• 样本内频次与独立来源数；
• 严重度、证据置信度与战略匹配；
• 最大未知；
• 最小验证动作。

用户提出的功能方案只作为可能响应，不等于已验证需求。若证据只支持问题存在，不直接承诺具体功能。

6. 行动建议

用一张表输出行动建议，每个产品机会占一行：

建议列完整填写以下四个值之一：

• 立即处理：已确认的高严重度故障、合规或不可逆风险；
• 进入验证：问题值得继续，但方案、覆盖面或价值仍需验证；
• 持续观察：信号存在，但独立来源或影响不足；
• 暂不推进：与目标用户或当前战略不匹配，或已有反证。

正向反馈、设计约束和补充说明放在表后，不另造建议值。若用户要求路线图，把机会作为候选输入，继续保留证据边界。

7. 待补证据

最后只列会改变判断的缺口，例如版本、设备、任务频率、独立用户数、基线、日志或代表性抽样。不要用泛泛的“继续调研”结束。

输出结构

按以下顺序输出：

1. 分析范围与限制
2. 证据台账
3. 主题与矛盾
4. 产品机会
5. 行动建议
6. 待补证据

完整口径和示例见 references/feedback-analysis-framework.md。仅在用户明确要求时，把已确认机会继续整理为 PRD 输入或需求候选。