AI需求分析结果模板建议以“需求条目”为一行，固定十类字段：需求编号、需求分类、摘要、原始诉求、约束条件、冲突与待澄清项、置信度、来源追踪、AI生成说明、评审状态。来源追踪用“来源类型+来源标识+原文位置+采集时间+整理人”五要素记录，与需求编号一一对应。本文给出可直接复制的空白表、字段口径、必填规则和一条完整示例，适用于把AI整理结果转成可评审、可回溯记录的团队。
要点总览（TL;DR）
- 模板以“需求条目”为一行，固定十类字段：需求编号、需求分类、摘要、原始诉求、约束条件、冲突与待澄清项、置信度、来源追踪、AI生成说明、评审状态。
- 来源追踪用“来源类型+来源标识+原文位置+采集时间+整理人”五要素记录，通过需求编号与主表一一对应，评审时可据此回到原始材料核对。
- 需求编号、需求分类、摘要、原始诉求、来源追踪、评审状态为必填；约束条件、冲突与待澄清项、置信度、AI生成说明为选填，缺失时按规则处理。
- 评审准入看必填字段完整性与来源可回溯性；置信度为低的需求须至少写出一条待澄清项并指定澄清对象，否则不进入评审。
- 模板需版本管理，字段增删以“填不出有效信息、字段边界重叠、反复因同类信息缺失退回”为触发条件，变更后新提交需求使用新版本。
可复制空白模板：AI需求分析结果表
模板由一张主表和一张来源追踪子表组成。主表一行对应一条需求，来源追踪子表一行对应一条来源记录，通过需求编号关联。复制到表格工具后，先保留表头，再按行填写。
主表：需求分析结果
| 需求编号 | 需求分类 | 摘要 | 原始诉求 | 约束条件 | 冲突与待澄清项 | 置信度 | 来源追踪 | AI生成说明 | 评审状态 |
|---|---|---|---|---|---|---|---|---|---|
| REQ-001 | SRC-001 | ||||||||
| REQ-002 | SRC-002 | ||||||||
| REQ-003 | SRC-003 |
来源追踪子表
| 来源记录编号 | 需求编号 | 来源类型 | 来源标识 | 原文位置 | 采集时间 | 整理人 |
|---|---|---|---|---|---|---|
| SRC-001 | REQ-001 | |||||
| SRC-002 | REQ-002 | |||||
| SRC-003 | REQ-003 |
评审记录列
评审状态列建议使用固定取值：待评审、通过、退回补充、暂缓。评审意见不塞进主表，另设评审记录表，记录需求编号、评审日期、评审人、结论、退回原因和补充要求。这样主表保持一行一条需求，评审历史可以多次追加。
| 需求编号 | 评审日期 | 评审人 | 评审结论 | 退回原因 | 补充要求 |
|---|---|---|---|---|---|
字段说明：每个字段记录什么、怎么填
字段说明的作用是让不同填写人对同一列采用相同口径。下表逐字段给出含义、填写口径和示例值，模板、说明和示例三处使用同一套字段名。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 需求编号 | 需求条目的唯一标识 | 项目前缀加顺序号，全表不重复；来源追踪子表引用同一编号 | REQ-001 |
| 需求分类 | 需求所属类型 | 使用团队固定的分类词表，如功能、体验、数据、合规、集成；一条需求只选一个主分类 | 功能 |
| 摘要 | 一句话说明需求要解决什么 | 写“谁在什么场景下需要什么结果”，控制在40字以内，不写实现方案 | 客服主管需要按工单标签批量导出周报 |
| 原始诉求 | 来源中的原话或原意 | 尽量保留原始表述，转述时标注“转述”；不在此列写分析结论 | “每周手动整理标签统计太费时间，希望能直接导出” |
| 约束条件 | 已明确的限制和前提 | 记录时间、范围、依赖系统、合规要求等已知边界；每条约束注明来源 | 仅限现有工单标签体系，本期不新增标签类型 |
| 冲突与待澄清项 | 尚未解决的问题 | 写清冲突双方或待确认问题，并指定澄清对象；已解决的移出本列 | 导出格式待确认：Excel还是CSV，需与客服主管确认 |
| 置信度 | AI整理结果与原始诉求的一致程度 | 采用高、中、低三级：高为原文直接支持；中为需要推断；低为信息不足 | 中 |
| 来源追踪 | 指向来源追踪子表的记录编号 | 填写SRC编号，可填多个，用分号分隔；每条需求至少一个 | SRC-001 |
| AI生成说明 | 哪些内容由AI生成、经过什么处理 | 写明生成环节和人工修改情况，便于评审判断可信度 | AI从会议记录提炼摘要，人工补充约束条件 |
| 评审状态 | 需求当前评审阶段 | 从待评审、通过、退回补充、暂缓中选一个 | 待评审 |
需求分类与摘要容易混写。分类回答“这是什么类型的需求”，摘要回答“这条需求要达成什么”。分类使用受控词表，摘要允许自然语言，但两者都不应包含技术方案。约束条件与冲突待澄清项的区别在于确定性：约束是已经确认的边界，冲突与待澄清项是尚未有结论的问题。把待确认事项写进约束条件，会让后续评审误以为边界已定。
来源追踪五要素各有分工。来源类型说明渠道，如访谈、会议、工单、问卷、聊天记录；来源标识是渠道内的唯一标识，如会议日期加议题、工单号、问卷编号；原文位置定位到具体段落、时间点或单元格；采集时间记录信息获取的时间；整理人记录把原始信息整理成需求条目的人。五要素合起来，任何人可以按图索骥回到原始材料核对。
必填与选填：哪些字段决定能否进入评审
评审准入看两件事：必填字段是否完整，来源是否可回溯。必填字段缺失或来源追踪无法定位到原文的需求，退回补充后再排评审。
| 字段 | 属性 | 缺失时的处理 |
|---|---|---|
| 需求编号 | 必填 | 由模板自动生成或整理人补号，无编号不进入评审 |
| 需求分类 | 必填 | 退回，要求按分类词表选择 |
| 摘要 | 必填 | 退回，要求补写到可独立理解 |
| 原始诉求 | 必填 | 退回，要求补录原话或标注转述 |
| 来源追踪 | 必填 | 退回，要求补齐五要素并核对原文位置 |
| 评审状态 | 必填 | 默认置为待评审 |
| 约束条件 | 选填 | 无已知约束时填“暂无”，不阻断评审 |
| 冲突与待澄清项 | 选填 | 无冲突时填“无”；有冲突但未指定澄清对象的，评审时列为跟进项 |
| 置信度 | 选填 | 未填视为中；填“低”时必须附待澄清项 |
| AI生成说明 | 选填 | 纯人工整理可填“人工整理”；AI参与生成时建议填写 |
置信度为低的需求，补充要求是至少写出一条待澄清项并指定澄清对象，否则不进入评审。置信度为中的需求可以进入评审，但评审人应优先核对摘要与原始诉求是否一致。这样处理的原因是低置信度通常意味着原始信息不足，直接评审容易在错误理解上做决策。
模板落地到工具时，可以把主表字段映射为需求工作项属性，把来源追踪子表作为关联记录或文档中的附表。ONES 的需求工作项与 Wiki 文档可以承载这类记录，ONES Assistant 能基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作，也可将整理结果保存为工作项或 Wiki 页面，减少重复录入。是否采用工具承载，取决于团队已有的需求管理流程；模板本身在表格工具中同样可用。
填写示例：一条需求的完整记录
以下示例为演示情景，展示一条需求从来源到评审结论的完整记录。
| 字段 | 填写内容 |
|---|---|
| 需求编号 | REQ-014 |
| 需求分类 | 功能 |
| 摘要 | 客服主管需要按工单标签批量导出周报数据 |
| 原始诉求 | “每周手动整理标签统计太费时间，希望能直接导出，最好能按周选时间范围。” |
| 约束条件 | 仅使用现有工单标签体系；导出范围限当前账号有权限的工单 |
| 冲突与待澄清项 | 导出格式待确认：Excel还是CSV，需与客服主管确认；是否需要包含已关闭工单待产品经理确认 |
| 置信度 | 中 |
| 来源追踪 | SRC-014 |
| AI生成说明 | AI从客服访谈录音转录中提炼摘要与原始诉求，人工补充约束条件 |
| 评审状态 | 退回补充 |
对应的来源追踪子表记录：来源记录编号SRC-014，需求编号REQ-014，来源类型为访谈，来源标识为“客服团队访谈-2025年3月第2周”，原文位置为录音第12分30秒至14分10秒，采集时间为访谈当天，整理人为需求分析人员。评审人按这五项可以回听录音核对原话。
冲突与待澄清项的写法要点是把问题和确认对象写在一起。“导出格式待确认”只是问题，“需与客服主管确认”才让问题有下一步。评审结论示例：评审人认为摘要与原始诉求一致，但导出格式和工单范围两项未确认，结论为退回补充，补充要求是确认格式后更新待澄清项，并将置信度调整为高。补充完成后状态改为待评审，再次评审通过后改为通过。
调整与维护：模板随项目演进怎么改
模板需要版本管理，否则字段口径会在不同批次之间漂移。建议在模板文件顶部保留版本号和变更记录，每次修改字段都记录原因、影响范围和生效日期。
| 版本 | 变更内容 | 变更原因 | 生效日期 | 影响范围 |
|---|---|---|---|---|
| v1.0 | 初始十字段与来源追踪五要素 | 建立统一记录口径 | 全部需求条目 | |
| v1.1 | 新增“合规要求”分类值 | 出现合规类需求无法归类 | 分类词表 | |
| v1.2 | 来源追踪增加“采集方式” | 访谈与问卷来源需要区分记录方式 | 来源追踪子表 |
字段增删的触发条件可以归纳为三类：现有字段反复填不出有效信息，说明口径不清或字段冗余；同类信息被填进多个字段，说明字段边界重叠；评审反复因同一类信息缺失而退回，说明该信息应升为必填。触发后先在小范围试用一个迭代，再决定是否全量切换。
来源链接失效是长期维护的常见问题。处理方式是来源追踪优先记录可定位的标识和原文位置，链接作为辅助；链接失效时保留来源标识和采集时间，并在子表备注中说明失效情况和替代获取方式。对于聊天记录、会议录音等有时效的材料，采集时同步归档关键原文摘录，避免后续无法回溯。
模板与评审流程的衔接体现在状态流转上：整理人提交时状态为待评审，评审人按必填完整性和来源可回溯性判断，通过则进入需求池，退回则填写退回原因和补充要求。模板版本变更时，已进入评审的需求沿用提交时的版本口径，新提交的需求使用新版本，避免同一批评审混用两套字段。ONES 的 AI 能力基于权限体系执行知识问答和任务执行，输出过程可追踪、结果可审计，适合把模板记录与评审状态放在同一套工作项和文档中维护；具体承载方式以团队实际配置为准。
常见问题
AI整理出的需求条目，原始诉求一栏可以只写概括吗？
建议尽量保留原话；确需概括时，在内容前标注“转述”，并在来源追踪中写清原文位置，方便评审人回查。原始诉求与分析结论分列记录，摘要写需求要达成什么，原始诉求保留来源中的表述，两者不要混写。
来源追踪里的“来源标识”和“原文位置”有什么区别？
来源标识定位到渠道内的某份材料，例如会议日期加议题、工单号、问卷编号；原文位置进一步定位到材料内部的具体段落、时间点或单元格。两者配合使用，评审人可以先按来源标识找到材料，再按原文位置核对原话。
一条需求对应多个来源时，来源追踪怎么填？
主表的来源追踪列可填多个SRC编号，用分号分隔；来源追踪子表为每个来源单独一行，均引用同一需求编号。这样一条需求可以同时保留访谈、工单、问卷等不同渠道的记录，评审时按来源逐条核对。
模板放进需求管理工具后，评审状态和评审意见怎么维护？
主表只保留当前评审状态，取值固定为待评审、通过、退回补充、暂缓；评审意见另设评审记录表，按需求编号追加评审日期、评审人、结论、退回原因和补充要求。这样一条需求可以保留多次评审历史，主表仍保持一行一条需求。ONES 的需求工作项与 Wiki 文档可以承载这类记录，ONES Assistant 能将整理结果保存为工作项或 Wiki 页面，减少重复录入；具体承载方式以团队实际配置为准。
来源链接失效后，这条需求还能通过评审吗？
可以，前提是来源标识、原文位置和采集时间仍能定位到原始材料。来源追踪优先记录可定位的标识和原文位置，链接作为辅助；链接失效时保留其余要素，并在子表备注中说明失效情况和替代获取方式。对聊天记录、会议录音等有时效的材料，采集时同步归档关键原文摘录。
