AI需求分析结果结构化字段模板：可复制空白表与填写规范

AI需求分析结果如果没有固定字段，评审时容易出现来源说不清、冲突漏记录、结论无法回溯的情况。下面给出一张可直接复制的结构化字段表，按“需求标识与来源—分类与摘要—约束与假设—冲突与待澄清项—置信度与依据—评审与追溯”六组组织，每条需求占一行；同时说明每个字段的填写口径、必填规则、完整示例，以及模板随团队调整的维护方法。适用于把会议记录、用户反馈、PRD草稿等材料经AI提炼后转为可评审需求条目的场景。

要点总览（TL;DR）

• 模板按“需求标识与来源—分类与摘要—约束与假设—冲突与待澄清项—置信度与依据—评审与追溯”六组共18个字段组织，每条需求一行，可直接复制到文档或表格工具中使用。
• 最小可用填写集为R01需求标识、R02需求标题、R03原始材料位置、R04提取方式、R06需求分类、R07需求摘要、R13置信度、R14置信度依据、R15评审状态；必填缺失时退回补齐，来源确实无法定位时在待澄清项登记并限期关闭。
• 冲突项与待澄清项单独成列，待澄清项须写清问题、责任人和关闭条件，让未解决的问题在评审中显性化。
• 置信度采用高/中/低三档并同时填写依据，说明判断来自原文明确表述还是AI归纳推断，评审人据此决定先澄清还是直接排期。
• 模板需按需求类型增删字段、维护版本与字段变更记录，并在每个评审周期后抽查必填完整性、待澄清项关闭情况和置信度依据，形成持续调整循环。

可复制空白模板：AI需求分析结果结构化字段表

将下表复制到文档或表格工具中即可使用。每条需求一行，空白单元格保持待填状态，由填写人根据原始材料和分析结果逐项补齐。字段编号用于在字段说明和评审意见中引用，不建议删除或重排。

字段编号	字段名	所属分组	填写位置与形式	填写内容
R01	需求标识	需求标识与来源	单元格，短编号	待填
R02	需求标题	需求标识与来源	单元格，一句话	待填
R03	原始材料位置	需求标识与来源	单元格，文档名+章节/页码/链接	待填
R04	提取方式	需求标识与来源	下拉或单元格：人工摘录/AI提炼/会议转录/反馈归纳	待填
R05	提出方	需求标识与来源	单元格，角色或来源渠道	待填
R06	需求分类	分类与摘要	下拉或单元格：功能/性能/体验/合规/数据等	待填
R07	需求摘要	分类与摘要	单元格，2–4句	待填
R08	目标用户与场景	分类与摘要	单元格	待填
R09	约束条件	约束与假设	单元格，逐条列出	待填
R10	假设	约束与假设	单元格，逐条列出	待填
R11	冲突项	冲突与待澄清项	单元格，描述冲突对象与内容	待填
R12	待澄清项	冲突与待澄清项	单元格，问题+责任人+关闭条件	待填
R13	置信度	置信度与依据	下拉：高/中/低	待填
R14	置信度依据	置信度与依据	单元格，说明判断来源	待填
R15	评审状态	评审与追溯	下拉：待评审/评审中/已通过/已驳回/挂起	待填
R16	评审结论与意见	评审与追溯	单元格，结论+关键意见	待填
R17	变更记录	评审与追溯	单元格，日期+变更内容+变更人	待填
R18	关联需求	评审与追溯	单元格，填写关联需求标识	待填

表格按六组字段从左到右排列，评审时可以按分组逐段检查：先确认来源是否可回溯，再看分类与摘要是否准确，然后核对约束与假设，重点处理冲突与待澄清项，最后确认置信度与评审结论。R11和R12单独成列，目的是让未解决的问题在评审中显性化，避免整条需求被笼统通过。

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

同一字段在不同角色手里容易填出不同口径，下面逐项说明含义和常见填法，建议连同空白表一起发给填写人。

需求标识与来源组

• 需求标识（R01）：团队内唯一且稳定的编号，建议采用“项目缩写-序号”形式。编号一经分配不随内容修改而变更，便于评审意见和变更记录引用。
• 需求标题（R02）：用一句话概括需求对象和动作，避免只写“优化体验”这类无法判断范围的标题。
• 原始材料位置（R03）：记录需求出自哪份材料的具体位置，如“用户访谈记录v2 第3节”“客服反馈表2024-05第12条”“PRD草稿 2.1节”。有链接时附链接，没有链接时写清文档名和章节页码。
• 提取方式（R04）：标明这条需求是人工摘录、AI从材料中提炼、会议转录整理还是反馈归纳。AI提炼的条目在评审时应优先核对原文，提取方式直接影响复核力度。
• 提出方（R05）：记录需求来源的角色或渠道，如某业务岗位、客户反馈、内部运营。用于后续澄清时找到对的人。

分类与摘要组

