把需求素材交给AI整理，结果常常泛泛复述，问题多出在输入太随意。本文给出一份已填写的AI需求分析输入规范示例，覆盖背景与目标、用户与场景、原始素材、约束边界、输出格式、待确认问题六个字段，并逐项解释填写理由。示例为虚构演示情景，用于说明写法，不代表真实客户案例或效果承诺。
要点总览（TL;DR）
- AI需求分析输入规范建议包含六个字段：背景与目标、用户与场景、原始需求素材、约束与边界、期望输出格式、待确认问题清单。
- 背景与目标要写出判断标准（如每条需求对应至少一条素材），原始素材保留原话与出处，约束写明不可变更项与范围外内容，输出格式指定结构、粒度与不确定项标注。
- 换业务场景时保留“目标—素材—约束—输出格式—待确认项”的结构骨架，替换用户角色、业务对象和术语表，并让素材颗粒度与输出粒度匹配。
- 该规范适合素材已有积累、需要收敛成结构化条目的场景；素材过少时先做澄清访谈，文档成稿与常规需求澄清流程需另行处理。
- 常见误用是素材留空导致AI补写、约束不写导致输出越界、输出格式不指定导致结果不可用，核对成本反而更高。
这份输入规范示例要解决什么问题
这份示例的目标很具体：让AI输出一份结构化、可核对的需求整理结果。所谓可核对，是指每条整理后的需求都能回到原始素材中的某句话或某个出处，读者能判断AI是复述、归纳还是自行补充。做到这一点，需求评审时就不必再逐条追问“这条是从哪来的”。
示例覆盖的范围是需求理解与整理：把零散的用户原话、工单摘录、会议记录收敛成有结构的需求条目，并标出需要澄清的地方。文档成稿、报告生成以及常规的需求澄清会议流程不在本文展开，这些环节有各自的输入输出要求，混在一起会让模板失焦。
需要说明的是，下文出现的产品名称、用户角色、业务数据和需求内容均为虚构，仅用于演示字段如何填写。示例展示的是输入写法，不对AI整理质量作效果承诺。
完整示例：一份已填写的AI需求分析输入
假设场景是一家虚构的在线教育平台，客服团队近期集中收到课程退款相关的反馈，产品经理希望AI先把这些素材整理成需求条目。以下是填好的完整输入，可直接对照使用。
背景与目标
填写内容示例：
- 业务背景：近一个月客服工单中，退款进度查询类反馈占比明显上升，客服需要反复登录后台查询状态再回复用户。
- 本次目标：把退款相关反馈整理成需求条目，区分“流程缺陷”“信息展示缺失”“操作体验问题”三类。
- 判断标准：每条需求能对应至少一条原始素材；分类有明确依据；无法判断的归入待确认，不强行归类。
用户与场景
填写内容示例：
- 涉及角色：学员（发起退款）、客服（处理咨询）、财务（审核退款）。
- 典型场景：学员在课程详情页申请退款后，无法在App内查看审核进度，转而联系客服；客服需在后台系统查询后口头告知。
- 场景边界：本次只讨论退款申请提交之后的进度查询，不涉及退款规则制定与支付渠道对接。
原始需求素材
填写内容示例（保留原话与出处）：
- 工单#1024，学员原话：“申请退款三天了，App里什么都看不到，只能打电话问。”
- 工单#1031，客服备注：“每天至少五个用户问退款到哪一步了，后台查起来要切三个页面。”
- 工单#1047，学员原话：“退款成功了也没通知，我是自己看银行卡才发现。”
- 会议记录摘录（产品与客服周会）：“客服主管提到退款状态对用户不透明，是近期投诉的主要来源之一。”
约束与边界
填写内容示例：
- 不可变更项：退款审核流程本身由财务系统控制，本次不改动审核规则与时效。
- 范围外内容：支付渠道退款接口改造、退款规则文案调整。
- 已知限制：App当前版本的信息架构中，订单模块与客服入口分属不同页面。
期望输出格式
填写内容示例：
- 按“需求条目—对应素材编号—问题类型—影响角色—不确定项”的表格输出。
- 每条需求一句话描述，不超过两行；同类素材合并为一条需求时，列出全部素材编号。
- 对推断性内容单独标注“推断”，与素材原话区分；无法归类的素材放入“待确认”区，不删除。
待确认问题清单
填写内容示例：
- 退款状态是否需要区分“审核中”“打款中”“已完成”三个节点，还是只展示“处理中/已完成”？
- 通知渠道是站内消息、短信还是两者都要？现有通知能力覆盖哪些渠道？
- 客服后台的查询效率问题，是否与用户侧展示问题合并为一条需求，还是分开立项？
逐项解释：每个字段为什么这样写
六个字段各自承担不同的约束作用，缺一项，AI的输出就会在对应方向上失去控制。下面逐项说明填写理由和判断标准。
背景与目标：给出判断标准，而不只是方向
“优化退款体验”这类表述无法指导整理，因为AI不知道整理到什么程度算完成。示例中把目标写成“区分三类问题”，并给出“每条需求对应至少一条素材”的判断标准，AI在归类时就有了可执行的依据。填写时可以先问自己：拿到整理结果后，我用什么标准判断它合格？把这个标准写进字段，比写业务愿景更有用。
原始需求素材：保留原话与出处
素材字段是整份输入的事实基础。保留原话和编号，AI才能区分哪些是用户明确说的、哪些是归纳出来的。示例中工单编号的作用是让每条整理结果可回溯，评审时可以直接核对。常见写法是把素材改写成“用户希望看到退款进度”这类概括句，这样AI失去原始依据，只能顺着概括继续发挥，推断和事实就混在一起了。
约束与边界：写明不可变更项与范围外内容
约束字段决定AI的输出会不会越界。示例中明确“不改动审核规则与时效”，AI就不会提出调整退款审核流程的建议；写明“支付渠道接口改造”在范围外，整理结果就不会混入技术方案类内容。填写时把两类内容分开写：一类是碰不得的既有规则，一类是本次不讨论的话题。两者都写清楚，输出范围才收得住。
期望输出格式：指定结构、粒度与不确定项标注
输出格式字段直接决定结果能不能用。示例指定了表格结构、每条需求的行数上限、合并素材时的编号规则，以及“推断”标注要求。粒度尤其关键：不限定一句话描述，AI可能给出一段分析；不要求标注不确定项，AI的猜测就会和素材原话混排。填写时按下游使用方式来定格式，如果整理结果要导入需求管理工具，字段名和顺序最好与工具中的字段对应。
待确认问题清单：把疑问显式化
这个字段容易被忽略，实际作用很大。示例中列出的三个问题，是产品经理在整理前就意识到、但暂时没有答案的事项。把它们写进输入，AI在整理时会围绕这些问题标注不确定项，而不是自行选择一个答案继续往下写。填写时不必等所有问题都有答案，把已知的疑问列出来即可，这份清单本身就是后续澄清会议的输入。
可迁移规律：换一个业务场景怎么改
这份示例的结构骨架可以整体保留，替换的是与业务相关的内容。下面区分哪些保持不变、哪些需要随场景调整。
保持不变的结构骨架
目标与判断标准、原始素材及出处、约束与边界、输出格式、待确认问题，这五类信息在任何需求整理场景中都必要。换场景时，字段顺序和填写逻辑不需要改，因为它们对应的是“AI需要知道什么才能整理得可核对”这一固定问题。
随场景替换的内容
用户角色、业务对象和术语表需要按场景重写。示例中的学员、客服、财务对应在线教育；换成企业内部系统场景，角色可能变成提交人、审批人、系统管理员，业务对象从退款单变成采购申请单。术语表尤其值得单独补充：同一业务中常有内部简称，AI不熟悉这些简称时容易理解偏差，在输入中附一小段术语对照，能减少这类问题。
素材颗粒度与输出粒度的匹配
素材越零散，输出粒度就应越细，并保留更多原文引用；素材本身已是成段的会议纪要，输出可以按主题合并，但仍需标注来源段落。如果素材只有几条概括性描述，就不宜要求AI输出细分到操作步骤的需求条目，否则补充内容会明显多于素材本身。
多来源需求输入的合并方式
同一模板可以处理工单、访谈记录、会议纪要、竞品观察等多来源输入。做法是在素材字段内按来源分组编号，并在输出格式中要求标注来源类型。这样整理结果既能按需求主题聚合，也能按来源追溯，后续判断某类反馈的集中程度时不必重新翻原始记录。
适用边界与常见误用
这份输入规范适合素材已有一定积累、需要收敛成结构化条目的场景，例如工单集中反馈、用户访谈记录整理、会议讨论要点归并。素材本身很少、需求方向尚不明确时，先做澄清访谈比套用模板更有效。
文档成稿与报告生成需要另一套输入要求，本文的字段设计不覆盖这类任务；常规需求澄清流程中的评审、优先级排序等环节，也应在整理结果产出之后另行进行。把整理环节和决策环节混在一次输入里，AI的输出会同时承担归纳和判断两种职责，可核对性下降。
常见误用有三类。素材字段留空或只写一句概括，AI只能自行补写内容，整理结果看似完整却无法回溯；约束字段不写，输出容易越界到流程改造、技术方案等范围外话题；输出格式不指定，结果可能是一段散文式分析，无法直接进入评审或导入工具。三类问题的共同点是输入信息不足，而输出看起来仍然像模像样，核对成本反而更高。
在团队协作中，整理结果和待确认问题通常需要进入同一个可追踪的载体。以ONES为例，ONES Assistant 可围绕用户反馈、会议和文档提炼要点、待澄清问题与拆解建议，整理结果可保存为工作项或 Wiki 页面，待确认问题也能作为条目继续流转，方便后续评审时逐条核对来源与结论。具体操作路径以实际产品界面为准。
最后需要重申，本文示例为虚构演示情景，展示的是输入字段的写法与填写理由，不对整理质量、处理效率作任何量化承诺。实际使用时，建议先用一小批真实素材试填，检查输出是否满足自己写下的判断标准，再决定是否在团队内推广这套模板。
常见问题
原始需求素材只有几条概括性描述，还能用这份输入规范吗？
可以用，但需要调整对输出的预期。素材本身是概括句时，AI能做的整理主要是归类和去重，难以产出细分到操作步骤的需求条目。此时建议在输出格式中要求标注“素材不足、需补充原始记录”的条目，并把补充素材列入待确认问题清单，先补齐工单原话或访谈记录，再进行下一轮整理。
待确认问题清单里的问题，需要在提交给AI之前都有答案吗？
不需要。这份清单的作用是把已知疑问显式写出来，让AI在整理时围绕这些问题标注不确定项，而不是自行选择一个答案继续写。清单本身也是后续澄清会议的输入，评审时可以逐条确认。若某个问题已有明确结论，直接写进约束与边界字段更合适，避免AI把它当成开放项反复标注。
整理结果要进入团队的需求管理工具，输入规范需要额外注意什么？
重点在期望输出格式字段。建议让输出字段名和顺序与工具中的字段对应，例如需求标题、描述、来源、类型、影响角色，减少导入时的二次转换。若整理结果需要保存为工作项或文档页面，可在输入中说明保存位置与命名规则。以ONES为例，ONES Assistant 可围绕用户反馈、会议和文档提炼要点、待澄清问题与拆解建议，整理结果可保存为工作项或 Wiki 页面，待确认问题也能作为条目继续流转；具体操作路径以实际产品界面为准。
同一批需求来自工单、访谈和会议纪要，怎么在模板里组织？
在原始需求素材字段内按来源分组编号，例如工单用“工单#编号”、访谈用“访谈-日期-序号”、会议纪要用“会议-日期-段落”。同时在输出格式中要求标注来源类型，这样整理结果既能按需求主题聚合，也能按来源追溯。来源类型不同，可信度判断也不同，分组编号能让评审时快速定位到原始记录。
这套模板用在团队里，怎么判断它是否值得推广？
先用一小批真实素材试填，检查AI输出是否满足你在背景与目标中写下的判断标准，例如每条需求能否回溯到素材、推断内容是否单独标注、待确认项是否完整。若核对时仍需大量人工补写，说明素材字段或输出格式需要调整，而不是直接扩大使用范围。试填阶段也适合收集团队对字段的反馈，再决定是否固化为统一模板。
