AI需求分析结果进入基线前，团队最容易混淆的是“谁看过”和“谁确认过”。合理的做法是把复核与冻结拆成两个动作：需求负责人牵头复核，业务代表确认业务口径，技术负责人确认可实现性，测试负责人确认可验证性；复核意见全部关闭、澄清问题有结论、变更影响已评估后，由需求负责人在评审节点宣布冻结并记录基线版本。AI输出始终作为待核对草稿，修改依据沿“AI原始输出—人工修改记录—复核意见—冻结版本”留痕。
要点总览（TL;DR）
- AI需求分析结果在进入基线前应定位为待核对草稿：需求负责人牵头复核，业务代表确认业务口径、技术负责人确认可实现性、测试负责人确认可验证性，三类确认不能缺位。
- 冻结时点设在评审节点而非固定日期：复核意见全部关闭、澄清问题有结论、变更影响已评估、相关方已知会后，由需求负责人宣布冻结并记录基线版本号。
- 修改依据沿“AI原始输出—人工修改记录—复核意见—冻结版本”留痕，每条改动写清改了什么、为什么改、依据来源、谁确认、何时确认。
- 冻结后仍可变更，但需走变更流程并关联原基线版本；AI再次生成的结果应标为草稿版本，与已冻结基线分开存放。
- 用角色、时点、留痕、一致性四个维度做完成检查，任何一项不满足都应补记或推迟发布。
复核与冻结的分工：谁签字、谁拍板
AI生成的需求描述、拆解建议和待澄清问题，适合作为讨论起点。它帮助团队更快暴露歧义，但其中的业务假设、边界条件和验收口径仍需人工逐条确认。把AI输出定位为“待核对草稿”，意味着任何条目在获得明确确认之前，都不能进入基线。
复核不是一次集体浏览，而是按职责分别签字。需求负责人组织复核、汇总意见并对最终条目负责；业务代表对业务口径负责，确认场景、规则和优先级是否符合真实业务；技术负责人对可实现性负责，判断依赖、约束和技术风险；测试负责人对可验证性负责，确认每条需求都有可观察的验收条件。产品/项目决策者在跨团队冲突无法在复核层解决时拍板，并确认冻结对排期和交付的影响。
| 角色 | 核心职责 | 签字/确认权限 | 只有建议权的情形 |
|---|---|---|---|
| 需求负责人 | 组织复核、汇总意见、维护条目版本、宣布冻结 | 对条目完整性和复核结论签字；有权宣布冻结 | 业务口径由业务代表确认，需求负责人不替代业务签字 |
| 业务代表 | 确认业务场景、规则、优先级和边界 | 对业务口径签字 | 对技术方案和测试设计提出建议，不代替技术、测试签字 |
| 技术负责人 | 评估依赖、约束、技术风险与实现路径 | 对可实现性签字 | 对业务优先级提出建议，最终由业务代表和决策者确认 |
| 测试负责人 | 检查验收条件是否可观察、可判定 | 对可验证性签字 | 对需求取舍提出建议，不单独决定需求是否保留 |
| 产品/项目决策者 | 裁决跨角色冲突，确认冻结对交付的影响 | 对冲突裁决和冻结时机拍板 | 日常条目复核由上述角色完成，决策者不逐条替代签字 |
小团队常出现一人兼多角的情况。角色可以合并，但三类确认不能缺位：业务口径、可实现性、可验证性都要有明确的人给出结论。例如同一人既做需求负责人又做测试负责人时，仍应分别记录“业务口径确认”和“可验证性确认”两条意见，避免一种视角覆盖另一种视角。冻结宣布权应落在需求负责人或项目决策者身上，其他复核人提供意见，不自行宣布基线成立。
从AI输出到冻结：四个阶段的操作步骤
把AI结果接入评审流程，关键是让每个阶段都有明确输入、动作、输出和完成标志。下面四个阶段可以直接作为团队的操作骨架。
| 阶段 | 输入 | 动作 | 输出 | 完成标志与卡点 |
|---|---|---|---|---|
| 一、AI结果初筛与标注 | AI生成的需求描述、拆解建议、待澄清问题 | 需求负责人逐条标注“可信”“待确认”“存疑”，标出涉及业务规则、外部依赖和验收口径的位置 | 待核对清单，含标注结果和初筛人 | 每条AI输出都有标注结论；存在未标注条目则不能进入澄清 |
| 二、澄清与补充 | 待确认项和存疑项 | 向业务代表、技术负责人提出具体问题，回填答案，必要时补充场景和边界 | 澄清结论，逐条对应原问题 | 每个待确认项都有结论或明确转为待决事项；悬空问题不能进入正式复核 |
| 三、正式复核 | 澄清后的需求条目 | 业务、技术、测试按职责评审，记录意见、责任人和关闭状态 | 复核意见清单与关闭状态 | 意见全部关闭或明确延期处理；存在未关闭的关键意见则冻结推迟 |
| 四、冻结与发布 | 意见已关闭的版本 | 需求负责人宣布冻结，记录基线版本号，归档评审记录和修改依据 | 基线版本号与冻结记录 | 版本号、冻结时间、宣布人、参与复核人齐全；缺项则补记后再发布 |
初筛阶段要克制“看起来合理就通过”的倾向。AI输出中常见的模糊表述，例如“系统应快速响应”“支持多种格式”，需要标注为待确认，而不是直接改写后放行。澄清阶段的问题应尽量指向可回答的事实：谁在什么场景下使用、输入输出是什么、异常情况如何处理。正式复核阶段记录意见时，写明提出人、对应条目和关闭依据，避免只写“已沟通”。
在复核意见流转和冻结版本记录环节，团队可以把需求条目、评审意见和版本标记放在同一套研发管理工具中承载。ONES 支持基于权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 可围绕PRD质量检查和需求智能生成提炼待澄清问题与拆解建议，帮助团队更快完成需求澄清和录入。将这些结果接入需求条目和评审记录后，复核意见的关闭状态与冻结版本能够对应到具体条目，减少线下表格与线上记录脱节。
冻结时点怎么定：进入基线的判断条件
冻结时点不宜定为某个固定日期，而应设为评审节点上的一组准入条件。条件满足即可冻结，条件不满足则推迟，这样基线才有可解释的依据。
- 复核意见全部关闭，或有明确结论的延期处理记录；
- 澄清阶段提出的问题均有结论，未决冲突已由决策者裁决；
- 需求变更的影响范围已评估，包括对排期、依赖团队和已冻结条目的影响；
- 相关方已知会，业务、技术、测试确认自己负责的部分无异议；
- 条目具备可验证的验收条件，测试负责人已确认。
以下情况应推迟冻结：关键复核角色缺席且未授权他人确认；业务口径存在未决冲突；外部依赖或上游接口尚未确认；验收条件仍无法判定。推迟不是流程失败，而是把风险留在评审阶段解决，避免冻结后反复返工。
冻结与迭代节奏的关系体现在“在评审节点冻结”。团队可以在迭代规划前的需求评审会上完成冻结，使基线版本与排期对齐；日常随时宣布冻结会让变更记录失去节奏，也让相关方难以判断哪个版本有效。冻结之后仍可变更，但需走变更流程：提出变更原因、评估影响、重新确认相关角色，并记录新版本与旧基线的关系。变更记录应指向原基线版本，便于追溯。
修改依据怎么记：留痕字段与记录方式
留痕的目标是让后来的人能回答三个问题：原来AI怎么写的、人改成了什么、为什么改。只记录最终结论，无法支撑复核和审计。
| 字段 | 填写内容 | 示例 |
|---|---|---|
| AI原始表述 | 保留AI输出的原文或原文位置 | “系统应支持订单导出，格式包括Excel和PDF” |
| 修改后内容 | 人工确认后的需求描述 | “系统支持按当前筛选条件导出订单为Excel；PDF导出列入后续版本评估” |
| 修改原因 | 业务规则、技术约束或验收要求 | “业务方确认首期只需Excel；PDF涉及版式模板，技术评估后延后” |
| 依据来源 | 澄清记录、评审意见或业务文档 | “2025-03-12澄清会结论；技术负责人评估意见” |
| 确认人 | 对该修改签字确认的角色 | 业务代表、技术负责人 |
| 确认时间 | 确认发生的日期 | “2025-03-13” |
记录载体可以分工：需求条目版本保存修改前后对照和确认人；评审记录保存意见、提出人和关闭状态；变更单保存冻结后的变更原因与影响评估。三者通过条目编号和基线版本号关联，避免各记各的。
常见缺口是只写“已与业务确认”而不写确认了什么。改进方式是把修改原因写成可核对的事实，例如“首期范围仅含Excel，依据业务方3月12日澄清结论”。AI再次生成或重新分析时，结果应标注为新的草稿版本，与已冻结基线分开存放，不覆盖原条目；若新结果触发修改，按变更流程处理并关联原基线。
示例：一次需求条目的复核到冻结全过程
以下为演示情景，用于说明流程如何跑通。
AI根据一份用户反馈材料生成需求条目：“系统应提供订单批量导出功能，支持Excel和PDF，导出速度要快。”需求负责人初筛时标注：“Excel/PDF范围待确认；‘速度要快’缺少可验证口径；批量上限未说明。”该条目进入待核对清单。
澄清阶段，业务代表回复：首期只需要按筛选条件导出Excel，单次上限一万条；PDF导出用于对账场景，可列入后续版本。技术负责人补充：一万条以内可同步导出，超过需异步任务。测试负责人提出验收条件应写明导出字段、筛选条件和完成提示。需求负责人将这些结论回填到条目，形成修改后描述。
正式复核时，业务代表确认业务口径，技术负责人确认同步导出的实现方式，测试负责人确认验收条件可判定。评审记录中三条意见均标记关闭，提出人和关闭依据可查。需求负责人在迭代规划前的需求评审会上宣布冻结，记录基线版本号V1.2，并归档AI原始表述、修改对照、澄清结论和评审记录。
这个例子中，冻结发生在意见关闭之后的评审节点，修改依据沿条目版本和评审记录留存。若后续业务提出增加PDF导出，则走变更流程，评估对排期和测试范围的影响，形成新版本并关联V1.2。
完成检查：基线确认是否做到位
基线确认完成后，可用下面这组检查项逐条核对。任何一项不满足，都应补记或推迟发布。
| 检查维度 | 核对项 | 常见缺口与补救 |
|---|---|---|
| 角色 | 业务口径、可实现性、可验证性是否均有明确确认人；冻结宣布人是否明确 | 缺测试确认：补做验收条件评审并记录；宣布人不明：由需求负责人或项目决策者明确并在冻结记录中写明 |
| 时点 | 复核意见是否全部关闭；澄清问题是否有结论；影响是否已评估；相关方是否已知会 | 存在悬空意见：转为待决事项并推迟冻结，不开“口头通过”的口子 |
| 留痕 | 每条修改是否有修改前后对照、原因、依据来源、确认人和时间 | 只记结论：补写原因和依据来源，关联澄清记录或评审意见 |
| 一致性 | 冻结版本号与评审记录、条目版本是否对应；AI草稿是否与基线分开 | 版本对不上：以评审记录为准重建版本关联；AI新结果覆盖基线：恢复原版本并将新结果标为草稿 |
检查的目的不是增加签字数量，而是让基线在后续变更、测试和交付中有据可查。团队可以把这张检查表放在每次需求评审会的最后一项，由需求负责人逐项确认后再宣布冻结。
常见问题
小团队里一人兼多个角色，复核签字怎么处理才不流于形式？
角色可以合并，但三类确认要分别留下结论：业务口径、可实现性、可验证性。同一个人既做需求负责人又做测试负责人时，仍应分别记录“业务口径确认”和“可验证性确认”两条意见，写明各自依据，避免一种视角覆盖另一种视角。冻结宣布权落在需求负责人或项目决策者身上，其他复核人提供意见，不自行宣布基线成立。
评审会上关键角色临时缺席，能不能先冻结后补签？
不建议先冻结后补签。关键复核角色缺席且未授权他人确认，属于应推迟冻结的情形。可行的处理是：由缺席角色提前书面授权一名代理人，代理人在评审会上给出明确结论并记录授权关系；或者将冻结推迟到该角色能参与的下一个评审节点。把风险留在评审阶段解决，比冻结后反复返工成本更低。
冻结之后业务方又提出调整，修改依据应该记在哪里？
冻结后的调整走变更流程，记录落在变更单上，并与原基线版本关联。变更单至少写明：变更原因、影响范围（排期、依赖团队、已冻结条目）、重新确认的角色与时间、新版本号与原基线版本号的关系。需求条目版本保存修改前后对照，评审记录保存意见与关闭状态，三者通过条目编号和基线版本号关联，避免各记各的。
AI重新分析同一批需求，新结果和已冻结版本怎么区分？
新结果标注为新的草稿版本，与已冻结基线分开存放，不覆盖原条目。若新结果中的内容触发修改，按变更流程处理，并在变更记录中关联原基线版本。这样既保留了AI原始输出，也能追溯每次人工确认的结论，后续复核时可以直接对比草稿与基线的差异。
复核意见记录到什么颗粒度才算可追溯？
每条意见至少包含：提出人、对应需求条目、意见内容、关闭依据、关闭时间。只写“已沟通”“已确认”无法支撑追溯。可核对的事实型写法更有效，例如“首期范围仅含Excel导出，依据业务方3月12日澄清结论”。意见未关闭时，应转为待决事项并推迟冻结，不开“口头通过”的口子。
