AI需求冲突检查的依据主要来自四类可追溯材料：需求条目本身、约束与规则、上下游关联信息以及决策记录。把这些材料按统一字段整理成可检索的输入，AI才能按“冲突类型—判定依据—证据位置”给出候选冲突，再由需求负责人逐条复核。本文给出依据清单、输入结构、提示设计、角色分工与完成检查方法，适用于需求理解与整理阶段。
要点总览（TL;DR）
- 冲突检查的依据分四类：需求条目（编号、版本、来源、验收口径）、规则与约束（业务规则、合规条款、技术限制、术语表）、上下游关联（相关需求、接口、数据字段、历史变更）、决策记录（评审结论、优先级、例外批准）。
- 把依据整理成统一字段的输入，同一术语只保留一个定义并注明出处，材料标注版本与时间，缺失项单独列出、不交给AI推断。
- 按目标冲突、约束冲突、范围重叠、术语不一致、优先级冲突五类设计提示，要求AI输出冲突类型、涉及需求、依据位置和置信度，无依据的疑似冲突标记为待确认。
- 复核由需求负责人逐条对照原文确认或驳回，确认项写明违反条款，驳回项写明理由，结论与处理动作留痕，作为下一轮检查的决策依据。
- 完成标准是每条候选冲突都能指向具体依据位置、待确认项单独分列、缺失依据列入补充清单。
冲突检查前要准备的四类依据
冲突检查的质量取决于输入材料是否完整、可追溯。四类依据各有最小字段要求，达到这个程度即可开始检查，不必等所有材料齐备。材料不全时，把缺失项单独列出，不交给AI推断。
| 依据类别 | 最小字段 | 作用 |
|---|---|---|
| 需求条目 | 需求编号、版本号、来源（业务方/用户反馈/合规要求）、验收口径 | 确定被检查对象及其边界，避免拿旧版本或模糊描述做判断 |
| 规则与约束 | 业务规则条款、合规条款、技术限制（性能、兼容性、依赖）、术语表 | 提供判定“是否违反”的标尺 |
| 上下游关联 | 相关需求编号、接口定义、数据字段说明、历史变更记录 | 发现范围重叠、接口不匹配、字段口径不一致 |
| 决策记录 | 评审结论、优先级排序、例外批准记录及批准人 | 区分真冲突与已决策的取舍，避免重复讨论 |
需求条目依据要能回答“这条需求是什么、从哪来、怎样算完成”。验收口径写得越具体，AI判断目标冲突时越有据可依。规则与约束依据中，术语表常被忽略，但同一术语在不同文档中含义不同，正是术语不一致类冲突的主要来源。关联依据的重点是接口与数据字段，两个需求各自合理、合在一起却字段口径冲突的情况，多从这里暴露。决策依据用于排除“已经拍过板”的项，例如某需求因合规要求被批准为例外，就不应再被标记为与通用规则冲突。
把依据整理成AI可读的输入结构
散落在文档、聊天记录和表格里的材料，需要先转成结构化输入。核心做法是统一字段、统一术语、标注版本，并显式记录缺失项。
统一字段设计
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 需求ID | 全局唯一，与需求管理工具中的编号一致 | REQ-1042 |
| 版本 | 标注当前有效版本及生效时间 | v3，2025-03-10生效 |
| 来源 | 业务方、用户反馈、合规要求或技术整改 | 合规要求 |
| 约束类型 | 业务规则、合规、技术限制、术语定义 | 合规 |
| 关联对象 | 相关需求ID、接口名、数据字段名 | REQ-0987；接口order.submit |
| 依据位置 | 原文所在文档与章节，便于复核时回查 | 《数据保留规范》第4.2节 |
整理步骤
- 按需求ID归集条目，同一需求的多份描述合并为一条，保留最新有效版本。
- 建立术语表，同一术语只保留一个定义并注明出处；发现两种定义并存时，先由领域专家裁定，再进入检查。
- 为每份材料标注时间与版本，旧版本材料单独存放，不参与对新需求的判断。
- 列出缺失材料清单，例如某需求缺少验收口径、某接口缺少字段说明；缺失项在提示中明确声明，要求AI不得据此推断。
整理完成后，输入应满足一个检验标准：任意一条候选冲突，都能从输入中定位到具体需求字段或规则条款。做不到这一点的材料，说明还没整理到位。
按冲突类型设计检查提示与判定口径
把冲突拆成可判定的类型，每类对应固定的依据来源和判定标准，提示中要求AI按统一格式输出，复核才有抓手。
| 冲突类型 | 主要依据来源 | 判定口径 |
|---|---|---|
| 目标冲突 | 需求条目的目标与验收口径 | 两条需求对同一业务对象提出互斥的结果要求 |
| 约束冲突 | 业务规则、合规条款、技术限制 | 需求内容与某条明确规则或限制直接相悖，且无例外批准记录 |
| 范围重叠 | 相关需求、接口与数据字段 | 两条需求覆盖同一功能范围或同一数据字段，职责归属未划分 |
| 术语不一致 | 术语表及原文定义 | 同一术语在不同需求中定义不同，导致行为理解分歧 |
| 优先级冲突 | 决策记录中的优先级与排期 | 资源或排期上互斥的需求被同时定为高优先级，且无取舍结论 |
提示结构建议固定为四段：检查范围（列出参与比对的需求ID与规则条款）、冲突类型清单、输出格式要求、缺失项声明。输出格式要求每条候选冲突包含：冲突类型、涉及需求编号、依据位置（文档与章节）、置信度（高/中/低）、建议复核人。对于找不到依据支撑的疑似冲突，统一标记为“待确认”，与有依据的候选冲突分列，避免混入结论。
置信度的用法要事先约定：高置信度指依据原文可直接对照，中置信度指需要结合上下文理解，低置信度指仅存在表述相似或潜在关联。复核顺序按置信度从高到低推进，可以在有限时间内先处理最确定的冲突。
角色分工与交付物
冲突检查涉及提供依据、运行检查、复核结论三类动作，责任要落到具体角色，每个环节有明确产出。
| 角色 | 输入 | 输出 |
|---|---|---|
| 需求负责人 | 需求条目、验收口径、需求间关联关系 | 结构化的需求条目清单，缺失项说明 |
| 业务或领域专家 | 业务规则原文、合规条款、术语使用情况 | 确认后的规则条款与术语表，含出处 |
| 架构或技术负责人 | 接口定义、数据字段说明、技术限制 | 技术约束清单与关联对象映射 |
| 检查执行人 | 上述整理后的输入、提示模板 | 候选冲突列表（含类型、依据位置、置信度） |
| 复核人 | 候选冲突列表、依据原文 | 逐条确认或驳回的结论，处理动作与责任人 |
复核人通常由需求负责人担任，涉及合规或技术条款的冲突，由对应专家会签。复核结论要写明依据：确认的冲突注明违反的条款或重叠的范围，驳回的冲突注明理由，例如“已有例外批准记录，见评审纪要2025-02-18”。这些记录本身就是下一轮检查的决策依据。
当需求条目、约束条款与评审记录集中留存并保持版本关联时，整理输入和回查依据会省去大量跨文档核对。ONES 的需求与文档管理可以把工作项、Wiki 页面和评审记录放在同一上下文中，ONES Assistant 能基于项目数据与团队知识回答问题并附引用来源，便于复核时定位原文；具体可用范围取决于所开通的模块与权限配置。
一次完整的冲突检查示例
以下为演示情景，用于说明流程形态，不代表真实项目数据。
某团队有两条需求：REQ-1042“用户注销后30天内清除个人数据”，来源为合规要求；REQ-1051“保留用户历史订单记录用于售后追溯，保留期3年”。相关约束包括《数据保留规范》第4.2节（个人数据删除时限）和术语表对“个人数据”的定义（含订单中的收货人信息）。
整理输入时，需求负责人补充了两条需求的验收口径，领域专家确认术语表中“个人数据”的范围，技术负责人提供订单表字段说明，标明收货人姓名与电话字段。评审记录显示，此前没有针对这两条需求的例外批准。
AI输出的候选冲突条目形态如下：
- 冲突类型：约束冲突；涉及需求：REQ-1042、REQ-1051；依据位置：《数据保留规范》第4.2节、术语表“个人数据”条目、订单表字段说明；置信度：高；建议复核人：需求负责人与合规专家。
- 冲突类型：术语不一致；涉及需求：REQ-1051；依据位置：术语表“个人数据”与需求原文“订单记录”；置信度：中；建议复核人：领域专家。
复核时，需求负责人对照原文确认第一条：订单记录中的收货人信息属于“个人数据”，3年保留期与30天删除要求直接相悖，且无例外批准，判定为确认冲突。第二条经领域专家核对，需求原文已注明“订单记录不含支付信息”，与术语表定义一致，判定为驳回，理由记入复核记录。
确认的冲突形成处理动作：由合规专家与业务方评估，将REQ-1051的保留范围调整为脱敏后的订单数据，保留期维持3年；调整后的需求重新进入下一轮检查。驳回项与处理结论一并留痕，作为后续检查的决策依据。
完成检查：结果可用性的判断标准
一轮冲突检查是否做到位，可以按以下清单逐项核对，全部满足即可视为完成。
- 每条候选冲突都能指向具体依据位置，包括文档名称与章节，或需求字段与版本。
- 无依据支撑的疑似冲突已单独标记为“待确认”，未混入确认结论。
- 每条候选冲突都有复核结论，确认项写明违反的条款或重叠范围，驳回项写明理由。
- 确认的冲突已形成处理动作，明确责任人与后续安排。
- 缺失依据已列入补充清单，注明缺失内容与补齐责任人。
- 本轮使用的材料版本与检查时间已记录，便于下一轮对比。
清单中任何一项不满足，说明结果还不能直接用于需求决策。常见缺口是候选冲突只写了“两条需求可能矛盾”而没有依据位置，这类条目应退回补充依据，而不是进入评审。缺失依据补齐后，可针对受影响的需求重新运行检查，已有结论无需重复复核。
常见问题
需求材料不齐时，能不能先让AI跑一轮冲突检查？
可以跑，但要先把缺失项写进提示，明确要求AI不得据此推断。缺验收口径的需求，AI无法判断目标冲突；缺接口字段说明的，范围重叠只能给出低置信度线索。更稳妥的做法是先补齐关键依据再检查，把缺失清单交给对应责任人，补齐后针对受影响的需求重跑，已有结论不必重复复核。
AI给出的候选冲突和人工判断不一致时怎么处理？
以依据原文为准。复核人对照AI标注的依据位置回查原文，能直接对照条款或字段的，按原文判定；AI判断有误的，驳回并写明理由，例如“术语表定义与需求原文一致”。若原文本身存在两种解释，先由领域专家裁定术语或规则口径，再重新检查，不把分歧留到评审会上解决。
已经评审通过的取舍，还会被AI重复标记为冲突吗？
取决于决策记录是否进入输入。把评审结论、优先级排序和例外批准记录按需求ID关联整理，并在提示中声明这些项已决策，AI就能区分真冲突与已拍板的取舍。若决策记录只存在于会议纪要中而未整理，重复标记的概率会明显上升，建议每轮检查前先同步一次决策记录。
冲突检查多久做一次比较合适？
常见做法是在需求进入评审前做一次，需求变更或新增关联需求后针对受影响范围重跑。全量重跑的成本主要在依据整理，若需求条目、约束条款与评审记录集中留存并保持版本关联，增量检查会轻很多。ONES 的需求与文档管理可以把工作项、Wiki 页面和评审记录放在同一上下文中，ONES Assistant 能基于项目数据与团队知识回答问题并附引用来源，便于复核时定位原文；具体可用范围取决于所开通的模块与权限配置。
术语不一致这类冲突，为什么建议单独列一类？
术语分歧往往不表现为两条需求直接矛盾，而是同一词在不同文档中含义不同，导致后续行为和验收标准出现偏差。单独列类并绑定术语表作为依据来源，可以迫使团队在检查阶段就把定义统一到一处并注明出处，避免在开发或验收阶段才发现理解不一致。
