AI需求冲突检查的输出，是一份供评审使用的冲突清单：它逐条列出冲突类型、涉及的需求条目与原文位置、冲突的具体表现、判断依据与置信度、影响范围，以及待人工确认的问题和建议处置方向。这份清单帮助评审者快速定位矛盾并作出判断，需求取舍和优先级决策仍由人完成。下面按输出构成、冲突类型、生成机制、概念边界和评审用法依次说明。
要点总览（TL;DR）
- AI需求冲突检查的输出是一份可评审的冲突清单，每条包含定位信息（冲突编号、涉及需求、原文位置）、判断信息（冲突类型、冲突表现、判断依据、置信度、影响范围）和处置信息（待确认问题、建议处置方向）。
- 检查主要识别四类冲突：目标冲突、范围重叠、约束矛盾、优先级冲突；类型标签决定评审时由谁主责、按什么规则处理。
- 冲突结论由抽取、比对、归并三个环节产生，置信度反映判断的确定程度，低置信度条目往往指向需求描述本身的模糊之处，值得优先澄清。
- 冲突检查在评审之前运行，为评审提供输入，不改变需求内容，也不替评审作决定；与需求分析、AI文档成稿各有分工。
- 评审时按类型分组处理，先核对原文再判断冲突是否成立，被驳回的条目也应记录理由，避免重复提出。
AI需求冲突检查输出的核心构成
冲突检查的输出以“条目”为单位组织，每条对应一个可独立讨论的冲突点。评审者拿到清单后，能够不依赖原始对话或检查过程，仅凭条目内容判断“这个问题是否成立、影响多大、该怎么处理”。因此，一条完整的冲突条目通常包含定位信息、判断信息和处置信息三类字段。
| 字段类别 | 字段名称 | 内容说明 | 对评审的作用 |
|---|---|---|---|
| 定位信息 | 冲突编号 | 清单内唯一标识，便于会上引用和会后跟踪 | 让讨论有共同指向 |
| 定位信息 | 涉及需求条目 | 冲突双方或多方的需求编号与标题 | 快速找到相关需求 |
| 定位信息 | 原文位置 | 冲突表述所在的章节、段落或语句 | 核对原文，避免断章取义 |
| 判断信息 | 冲突类型 | 目标冲突、范围重叠、约束矛盾、优先级冲突等标签 | 决定由谁主责、按什么规则处理 |
| 判断信息 | 冲突表现 | 用一两句话说明两处表述如何相互矛盾 | 评审的第一判断依据 |
| 判断信息 | 判断依据 | 引用的原文语句、术语定义或约束条件 | 支撑结论可被检验 |
| 判断信息 | 置信度 | 高、中、低或类似分级，表示AI对结论的把握 | 决定复核力度和讨论顺序 |
| 判断信息 | 影响范围 | 涉及的功能模块、版本、上下游需求或验收条件 | 评估处理优先级 |
| 处置信息 | 待确认问题 | 需要业务方或需求方回答的具体问题 | 把讨论导向可决策的点 |
| 处置信息 | 建议处置方向 | 如合并、拆分、补充约束、调整优先级等候选动作 | 提供起点，供评审选择 |
可评审性主要体现在三处：原文位置让结论可核对，判断依据让结论可检验，待确认问题让讨论可收敛。缺少其中任何一项，条目就容易退化成“AI说这里有问题”的模糊提示，评审时难以推进。
冲突类型：检查主要识别哪几类问题
冲突类型是对问题性质的归类，决定评审时由谁主责、按什么规则处理。常见的四类冲突在需求文本中有不同的识别线索。
| 冲突类型 | 含义 | 需求文本中的典型表现 |
|---|---|---|
| 目标冲突 | 两条需求追求的业务目标相互抵触 | 一处要求提升转化率、放宽审批，另一处要求强化风控、增加审批环节 |
| 范围重叠 | 不同需求覆盖同一功能或同一数据对象，边界不清 | 两个需求都描述“订单导出”，字段与权限定义不一致 |
| 约束矛盾 | 性能、合规、兼容性、时限等约束条件无法同时满足 | 一处要求响应时间在1秒内，另一处要求全量实时校验 |
| 优先级冲突 | 资源或排期上互斥的需求被同时标为高优先级 | 同一迭代内两项需求都标注“必须上线”，依赖同一批人力 |
类型标签的价值在于分流：目标冲突通常需要业务负责人拍板，范围重叠适合由需求分析人员合并澄清，约束矛盾往往要回到技术方案评估，优先级冲突则进入排期协调。评审会按类型分组处理，比逐条泛泛讨论更高效。类型标签同时提示了判断依据的来源——目标冲突看业务背景，约束矛盾看指标口径，评审者可据此检查AI引用的依据是否成立。
从需求文本到冲突条目：检查是怎么跑出来的
冲突检查的输入是结构化的需求材料：需求条目及其正文、明确的约束条件（性能、合规、兼容性等）、优先级标注，以及必要的术语定义和业务背景。输入越完整，比对越有依据；如果约束条件只存在于口头约定，检查就难以发现相关矛盾。
检查过程大致经过三个环节。第一步是抽取，把每条需求拆成目标、功能范围、约束、优先级等要素，并保留原文位置。第二步是比对，在同一需求集内交叉比较要素之间的一致性，包括目标之间是否抵触、范围是否重叠、约束能否同时满足、优先级与资源是否匹配。第三步是归并与表述，把发现的问题整理成条目，附上原文引用、置信度和待确认问题。
置信度反映的是判断的确定程度，与结论正确性不是一回事。表述明确、依据直接的矛盾，置信度较高；依赖语义推断、术语含义不清或背景缺失的判断，置信度较低。低置信度条目不应被直接删除，它们往往指向需求描述本身的模糊之处，值得在评审中优先澄清。人工复核的重点因此有两层：核对高置信度条目的依据是否被正确引用，以及判断低置信度条目是误报还是真实缺口。
需要明确能力边界：冲突检查基于已有文本做一致性比对，无法发现文本中完全没有记录的口头约定或外部约束；它给出的是候选冲突，不是定论。
冲突检查与需求评审、需求分析的边界
冲突检查、需求分析、需求评审是三个相邻但不同的动作。需求分析回答“需求是否完整、清晰、可实现”，产出的是澄清后的需求描述；冲突检查回答“这些需求之间是否相互矛盾”，产出的是冲突清单；需求评审则是人对需求（包括冲突清单）作出取舍和批准的会议决策过程。
三者的衔接关系是：冲突检查在评审之前运行，把分散在各处的矛盾集中呈现，减少评审会上逐条比对原文的时间；评审会以冲突清单为输入之一，对每条冲突作出确认、驳回或延后处理的决定，并记录结论。冲突检查不改变需求内容，也不替评审作决定。
与AI文档成稿的分工同样清晰：冲突检查的输出是结构化的条目清单，供人判断；文档成稿是把已确认的内容组织成PRD、评审纪要等成品文档。前者服务于“发现问题”，后者服务于“表达结论”，两者可以衔接，但输出形态和用途不同。
在评审流转环节，冲突条目需要被登记、指派、跟踪到关闭。ONES Assistant可理解项目、工作项、迭代和Wiki页面等工作上下文，并把自然语言指令转化为ONES中可追踪的工作，将结果保存为工作项、Wiki页面等内容；结合ONES权限体系的输出过程可追踪、结果可审计。团队可以把冲突条目登记为工作项、关联到对应需求，在评审后更新处置状态，使每条冲突都有明确的负责人和结论记录。
一个具体例子：评审会上怎么用这份输出
以下为演示情景。某团队准备评审“会员中心改版”需求集，冲突检查输出中有一条条目：
- 冲突编号：C-07
- 涉及需求：REQ-112“会员等级页支持实时折扣计算”、REQ-118“折扣规则统一由后台配置下发”
- 原文位置：REQ-112第3节“性能要求”；REQ-118第2节“配置管理”
- 冲突类型：约束矛盾
- 冲突表现：REQ-112要求页面加载时本地实时计算折扣，REQ-118要求折扣规则统一由后台配置下发，两处对计算位置的约定不一致
- 判断依据：引用两处原文语句
- 置信度：中（“实时计算”是否包含本地计算存在语义空间）
- 影响范围：会员等级页、折扣配置后台、相关验收用例
- 待确认问题：折扣计算放在前端还是后台？实时性指标的具体口径是什么？
- 建议处置方向：明确计算位置后修订其中一条需求，或拆分为“展示实时、计算后台”的方案
评审会上，主持人按类型分组处理，先讨论约束矛盾类条目。针对C-07，技术负责人确认计算位置应放在后台，产品负责人同意修订REQ-112的表述，条目状态更新为“已决议”，并关联修订后的需求版本。整个过程约五分钟，结论有原文依据、有负责人、有记录。
常见误解是把AI结论当最终裁决。C-07的置信度为中，说明AI对“实时计算”的理解存在不确定性；如果评审者不看依据直接按AI建议修改需求，可能改错方向。正确做法是把条目当作讨论的起点：先核对原文，再判断冲突是否成立，最后由相应角色作出决定。对于被驳回的条目，也应记录驳回理由，避免下次检查重复提出同一问题。
常见问题
AI给出的冲突条目置信度低，评审时应该直接忽略吗？
不建议直接忽略。低置信度通常意味着AI在语义推断上存在不确定性，比如术语含义不清、背景信息缺失，或者同一表述可以有两种理解。这类条目恰恰指向需求描述本身的模糊之处，在评审中优先澄清往往能消除后续歧义。处理方式可以是：先核对原文，确认表述是否确实存在多种解读；如果确实模糊，补充术语定义或约束口径；如果确认是误报，记录驳回理由，便于后续检查参考。
需求材料不完整时，冲突检查还能用吗？
可以使用，但需要调整对结果的预期。冲突检查基于已有文本做一致性比对，输入越完整，比对越有依据。如果约束条件只存在于口头约定、优先级没有明确标注，检查就难以发现相关矛盾，输出可能偏向文本中已记录的部分。实践中的做法是：先补齐需求条目、约束条件和优先级标注等基础材料，再运行检查；对输出中置信度低或依据不足的条目，在评审中作为“待补充信息”处理，而不是当作结论使用。
冲突检查发现的条目，评审会上应该按什么顺序讨论？
常见做法是按冲突类型分组，而不是按条目编号逐条讨论。目标冲突通常需要业务负责人拍板，范围重叠适合由需求分析人员合并澄清，约束矛盾往往要回到技术方案评估，优先级冲突则进入排期协调。分组后由对应角色主责，讨论更容易收敛。组内可以再按影响范围和置信度排序：影响范围大、置信度高的条目优先处理，低置信度条目留出澄清时间。具体顺序应结合团队评审习惯确定。
被评审驳回的冲突条目需要记录吗？
建议记录。驳回理由本身是需求决策的一部分，说明团队已经判断过该问题不成立或暂不处理。记录驳回理由有两个作用：一是避免后续检查重复提出同一问题，减少评审噪音；二是当需求背景变化时，可以回溯当初的判断依据。记录内容可以包括驳回原因、判断人和时间，与冲突条目一起归档。
冲突检查的输出和需求评审纪要是什么关系？
两者是输入与产出的关系。冲突检查输出的是待评审的候选冲突清单，评审纪要是评审过程中对每条冲突作出确认、驳回或延后处理决定后的记录。冲突清单帮助评审聚焦矛盾点，评审纪要则固化决策结论和责任人。两者可以关联存放，便于从结论回溯到原始冲突条目，也便于跟踪未关闭条目的后续处理。
