AI把自然语言需求整理成结构化条目后，人工复核的重点是核对拆分是否合理、语义是否失真、约束是否遗漏。比较稳妥的安排是三层角色依次复核：需求负责人先看条目拆分和字段完整性，业务提出方再确认语义与优先级，技术负责人最后判断可实现性与依赖。复核范围按风险分级，高优先级、跨系统、含合规或安全约束的条目全量复核，其余可抽样；AI标出的歧义和冲突要单独走澄清闭环，未澄清的条目不进入开发。
要点总览（TL;DR）
- 人工复核按三层角色依次进行：需求负责人核对条目拆分与字段完整性，业务提出方确认语义与优先级，技术负责人判断可实现性与依赖，前一层通过后再进入下一层。
- 复核前先约定结构化条目的字段与来源追踪规则，让每条需求都能在两步内找到原文段落和提出人，复核才有逐项核对的依据。
- 复核范围按风险分级：高优先级、跨系统、含合规或安全约束的条目全量复核，低优先级且描述清晰的条目可抽样，并保留定期复查机制。
- AI标出的歧义和冲突走单独澄清闭环，保留原文、标注问题、指定责任人、回写结论，未澄清的条目不进入开发。
- 复核结论统一为通过、退回补充、需澄清三种状态并留痕，复核中发现的问题回流为提示词或规则调整，再用小批量验证效果。
复核前先定好结构化条目和来源追踪
人工复核需要明确的对象。如果AI输出的只是几段改写后的文字，复核人只能凭印象判断对错；如果输出的是字段齐全、能回溯到原文的结构化条目，复核就可以逐项核对。因此在安排复核之前，先约定AI整理需求的输出规格。
一条结构化需求至少包含以下字段：
| 字段 | 填写要求 | 复核用途 |
|---|---|---|
| 需求标题 | 一句话概括需求目标，避免把实现方式写进标题 | 判断条目主题是否与原文一致 |
| 需求描述 | 说明谁在什么场景下需要什么能力，保留原文关键限定词 | 核对语义是否失真 |
| 验收要点 | 列出可观察的完成条件，区分必须满足与期望满足 | 核对是否遗漏原文中的约束 |
| 优先级 | 按团队既有口径填写，并注明依据 | 业务方确认优先级是否合理 |
| 来源原文位置 | 记录原文段落编号或章节位置，必要时附原文摘录 | 复核时可随时对照原文 |
| 提出人与提出时间 | 记录原始需求来源，便于澄清时找到对的人 | 歧义澄清时指定责任人 |
| AI改写说明 | 简要说明AI做了哪些归纳、合并或补全 | 识别AI推断过度的位置 |
| 歧义标记 | AI无法判断时保留原文表述，标注待澄清点 | 进入澄清流程，不直接通过 |
层级关系也要在整理阶段定好。常见做法是按“史诗—特性—用户故事”或“业务需求—子需求”挂接，子条目继承父条目的来源信息，同时保留自己的原文出处。层级不清会导致复核时无法判断某条需求是独立需求还是某条需求的拆解，优先级和验收要点也容易错位。
来源追踪规则建议写成一句话要求：每条结构化条目都能在两步之内找到原文段落和提出人。AI改写说明不需要长篇解释，但要写清合并了哪几段、补全了哪些原文没有明说的内容。歧义标记的原则是“保留原文、标注问题、不替原文做决定”，这样复核人看到标记就知道这里需要人来判断。
人工复核怎么分工：三层角色与各自检查项
复核如果交给一个人通读，容易出现两种问题：业务语义没人真正确认，技术约束到最后才暴露。按三层角色分工、逐层交接，可以让每层只关注自己最有判断力的部分。
| 顺序 | 角色 | 主要检查项 | 交接条件 |
|---|---|---|---|
| 第一层 | 需求负责人 | 条目拆分是否合理；字段是否完整；原文信息是否遗漏；层级挂接是否正确；来源追踪是否可回溯 | 条目结构完整、来源可查，转入业务确认 |
| 第二层 | 业务提出方 | 语义是否失真；优先级与业务目标是否一致；验收要点是否覆盖真实诉求；是否存在多方需求冲突 | 语义与优先级确认，转入技术评估 |
| 第三层 | 技术负责人 | 可实现性；系统依赖与改造范围；非功能约束（性能、安全、兼容性）是否被识别；是否存在技术前置条件 | 技术约束补充完成，给出最终复核结论 |
需求负责人是第一道关，重点在“条目是否成立”。拆分过粗会让一条需求包含多个目标，拆分过细会产生大量无法独立验收的碎片；这两种情况都在这一层调整。字段缺失、来源位置写错、AI改写说明含糊，也在这里退回补充。
业务提出方关注“意思对不对”。AI在归纳时可能把“希望支持批量导入”改写成“支持数据导入”，丢掉批量这个限定；也可能把某个部门的诉求合并成全员需求。业务方对照原文确认语义，同时确认优先级是否与当前业务目标一致。多方需求存在冲突时，在这一层标记出来，进入澄清流程。
技术负责人关注“能不能做、依赖什么”。这一层要识别跨系统依赖、数据迁移、权限模型变化、性能指标等非功能约束。技术评估的结论可以是可实现、需拆分、需前置改造，也可以是建议调整验收要点。三层顺序不宜颠倒：结构没定就做技术评估，容易在错误条目上讨论方案；技术约束没确认就通过，开发阶段会反复返工。
按风险安排复核范围：全量、抽样与重点项
需求量大时，全部逐条深度复核会拖慢节奏，完全依赖抽样又可能漏掉高风险条目。可行的做法是按风险分级：高风险条目全量复核，低风险条目抽样复核并定期复查。
必须全量复核的情形包括：高优先级需求；跨系统或跨团队的需求；含合规、安全、隐私约束的需求；涉及计费、权限、数据删除等敏感逻辑的需求；AI标注了歧义或置信度低的条目。这些条目一旦理解偏差，返工成本高，复核投入是值得的。
可以抽样复核的情形包括：低优先级、描述清晰、原文本身结构完整的条目；AI改写幅度小、来源段落单一的条目；同类需求已有通过先例的条目。抽样比例没有统一标准，可以从每批抽取一定比例起步，根据复核发现的问题率调整：问题率上升就提高比例，连续多批稳定后再降低。
抽样之外还要保留复查机制。被抽中的条目按完整三层流程复核，未被抽中的条目在进入开发前由需求负责人做一次快速通读，确认没有明显遗漏。复核记录要留痕，至少记录复核人、复核时间、结论和修改内容，便于后续回溯某条需求为什么被通过，也便于统计哪类条目问题最多。
歧义和冲突怎么处理：从标记到澄清闭环
AI整理结果中的歧义通常来自三个方向：原文本身表述模糊，例如“响应要快”没有给出指标；AI推断过度，把原文没有的条件补了进去；多方需求相互冲突，例如两个部门对同一功能的权限要求相反。三类问题的处置方式不同，但都需要走同一个闭环。
处置动作可以按以下顺序执行：
- 保留原文：不删除原始表述，结构化条目中同时保留原文摘录和AI整理版本。
- 标注问题：写清歧义点是什么、为什么无法判断，例如“原文未说明并发用户数，验收要点无法量化”。
- 指定澄清责任人：根据问题类型指定业务提出方、技术负责人或需求负责人，明确回复时限。
- 回写结论：澄清结果写回结构化条目的对应字段，同时更新来源追踪，记录澄清人、澄清时间和结论依据。
- 更新状态：条目状态从“待澄清”转为“已澄清待复核”或“退回补充”，再进入正常复核流程。
状态管理是闭环的关键。建议至少定义四种状态：待复核、待澄清、退回补充、复核通过。处于待澄清和退回补充的条目不计入开发就绪范围，避免带着歧义进入排期。多方冲突的条目可以拆成两条候选需求，分别标注来源方，由业务负责人裁决后再合并或取舍。
一个完整示例：从原始需求到复核通过
以下为演示情景，用于说明各环节如何衔接。
原始需求来自一次业务沟通记录：“财务同事导出报表太慢了，每个月结账前都要等很久，希望能快一点，最好能自己选时间段，另外导出格式要能直接给审计看。”
AI整理后的结构化条目示例：
- 需求标题：财务报表导出支持自定义时间范围并提升导出速度
- 需求描述：财务人员在月度结账场景下导出报表，当前等待时间较长；希望支持自行选择导出时间段，导出结果满足审计查看要求。
- 验收要点：支持按自定义起止时间导出；常用时间段导出在可接受时间内完成；导出格式满足审计使用。
- 优先级：高，依据为影响月度结账节奏。
- 来源原文位置：沟通记录第3段；提出人：财务接口人；提出时间：记录日期。
- AI改写说明：将“快一点”归纳为导出速度要求，将“给审计看”归纳为格式要求，未补充具体指标。
- 歧义标记：①“很久”未给出当前耗时和期望耗时；②“审计看”未说明具体格式或字段要求；③“自己选时间段”是否包含跨年度范围未说明。
三层复核过程：需求负责人确认条目拆分合理，但指出验收要点缺少可量化指标，保留歧义标记并转业务确认。业务提出方确认语义基本准确，补充说明当前导出约需数分钟、期望控制在可接受范围内，审计格式指固定模板的明细表，跨年度范围暂不需要；优先级维持高。技术负责人评估后指出导出速度受数据量和报表复杂度影响，建议验收要点改为分数据量档位描述，并补充一条依赖：需要确认报表服务当前查询性能。澄清结论回写后，条目状态更新为复核通过。
这个例子说明：AI负责把散落的口语整理成条目并标出不确定处，人工复核负责补指标、定范围、确认依赖。三层各自只改自己负责的部分，来源追踪让每次修改都能回到原文核对。
复核完成检查与质量回流
单条需求是否复核完成，可以用一张检查表逐项判断：
- 条目字段齐全，标题、描述、验收要点、优先级、来源位置均已填写；
- 来源可回溯，能在两步内找到原文段落和提出人；
- AI改写说明已阅读，改写处与原文语义一致；
- 歧义标记已全部处理，或已转为明确的待澄清状态并指定责任人；
- 业务方已确认语义和优先级；
- 技术负责人已确认可实现性、依赖和非功能约束；
- 复核结论已记录，状态为通过、退回补充或需澄清之一。
批次复核的完成标志可以定为：本批次所有高优先级、跨系统和含合规约束的条目均已完成三层复核；抽样条目完成复核且问题率在约定范围内；待澄清条目已全部指定责任人和回复时限。统计口径建议按条目数而非文档数计算，分别统计通过率、退回率和澄清率，便于比较不同批次和不同需求来源的整理质量。
复核中发现的问题要回流到AI整理环节。常见做法是把问题归类：字段缺失对应输出模板调整，语义失真对应提示词中补充“保留限定词、不做推断”的要求，歧义漏标对应增加“无法判断时保留原文并标注”的规则。调整后先在小批量需求上验证，再扩大使用范围。定期抽样复查可以按固定周期从已通过条目中抽取一部分重新核对，观察问题是否集中在某类需求或某个来源，以此判断规则调整是否有效。
在ONES中承载这套流程时，AI整理出的需求和任务可以进入项目工作项，来源原文、改写说明和澄清记录可以关联到对应的Wiki页面，复核结论以工作项状态和评审记录的形式留痕。ONES Assistant可基于项目、工作项和Wiki页面等上下文回答问题并执行后续操作，其输出过程可追踪、结果可审计，适合把复核所需的来源信息和状态变化放在同一处管理。具体到复核状态字段如何配置、评审流程如何设置，需要结合团队现有的项目模板确认。
常见问题
AI整理出的需求条目，复核时发现拆分过细或过粗，应该在哪一层调整？
拆分问题在需求负责人这一层处理，也就是第一层复核。拆分过粗通常表现为一条需求包含多个目标、验收要点无法逐条判断；拆分过细则表现为条目无法独立验收、彼此高度重复。需求负责人对照原文重新划分层级，把子条目挂接到正确的父条目下，并同步更新来源追踪。业务提出方和技术负责人不负责重新拆分，他们只在语义和技术约束上给出结论，避免同一问题在多层反复修改。
低优先级需求抽样复核后，还需要业务方确认语义吗？
需要区分抽样复核的范围。抽样复核减少的是复核深度和覆盖条数，语义确认这一步不能省略。可行的做法是：被抽中的低优先级条目走完整三层流程；未被抽中的条目由需求负责人做快速通读，确认没有明显遗漏，业务语义的确认可以合并到批次确认中，由业务提出方一次性确认该批次条目。如果某条低优先级需求在通读中被发现描述含糊或涉及多方，应升级为全量复核，不再按抽样处理。
歧义澄清迟迟没有回复，条目应该怎么管理？
建议在状态上明确区分“待澄清”和“退回补充”，并给澄清责任人设定回复时限。超时未回复的条目保持待澄清状态，不计入开发就绪范围，由需求负责人定期汇总超时条目，向业务负责人或项目负责人升级。另一种处理方式是把该条目拆出一个已明确的部分先行推进，未明确的部分单独保留待澄清状态，但拆分后的条目要各自保留来源追踪，避免澄清结论回写时找不到对应原文。
复核记录需要记到什么程度，才能支撑后续回溯和统计？
至少记录四项：复核人、复核时间、复核结论、修改内容。修改内容写清改了哪个字段、依据是什么，例如“验收要点补充并发用户数，依据业务方澄清回复”。统计口径按条目数计算，分别统计通过率、退回率和澄清率，并可按需求来源或条目类型分组，便于判断问题集中在哪类需求。记录粒度不必写到逐字讨论，但要保证隔一段时间后能回答“这条需求为什么被通过”这个问题。
复核结果回流调整AI整理规则后，怎么判断调整是否有效？
先在小批量需求上验证，观察同类问题是否减少，再扩大使用范围。验证时保持统计口径一致，比较调整前后的退回率和澄清率变化，并区分问题类型：字段缺失、语义失真、歧义漏标分别对应不同的规则调整，混在一起看会掩盖真实效果。定期抽样复查可以从已通过条目中抽取一部分重新核对，如果问题集中在某类需求或某个来源，说明规则还需要针对该类场景补充，而不是整体推倒重来。
