AI需求分析的人工复核，依据要能回答三件事：AI的结论从哪来、结论是否站得住、改动是否可追溯。可落地的依据分四类：原始输入、AI输出的过程信息、判断标准、复核记录。复核时逐条对照原文核对事实，标注假设，按准则判定通过或退回，并把修改理由留痕。复核记录与状态流转可以放在ONES这类协作平台中承载，让依据跟着需求条目走。
要点总览（TL;DR）
- AI需求分析的人工复核需要四类依据：原始输入、AI输出的过程信息、判断标准、复核记录，分别回答“AI看到什么”“为什么这样判断”“凭什么算合格”“谁改了什么”。
- 复核按五步执行：锁定原始输入、核对引用与原文一致性、标注假设与不确定项、按需求质量准则逐条判定、记录修改理由与结论，每步都有明确的完成标志。
- 复核责任要落到角色：需求提出方确认业务事实与验收口径，需求分析人员整理输入并初筛AI输出，复核人签署判定，评审环节查验复核记录。
- 复核能否关闭用检查表判定，无出处结论、未确认假设、无复核记录属于阻断项，复核保持开启。
- 复核记录应挂接到需求条目并随状态流转留存，ONES 可承载复核记录、假设跟踪与评审准入，具体配置结合团队实际部署确定。
复核依据分四类：从原文到留痕
复核不是把AI输出再读一遍，而是用一组可查证的依据去检验它。四类依据分别回答不同问题：原始输入回答“AI看到的是什么”，过程信息回答“AI为什么这样判断”，判断标准回答“凭什么算合格”，复核记录回答“谁改了什么、为什么改”。四类齐备，复核结论才有支撑；缺任何一类，复核都容易退化成个人印象。
| 依据类别 | 回答的复核问题 | 提供方 | 留存形式 |
|---|---|---|---|
| 原始输入 | AI依据的材料是否完整、准确、为最新版本 | 需求提出方、需求分析人员 | 需求来源记录、访谈纪要、工单原文、上下文附件，与需求条目关联保存 |
| AI输出过程信息 | 结论引用了哪段原文，哪些是假设或推测，拆分合并的理由是什么 | AI使用人整理，AI输出提供 | 引用片段对照、假设与不确定项清单、拆分合并说明 |
| 判断标准 | 这条需求是否达到可进入下一环节的质量要求 | 产品负责人、业务方、质量或测试角色 | 需求质量准则、业务规则、验收口径，作为团队约定文档固定下来 |
| 复核记录 | 谁复核、改了什么、为什么改、最终结论如何 | 复核人 | 复核意见、修改前后对照、修改理由、结论与时间，回写需求条目 |
四类依据中，原始输入和判断标准应在复核开始前就准备好；过程信息随AI输出一并取得；复核记录在复核过程中产生。把顺序理清，可以避免复核人一边找材料一边下判断。
复核操作步骤：从拿到AI输出到给出结论
下面五步按依赖关系排列，前一步的输出是后一步的输入。每步都给出完成标志，便于判断是否可以进入下一步。
步骤一：收集并锁定原始输入
输入：需求来源、访谈记录、工单原文、相关上下文材料。动作：确认AI实际读取的材料范围，核对版本与时间，剔除过期或重复材料，把最终采用的输入清单固定下来。输出：一份锁定的输入清单。完成标志：清单中的每份材料都能对应到具体来源，且与AI输出所依据的材料一致。
步骤二：核对引用是否与原文一致
输入：AI输出及其引用的原文片段。动作：逐条比对引用内容与原文，确认语义未被截断或改写；对没有出处的结论单独列出，标记为待核实。输出：引用一致项清单与无出处结论清单。完成标志：每条关键结论都能指向原文位置，或已被明确标为无出处。
步骤三：识别并标注假设与不确定表述
输入：AI输出全文。动作：找出“通常”“一般”“建议”等推测性表述，以及AI自行补充的业务前提，逐条写成显式假设，注明需要谁确认。输出：假设与待确认项清单。完成标志：清单中每一项都有确认人和确认状态，未确认项不会被当作既定事实使用。
步骤四：按需求质量准则逐条判定
输入：核对后的结论、假设清单、需求质量准则与验收口径。动作：对每条需求内容判定通过、修改或退回；修改项写明改法，退回项写明缺失的依据。输出：逐条判定结果。完成标志：每条需求都有明确判定，没有“待定”悬空项。
步骤五：记录修改理由与复核结论
输入：判定结果与修改内容。动作：填写复核人、修改前后对照、修改理由、最终结论，回写到对应需求条目。输出：完整的复核记录。完成标志：他人仅凭该记录即可还原复核过程，无需再询问复核人。
角色分工与各自交付物
复核责任悬空，通常是因为没人对某类依据负责。按角色划分依据归属，并在固定节点交接，可以让每条依据都有明确出处。
| 角色 | 负责的依据 | 交付物 | 交接节点 |
|---|---|---|---|
| 需求提出方 | 业务事实、验收口径 | 需求来源说明、验收标准确认 | 复核开始前提供；假设确认时再次参与 |
| AI使用人（需求分析人员） | 原始输入整理、AI输出初筛 | 锁定输入清单、引用对照表、疑点标注 | 提交复核时一并移交 |
| 复核人（业务或产品负责人） | 判断标准应用、最终结论 | 逐条判定结果、复核意见与签署 | 复核完成时签署，退回项返回使用人 |
| 评审或变更环节 | 复核记录的接收与使用 | 评审结论、变更记录 | 需求进入开发前查验复核记录 |
一个常见问题是需求提出方只在开头出现一次，导致假设无人确认。把“假设确认”设为提出方的第二个交接点，可以避免推测性内容流入下游。
示例：一条需求的复核记录怎么写
以下为演示情景，用于说明记录写法，不代表真实项目数据。
原始输入：客服工单原文一份，记录用户反馈“导出报表时字段顺序与页面显示不一致”；产品访谈纪要一份，提到导出功能面向财务对账场景。AI输出摘要：将需求归纳为“导出字段顺序可配置”，并建议增加模板保存能力。
| 核对项 | 核对结果 | 处理 |
|---|---|---|
| “字段顺序不一致”结论 | 与工单原文一致 | 保留，标注引用位置 |
| “面向财务对账场景” | 访谈纪要中有提及，但未说明是否仅限该场景 | 标为假设，需产品负责人确认适用范围 |
| “模板保存能力” | 原文与纪要均未提及，属AI补充建议 | 标为无出处建议，移出本次需求范围，另立待评估项 |
| 验收口径 | 原始输入中缺失 | 退回补充，由需求提出方给出字段顺序的验收标准 |
复核记录填写示例：复核人——产品负责人；修改内容——删除模板保存能力，将场景描述改为“财务对账等场景，具体范围待确认”；修改理由——原文无模板需求，场景范围缺少明确依据；结论——修改后通过，验收口径补充完成前不进入开发。
可迁移的写法规律有三条：结论必须能指回原文位置；AI补充的内容单独隔离，不混入需求正文；缺失项写清由谁补、补什么，而不是笼统写“待完善”。
复核完成检查：什么算复核到位
复核能否关闭，用一张检查表判定。任一项不满足，复核保持开启状态。
| 检查项 | 通过标准 | 阻断条件 |
|---|---|---|
| 事实核对 | 关键结论均有原文出处，引用与原文语义一致 | 存在无出处的关键结论 |
| 假设处理 | 假设与不确定项已显式标注，并有确认人及确认结果 | 存在未确认却被当作事实使用的假设 |
| 标准判定 | 已按需求质量准则与验收口径逐条判定 | 存在未判定的需求条目 |
| 留痕完整 | 复核人、修改内容、修改理由、结论齐全且可追溯 | 缺少复核记录或修改理由 |
这四项中，假设处理和留痕最容易被跳过。建议把“无出处结论、未确认假设、无复核记录”直接列为不得关闭的阻断项，在评审入口处校验。
把复核依据沉淀进协作流程
单次复核做得好，不等于团队能持续做到。四类依据需要跟着需求条目走，而不是散落在聊天记录和个人文档里，否则下一次复核又要从头找材料。
具体做法有四条。第一，复核记录挂接到需求条目本身，作为条目的一部分保存，评审时直接打开条目即可查看。第二，假设与待确认项作为独立字段或独立工作项跟踪，指定确认人和状态，避免混在正文里被忽略。第三，退回与修改形成状态流转，需求从“待复核”到“已复核”再到“可开发”，每次流转留下操作人和时间。第四，把复核结论作为需求进入开发的准入条件，没有复核记录的需求不进入排期。
ONES 可以在这一层提供承载：ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把结果保存为工作项、Wiki 页面等内容，便于把AI输出与需求条目放在同一处；其输出过程可追踪、结果可审计，配合权限体系使用。围绕需求澄清场景，ONES Assistant 可提炼要点、待澄清问题与拆解建议，这些内容正好对应复核中的假设与待确认项。团队可以把复核记录、假设清单和状态流转配置在需求条目与评审流程中，让每次复核的依据都能被下一位参与者直接查阅。具体的字段与流转配置方式，需结合团队实际部署确定。
常见问题
AI输出里没有标注出处的结论，复核时应该怎么处理？
把无出处结论单独列出，标记为待核实，不要直接当作事实使用。处理方式有两种：能回到原始输入中找到支撑的，补上引用位置后保留；找不到支撑的，要么删除，要么改写为显式假设并指定确认人。若该结论对需求范围有实质影响，应作为阻断项，在补齐依据前不关闭复核。
需求提出方只在复核开始时参与一次，够不够？
通常不够。复核过程中AI补充的业务前提往往需要提出方确认，如果提出方只在开头出现，这些假设容易无人认领而流入下游。建议设置两个交接点：复核开始前提供需求来源与验收口径；假设确认阶段再次参与，逐条确认或否定AI补充的前提。确认结果写入假设清单，作为复核记录的一部分。
复核记录应该写多细，才既可用又不至于变成负担？
判断标准是他人仅凭记录就能还原复核过程，无需再询问复核人。至少要包含复核人、修改前后对照、修改理由和最终结论四项。修改理由写清依据来源，例如“原文未提及，属AI补充建议”，而不是笼统写“待完善”。记录挂在需求条目上，随条目一起流转，避免另建文档造成两处维护。
团队刚开始做AI需求分析复核，应该先补齐哪类依据？
优先补齐判断标准与原始输入。判断标准缺失时，复核只能凭个人经验，结论难以对齐；原始输入不完整时，引用核对无从做起。这两类准备好之后，再要求AI输出附带引用片段与假设说明，最后建立复核记录模板。分阶段推进比一次性要求四类齐备更容易落地。
复核依据如何长期留存，避免下次复核重新找材料？
把依据跟着需求条目走：复核记录作为条目的一部分保存，假设与待确认项用独立字段或独立工作项跟踪并指定确认人，退回与修改形成状态流转并留下操作人和时间。评审时直接打开条目查看依据，复核结论作为进入开发的准入条件。ONES 可将AI输出结果保存为工作项、Wiki 页面等内容，其输出过程可追踪、结果可审计，便于把复核依据与需求条目放在同一处；具体字段与流转配置需结合团队实际部署确定。
