合并多渠道需求并列出补问

这个场景能帮你做什么

销售说“客户要更快”，售后说“换型经常出错”，研发收到的可能是同一问题，也可能是不同问题。WorkBuddy 可以合并邮件、访谈和反馈中的需求候选，保留差异，形成研发可以继续澄清的清单。

开始前需要准备什么

准备本轮邮件、访谈证据表、售后记录、销售反馈及现有需求清单。各条保留日期、客户或用户角色、型号、使用情境与出处。提供产品范围和既有术语表；没有确认的用户数、损失和预算不作为事实输入。

具体怎么做

第一步：统一描述，不丢原文

让 WorkBuddy 按“使用者—任务—触发条件—障碍—期望结果”整理每条反馈，并保留原始表述。把要求某功能的方案建议与它想解决的问题分开。

第二步：比较是否是同一任务

只有对象、场景、工作目标和处理阶段基本相同时，才列为合并候选。名称相近但工况、责任或验收不同的分别保留。一个客户多次催同一问题，不能算成多个客户独立需求。

第三步：列出冲突和缺口

对速度与精度、成本与寿命等相互约束的要求，记录各自提出者和条件，不替团队选边。为缺少输入、边界、例外或验收条件的项目写具体补问，并注明应找谁确认。

第四步：形成可进入需求评审的候选表

每个合并项保留来源集合、共同部分、不能合并的差异、确认状态和下一步。仅已确认内容进入正式需求文档，假设与待补项单列。

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

请合并附件中本产品的多渠道需求候选。先提取角色、对象、任务、条件、问题和期望结果，保留原文定位。
按实际工作任务判断重复，列出合并理由和仍需保留的差异；不要按关键词相同直接合并。
统计时区分反馈条数、独立事件数与已确认用户数，没有身份依据不推断人数。
输出统一需求候选表、冲突表、补问清单。补问写明要确认什么及适合回答的角色。
不替客户补事实，不决定优先级，不把功能建议直接作为已确认方案。

完成后会得到什么

一张统一需求候选表及其来源关联。例如同一型号不同渠道提出的换型问题可放在同一主题下，但“设置参数耗时”和“机械换装耗时”应保留为不同处理任务。

结果应该怎么检查

抽查被合并的项目，确认没有混掉不同使用者、工况和验收标准。再检查未匹配记录，防止只整理高频反馈而遗漏低频但影响重大的例外。

遇到这些情况怎么处理

渠道说法冲突时安排验证，不按反馈职位高低自动判真。只有转述没有原始记录时，标明待核。旧版已解决问题仍被反馈时，检查实际使用版本，不直接重开开发任务。

哪些必须人工决定

产品负责人确认合并、拆分和需求状态，相关业务人员补足事实。AI 的归并结果只是评审输入，不构成对外承诺或排期决定。