多来源需求合并与澄清

这个场景能帮你做什么

访谈、群聊和旧文档对同一需求说法不同，直接让 AI 写一份摘要，容易丢失例外条件或制造不存在的共识。本任务先逐份提取，再合并同义内容，保留来源、冲突与补问，形成可评审的需求清单。

开始前需要准备什么

准备访谈文字、会议笔记、需求文档、业务规则及已批准范围。说明提出者、角色、日期、版本、适用对象。旧稿仅供背景时明确注明。

最低输入是一组有出处的需求原话和业务背景。没有出处的转述只能作为待核线索，不能直接进入已确认需求。

具体怎么做

第一步：建立来源清单并逐份提取

让 WorkBuddy 为每份材料列名称、版本、角色、适用阶段和可读范围，再逐份提取业务对象、触发条件、希望采取的动作、预期结果、例外及原话位置。

资料多时分批处理，每批先交完整提取结果，再合并；不要要求它凭一次全库摘要直接给最终清单。

第二步：合并同义项，保留差异

比较是否在相同场景下解决同一问题。措辞不同而实际相同的可以合并，并保留全部来源；同样叫“审批”，但角色、金额条件或状态不同的，不应粗暴合成一句。

一般规则和例外分开记录。两个角色提出相反要求时，列冲突及影响，不能由工具选较顺口的一项。

第三步：区分事实、推断和假设

原文明确说出的内容列事实；工具推导的解释标推断；为使流程完整而提出的内容列假设或建议。将“应该可以配置”写成“必须支持所有配置”，就扩大了原始承诺，需要退回修改。

对“方便、快速、智能”等表达，提出面向实际业务的补问：谁在什么节点使用，希望看到什么结果，怎样判断可接受。

第四步：形成评审与澄清清单

按业务对象组织稳定编号，保留候选需求、确认状态、来源、例外和问题。让业务负责人逐项确认冲突、优先级及验收口径。确认结果再交范围和需求追踪任务使用。

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

请整理指定访谈、会议和需求文档，不修改原文。
先逐份提取业务对象、场景条件、期望动作、结果、例外和原话位置，再按业务对象比较合并。
合并项保留所有来源；相似表述存在条件差异时保留差异，冲突不要自动统一。
区分原文事实、分析推断、待确认假设。不得新增确定需求或自定验收阈值。
输出带编号的需求清单、重复合并说明、冲突清单和澄清问题。每个问题说明影响及建议确认角色；原文没有负责人或时间时保持待确认。

完成后会得到什么

需求表应含编号、业务对象、条件、动作、结果、例外、来源及状态；另有冲突和补问表。读者应能从任何合并项回到所有原始说法。

结果应该怎么检查

抽查合并后是否丢角色、否定词和例外；检查未来期待是否被写成本期必须交付；已确认是否确有确认依据。数量减少本身不证明合并正确。

遇到这些情况怎么处理

规则冲突先找规则负责人；关键原话缺上下文则补取相关段落；旧版已失效但被多次引用，注明历史身份。输入只有零散片段时，只声明覆盖这些片段，不宣布需求收集完整。

哪些由工具处理，哪些必须人工决定

WorkBuddy 提取、建议合并和列疑问。相关方确认真实需求与条件，授权人决定优先级和承诺范围，工具不代表各方达成共识。