AI需求分析结果模板：字段清单与来源追踪

AI需求分析结果模板的核心，是把每条需求整理成表格中的一行，让摘要、约束、冲突和置信度都能对应回原文。字段通常分为五组：需求标识与分类、摘要与原始表述、约束与假设、冲突与待澄清项、置信度与来源追踪。其中来源追踪至少记录原始来源位置、AI生成环节、人工确认人和确认时间，评审时才能判断每条结论是否有原文支撑、是否经过复核。

要点总览（TL;DR）

• AI需求分析结果模板以“一条需求一行”的登记表为主体，字段分五组：需求标识与分类、摘要与原始表述、约束与假设、冲突与待澄清项、置信度与来源追踪。
• 来源追踪按“原始来源位置—AI生成环节—人工确认人—确认时间”四段链路填写，评审时每条结论都能回查原文并判断是否经过复核。
• 需求编号、分类、摘要、原始表述、来源位置、冲突与待澄清项、置信度及依据、人工确认信息为必填，缺项退回补录后再排期。
• 组织交付物时按分类分组、低置信度优先评审，评审结论单独记录并挂接需求编号与责任人，变更保留旧确认记录、新增确认记录。
• 模板每季度检查一次字段使用情况，空值率长期偏高的选填字段可移除，需求编号、原始表述、来源位置、确认人等回溯字段不裁剪。

可复制空白模板：AI需求分析结果登记表

下面这张表可以直接复制到文档或表格工具中，按“一条需求一行”填写。列的顺序按阅读和评审习惯排列：先定位需求，再看内容，最后核对来源与确认状态。

需求编号	需求分类	需求摘要	原始表述	原始来源位置	约束条件	假设	冲突与待澄清项	置信度	置信度依据	AI生成环节	人工确认人	确认时间	备注

如果团队习惯把来源追踪放在表格末尾，也可以把“原始来源位置”到“确认时间”这几列整体右移，但不要拆散，否则回溯时容易漏项。表格之外建议保留一个表头说明区，写清模板版本、适用项目和填写责任人。

字段说明：每个字段填什么、怎么判断

字段说明解决的是“填得对不对”的问题。同一列在不同人手里填出不同口径，评审时就要反复解释。下表按字段给出含义、填写口径和常见错误。

字段	含义	填写口径	常见错误
需求编号	本条需求在需求池或登记表中的唯一标识	沿用团队现有编号规则，与需求池条目保持一致	同一需求出现两个编号，或编号在流转中变更
需求分类	需求所属类型，用于分组评审和排期	使用团队约定的固定取值，如功能新增、体验优化、缺陷修复、合规要求、内部效率	临时造分类，或一条需求同时挂多个分类
需求摘要	用一两句话概括需求要解决的问题	写“谁在什么场景下需要什么结果”，不写实现方案	把摘要写成技术方案，或直接复制原文长段落
原始表述	来源材料中的原话或原文片段	尽量保留原词原句，可截取关键句，不改写语气	用自己的话转述后当作原文，导致回溯失真
原始来源位置	原文所在的具体位置	记录文档名加章节或页码、会议记录时间加发言段落、反馈工单编号等可定位信息	只写“来自用户反馈”，无法定位到具体条目
约束条件	已明确、必须满足的限制	写有出处或已确认的限制，如上线时间、依赖系统、合规要求、预算上限	把猜测写成约束，或把约束和假设混在一列
假设	当前未确认、但分析时先按此推进的前提	写“假设……成立”，并注明由谁在什么时间前确认	假设长期不验证，评审时被当成事实
冲突与待澄清项	与其他需求、现有规则或原文之间的矛盾，以及尚不清楚的问题	一条一行，写清冲突对象或问题、影响范围、需要谁澄清	只写“待确认”，不写确认什么、找谁确认
置信度	对这条需求理解准确程度的判断	用高、中、低三档，并必须在“置信度依据”列写明理由	只填分值不写依据，评审时无法复核
置信度依据	支撑置信度判断的具体理由	写原文是否完整、是否有多个来源互相印证、是否存在未决冲突	写“感觉比较确定”这类无法核验的描述
AI生成环节	本条内容由AI参与了哪一步	写具体环节，如原文要点提炼、待澄清问题生成、需求拆解建议、摘要初稿	整表只写“AI生成”，无法区分哪些是原文、哪些是推断
人工确认人	对这条登记结果负责复核的人	写具体姓名或工号，不用“产品组”代替	写团队名，出问题时找不到责任人
确认时间	人工复核完成的日期	写到日，需求变更后重新确认时更新	沿用初次填写时间，变更后未更新

