AI识别出的需求冲突更适合当作待验证线索：它可能指向真实矛盾，也可能只是术语歧义或上下文缺失造成的误报。本文给出一套可直接套用的做法，先按统一字段登记冲突记录并保留原文出处，再用三步复核把记录分为有效冲突、误报和待澄清，最后通过指派、澄清和误报回写形成闭环。
要点总览（TL;DR）
- AI识别出的需求冲突先按统一字段登记：冲突编号、涉及需求条目及原文位置、冲突双方原文、AI判断类型与置信度、识别时间与模型版本、记录状态、复核结论与判定人。
- 用三步复核区分有效冲突与误报：先核对原文来源是否真实存在且指向同一对象，再判断语义是真矛盾、范围重叠还是表述含糊，最后评估对范围、验收标准和排期的影响。
- 复核由需求分析或产品负责人执行，有效冲突指派能对取舍做决定的责任人并设截止时间，关闭时留下澄清结论和需求条目修订或基线更新说明。
- 误报按术语歧义、上下文缺失、跨版本对比、把补充说明当对立要求等成因归类，回写到提示词、术语表或识别规则，并定期抽查已判误报的记录。
- 按周或按批次统计记录总数、有效冲突数、误报数和待澄清积压数，积压持续上升说明复核人力或澄清责任需要调整。
冲突记录先定字段：一条记录要能复核
冲突记录的价值在于让另一个人不看AI原始输出也能独立判断。字段设计围绕这个目标展开：保留原文、标明AI依据、区分自动填充与人工补充，并让状态可流转。下表是一套最小字段集，可以直接作为登记模板使用。
| 字段名 | 来源 | 是否必填 | 填写说明 |
|---|---|---|---|
| 冲突编号 | AI自动生成 | 必填 | 全局唯一，建议带批次前缀，便于按批次统计 |
| 涉及需求条目及原文位置 | AI自动填充，人工核对 | 必填 | 写明需求编号、文档名称、章节或段落位置；两条冲突表述分别记录 |
| 冲突双方表述 | AI自动填充 | 必填 | 直接引用原文，不做改写；AI摘要另设一栏，不能替代原文 |
| AI判断类型与置信度 | AI自动填充 | 必填 | 记录AI给出的冲突类型（如时限矛盾、范围矛盾）及置信度分值 |
| 识别时间与模型/规则版本 | AI自动填充 | 必填 | 用于回溯：同一文档在不同版本下识别结果可能不同 |
| 记录状态 | 人工更新 | 必填 | 待复核、有效冲突、误报、待澄清、已关闭，五选一 |
| 复核结论与判定人 | 人工填写 | 复核后必填 | 写明判定理由，指向三步复核中哪一步得出结论 |
| 澄清责任人与截止时间 | 人工填写 | 判定为有效冲突或待澄清时必填 | 责任人应为能对需求取舍做决定的人 |
| 关闭说明 | 人工填写 | 关闭时必填 | 记录澄清结论、需求条目修订或基线更新说明 |
填写时把AI自动填充部分与人工补充部分分开标注，例如用不同列或字段前缀区分。这样做的目的是让复核人一眼看出哪些内容是机器判断、哪些是人的结论，避免把AI摘要当成需求原文。原文引用必须保留到段落级位置，只留摘要的记录在复核时无法验证，等于把AI的判断又信了一遍。
三步复核：把有效冲突和误报分开
复核按固定顺序走三步，每一步都有明确的输入、动作和输出，任何人执行都能得到可比较的结论。顺序不能颠倒：来源不成立时无需判断语义，语义不构成矛盾时无需评估影响。
第一步：核对来源
输入是冲突记录中的两条原文引用。动作是回到需求文档确认这两条表述真实存在、未被断章取义，并且指向同一功能对象。输出是“来源成立”或“来源不成立”。常见的不成立情形包括AI引用了已删除的旧版本段落、把两条分属不同产品的需求放在一起比较。来源不成立直接判为误报，并在记录中注明原因。
第二步：判断语义
输入是确认存在的两条表述。动作是判断它们在同一条件下是否互斥。这里要区分三种情况：真矛盾，即同一条件下两条要求无法同时满足，例如同一接口的响应时限分别写为1秒和3秒；范围重叠，即两条表述分属不同模块、版本或场景，各自成立，放在一起看像冲突但实际不矛盾；表述含糊，即用词模糊导致AI读出对立含义，补充上下文后可能并不冲突。输出是“真矛盾”“范围重叠”或“表述含糊”。范围重叠判为误报，表述含糊判为待澄清。
第三步：评估影响
输入是判定为真矛盾的记录。动作是评估该冲突是否影响需求范围、验收标准或排期，据此定优先级。影响验收标准的冲突优先处理，仅影响文档表述的可以排后。输出是优先级和是否进入澄清流程。
| 判定条件 | 结论 | 后续动作 |
|---|---|---|
| 原文不存在、被断章取义或指向不同对象 | 误报 | 记录误报原因，归入回写清单 |
| 两条表述分属不同模块、版本或场景，各自成立 | 误报 | 注明范围差异，回写识别规则 |
| 同一条件下要求互斥，影响范围、验收标准或排期 | 有效冲突 | 指派澄清责任人，设定截止时间 |
| 表述含糊，需补充上下文才能判断 | 待澄清 | 向需求提出方补充信息后重新判定 |
误报的成因集中在几类：术语歧义，同一词在不同团队含义不同；上下文缺失，AI只看到片段没看到前置条件；跨版本对比，把历史版本和新版本的要求放在一起；把补充说明当成对立要求，例如一条写“响应时间不超过3秒”，另一条写“高并发场景下可放宽至5秒”，后者是对前者的补充而非否定。复核时对照这几类成因，能加快判定并让误报原因可归类。
角色与交付物：谁复核、谁澄清、谁关闭
记录堆积的常见原因是每个环节都以为别人会处理。把角色、动作和交付物固定下来，记录才有流转的动力。
| 角色 | 动作 | 交付物 |
|---|---|---|
| AI工具侧 | 生成冲突记录，标注置信度与原文出处 | 待复核状态的冲突记录，不直接判定冲突成立 |
| 需求分析或产品负责人 | 执行三步复核，判定记录状态，组织澄清 | 复核结论与判定理由，澄清会议或澄清问题的清单 |
| 需求提出方 | 参与澄清，说明原始意图与业务约束 | 对冲突双方表述的取舍意见 |
| 实现方 | 参与澄清，说明技术约束与实现影响 | 可行性反馈与影响范围说明 |
| 需求分析或产品负责人 | 确认取舍结论，更新需求条目 | 澄清结论、需求条目修订或基线更新说明 |
关闭记录的交付物必须包含澄清结论和需求条目的修订说明，仅有“已处理”字样的记录无法支撑后续追溯。复核时限按批次设定，例如每批记录在三个工作日内完成判定；超时未判定的记录升级到需求负责人，由其决定是加急复核还是暂缓。待澄清记录同样设时限，超过时限未补充信息的，由复核人决定降级为误报或维持待澄清并说明原因。
示例：一条冲突记录从识别到关闭
以下为演示情景，用于说明字段填写和判定过程。
背景：AI从一份需求文档中识别出两条关于同一查询接口响应时限的表述。表述A位于第3章“性能要求”：“单次查询响应时间不超过1秒。”表述B位于第5章“验收标准”：“批量查询场景下响应时间不超过3秒。”AI判定为时限矛盾，置信度0.82。
记录填写：冲突编号CR-2024-031；涉及需求条目REQ-118与REQ-121，原文位置分别为第3章第2节、第5章第1节；冲突双方表述直接引用上述两句；AI判断类型为时限矛盾，置信度0.82；识别时间与模型版本按实际填写；状态为待复核；AI自动填充部分标注为机器生成，复核结论栏留空待人工填写。
复核过程：第一步核对来源，两条表述在文档中真实存在，均指向查询接口，来源成立。第二步判断语义，表述A针对单次查询，表述B针对批量查询，属于不同场景各自成立，判定为范围重叠，即误报。第三步无需评估影响。
误报处理：记录状态改为误报，原因归类为“上下文缺失——AI未识别场景限定词”。回写动作是在提示词中补充要求：比较时限类表述时先提取适用场景，场景不同则不判为冲突。
对照一条有效冲突：另一条记录中，表述C写“登录失败5次锁定账户”，表述D写“登录失败10次锁定账户”，两条均针对同一登录功能且无场景限定，属于同一条件下要求互斥。复核判定为有效冲突，影响安全验收标准，优先级高。指派安全模块的产品负责人为澄清责任人，截止时间为两个工作日后。澄清结论采用5次锁定，需求条目REQ-130修订，基线更新说明记录在案，记录状态改为已关闭。
闭环跟踪与误报回写：让下一轮识别更准
单条记录的判定解决个案，批量统计和规则回写才让识别质量逐步提升。统计按周或按识别批次进行，口径固定为四项：记录总数、有效冲突数、误报数、待澄清积压数。积压数反映流程是否通畅，连续多期上升说明复核人力不足或澄清责任不清。
误报原因按前述几类归因后，回写到三个位置之一：提示词，补充判定条件和排除规则；术语表，统一团队内易混淆词汇的含义；识别规则，调整AI比较表述时的匹配范围。每次回写记录版本和生效时间，便于对比回写前后的误报率变化。
有效冲突的处理结果要与需求基线变更建立关联，关闭记录中注明对应的需求条目修订或基线版本，这样在追溯需求变更原因时能查到冲突澄清的依据。此外定期抽查已判定为误报的记录，例如每批抽取一定比例由另一名需求分析人员复看，防止复核人因赶进度而漏判。
当冲突记录需要进入团队日常协作流程时，可以把记录作为工作项登记在项目管理工具中跟踪状态流转。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和 Wiki 页面等真实工作上下文，并基于相关项目数据和团队知识回答问题、执行后续操作；其AI能力基于ONES权限体系运行，输出过程可追踪、结果可审计。围绕PRD质量检查，ONES Assistant 可提炼待澄清问题与拆解建议，这些输出可以作为冲突记录的输入线索，复核判定和关闭仍由需求负责人完成。是否具备自动识别需求冲突并生成记录的能力，需结合具体场景核验。
完成检查：这套记录机制是否可用
机制上线前逐项核对以下条目，全部满足即可认为达到可用状态；有未满足项时，先补齐再扩大使用范围。
- 每条记录都能追溯到需求原文的具体章节或段落位置，原文引用完整保留。
- 每条记录都有明确的判定结论和判定人，结论对应三步复核中的具体步骤。
- 有效冲突都有澄清责任人和关闭时间，超时记录有升级处理记录。
- 误报有原因归类，并已回写到提示词、术语表或识别规则，回写有版本记录。
- 统计口径固定，能按周或按批次输出记录总数、有效冲突数、误报数和待澄清积压数。
- 已关闭记录包含澄清结论和需求条目修订或基线更新说明。
- 已判定为误报的记录有定期抽查安排，抽查结果有记录。
常见问题
AI给出的冲突置信度很高，还需要人工复核吗？
需要。置信度反映的是模型对自身判断的把握程度，不能替代对原文的核对。复核的第一步就是回到需求文档确认两条表述真实存在、未被断章取义且指向同一对象，这一步只有人能完成。实践中可以把高置信度记录排在复核队列前面，但判定结论仍由复核人填写，并在记录中写明依据三步复核中的哪一步得出结论。
两条需求分属不同版本，AI判为冲突，应该算有效冲突还是误报？
先确认这两条表述当前是否同时生效。如果旧版本要求已被新版本替代，属于跨版本对比造成的误报，记录中注明版本差异并回写识别规则，让AI比较时先确认版本有效性。如果两个版本的要求需要并行维护，例如不同客户或不同部署环境各自适用，则属于范围重叠，同样判为误报，但要注明适用范围，避免后续读者误读。
待澄清记录长期没人补充信息，怎么处理？
待澄清记录也要设时限，到期未补充信息的由复核人做二次决定：能根据现有上下文判断的，直接给出结论并转为有效冲突或误报；仍无法判断的，维持待澄清状态并写明卡点和下一步需要谁提供什么信息。连续多期待澄清积压上升时，应检查澄清责任人是否指错了人，或者问题描述是否过于笼统导致对方无法回应。
误报回写到提示词或识别规则后，怎么知道有没有效果？
每次回写记录版本和生效时间，然后用固定统计口径对比回写前后的误报数变化。对比时注意识别批次的文档范围是否可比，不同项目或不同文档类型的误报率差异较大，混在一起统计会掩盖真实变化。建议按文档类型或项目分别观察，连续几个批次误报率下降再判断回写有效。
冲突记录放在文档里还是放进项目管理系统跟踪？
取决于记录量和协作范围。记录少、参与人固定时，用带状态列的表格文档即可运转。记录量大、需要跨角色指派和跟踪截止时间时，把记录作为工作项登记在项目管理工具中更便于状态流转和统计。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和 Wiki 页面等真实工作上下文并执行后续操作，其AI能力基于ONES权限体系运行，输出过程可追踪、结果可审计；围绕PRD质量检查可提炼待澄清问题与拆解建议，这些输出可作为冲突记录的输入线索，复核判定和关闭仍由需求负责人完成。
