AI需求分析结果要进入评审，先要解决“每条结论从哪里来、由谁核对、当前是什么状态”的问题。本文给出一套可直接复制的五块表格模板：结果头信息、需求条目主表、来源追踪表、冲突与待澄清表、评审记录，并逐字段说明填写口径、区分必填与选填、用一条完整示例串起追溯链。模板适合把AI输出的需求要点整理成可评审、可追溯的交付物，字段可按团队流程增删；在评审组织与状态回写环节，也会说明ONES的需求条目与文档管理方式如何承载这些记录。
要点总览（TL;DR）
- 模板采用五块结构：结果头信息、需求条目主表、来源追踪表、冲突与待澄清表、评审记录，各表通过需求编号和来源编号关联。
- 主表至少包含需求编号、需求分类、需求摘要、约束条件、置信度、状态和来源编号；来源追踪表记录来源类型、来源位置、原文摘录、提取方式与核对人。
- 最小可用版本保留支撑评审判断和回查的字段，原始表述、原文摘录、提取方式等按需求类型和材料形态选填。
- 评审前先核对追溯链完整性，评审后把结论回写到主表状态字段，并递增版本号、登记变更要点。
- 模板按季度复核，新增字段需说明用途和填写责任人，来源类型字典保持少量稳定取值。
可复制空白模板：五块表格结构
模板采用五块结构，各表通过“需求编号”和“来源编号”关联。复制到文档或表格工具后，先填结果头信息，再逐条录入需求条目，最后补齐来源追踪与待澄清项。以下表格保留表头，正文留空供填写。
表1 结果头信息
| 字段 | 填写内容 |
|---|---|
| 分析批次编号 | |
| 分析对象 | |
| 输入材料范围 | |
| AI工具与使用方式 | |
| 分析日期 | |
| 整理人 | |
| 核对人 | |
| 模板版本 |
表2 需求条目主表
| 需求编号 | 需求分类 | 需求摘要 | 原始表述 | 约束条件 | 置信度 | 状态 | 来源编号 |
|---|---|---|---|---|---|---|---|
表3 来源追踪表
| 来源编号 | 关联需求编号 | 来源类型 | 来源位置 | 原文摘录 | 提取方式 | 核对人 | 核对结果 |
|---|---|---|---|---|---|---|---|
表4 冲突与待澄清表
| 问题编号 | 关联需求编号 | 问题类型 | 问题描述 | 涉及来源 | 澄清对象 | 期望回复时间 | 处理状态 |
|---|---|---|---|---|---|---|---|
表5 评审记录表
| 评审日期 | 评审范围 | 参与人 | 评审结论 | 需修改条目 | 状态回写结果 | 版本号 |
|---|---|---|---|---|---|---|
字段说明：每个字段填什么、怎么判断
字段说明解决“填得对不对”的问题。以下按表格顺序解释关键字段的填写口径，重点是需求分类、摘要、约束条件、置信度，以及来源追踪中容易混淆的几组字段。
需求分类与摘要
需求分类用于后续筛选和分工，建议使用团队已有的分类字典，例如功能类、体验类、数据类、合规类、集成类。分类只选一项主分类，跨类需求在摘要中说明次要属性，避免一条需求挂多个分类导致统计失真。摘要用一句话写清“谁在什么场景下需要什么结果”，控制在40字以内，保留可判断的对象和动作，不写“优化体验”这类无法验收的表述。
约束条件与置信度
约束条件记录需求成立的前提，包括时间窗口、依赖系统、合规要求、适用范围和明确排除项。填写时区分“材料中明确写出的约束”和“整理人推断的约束”，后者需在来源追踪中标注提取方式为推断。置信度建议采用高、中、低三档：高表示有原文直接支撑且核对人已确认；中表示有间接依据或需补充确认；低表示主要来自AI归纳、缺少原始材料支撑。置信度由填写人依据证据标注，并写明判定口径，避免直接采用AI自评分数。
来源类型与来源位置
来源类型用于区分材料性质，常用取值包括访谈记录、会议纪要、工单或反馈原文、业务文档、数据报表、竞品资料。来源位置要精确到可回查的粒度，例如“2025-03访谈记录第2段”“工单#12345”“PRD v1.2 第3.1节”，只写“来自用户反馈”无法支撑核对。同一需求有多条来源时，在来源追踪表中分行记录，主表来源编号填写多个编号。
原文摘录与提取方式的区别
原文摘录是从材料中直接复制的原话或原句，保留原始措辞，用于核对AI是否改写了含义；提取方式是说明这条结论如何得到，例如“原文直引”“同义归纳”“跨材料合并”“推断补充”。两者分开记录，评审时才能判断偏差来自材料本身还是整理过程。摘录过长时截取关键句，并用省略号标明删减位置。
| 字段 | 填写口径 | 常见错误 |
|---|---|---|
| 需求分类 | 从团队分类字典选一项主分类 | 一条需求挂多个分类 |
| 需求摘要 | 一句话写清对象、场景、期望结果 | 写成无法验收的口号 |
| 约束条件 | 写明前提、依赖、排除项，区分原文与推断 | 把假设当既定条件 |
| 置信度 | 按证据充分程度标高中低，写明口径 | 直接抄AI自评分数 |
| 来源位置 | 精确到段落、条目或文档章节 | 只写材料名称 |
| 原文摘录 | 保留原始措辞，删减处标注 | 用摘要替代摘录 |
| 提取方式 | 标注直引、归纳、合并或推断 | 全部填“AI提取” |
必填与选填：最小可用字段集
模板字段不必一次填满。评审必需的是能支撑判断和回查的字段，其余字段按需求类型和团队流程补充。最小可用版本保留以下必填项即可发起评审。
必填字段及理由
- 需求编号：关联主表、来源追踪和待澄清项的唯一键，缺失会导致追溯链断裂。
- 需求摘要：评审人快速判断需求内容的基础。
- 需求分类：决定后续分流和责任人，缺失时评审无法给出处理意见。
- 约束条件：至少写明已知前提和排除项，避免评审后反复返工。
- 置信度：让评审人知道哪些条目需要重点核对。
- 状态：标明条目处于待评审、已确认、待澄清还是已关闭。
- 来源编号、来源类型、来源位置、核对人：构成最小追溯单元，缺一项就无法回查。
选填字段及适用场景
- 原始表述：需求涉及敏感措辞或合规要求时填写，便于对照AI改写是否失真。
- 原文摘录：来源为长文档或访谈录音时填写，短工单可只记来源位置。
- 提取方式：多条材料合并或存在推断时填写，单一来源直引可省略。
- 澄清对象、期望回复时间：存在待澄清项时填写，用于跟踪回复进度。
- 评审参与人、版本号：正式评审或需要留痕的批次填写。
按需求类型调整必填项
合规类、集成类需求建议把原始表述和约束条件列为必填，因为措辞和边界直接影响实现；体验类需求可把原文摘录列为选填，重点保留来源位置和核对人；来自单一工单的简单需求，来源追踪可合并为一行，但仍需保留来源编号与核对人。调整规则应写入模板说明，避免每位整理人自行增减。
| 字段 | 最小可用版本 | 建议补充场景 |
|---|---|---|
| 需求编号 | 必填 | — |
| 需求摘要 | 必填 | — |
| 需求分类 | 必填 | — |
| 约束条件 | 必填 | 合规、集成类需写全排除项 |
| 置信度 | 必填 | — |
| 状态 | 必填 | — |
| 来源编号/类型/位置/核对人 | 必填 | — |
| 原始表述 | 选填 | 敏感措辞、合规要求 |
| 原文摘录 | 选填 | 长文档、访谈录音 |
| 提取方式 | 选填 | 多来源合并、存在推断 |
| 澄清对象/期望回复时间 | 选填 | 存在待澄清项 |
填写示例：一条需求的完整记录
以下示例为演示情景，用于说明字段之间如何对应，不代表真实项目数据。示例需求来自一次用户访谈和一条客服工单，AI归纳后由整理人核对。
示例需求条目主表行
| 需求编号 | 需求分类 | 需求摘要 | 原始表述 | 约束条件 | 置信度 | 状态 | 来源编号 |
|---|---|---|---|---|---|---|---|
| REQ-014 | 功能类 | 财务人员在月末对账时需要按项目导出明细，减少手工汇总 | “每个月对账都要从几个表里拼数据，希望能直接按项目导出来” | 仅限已归档项目；导出字段需与现有对账表一致；本季度内上线 | 中 | 待评审 | SRC-03；SRC-07 |
对应来源追踪行
| 来源编号 | 关联需求编号 | 来源类型 | 来源位置 | 原文摘录 | 提取方式 | 核对人 | 核对结果 |
|---|---|---|---|---|---|---|---|
| SRC-03 | REQ-014 | 访谈记录 | 2025-03财务访谈第2段 | “每个月对账都要从几个表里拼数据” | 原文直引 | 李某 | 已确认 |
| SRC-07 | REQ-014 | 工单 | 工单#12345 | “希望支持按项目导出对账明细” | 同义归纳 | 王某 | 已确认 |
对应冲突与待澄清行
| 问题编号 | 关联需求编号 | 问题类型 | 问题描述 | 涉及来源 | 澄清对象 | 期望回复时间 | 处理状态 |
|---|---|---|---|---|---|---|---|
| Q-05 | REQ-014 | 范围冲突 | 访谈提到“已归档项目”，工单未限定项目状态，需确认导出范围 | SRC-03；SRC-07 | 财务负责人 | 评审前 | 待回复 |
示例中，主表的来源编号与来源追踪表的来源编号一一对应；置信度标为“中”，因为工单来源为同义归纳，且导出范围尚待确认；待澄清项引用同一组来源编号，评审时可沿编号回到原文核对。字段说明中的“来源位置精确到段落或工单号”“提取方式区分直引与归纳”在这条记录中都有对应体现。
组织成可评审、可追溯交付物的做法
填好的模板需要经过一次整理才能成为评审材料。核心动作是核对追溯链完整性、逐条确认状态、把评审结论回写到同一份记录中，并保留版本变化。
评审前检查项
- 每条需求都有唯一编号，主表与来源追踪表的编号能互相找到。
- 必填字段无空缺，置信度为“低”的条目已列入待澄清表。
- 来源位置可回查，原文摘录与原始材料措辞一致。
- 待澄清项已指定澄清对象和期望回复时间。
- 结果头信息中的分析对象、输入材料范围与实际材料一致。
来源追踪与需求条目的关联方式
关联依靠编号而非文字描述：主表一行需求可对应来源追踪表多行来源，来源追踪表每行只归属一个需求编号；待澄清表通过关联需求编号挂到具体条目上。评审时按需求编号逐条展开，先看来源是否齐全，再看摘录是否支撑摘要，最后判断置信度是否合理。这样即使AI输出经过多轮整理，追溯链仍能沿编号回到原始材料。
评审结论与状态回写
评审结束后，把每条需求的结论写回主表状态字段，取值建议统一为已确认、需修改、待澄清、已关闭；需修改的条目在评审记录表登记修改要点，待澄清的条目同步更新待澄清表处理状态。状态回写完成后，主表即成为本次分析的当前结论，后续变更在此基础上追加，不覆盖历史记录。
版本与变更记录
每次评审或批量修改后递增版本号，并在评审记录表登记日期、范围、参与人和结论。变更记录只写“改了什么、为什么改、影响哪些需求编号”，不重复粘贴整张表。需要多人协作时，可以把需求条目和来源记录放在同一工作空间中维护，ONES 的需求条目与 Wiki 文档可承载条目状态和评审记录，ONES Assistant 在指定 Wiki 页面组内回答问题时附引用来源，便于整理人回查材料；具体字段结构以团队模板为准。
调整与维护：模板随流程演进的规则
模板使用一段时间后，字段会随流程变化增减。维护的重点是让新增字段有明确用途、废弃字段有交接方式、来源口径保持稳定。
新增字段的判断标准
新增字段前先回答三个问题：这个字段是否影响评审判断或回查效率；是否已有字段可以承载同类信息；由谁负责填写、何时填写。三个问题都有明确答案再新增，并在字段说明中补充填写口径。仅为统计方便而增加的字段，优先通过分类或标签实现，避免主表持续变宽。
字段废弃与合并的处理
字段废弃时，先确认历史记录中的值已迁移或归档，再在模板说明中标注停用日期和替代字段。两个字段含义重叠时合并为一个，保留信息更完整的字段名，并在变更记录中写明合并规则。已发出的评审材料不回溯修改，新批次使用新版本模板。
来源类型字典的维护
来源类型保持少量稳定取值，新增类型需说明与现有类型的区别。建议每季度检查一次字典使用情况，把长期空置的类型合并或停用，把频繁出现的“其他”拆分为具体类型。来源位置和原文摘录的填写口径同步更新，确保新旧批次可以对比。
定期复核机制
建议每季度抽查一批已完成评审的记录，核对来源编号是否可回查、状态是否与最新结论一致、待澄清项是否已关闭。复核结果记入模板维护记录，作为下一轮调整依据。复核由整理人和评审人共同参与，避免模板只增不减、字段说明与实际填写脱节。
常见问题
AI给出的需求摘要和原文摘录不一致时，以哪个为准？
以原文摘录为准，摘要作为整理后的表达保留在需求条目主表中。两者不一致通常说明AI在归纳时改动了措辞或扩大了范围，处理方式是把原文摘录补全到来源追踪表，再据此修正摘要，并在核对结果中记录修正原因。如果差异涉及需求边界，应同时登记到冲突与待澄清表，由澄清对象确认后再更新状态。
来源材料只有一条工单时，来源追踪表还需要单独建行吗？
需要保留一行来源记录，但可以精简字段。来源编号、关联需求编号、来源类型、来源位置和核对人仍应填写，原文摘录和提取方式在工单原文较短且为直引时可以省略。这样做的目的是让评审人沿来源编号回到工单核对，同时避免为简单需求维护过重的记录。
置信度标为“低”的需求，评审时应该怎么处理？
置信度低表示结论主要来自AI归纳、缺少原始材料直接支撑。评审时不宜直接确认，应先列入冲突与待澄清表，指定澄清对象和期望回复时间；补齐来源后再重新标注置信度。若评审时间紧，可先标记为待澄清并保留在本次记录中，待回复后回写状态，避免把未核实结论混入已确认条目。
多人协作填写同一份模板时，如何避免来源编号重复或断链？
建议在结果头信息中约定编号规则，例如按批次加序号生成来源编号，并由整理人统一分配后再分发填写。填写过程中，主表的来源编号只引用已登记的来源记录，新增来源先补来源追踪表再回填主表。评审前做一次编号对照检查，确认主表、来源追踪表和待澄清表之间的引用都能互相找到。
模板字段和团队现有需求管理工具的字段不一致，是否需要完全照搬？
不需要完全照搬。模板的作用是保证AI分析结果可评审、可追溯，字段可以按团队流程增删。若团队已有需求管理工具，可把需求编号、摘要、分类、状态等字段与工具字段对齐，来源追踪和待澄清信息作为补充记录保留。关键是评审人能看到每条结论的来源和当前状态，字段名称不必强求一致。