需求分类的取值口径要在模板启用前定好，并附在表头说明里。分类一旦频繁变动，历史统计就失去可比性。摘要与原始表述的区别在于：摘要是给人快速判断用的，原始表述是给回溯用的，两者不能互相替代。约束与假设的区分标准是“是否已有确认出处”：有出处、必须满足的写约束；没有出处、先按此推进的写假设。冲突与待澄清项要写成可执行的问题，例如“与现有登录方式冲突，需确认是否允许第三方账号登录，由安全负责人确认”。置信度的高低取决于原文完整度和冲突数量，依据列写清楚，评审时才能快速定位低置信度条目。

必填与选填：哪些字段缺了就不能评审

评审准入的关键，是保证每条进入评审的需求都能被定位、被理解、被追责。必填字段围绕这三件事设置，其余字段按需补充。

类别	字段	缺失时的处理
必填	需求编号、需求分类、需求摘要、原始表述、原始来源位置	缺任一项不得进入评审，退回填写人补录后再排期
必填	冲突与待澄清项（无冲突时填“无”）	空白视为未完成分析，不允许以“暂时没有”跳过
必填	置信度、置信度依据	缺依据的低置信度条目应转为待澄清项，不进入排期
必填	AI生成环节、人工确认人、确认时间	缺人工确认的条目视为AI草稿，不得作为评审结论
选填	约束条件、假设	没有相关内容可留空，但需在备注中说明“暂无”
选填	备注	用于记录补充背景、关联需求编号等

来源追踪列为必填，原因很直接：AI提炼的摘要和待澄清项属于二次加工内容，评审时需要判断它是否忠实于原文。没有原始来源位置，复核人只能重新翻材料；没有AI生成环节，无法区分哪些是原文事实、哪些是模型推断；没有人工确认人和确认时间，就无法判断这条结论是否经过责任人把关。缺项补录的规则建议写进模板说明：评审前一个工作日完成补录，逾期未补的条目顺延到下一次评审，避免带着缺口进入讨论。

填写示例：一条需求的完整登记

下面用一条演示需求展示各字段如何对应。示例中的项目、人名和时间均为演示情景，不代表真实案例。

字段	填写内容
需求编号	REQ-2024-0317
需求分类	体验优化
需求摘要	客服人员在处理退款工单时，希望能一次看到订单的退款历史，减少在多个页面之间切换
原始表述	“现在退过一次的订单再退，我得先去订单页翻记录，再去售后页看进度，一天下来切来切去很费时间。”
原始来源位置	2024-03-12 客服团队访谈记录，第2段，受访人：客服主管（演示）
约束条件	退款历史数据来自现有售后系统，本期不改造数据源；上线时间跟随4月版本
假设	假设客服角色已有查看退款记录的权限，由权限管理员在3月20日前确认
冲突与待澄清项	1. 与现有工单详情页布局冲突，需确认退款历史放在详情页还是独立标签页；2. 历史退款是否包含已关闭工单，需客服主管澄清
置信度	中
置信度依据	原文对场景描述清楚，但展示位置和范围两个问题未决，且只有单一访谈来源
AI生成环节	原文要点提炼、待澄清问题生成
人工确认人	产品经理 李明（演示）
确认时间	2024-03-13

这条示例的来源追踪链路是：访谈记录原文（原始来源位置）→ AI提炼摘要并生成两条待澄清问题（AI生成环节）→ 产品经理复核后确认（人工确认人、确认时间）。评审人拿到这一行，可以先看原文位置核对表述，再看待澄清项判断能否排期，最后看置信度依据决定是否需要补充访谈。冲突与待澄清项写成两条独立问题，每条都指明需要谁澄清，避免会上再拆解。

组织成可评审、可追溯的交付物

登记表填完后，还需要组织成评审材料，否则表格只是零散记录。建议按以下步骤整理：

1. 按需求分类分组，每组内按置信度从低到高排列，让评审先处理不确定性高的条目。
2. 为每条需求附上原始来源的链接或文档位置，确保评审现场能直接打开原文。
3. 在表头写明模板版本号、统计周期和填写责任人，作为本次评审材料的封面信息。
4. 评审结论单独记录：通过、退回补充、转为待澄清、暂缓，每条结论挂接需求编号和责任人。
5. 评审后更新确认时间和状态，把结论同步回需求池，形成闭环。

