AI需求分析结果要进入基线，需要先明确两件事：谁对内容负责、谁对基线负责。本文给出一套可执行的分工与机制——整理人自检、领域复核人确认、需求负责人批准的三级复核，以及以四个前置条件为准的冻结时点，并附变更记录字段和检查清单，帮助团队把AI输出稳妥地接入需求基线。
要点总览（TL;DR）
- AI需求分析结果进入基线前，建议设置整理人自检、领域复核人确认、需求负责人批准的三级复核；批准权与整理执行保持分离。
- 冻结时点以四个条件同时满足为准：澄清问题关闭或有明确结论、复核意见处理完毕并留痕、影响范围已评估并知会相关方、版本与范围描述一致。
- 冻结后任何修改都要记录变更内容、修改依据、影响范围、提出人、批准人和生效版本，并区分AI生成内容与人工修改。
- 流程可按五步推进：整理与标注来源、组织评审与澄清、意见处理与二次确认、变更影响评估、宣布冻结并归档。
- 基线确认完成后用检查清单逐项核对角色履职、来源标注、问题关闭、意见留痕、冻结证据和版本记录。
复核与冻结的核心分工：三个角色各管什么
AI需求分析结果在进入基线前，建议设置三级复核：整理人自检、领域复核人确认、需求负责人批准。三个角色分别承担内容质量、领域准确性和基线决策的责任，职责边界清晰，避免出现“AI生成的内容没人真正负责”的情况。
整理人是AI输出的第一责任人。其职责包括：整理AI生成的需求条目，标注每条内容的来源（如会议记录、用户反馈、原始需求文档），剔除明显偏离主题或重复的内容，并把不确定的表述转成待澄清问题。整理人对“内容是否被正确整理和标注”负责，不对业务判断的最终正确性负责。
领域复核人通常是业务方、产品负责人或熟悉该业务领域的资深成员。其职责是确认需求描述是否符合业务实际、术语是否准确、边界条件是否完整，并对整理人提交的待澄清问题给出结论。领域复核人对“内容在业务上是否成立”负责。
需求负责人对基线本身负责。其职责是确认复核意见已处理完毕、澄清问题已关闭或有明确结论、变更影响已评估，然后批准冻结并记录版本。需求负责人拥有冻结的决定权，也承担冻结后基线变更的批准责任。
关于冻结时点，判断依据是条件而非会议时间：澄清问题关闭、复核意见处理完毕、影响范围已评估并知会相关方、版本与范围描述一致，四项同时满足即可冻结。具体条件在第三节展开。
| 角色 | 复核内容 | 输出 | 批准权限 |
|---|---|---|---|
| 整理人 | 内容完整性、来源标注、表述清晰度、待澄清问题整理 | 整理后的需求条目、来源标注、待澄清问题清单 | 无基线批准权；对整理质量负责 |
| 领域复核人 | 业务准确性、术语一致性、边界条件、澄清问题结论 | 复核意见、澄清结论、确认或退回意见 | 对领域内容确认；无冻结权 |
| 需求负责人 | 复核意见处理情况、冻结条件满足情况、变更影响 | 冻结决定、基线版本记录、变更批准 | 批准冻结与冻结后变更 |
团队规模较小时，领域复核人与需求负责人可由同一人兼任，但整理人与批准人应保持分离，确保自检与批准不是同一个动作。
从AI输出到基线：五步操作流程
把AI需求分析结果接入基线，可以按五个步骤推进。每一步都有明确的输入、动作、输出和完成标志，便于团队对照执行，也便于在评审会上判断当前进行到哪一步。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 整理与标注来源 | AI生成的需求分析结果、原始素材（会议记录、反馈、文档） | 合并重复条目、拆分过粗条目、为每条需求标注来源和AI生成标记 | 结构化需求条目清单 | 每条需求都有来源标注，无孤立条目 | 整理人 |
| 2. 组织评审与澄清 | 结构化需求条目清单 | 召开评审会或异步评审，领域复核人逐条确认，形成待澄清问题清单 | 评审意见、待澄清问题清单 | 所有条目已过评审，问题清单有责任人和期限 | 领域复核人 |
| 3. 意见处理与二次确认 | 评审意见、待澄清问题清单 | 逐条处理意见，补充或修改需求，关闭问题；领域复核人对修改结果二次确认 | 修订后的需求条目、问题关闭记录 | 问题清单全部关闭或有明确结论，复核人确认 | 整理人、领域复核人 |
| 4. 变更影响评估 | 修订后的需求条目、现有基线或相关计划 | 评估本次需求对范围、进度、关联模块的影响，知会相关方 | 影响评估说明、知会记录 | 影响范围已写明，相关方已知会 | 需求负责人 |
| 5. 宣布冻结并归档 | 满足冻结条件的需求条目、影响评估说明 | 需求负责人确认条件满足，宣布冻结，记录版本号与冻结时间，归档 | 基线版本记录、归档材料 | 版本记录可查，冻结通知已发出 | 需求负责人 |
在流程承载上，如果团队使用ONES，可以把整理后的需求条目放入ONES Project作为工作项管理，评审意见和澄清结论记录在对应工作项或ONES Wiki页面中，冻结时以版本或状态标记基线，后续变更在同一工作项上留痕。ONES Assistant可基于项目数据与团队知识辅助提炼待澄清问题和拆解建议，其输出过程可追踪、结果可审计，便于整理人核对来源。具体字段配置和状态流转需按团队实际部署确认。
冻结时点怎么定：四个前置条件
冻结时点建议以条件满足为准，不以评审会结束时间或某个固定日期为准。以下四个条件同时满足，才具备冻结资格；任一条件未满足，应继续处理而不是先冻结再补。
| 前置条件 | 判定规则 | 证据 |
|---|---|---|
| 澄清问题全部关闭或有明确结论 | 问题清单中无“待定”“待确认”状态；暂不处理的问题需写明结论和后续处理安排 | 问题清单关闭记录 |
| 复核意见处理完毕并留痕 | 每条评审意见有处理结果（采纳、修改、不采纳并说明理由），处理人可查 | 评审意见处理记录 |
| 影响范围已评估、相关方已知会 | 影响评估说明覆盖范围、进度、关联模块；相关方有知会记录 | 影响评估说明、知会记录 |
| 版本与范围描述一致 | 基线版本号、需求条目数量、范围描述三者对应，无遗漏或多余条目 | 版本记录与条目清单核对结果 |
四个条件中，前两项保证内容质量，第三项保证决策信息完整，第四项保证基线本身可识别。实际执行中，第四项最容易被忽略：条目增删后版本描述未同步更新，导致后续追溯时对不上。建议在冻结前由整理人做一次条目清单与版本描述的逐项核对。
修改依据怎么记：变更记录的最小字段
冻结后的任何修改都要走变更记录，写清修改依据、影响范围和批准人。记录的目的不是增加流程负担，而是让每条改动在事后都能回答“为什么改、谁批准的、影响了什么”。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 变更内容 | 写明修改的具体条目和修改前后内容 | 需求R-012的验收条件由“响应时间小于2秒”改为“小于1秒” |
| 修改依据 | 写明触发修改的来源，如客户反馈、测试发现、业务规则调整 | 依据2024年3月客户验收反馈第5条 |
| 影响范围 | 列出受影响的关联需求、模块、计划或测试用例 | 影响R-015联调计划与TC-033测试用例 |
| 提出人 | 填写发起变更的人员 | 产品经理张某 |
| 批准人 | 填写有权批准该变更的需求负责人 | 需求负责人李某 |
| 生效版本与时间 | 写明变更进入哪个基线版本、何时生效 | 基线V1.1，2024年3月20日生效 |
| 内容来源标注 | 区分AI生成内容与人工修改内容，标明人工修改的部分 | 原条目由AI整理，验收条件为人工修改 |
AI生成内容与人工修改的区分标注值得单独强调。AI整理的需求条目在冻结后发生修改时，记录中应说明修改针对的是AI原始表述还是人工已调整的表述，这样在追溯责任和依据时不会混淆。记录建议存放在与需求条目关联的位置，例如工作项的变更历史或Wiki的版本记录中，确保查阅时能从需求条目直接找到对应变更。
示例：一次需求基线确认的完整走查
以下为演示情景，用于说明方法如何落地，不代表真实项目数据。
某团队用AI助手整理了一次用户反馈会议的需求分析结果，生成12条需求条目。整理人小王逐条标注来源，发现其中3条表述重复，合并为1条，最终形成10条需求，并标记每条为AI生成。整理人将2条含义模糊的条目转为待澄清问题，提交领域复核人。
领域复核人老陈在评审中确认了7条需求，对1条提出术语不准确的意见，对2条待澄清问题给出结论：一条确认为本期范围，一条移出本期并记录原因。整理人据此修改术语、更新条目，老陈二次确认通过。需求负责人李某评估影响：本期范围未变，但移出的1条影响后续排期，知会了项目经理。四个冻结条件满足后，李某宣布冻结，记录基线版本V1.0及冻结时间。
两周后，客户提出验收条件调整，涉及条目R-005。团队提交变更记录：变更内容为验收条件调整，修改依据为客户反馈第3条，影响范围为R-005关联的2个测试用例，提出人为产品经理，批准人为李某，生效版本V1.1。记录中同时注明该条目原为AI整理、本次为人工修改。变更批准后更新基线版本，测试用例同步调整。
完成检查：基线确认是否做到位
基线确认结束后，可用以下清单逐项核对。每项都应有对应证据，避免只凭口头确认。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 角色到位 | 整理人、领域复核人、需求负责人均已履职，批准人与整理人分离 | 评审记录、确认记录 | 需求负责人 |
| 来源标注完整 | 每条需求有来源标注，AI生成内容有标记 | 需求条目清单 | 整理人 |
| 澄清问题关闭 | 问题清单无待定项，暂不处理项有结论 | 问题关闭记录 | 领域复核人 |
| 复核意见留痕 | 每条意见有处理结果和理由 | 评审意见处理记录 | 整理人 |
| 冻结条件满足 | 四个前置条件均有对应证据 | 冻结准入检查记录 | 需求负责人 |
| 版本记录可查 | 版本号、冻结时间、范围描述一致且可查阅 | 基线版本记录 | 需求负责人 |
| 变更记录完整 | 冻结后每条变更含必填字段，AI与人工修改可区分 | 变更记录 | 需求负责人 |
常见遗漏项包括：冻结后修改只改内容不补记录；澄清问题以“会后再议”关闭但无结论；版本号更新了但范围描述未同步；AI生成标记在多次修改后丢失。核对时重点检查这几处，基本可以判断本次基线确认是否合格。
常见问题
团队规模小，三级复核可以合并吗？
可以合并，但建议保留一条底线：整理人与批准人分离。领域复核人与需求负责人由同一人兼任，在业务单一、风险较低的项目中通常可行；当需求涉及多个业务域或对外交付承诺时，建议由不同角色分别确认领域准确性和基线决策，避免同一人既判断内容成立又决定冻结。
评审会上问题无法当场关闭，还能按计划冻结吗？
不建议先冻结再补。未关闭的问题应写明结论和后续处理安排，例如移出本期范围并记录原因，或明确责任人和解决期限后再判断是否属于本期基线。若问题影响范围或验收条件，应先完成影响评估，再决定冻结时点。冻结以条件满足为准，会议日期可以调整。
冻结后发现AI整理的需求条目有误，修改记录要特别注明什么？
除常规的变更内容、修改依据、影响范围、提出人和批准人外，应注明该条目原为AI生成、本次修改针对的是AI原始表述还是人工已调整的表述。这样在追溯时能区分错误来源，也便于后续评估AI输出质量。记录应存放在与需求条目关联的位置，从条目可直接查到对应变更。
澄清问题以“会后再议”关闭，算不算满足冻结条件？
不算。“会后再议”属于待定状态，冻结条件要求问题关闭或有明确结论。可以采用的写法是：明确该问题移出本期基线并记录原因，或给出结论和后续处理安排，指定责任人与时间。问题清单中不应保留无结论的待定项。
用ONES承载这套流程时，评审意见和变更记录放在哪里比较合适？
常见做法是把整理后的需求条目放入ONES Project作为工作项管理，评审意见和澄清结论记录在对应工作项或ONES Wiki页面中，冻结时以版本或状态标记基线，后续变更在同一工作项上留痕。ONES Assistant可基于项目数据与团队知识辅助提炼待澄清问题和拆解建议，其输出过程可追踪、结果可审计，便于整理人核对来源。具体字段配置和状态流转需按团队实际部署确认。