• 需求分类（R06）：按团队约定的分类填写，常见维度包括功能、性能、体验、合规、数据等。分类用于分配评审人和后续排期，不宜过细，保持五到八类即可。
• 需求摘要（R07）：用2–4句写清“谁在什么场景下需要什么、期望达到什么结果”。摘要应能独立阅读，不依赖原始材料也能理解大意。
• 目标用户与场景（R08）：写明受影响的使用角色和触发场景，帮助评审判断需求范围和优先级。

约束与假设组

• 约束条件（R09）：记录已经确定、不可随意变更的限制，如合规要求、既有系统接口、上线时间窗口。逐条列出，每条写清约束内容和来源。
• 假设（R10）：记录分析时默认成立但尚未验证的前提，如“假设现有账号体系可复用”。假设需要标注验证方式，验证后转为约束或删除。

冲突与待澄清项组

• 冲突项（R11）：写明与哪条需求、哪个约束或哪份材料存在冲突，以及冲突的具体内容。存在多条冲突时分条记录，不合并成一句“有冲突”。
• 待澄清项（R12）：每条待澄清项写清三要素——需要澄清的问题、责任人、关闭条件。例如“支付失败后的重试次数是否受限｜责任人：支付模块负责人｜关闭条件：给出明确次数上限并确认”。没有责任人和关闭条件的待澄清项在评审中视为未完成记录。

置信度与依据组

• 置信度（R13）：采用高/中/低三档。高表示原始材料表述明确、来源可直接核对；中表示材料有依据但存在推断成分或表述不完整；低表示主要来自AI归纳、缺少原文支撑或存在明显歧义。三档口径应在团队内统一，避免同一档位在不同人手里含义不同。
• 置信度依据（R14）：说明为什么给这一档，如“原文明确写出次数上限”“由会议讨论归纳，未形成书面结论”。置信度离开依据就失去评审价值，此字段应与R13同时填写。

评审与追溯组

• 评审状态（R15）：按待评审、评审中、已通过、已驳回、挂起填写。状态变化时同步更新，作为需求流转的依据。
• 评审结论与意见（R16）：记录评审形成的结论和关键修改意见，结论与意见写在同一行，便于后续执行人直接查看。
• 变更记录（R17）：每次修改摘要、约束或分类时追加一条记录，格式为“日期+变更内容+变更人”，保留历史而非覆盖。
• 关联需求（R18）：填写与本条存在依赖、拆分或重复关系的需求标识，支撑需求间的追溯。

必填与选填：哪些字段不能空

模板字段较多，但最小可用填写集只需要保证评审能做出判断。下表区分必填与选填，团队可在此基础上按需收紧。

字段	必填/选填	说明
R01 需求标识	必填	评审和变更引用的基础
R02 需求标题	必填	无标题无法进入评审列表
R03 原始材料位置	必填	保证来源可回溯
R04 提取方式	必填	决定复核力度
R05 提出方	选填	澄清阶段需要时补充
R06 需求分类	必填	用于分配评审人
R07 需求摘要	必填	评审的主要阅读对象
R08 目标用户与场景	选填	范围不清时建议填写
R09 约束条件	选填	存在明确限制时填写
R10 假设	选填	有未验证前提时填写
R11 冲突项	选填	存在冲突时必填，无冲突填“无”
R12 待澄清项	选填	存在待澄清问题时必填
R13 置信度	必填	评审判断可信程度的依据
R14 置信度依据	必填	与R13同时填写
R15 评审状态	必填	需求流转的状态标识
R16 评审结论与意见	选填	评审后填写
R17 变更记录	选填	发生变更时追加
R18 关联需求	选填	存在依赖或拆分关系时填写

必填字段缺失时，该条需求不进入正式评审，退回填写人补齐；如果原始材料确实无法定位，R03填写“来源待补”并在R12登记待澄清项，由责任人限期关闭。选填字段在无内容时填“无”或留空，两种做法团队内统一即可，避免同一张表里混用。

填写示例：一条需求从原始材料到评审结论

以下为演示情景，用于说明字段之间的配合方式，不代表真实项目数据。

字段	填写内容
R01 需求标识	PAY-017
R02 需求标题	支付失败页面提供重试入口
R03 原始材料位置	用户访谈记录v2 第3节“支付环节反馈”；客服反馈表2024-05 第12条
R04 提取方式	AI提炼，人工核对原文
R05 提出方	客服渠道转交的用户反馈
R06 需求分类	体验
R07 需求摘要	用户在支付失败后停留在错误页，无法直接重新发起支付，需要返回订单页重新操作。希望在失败页提供重试入口，减少重复操作。
R08 目标用户与场景	下单后支付失败的用户，在支付结果页停留时触发
R09 约束条件	重试需复用原订单号，不得生成重复订单；受支付渠道回调时效限制
R10 假设	假设支付失败原因可由渠道返回码区分；验证方式：与支付模块确认返回码覆盖范围
R11 冲突项	与PAY-009“支付失败自动跳转订单列表”方案存在交互冲突，需二选一或合并
R12 待澄清项	重试次数是否设上限｜责任人：支付模块负责人｜关闭条件：给出明确次数上限并书面确认
R13 置信度	中
R14 置信度依据	用户反馈原文明确提到重试诉求，但重试次数和交互方式由AI归纳，原文未给出
R15 评审状态	评审中
R16 评审结论与意见	方向认可；需先关闭与PAY-009的冲突，再确认重试次数上限后进入排期
R17 变更记录	2024-05-20 补充客服反馈来源 张三；2024-05-22 增加冲突项 李四
R18 关联需求	PAY-009