来源追踪支撑追溯的方式，是让每个结论都能沿“原文—AI环节—确认人—时间”四段链路回查。版本与变更记录建议单独维护一张变更表，记录需求编号、变更字段、变更原因、变更人和变更时间；需求内容调整后，原确认记录保留，新增一条确认记录，不覆盖历史。评审结论与后续动作的挂接，可以在登记表中增加“评审结论”和“下一步动作”两列，或在需求池中通过状态字段关联，两种方式选一种并保持一致。

当登记表需要长期承载需求条目和评审流转时，可以把表格结构落到 ONES 的工作项与 Wiki 页面中：需求条目作为工作项管理，字段对应自定义属性，评审记录和原始材料沉淀在 Wiki 页面，AI 辅助生成的摘要与待澄清项保存为可追踪的内容。ONES Assistant 可基于项目、工作项和 Wiki 页面等上下文回答问题，并在指定 Wiki 页面组时附上引用来源，这与来源追踪的思路一致；具体字段配置和评审流转方式需按团队实际环境设置。

调整与维护：按团队情况裁剪字段

模板用久了容易出现两种问题：字段越加越多，填写成本上升；或者长期不更新，和实际流程脱节。裁剪和维护需要明确边界。

类型	字段	说明
不可裁剪	需求编号、需求摘要、原始表述、原始来源位置、人工确认人、确认时间	这六项支撑定位、理解和追责，裁剪后无法回溯
可裁剪	约束条件、假设、备注	小团队或早期阶段可先留空，但需在模板说明中注明
可合并	置信度与置信度依据	可合并为一列，但必须同时写档位和理由
按需新增	关联需求、优先级、目标版本	当需求之间依赖增多或排期需要时再增加

新增字段的判断标准有两条：一是这个字段是否会影响评审结论或后续动作，二是是否有明确的责任人来填写和维护。两条都不满足的字段，先放进备注列观察一段时间。维护节奏建议每季度检查一次字段使用情况，统计各列的空值率和填写错误率，空值率长期偏高的选填字段可以考虑移除。维护责任人建议由需求管理流程的负责人担任，变更模板时同步更新表头说明和版本号。与需求变更的同步方式是：需求内容变更时更新原始表述和来源位置，保留旧确认记录并新增确认记录；模板字段本身变更时，在变更表中记录变更前后的字段清单，避免历史数据口径不一致。

常见问题

AI提炼的摘要和待澄清项，评审时如何判断是否忠实于原文？

靠来源追踪列逐条核对。评审人先看“原始来源位置”打开原文，对照“原始表述”确认原话是否被保留；再看“AI生成环节”区分哪些内容是原文要点、哪些是模型推断；最后看“人工确认人”和“确认时间”，判断这条结论是否经过责任人把关。三段信息缺一段，复核就只能重新翻材料，所以来源追踪在模板中列为必填。

需求分类的取值可以随项目临时调整吗？

建议在模板启用前把分类取值定好，并附在表头说明里。分类用于分组评审和排期，频繁变动会让历史统计失去可比性。如果确有新类型出现，按季度维护节奏统一增补，并记录变更前后的取值清单，避免同一类需求在不同时期挂在不同分类下。

一条需求同时存在多个冲突，登记表怎么填？

在“冲突与待澄清项”列内一条一行写清楚，每条都包含冲突对象或问题、影响范围、需要谁澄清。例如“与现有工单详情页布局冲突，需确认退款历史放在详情页还是独立标签页，由产品经理确认”。多条问题合并成一句“待确认”，评审时还要现场拆解，反而拖慢排期。

需求内容变更后，原来的确认记录要覆盖吗？

不覆盖。需求内容调整时更新原始表述和来源位置，保留旧确认记录，新增一条确认记录并更新确认时间。版本与变更记录单独维护一张变更表，记录需求编号、变更字段、变更原因、变更人和变更时间。这样回溯时能看到每次确认对应的内容版本，历史口径保持一致。

登记表要长期承载需求条目和评审流转，可以放到哪里？

可以把表格结构落到 ONES 的工作项与 Wiki 页面中：需求条目作为工作项管理，字段对应自定义属性，评审记录和原始材料沉淀在 Wiki 页面。ONES Assistant 可基于项目、工作项和 Wiki 页面等上下文回答问题，并在指定 Wiki 页面组时附上引用来源，与来源追踪的思路一致。具体字段配置和评审流转方式需按团队实际环境设置。