AI需求冲突检查是在需求进入评审或排期前，用模型对同一批次或同一需求集内的需求文本做交叉比对，找出彼此矛盾、重叠或无法同时满足的地方。它主要识别四类冲突：目标冲突、范围重叠、约束矛盾和优先级冲突，输出一份可逐条判定的冲突清单。
要点总览（TL;DR）
- AI需求冲突检查在需求评审或排期前，对同一批次需求做交叉比对，主要识别目标冲突、范围重叠、约束矛盾和优先级冲突四类问题。
- 目标冲突看业务目标与成功指标是否对立，范围重叠看功能、数据对象、用户群体是否重复覆盖，约束矛盾看性能、合规、兼容、工期等限制是否互斥，优先级冲突看资源与排期下优先顺序能否同时成立。
- 输出是一份可逐条判定的冲突清单，包含冲突类型、严重程度、涉及需求条目、冲突位置、判定依据、影响范围、建议处置和待确认问题与责任人。
- 冲突检查只比对已落文本的需求之间的关系，不替代需求澄清访谈、业务决策和需求文档成稿，隐含需求与口头约定需先补录为条目才能参与比对。
- 模型输出的是候选冲突，需经需求负责人复核确认，未识别出冲突不等于需求集一致。
AI需求冲突检查识别哪些冲突类型
冲突检查的核心判断标准是“两条或多条需求放在一起能否同时成立”。单条需求写得是否清楚、是否完整，属于需求质量检查的范围；冲突检查关注的是需求之间的关系。以下四类覆盖了多数实际场景，判定时可以对照需求原文中的表述线索。
| 冲突类型 | 定义 | 判定线索 | 典型表述 |
|---|---|---|---|
| 目标冲突 | 两条需求追求相反的业务结果或成功指标 | 业务目标、成功指标、用户价值方向是否对立 | 一条要求“缩短下单路径至两步”，另一条要求“下单前增加实名核验与风险确认” |
| 范围重叠 | 多条需求覆盖同一功能、同一数据对象或同一用户群体，边界未划清 | 功能名称、数据字段、页面入口、适用人群是否重复 | 两条需求都要求“在订单详情页展示物流轨迹”，一条归客服模块，一条归履约模块 |
| 约束矛盾 | 性能、合规、兼容性、工期等限制条件互相排斥 | 响应时间、数据留存期限、支持的系统版本、交付日期是否互斥 | 一条要求“日志保留180天用于审计”，另一条要求“日志7天后自动清除以控制存储成本” |
| 优先级冲突 | 在既定资源和排期下，优先顺序无法同时成立 | 优先级字段、依赖关系、同一迭代容量是否超载 | 两条需求都标为最高优先级，且都依赖同一个开发小组在同一迭代内完成 |
目标冲突往往藏在措辞温和的需求里，需要比对成功指标而非字面表述。范围重叠的判定重点是边界：同一功能由两个模块各自建设，交付后会出现重复入口或数据口径不一致。约束矛盾的线索通常是具体数字和期限，两个数字放在一起就能看出无法同时满足。优先级冲突则要结合资源与排期看，单看优先级字段可能都合理，放进同一迭代才暴露问题。
冲突检查的边界：它检查什么、不检查什么
冲突检查的对象是需求文本之间的关系，前提是这些需求已经以条目形式落入需求库或文档。它回答“这些需求放在一起有没有打架”，不回答“这条需求值不值得做”。把边界划清，才能判断检查结果该交给谁处理。
它不替代需求澄清访谈。需求背后的用户意图、业务取舍，需要产品负责人与业务方沟通确认；冲突清单只能指出“这里存在矛盾”，无法替团队决定保留哪一条。它也不替代业务决策，涉及预算、合规底线、战略方向的取舍，仍由相应负责人拍板。
它不负责生成需求文档成稿。冲突检查的产物是问题清单，不是PRD；把清单结论回填到需求条目、补充验收标准，属于后续整理动作。对于尚未落成文本的内容，例如会议上的口头约定、团队默认的隐含需求，检查无法覆盖，这类内容需要先补录为需求条目再参与比对。
冲突是怎么被识别出来的：比对机制与组成
一次完整的冲突检查由输入准备、多维比对、结果生成和人工复核四个环节组成。模型负责扩大比对覆盖面，人负责判定取舍，两者分工明确。
输入准备
输入包括需求条目本身、结构化字段和必要上下文。条目提供需求描述与验收标准；字段提供优先级、所属模块、目标版本、依赖关系等可比对的结构化信息；上下文包括所属业务目标、迭代容量和已有约束规范。字段越完整，规则校验能发现的问题越多。
多维比对
比对沿四个维度展开：目标维度看业务目标与成功指标是否对立；范围维度看功能、数据对象、用户群体是否重复覆盖；约束维度看性能、合规、兼容、工期等限制是否互斥；优先级维度结合资源与排期看优先顺序能否同时成立。语义比对负责发现措辞不同但含义相近或相反的需求，规则与字段校验负责发现优先级重复、依赖成环、同一迭代容量超限这类结构化问题。
结果生成与人工复核
比对结果汇总为冲突条目，每条附上涉及的需求、冲突位置和判定依据。人工复核放在评审环节：由需求负责人逐条确认冲突是否成立、属于哪一类、如何处置。模型给出的是候选冲突，复核后的结论才进入需求变更。
冲突检查输出通常包含哪些可评审信息
输出清单要能直接支撑一场评审会，每条冲突需要让人在不翻原文的情况下判断“是否成立、影响多大、谁来处理”。以下字段构成一份可评审的冲突清单。
| 字段 | 内容说明 | 评审用途 |
|---|---|---|
| 冲突类型 | 目标冲突、范围重叠、约束矛盾或优先级冲突 | 决定由哪类角色主导处置 |
| 严重程度 | 按影响范围与阻塞程度分级，如阻塞排期、影响体验、待观察 | 确定评审处理顺序 |
| 涉及需求条目 | 冲突各方的需求编号与标题 | 快速定位原文 |
| 冲突位置 | 具体到需求中的目标句、约束条款或字段值 | 避免整条需求被误判 |
| 判定依据 | 引用双方原文，说明为何构成冲突 | 供复核时核对，减少误报争议 |
| 影响范围 | 受影响的模块、版本、用户群体或下游依赖 | 评估处置成本 |
| 建议处置 | 合并、拆分、调整优先级、修改约束或补充澄清 | 作为讨论起点，非最终结论 |
| 待确认问题与责任人 | 需要谁回答什么问题，何时给出结论 | 把评审结论落到人和时间 |
清单进入评审后，处置动作需要被跟踪到关闭。在ONES中，需求以工作项形式管理，评审中确认的冲突可以转为待澄清事项或关联到对应需求条目，处置结论回写到需求描述或Wiki页面，后续迭代排期时可直接查看。ONES Assistant可基于项目与Wiki上下文提炼待澄清问题与拆解建议，帮助团队在需求澄清阶段把冲突讨论转化为可追踪的工作项；相关输出过程可追踪、结果可审计。
与相邻概念的区别：冲突检查、需求分析与文档生成
这三个概念常被混用，区别在于各自回答的问题不同：冲突检查回答“需求之间是否打架”，需求分析回答“需求是否成立、是否值得做”，文档生成回答“如何把结论写成规范文本”。
| 对比项 | 冲突检查 | 常规需求分析与澄清 | AI辅助文档与报告生成 |
|---|---|---|---|
| 核心问题 | 多条需求能否同时成立 | 需求背后的真实问题与价值 | 如何形成规范、完整的文档 |
| 主要输入 | 已落文本的需求条目与字段 | 用户访谈、业务目标、数据 | 分析结论、评审记录、模板 |
| 主要输出 | 冲突清单与待确认问题 | 需求范围、优先级与验收标准 | PRD、报告、会议纪要等成稿 |
| 主导角色 | 需求负责人组织评审 | 产品负责人与业务方 | 文档撰写者与评审人 |
与需求去重的关联在于：范围重叠是去重的主要线索，但去重只处理重复建设，冲突检查还要处理目标对立和约束互斥。与需求评审的关联在于：冲突清单是评审的输入材料之一，评审还要判断需求价值、估算工作量、确认验收标准。冲突检查让评审更聚焦，评审结论反过来修正冲突清单中的建议处置。
具体例子与常见误解
下面两组示例展示四类冲突在真实需求文本中如何出现，随后列出三个需要纠正的常见误解。
示例一：目标冲突与范围重叠
某电商团队同一批次提交两条需求。需求A：“优化结算流程，将下单步骤从四步压缩到两步，提升转化率。”需求B：“结算前增加收货地址二次确认与风险提示，降低错发率。”两条需求的目标指标一个指向转化率、一个指向错发率，在结算页这一同一范围内形成目标冲突；同时两条需求都改动结算页交互，范围重叠，边界未划清。检查输出应指出冲突位置在结算页流程，建议合并为一条需求并明确两个指标的取舍顺序。
示例二：约束矛盾与优先级冲突
某后台系统两条需求：需求C要求“操作日志保留180天以满足审计要求”，需求D要求“日志存储成本下降，超过7天的日志自动清理”。两条约束在留存期限上直接互斥，属于约束矛盾，需要合规与运维共同确认折中方案。另一组：需求E和需求F都标记为最高优先级，且都依赖同一小组在同一迭代完成，迭代容量不足以同时承载，属于优先级冲突，需要在排期会上调整顺序或拆分交付。
常见误解纠正
- 误解一：AI判定即为最终结论。模型输出的是候选冲突，措辞差异、上下文缺失都可能造成误报，需经需求负责人复核确认。
- 误解二：冲突数量越多越好。冲突数量反映的是需求集的不一致程度，不是检查质量；大量低置信度条目会稀释评审注意力，清单应按严重程度排序。
- 误解三：未识别即代表无冲突。检查只覆盖已落文本的需求，隐含需求、口头约定和跨批次需求不在比对范围内，未报出冲突不等于需求集一致。
常见问题
需求还没有写成正式条目，能做冲突检查吗？
冲突检查的比对对象是已落文本的需求条目及其字段，需求尚未形成条目时缺少可交叉比对的内容。会议上的口头约定、团队默认的隐含需求，需要先补录为需求条目，补齐优先级、所属模块、目标版本等字段，再纳入同一批次参与比对。补录本身也是整理过程，常能提前暴露部分矛盾。
AI报出的冲突都需要在评审会上逐条讨论吗？
不必逐条平均用力。冲突清单通常带有严重程度和判定依据，可以按影响范围与阻塞程度排序：会阻塞排期或影响合规底线的先处理，影响体验的次之，置信度低、依据不足的条目可由需求负责人先做一轮筛选。评审会的时间应集中在需要跨角色取舍的冲突上，措辞差异造成的误报可以在会前核对原文后直接关闭。
同一批需求分属不同团队维护，冲突检查还能覆盖吗？
可以覆盖，前提是这些需求能被放进同一次比对范围。跨团队需求往往分散在各自的需求库中，字段口径也可能不一致，检查前需要先统一比对范围，例如按同一业务目标或同一版本拉取需求集，并尽量对齐优先级、模块等字段定义。跨批次、跨版本的需求关系容易遗漏，建议在检查说明中标注本次比对的范围边界。
冲突清单确认后，处置结论怎么跟踪到关闭？
评审确认的冲突需要转化为可追踪的事项，常见做法是把待澄清问题转为任务或关联到对应需求条目，明确责任人与答复时间，处置结论回写到需求描述或知识库页面。在ONES中，需求以工作项形式管理，评审结论可以落到工作项与Wiki页面，后续迭代排期时可直接查看；ONES Assistant可基于项目与Wiki上下文提炼待澄清问题与拆解建议，相关输出过程可追踪、结果可审计。
冲突检查发现的问题越多，是否说明需求质量越差？
冲突数量反映的是需求集内部的不一致程度，与单条需求的撰写质量不是同一件事。需求写得清楚但目标彼此对立，同样会产生冲突；反过来，需求描述含糊时，模型可能因语义不清而漏判或误判。评估检查效果更适合看高严重程度冲突是否被及时发现、误报比例是否可控，而非单纯比较条目数量。