这条示例体现了三个关键点：来源同时记录访谈和客服两个位置，评审时可以分别核对；冲突项和待澄清项各自独立成行，并带上责任人和关闭条件；置信度给“中”并写明推断部分，评审人据此决定先澄清再排期。需求条目在评审中流转时，可以把这类字段表落到具体的工作项和文档上。ONES Assistant 可围绕用户反馈、PRD质量检查等材料提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求澄清和录入；提炼结果可以保存为工作项或Wiki页面，评审状态和变更记录随工作项与文档保留，便于沿来源和变更链回溯。具体可用范围取决于所接入的ONES产品与权限配置。

调整与维护方法：让模板适配团队并持续可用

模板上线后需要按团队实际使用情况调整，否则字段会越填越形式化。调整围绕三件事展开：字段增减、版本记录、定期复核。

按需求类型增删字段

基础字段保持稳定，按需求类型增加专用字段。例如合规类需求可增加“适用条款”和“审计要求”字段；数据类需求可增加“数据来源”和“保留期限”字段；纯体验优化类需求可以省略R09约束条件中与合规相关的内容。增删原则是：新增字段必须能对应一个评审判断动作，评审时不会用到的字段不加；删除字段前确认历史数据中该字段没有被引用。团队规模较小时可先使用最小必填集，随评审问题增多再逐步补充。

模板版本与字段变更记录

模板本身也需要版本管理。建议在表格首行之外维护一张变更说明，记录版本号、变更日期、变更字段和变更原因。字段编号一经使用不重复分配，删除的字段保留编号并标注停用，避免旧数据引用失效。字段含义发生变化时，同步更新字段说明文档，并在团队内通知一次，防止新旧口径混用。

定期复核字段有效性

建议每个评审周期结束后抽查若干条已通过需求，检查三项：必填字段是否完整、待澄清项是否都有责任人和关闭条件、置信度依据是否与原始材料对得上。连续多个周期无人填写的选填字段，考虑删除或并入其他字段；评审中反复口头补充的信息，考虑新增为字段。复核结论记入模板变更说明，形成“使用—发现问题—调整字段—再使用”的循环。

当需求条目数量增长、参与角色增多时，字段表的承载方式也需要跟着调整。把结构化字段对应到工作项属性，把来源材料、评审意见和变更记录放在关联文档中，可以让逐条评审和来源追溯在同一处完成。ONES 的AI能力基于权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合承载这类需要留痕的需求评审流程；具体配置方式以团队实际接入的产品模块为准。

常见问题

AI提炼出的需求条目，置信度应该怎么定档？

建议按原始材料的支撑程度定档：原文明确写出且可直接核对的内容给“高”；有材料依据但含推断或表述不完整的给“中”；主要来自AI归纳、缺少原文支撑或存在明显歧义的给“低”。定档后必须在R14写清依据，例如“原文明确写出次数上限”或“由会议讨论归纳，未形成书面结论”。三档口径要在团队内统一，避免同一档位在不同人手里含义不同。

待澄清项一直没人关闭，评审该怎么处理？

R12要求每条待澄清项同时具备问题、责任人和关闭条件，缺少任一项即视为记录未完成，该条需求不进入正式评审。评审时可以先处理不依赖该澄清项的部分，把结论记为“挂起”并写明关闭条件；澄清项关闭后再恢复评审。若责任人长期无法确定，可由评审主持人指定，并在变更记录中注明指定原因。

原始材料找不到出处时，来源字段能空着吗？

R03是必填字段，不建议留空。确实无法定位时填写“来源待补”，同时在R12登记一条待澄清项，写明补齐来源的责任人与期限，评审时按低置信度处理。来源补齐后更新R03和R14，并在变更记录中追加一条。这样处理可以保留条目，同时让来源缺口在评审中可见。

团队规模小、需求数量少，字段可以精简到多少？

可以先使用最小必填集：R01需求标识、R02需求标题、R03原始材料位置、R04提取方式、R06需求分类、R07需求摘要、R13置信度、R14置信度依据、R15评审状态。冲突项、待澄清项、约束、假设、关联需求等字段在出现对应情况时再填写。精简时保留字段编号不变，后续补充字段不会打乱已有引用。

结构化字段表如何与工作项、文档配合使用？

常见做法是把R01至R14这类描述性字段对应到工作项属性，把来源材料、评审意见和变更记录放在关联文档中，评审状态随工作项流转更新。ONES Assistant 可围绕用户反馈、PRD质量检查等材料提炼要点、待澄清问题与拆解建议，提炼结果可以保存为工作项或Wiki页面，评审状态和变更记录随工作项与文档保留，便于沿来源和变更链回溯；具体可用范围取决于所接入的ONES产品与权限配置。