jiaxuan-tao 用户反馈洞察
把访谈记录、客服工单、问卷开放题、应用商店评论等原始反馈转成可回到证据的产品机会。先判断证据支持什么，再讨论产品响应。
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. 待补证据
最后只列会改变判断的缺口，例如版本、设备、任务频率、独立用户数、基线、日志或代表性抽样。不要用泛泛的“继续调研”结束。
输出结构
按以下顺序输出：
分析范围与限制证据台账主题与矛盾产品机会行动建议待补证据
完整口径和示例见 references/feedback-analysis-framework.md。仅在用户明确要求时，把已确认机会继续整理为 PRD 输入或需求候选。