从用户反馈提取产品改进问题

这个场景能帮你做什么

评论、售后和服务记录混着产品问题、物流抱怨和使用误解。WorkBuddy 可以把已有反馈按型号、使用条件和问题现象整理，帮助研发找到值得核实的改进线索。

开始前需要准备什么

提供已取得的反馈文字、时间、型号或 SKU、渠道及可用的使用情境。说明研究期间、目标型号和已有分类规则。不要用少量精选好评或差评代表全部用户。

具体怎么做

第一步：分清反馈对象

先区分产品功能、可靠性、使用体验、包装、物流和服务。涉及多个问题的保留多项标签；没有足够文字的记录标为信息不足，不按星级自动推断原因。

第二步：形成可验证的问题描述

从原话提取现象、触发条件、影响和临时办法。将“质量差”保留为主观评价，将有具体条件的异常单列。型号不明、购买与使用时间不清的不能强行归入某个版本。

第三步：看分布与反例

按型号、期间和场景比较问题，统计时保留有效记录总数与重复处理口径。检查同一问题是否集中于某批次，是否也有同条件下正常使用的反馈。提及频率不能直接等同故障率。

第四步：转成研发验证清单

每项写清原话证据、影响对象、需补信息以及建议验证方式。物流破损可能要采购或交付参与，不能把所有问题都分给研发改设计。

可以直接交给 WorkBuddy 的完整要求

请整理附件中的用户反馈，目标型号与期间见说明。
区分产品、使用、物流和服务问题，保留原话及来源。抽取现象、条件、影响、临时处理和缺失信息。
按型号/版本/期间对比，说明有效记录数、重复口径和无法归属记录。不把评论频率当故障率，不从一句抱怨推定根因。
输出问题簇、代表原话、反例、需要补充的信息和研发验证清单。产品改进与物流服务改进分别交付。

完成后会得到什么

一份有证据的问题分类表和验证清单。例如“某接口在特定连接顺序下失效”可以进入复现准备，“不好用”需要继续补问。

结果应该怎么检查

抽查分类是否尊重原文，重复反馈是否被多算，型号和期间是否可比。重点检查高频问题之外的严重异常，避免按数量掩盖风险。

遇到这些情况怎么处理

反馈太短时补访，不自动写根因。只有截图时先取得可读文字，本流程不默认识图。新旧版本混杂时分组；无法确认版本的记录保留为未知。

哪些必须人工决定

研发与质量人员决定是否立项、复现和更改设计。AI 整理的是反馈线索，不能据此认定产品缺陷、责任归属或真实故障率。