AI在需求提取和整理中识别出的冲突，往往以零散提示或批注的形式出现，缺少统一登记和责任人，容易在评审前被忽略。要把这些提示变成可处理的问题，需要建立一条从登记、有效性判定、澄清、指派到关闭回写的治理链路。下面按环节给出字段、规则和检查项，并说明如何借助ONES承载记录状态与需求回写。
要点总览（TL;DR）
- AI识别出的冲突先按统一字段登记为待判定记录，保留AI原始输出片段和需求原文摘录，作为后续复核依据。
- 有效性判定看三点：指向同一需求对象、存在可比较的矛盾点、影响范围可说明；误报标注原因后关闭，并汇总用于调整AI提取规则。
- 有效冲突转为澄清事项，问题写到具体取值或排序，结论归为确认一方、合并折中、拆分需求、暂缓待定四类，并回写需求条目。
- 每条记录只设一个处理责任人，需求提出方、业务方、技术负责人按参与边界协办，超期未澄清按预设路径升级。
- 闭环以状态流转和三项关闭条件实现：需求已更新、结论有记录、相关方已确认；定期核对记录完整性与误报率、澄清周期。
冲突记录先落成什么：一张可判定的登记表
AI输出的冲突提示本身只是线索，登记的目标是让每条线索具备可判定、可指派、可追踪的基础信息。登记表不必复杂，但字段要固定，避免不同人用不同口径记录导致后续无法比较。
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 冲突编号 | 按统一规则生成，如CF-年份-序号，全项目唯一 | 作为澄清事项、讨论记录和需求变更的关联锚点 |
| 涉及需求条目 | 列出冲突双方或多方的需求编号与标题 | 明确冲突对象，便于回写 |
| 冲突类型 | 从预设类型中选择，如取值矛盾、范围重叠、优先级冲突、表述歧义、术语不一致 | 决定判定重点和指派方向 |
| AI识别依据与原文摘录 | 粘贴AI给出的判断理由及对应需求原文片段 | 支撑复核，减少二次查找 |
| AI原始输出片段 | 保留AI输出的完整上下文，不只保留结论句 | 用于判断是否误报 |
| 提出时间与提出人 | 记录AI输出被采纳为记录的时间及登记人 | 计算判定与澄清时限 |
| 状态 | 初始值统一设为“待判定” | 进入状态流转的起点 |
登记时建议区分两类冲突。事实型冲突指可以直接比较出对错的矛盾，例如同一字段在两个需求中取值不同、功能范围互相覆盖、优先级排序相反。解释型冲突指表述层面的不一致，例如同一概念使用不同术语、描述存在多种理解、补充说明与主描述语气冲突。事实型冲突通常判定快、澄清路径短；解释型冲突需要更多干系人参与，登记时应把歧义点写清楚，避免澄清会变成重新讨论需求本身。
登记规则有两条值得固定下来。其一，一条记录只对应一组冲突对象，若AI一次提示涉及三处矛盾，拆成三条记录，保证每条记录有独立的责任人和结论。其二，原文摘录保留版本信息，注明取自哪一版需求文档或哪个工作项，防止后续需求已修改而记录仍指向旧内容。
先判有效性：把有效冲突与误报分开
AI识别冲突依赖上下文匹配，误报并不少见。判定环节的任务是在投入澄清成本之前，筛掉不成立的记录。有效冲突需要同时满足三个条件：指向同一需求对象，存在可比较的矛盾点，影响范围可以说明。三者缺一，记录就不应进入澄清流程。
常见误报来源集中在三类。第一类是版本混读，AI把旧版需求和新版需求放在一起比较，得出并不存在的矛盾。第二类是对象错配，不同模块存在同名字段或同名功能，被当成同一对象。第三类是把补充说明误判为矛盾，例如一条需求写“支持批量导入”，另一条写“单次导入不超过五千条”，两者是主功能与限制条件的关系，并非冲突。
判定人建议由需求负责人或需求分析角色承担，涉及技术取值时邀请技术负责人共同确认。判定时限可以设为登记后一个工作日内完成，避免记录在“待判定”状态积压。判定结论只有两种：有效，转入待澄清；误报，标注误报原因后关闭。
误报不应简单丢弃。每条误报记录应写明误报类型，例如版本混读、对象错配、补充说明误判，并定期汇总。这些信息可以回流为AI提取规则的调整依据，例如在提示词或提取配置中补充版本过滤条件、明确对象标识字段。误报原因分类越稳定，后续优化越有针对性。
澄清怎么组织：从记录到澄清事项
有效冲突转为澄清事项时，输入包括冲突记录、涉及需求的当前原文、相关干系人名单。澄清事项应带着明确问题进入讨论，例如“需求A要求响应时间两秒内，需求B要求五秒内，以哪个为准”，而不是笼统地写“讨论响应时间冲突”。问题写得越具体，澄清会越短。
澄清方式按冲突复杂度和参与人数选择。同步评审会适合涉及三个以上角色、存在多种可选方案、需要当场权衡取舍的冲突，例如范围重叠导致的优先级重排。异步书面澄清适合事实型冲突或参与人少、结论明确的场景，例如取值矛盾只需业务方确认一个数值。异步澄清应设定回复截止时间，并在记录中保留书面回复作为依据。
澄清结论建议归为四种类型，便于统计和回写：
- 确认一方：采纳其中一条需求的取值或优先级，另一条相应调整。
- 合并折中：两条需求各取部分条件，形成新的统一表述。
- 拆分需求：冲突源于一条需求承载了过多目标，拆成两条独立需求后矛盾消失。
- 暂缓待定：当前信息不足或依赖外部决策，明确暂缓原因、责任人和复查时间。
无论哪种结论，都必须回写需求条目。回写内容包括修改后的需求描述、修改人、修改时间和结论依据。只在澄清会纪要里写结论而不改需求，等于冲突仍然留在文档里，下一轮AI提取还会再次识别出同一问题。
在ONES中，AI提炼出的待澄清问题可以保存为工作项或Wiki页面，澄清讨论和结论随记录一起留存，需求条目的修改也在同一项目上下文中完成，减少在多个页面之间搬运信息。ONES Assistant基于项目、工作项和Wiki页面等上下文回答问题并执行操作，输出过程可追踪，适合把澄清结论与原始记录放在同一条链路上核对。
指派与责任：谁改、谁确认、谁关闭
每条冲突记录只设一个处理责任人，这是指派环节的核心规则。责任人负责推动判定后的澄清、组织回写、确认关闭条件满足。多人共同负责容易造成等待和推诿，协办角色则以参与边界的方式定义，不共享处理责任。
| 角色 | 职责 | 参与边界 |
|---|---|---|
| 处理责任人 | 推动澄清、组织回写、发起关闭 | 每条记录唯一 |
| 需求提出方 | 说明原始诉求和业务背景 | 参与澄清，不承担记录流转 |
| 业务方 | 对取值、优先级、范围做业务判断 | 在涉及业务取舍时参与 |
| 技术负责人 | 评估技术可行性与影响范围 | 在涉及实现约束时参与 |
指派依据可以简化为两条：按冲突类型定角色，按需求归属模块定人选。取值矛盾和优先级冲突通常指派给需求负责人，由其协调业务方；范围重叠和术语不一致通常指派给对应模块的需求分析角色，技术负责人作为协办。若冲突跨越两个模块，由需求条目所属层级更高的一方责任人牵头，另一方作为协办。
升级路径需要提前写明。可以设定澄清时限，例如有效冲突登记后三个工作日内未形成结论，记录自动标记超期并上报至需求负责人上级或需求评审组。升级不是惩罚，而是把卡住的决策交给有权限的人。超期原因也应记录，区分“等待业务方回复”和“无人推进”，前者调整时限，后者调整责任人。
闭环跟踪：状态流转、时限与关闭条件
冲突记录的状态应少而明确，每个状态对应一个明确的下一步动作和责任人。
| 状态 | 进入条件 | 下一步动作 | 责任角色 |
|---|---|---|---|
| 待判定 | 记录登记完成 | 判定有效性 | 判定人 |
| 有效待澄清 | 判定为有效冲突 | 组织澄清 | 处理责任人 |
| 澄清中 | 澄清事项已发出或会议已安排 | 形成结论 | 处理责任人及协办 |
| 已澄清待回写 | 结论类型已确定 | 修改需求条目并留证 | 处理责任人 |
| 已关闭 | 关闭条件全部满足 | 无 | 处理责任人确认 |
| 已关闭（误报） | 判定为误报并标注原因 | 汇总误报原因 | 判定人 |
跟踪节奏建议与需求评审节奏对齐。每周查看一次处于“有效待澄清”和“澄清中”的记录，重点看是否临近时限；每次需求评审前核对“已澄清待回写”的记录是否完成回写。超期提醒可以由记录系统按截止时间触发，也可以由需求负责人在周会上逐条过。提醒的对象是处理责任人，抄送其上级。
关闭条件需要三项同时满足：需求条目已按结论更新，结论有书面记录，相关方已确认。三项缺一不可，尤其要防止“会开完了但需求没改”的情况。闭环证据包括澄清结论原文、确认记录（会议纪要、书面回复或系统确认）、变更后的需求版本号。证据与冲突编号关联保存，便于后续审计或复盘时追溯。
暂缓待定的记录不进入关闭，而是保留在“澄清中”并标注复查时间。复查到期后重新判定，若仍无法决策，按升级路径处理，避免暂缓变成事实上的遗忘。
示例：一条优先级冲突记录的完整处理过程
以下为演示情景，用于说明各环节的填写方式。
背景：某产品在需求整理时，AI提示两条需求存在优先级矛盾。需求REQ-118“订单列表支持按金额筛选”标注为P1，需求REQ-124“订单列表支持按时间筛选”标注为P0，两条需求同属订单模块同一迭代，资源只能先做一个。
登记环节填写：冲突编号CF-2024-037；涉及需求REQ-118、REQ-124；冲突类型为优先级冲突；AI识别依据为两条需求同模块同迭代且优先级标注相反，原文摘录分别保留两条需求的优先级字段和迭代字段；AI原始输出片段完整粘贴；提出时间为登记当日；状态设为待判定。
判定环节：判定人核对两条需求均指向订单列表筛选能力，矛盾点可比较，影响范围为当前迭代排期，判定为有效冲突，状态转为有效待澄清。若AI实际比较的是上一迭代的REQ-118旧版本，则应判定为版本混读误报，标注原因后关闭。
澄清环节：处理责任人组织异步书面澄清，向业务方提出具体问题“本迭代优先支持金额筛选还是时间筛选，依据是什么”。业务方回复时间筛选与本月对账场景直接相关，金额筛选可延后。结论类型为确认一方，采纳REQ-124的P0优先级，REQ-118调整为P2并移出本迭代。结论回写两条需求条目，记录修改人和修改时间。
指派与关闭：处理责任人由订单模块需求分析角色担任，业务方为协办。回写完成后核对关闭条件：两条需求条目已更新，结论有书面回复记录，业务方已确认，状态转为已关闭，证据与CF-2024-037关联保存。
完成检查：这套机制是否真的在运转
机制建立后，需要定期核对记录本身是否完整，而不是只看流程文档是否存在。以下检查项可以逐条核对：
- 所有冲突记录是否都有明确状态，是否存在长期停留在“待判定”的记录。
- 每条有效冲突是否都有唯一处理责任人和至少一个协办角色。
- 每条已关闭记录是否都能找到回写后的需求版本和结论依据。
- 误报记录是否标注了误报类型，是否定期汇总并用于调整AI提取规则。
- 暂缓待定的记录是否设定了复查时间，到期是否有人处理。
除完整性检查外，可以观察两个指标：误报率和澄清周期。误报率按误报记录数除以总记录数计算，持续偏高说明AI提取的上下文范围或匹配规则需要调整；澄清周期按有效冲突从登记到关闭的平均时长计算，周期拉长通常指向责任人空缺或决策权限不足。两个指标都应与上一周期对比，看趋势而非单点数值。
机制失效往往有早期信号：记录数量持续增加但关闭数量很少，说明澄清环节没有真正推进；结论写在会议纪要里但需求条目未变，说明回写责任没有落实；多条记录责任人一栏为空或反复变更，说明指派规则未被遵守。发现这些信号时，优先修复对应环节的责任人和时限，而不是增加更多记录字段。
常见问题
AI一次提示涉及多处矛盾，应该登记成一条还是多条记录？
建议拆成多条记录，一条记录只对应一组冲突对象。原因在于每条记录需要独立的责任人、澄清结论和关闭证据，若三处矛盾合并在一条记录里，容易出现部分结论已定、部分仍悬空，状态无法准确表达。拆分后按冲突编号分别跟踪，涉及同一需求条目的记录可以在回写时一并核对。
判定为误报的记录直接删除可以吗？
不建议删除。误报记录应标注误报类型后关闭，例如版本混读、对象错配、补充说明误判，并定期汇总。这些分类是调整AI提取规则的直接输入，例如补充版本过滤条件或明确对象标识字段。删除后误报原因无从统计，同类问题会在下一轮提取中重复出现。
澄清会上结论已达成，但需求条目暂时无法修改，记录能否先关闭？
不能。关闭条件要求需求条目已按结论更新、结论有书面记录、相关方已确认三项同时满足。只开会不改需求，冲突仍留在文档里，下一轮AI提取还会识别出同一问题。若确实需要等待排期修改，记录保留在“已澄清待回写”状态，由处理责任人跟踪到回写完成再关闭。
暂缓待定的冲突记录如何避免被遗忘？
暂缓待定不进入关闭，保留在“澄清中”状态并标注复查时间、暂缓原因和责任人。复查到期后重新判定：信息已具备则继续澄清，仍无法决策则按升级路径上报。把复查时间纳入每周跟踪清单，与临近时限的记录一起核对，可以避免暂缓变成事实上的遗忘。
用ONES承载这套冲突记录流程，需要额外配置什么？
ONES Assistant可基于项目、工作项和Wiki页面等上下文回答问题并执行操作，AI提炼出的待澄清问题可以保存为工作项或Wiki页面，澄清讨论与结论随记录留存，需求条目的修改也在同一项目上下文中完成。至于冲突记录是否需要专用对象、状态字段如何配置，需结合团队实际流程在ONES中自行设计，具体版本与套餐信息建议向官方确认。
