把需求材料直接丢给AI，常见结果是输出空泛、反复追问、结论无法验收。问题往往出在输入：目标没说清、范围没划界、角色和约束散落在聊天记录里。AI需求分析输入规范要解决的，就是把原始材料整理成一份结构固定、边界清楚的输入包，让分析有据可依、结果可以回检。本文给出可直接套用的字段表、六步操作流程、角色分工、填写示例和完成检查清单；输入包的存放与评审，可以借助ONES这类研发协作平台承载。
要点总览（TL;DR）
- 输入包固定六组字段：目标与范围、来源与背景、角色与对象、约束与假设、术语与参考、输出与验收；必填项缺失时不交付AI。
- 执行按收集、清洗、结构化、评审、交付AI、回检六步走，每步有输入、动作、输出和完成标志。
- 需求负责人主笔，业务方确认目标范围与术语，技术负责人核对约束与假设，评审组织者维护版本留痕。
- 交付前用六项检查清单逐项判断，范围、约束、验收口径三项不建议删减。
- 输入包作为需求工作项的附件或关联文档存放，按草稿到已回检的状态流转，交接边界写清楚。
一份合格的AI需求分析输入包包含哪些字段
输入包是交给AI做需求分析的全部材料集合，字段固定下来，不同人写出来的输入才有可比性。建议按下面六组字段组织，每组都写明填写要求和是否必填。
| 字段组 | 字段名 | 填写要求 | 示例 | 是否必填 |
|---|---|---|---|---|
| 目标与范围 | 分析目标 | 一句话说明本次要AI产出什么，如澄清问题清单、需求拆解建议、PRD质量检查意见 | 对“订单批量导出”需求做澄清，输出待确认问题清单 | 必填 |
| 目标与范围 | 范围边界 | 写明涉及的业务模块、用户群体、时间窗口，以及明确不纳入的内容 | 仅限B端订单管理模块，不含财务对账 | 必填 |
| 来源与背景 | 需求来源 | 说明需求由谁提出、来自什么渠道（客户反馈、运营诉求、合规要求等） | 来自3家KA客户的工单汇总 | 必填 |
| 来源与背景 | 业务背景与目标 | 交代当前业务现状、要解决的问题、期望达成的业务结果 | 大客户每月手工导出订单耗时约2人天，希望降到半天以内 | 必填 |
| 角色与对象 | 角色清单 | 列出涉及的用户角色及其职责、使用频率 | 订单管理员：每日导出；财务专员：月末核对 | 必填 |
| 角色与对象 | 业务对象与流程 | 描述核心业务对象（订单、客户、账单等）及关键流程步骤 | 订单生成→审核→导出→对账 | 必填 |
| 约束与假设 | 已知约束 | 技术、合规、时间、预算等硬性限制，注明来源 | 导出文件需符合财务归档格式要求（来源：财务部规范） | 必填 |
| 约束与假设 | 假设与待确认项 | 列出分析中依赖但尚未证实的判断，标注待谁确认 | 假设单次导出上限为1万条，待技术负责人确认 | 必填 |
| 术语与参考 | 术语表 | 统一业务术语与缩写，避免AI按通用含义理解 | “大客户”指年订单额≥500万的客户 | 必填 |
| 术语与参考 | 参考材料 | 附上相关文档、历史需求、竞品说明等，标注版本 | 《订单管理操作手册v2.3》 | 选填 |
| 输出与验收 | 期望输出形态 | 说明输出格式，如问题清单、结构化需求条目、检查表 | 按“问题—影响—建议确认人”三列输出 | 必填 |
| 输出与验收 | 验收口径 | 写明判断输出合格的标准，如覆盖全部角色、每个问题可追溯到来源 | 问题清单需覆盖3类角色，每条问题注明来源材料 | 必填 |
字段不必一次写满，但必填项缺失时不要交付AI。选填的参考材料按相关性取舍，堆得越多，AI越容易被无关内容带偏。
从原始材料到输入包的六步操作流程
规范落地时按“收集—清洗—结构化—评审—交付—回检”六步执行，每步都有明确的输入、动作、输出和完成标志，避免流程停在纸面。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集 | 工单、访谈记录、会议纪要、历史需求文档 | 按需求来源和范围圈定材料清单，逐项收集并登记来源 | 原始材料清单 | 清单内材料齐全，每份标注来源与日期 |
| 2. 清洗 | 原始材料清单 | 去重、剔除与本次分析无关的内容，合并同一诉求的不同表述 | 清洗后的材料集 | 无重复条目，无关内容已移出并记录原因 |
| 3. 结构化 | 清洗后的材料集 | 按字段表逐项填写输入包，缺失项标注“待补充” | 输入包初稿 | 必填字段全部有内容或明确标注待补充 |
| 4. 评审 | 输入包初稿 | 组织业务方、技术负责人评审，确认范围、约束与术语 | 评审通过的输入包 | 评审意见已处理，范围与约束获得确认 |
| 5. 交付AI | 评审通过的输入包 | 提交AI分析，记录提问、补充材料和调整过程 | AI输出与交互记录 | 交互记录完整，补充材料已回填输入包 |
| 6. 回检 | AI输出与输入包 | 逐条核对输出是否落在范围内、是否引用输入中的事实 | 回检结论 | 输出与输入一致，偏差项已标注并处理 |
第5步的交互记录值得保留：AI提出的追问往往暴露输入包的缺口，把这些追问和补充材料回填到输入包，下一轮分析的质量会明显提升。第6步的回检重点看两类偏差，一是输出超出范围边界，二是结论找不到输入依据，两类都要退回修改而不是直接采用。
角色分工与各环节交付物
输入规范要真正执行，需要把主笔、确认、核对三类责任落到具体角色上。以下分工适用于多数研发团队，团队规模较小时可由一人兼任多个角色，但确认动作建议保留独立人员。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 需求负责人 | 主笔输入包，组织收集与清洗，跟进评审意见处理 | 输入包初稿、评审记录、最终版输入包 |
| 业务方 | 确认分析目标、范围边界、角色与术语定义 | 范围确认意见、术语确认记录 |
| 技术负责人 | 核对技术约束、依赖关系与假设的合理性 | 约束核对意见、待确认项处理结论 |
| 评审组织者（可由需求负责人兼任） | 发起评审、汇总意见、维护版本留痕 | 评审纪要、版本变更记录 |
版本留痕是容易被忽略的一环。输入包每次修改都应记录改了什么、为什么改、谁确认，否则回检时无法判断AI输出对应的是哪一版输入。评审记录与输入包放在一起管理，交接时一并移交。
示例：一条业务需求的输入包怎么写
以下示例为演示情景，用于说明字段如何落地，读者可按自身业务改写。
示例背景与目标：某B端产品的订单管理模块收到多家客户反馈，批量导出订单操作繁琐。本次分析目标是产出澄清问题清单，为后续需求评审做准备；范围限定在订单导出功能，不含对账与结算。
输入包片段：
- 需求来源：近三个月12条客户工单，集中在导出字段不全、操作步骤多两类问题。
- 业务目标：将单次批量导出的操作步骤从7步压缩到3步以内。
- 角色清单：订单管理员（每日使用）、财务专员（月末使用）、客户成功经理（按需协助客户）。
- 业务对象与流程：订单→导出任务→导出文件，流程为筛选订单、选择字段、生成文件、下载。
- 已知约束：导出文件格式需符合财务归档要求（来源：财务部规范v1.2）；导出操作需保留审计日志（来源：合规要求）。
- 假设与待确认项：假设单次导出上限为1万条，待技术负责人确认；假设财务专员不参与日常导出，待业务方确认。
- 术语表：“批量导出”指一次选择多条订单生成文件；“导出模板”指预设的字段组合。
- 期望输出：按“问题—影响角色—建议确认人”三列输出澄清问题清单。
- 验收口径：覆盖全部3类角色，每条问题注明来源材料，不提出范围外的对账相关问题。
交付AI后的追问与补充：AI追问“导出模板是否允许用户自定义字段顺序”，输入包中未涉及，需求负责人补充“模板字段顺序固定，本期不支持自定义”并回填。另一追问涉及导出文件的历史保留期限，转交技术负责人确认后补入约束字段。
输出回检结论：AI输出的问题清单共14条，覆盖3类角色，其中2条涉及对账范围，按验收口径剔除；其余12条均可追溯到输入材料，回检通过，进入需求评审环节。
输入包评审与完成检查清单
输入包是否可以交给AI，用下面这份清单逐项判断。任一项不通过，先补齐再交付。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 范围与目标是否明确 | 分析目标一句话可读，范围边界写明纳入与排除内容 | 需求负责人 |
| 角色与业务对象是否齐全 | 涉及角色全部列出并说明职责，核心业务对象与流程有描述 | 需求负责人、业务方 |
| 约束与假设是否标注来源 | 每条约束注明来源，每条假设标注待确认人和确认状态 | 技术负责人 |
| 术语是否统一 | 业务术语与缩写在术语表中定义，全文用法一致 | 业务方 |
| 输出形态与验收口径是否写明 | 输出格式具体到结构，验收标准可逐条判断 | 需求负责人 |
| 版本与评审记录是否留存 | 有版本号、变更记录和评审纪要，可追溯到确认人 | 评审组织者 |
清单建议随输入包一起归档，评审时逐项打勾，回检时对照使用。检查项可以根据团队实际增补，但范围、约束、验收口径三项不建议删减，它们直接决定AI输出能否被采用。
把输入规范接入研发协作流程
输入包写完后需要有固定的存放位置和流转方式，否则容易散落在个人文档里，评审和交接都无从谈起。常见做法是把输入包作为需求工作项的附件或关联文档，与需求条目放在同一处管理，评审意见和版本记录也留在同一上下文中。
流转上可以按“草稿—评审中—已确认—已交付AI—已回检”设置状态，每次状态变更对应一次评审或交付动作，状态记录本身就是交接凭据。ONES 支持围绕项目、工作项和 Wiki 页面组织研发协作内容，输入包可以作为工作项附件或 Wiki 文档存放，评审意见与状态流转在同一平台内留痕；ONES Assistant 智能助手能够理解项目、工作项和 Wiki 页面等工作上下文，围绕需求澄清提炼要点、待澄清问题与拆解建议，适合承接输入包交付后的分析环节。具体可用范围以团队实际开通情况为准。
交接边界要写清楚：输入包确认后，后续的需求澄清、文档成稿由对应环节接手，输入包本身不再随意改动；如需修改，走版本变更并重新回检。这样输入规范既支撑了AI分析的质量，也不会与下游的需求管理和文档工作相互纠缠。
常见问题
团队规模小、没人专职做需求分析，输入规范还能执行吗？
可以执行，但要把主笔和确认分开。小团队里需求负责人可以同时承担评审组织者的工作，业务方和技术负责人的确认动作建议保留独立人员，哪怕只是口头确认后由需求负责人记录。字段表也不必一次全填，先保证分析目标、范围边界、角色清单、已知约束和验收口径五项有内容，其余字段随需求复杂度逐步补齐。规范的价值在于每次交付AI前都过一遍同样的检查，而不是配齐一套完整岗位。
AI追问的问题输入包里没有，应该当场补还是先记录？
看问题性质。涉及范围边界、角色定义、验收口径的追问，应当暂停分析，补齐并确认后再继续，否则输出会偏离目标。涉及实现细节、历史数据口径的追问，可以先记录在交互记录里，标注待确认人，继续完成其余部分的分析，回填后重新回检相关条目。无论哪种，追问和补充材料都要回填到输入包，否则下一轮分析会重复暴露同一个缺口。
输入包评审通过后，业务方又提出范围变更怎么办？
走版本变更，不直接改当前版本。记录变更内容、提出人、影响范围，重新确认范围边界和验收口径，必要时重新组织一次简短评审。已经交付AI并回检过的输出，要标注对应的是哪一版输入，避免后续引用时混淆。变更频繁时，可以先把变更项集中记录，按周合并处理，减少反复评审的成本。
输入包和后续的需求澄清、文档成稿怎么划边界？
输入包负责把材料整理成AI可用的结构化输入，产出的是澄清问题清单、拆解建议这类中间结果；需求澄清负责与业务方逐条确认这些问题并形成结论；文档成稿负责把结论写成正式文档。输入包确认后不再随意改动，下游环节需要补充信息时，通过版本变更回写。边界写清楚，可以避免同一份材料在多个环节反复修改、版本对不上。
输入包放在协作平台里，需要保留哪些记录？
至少保留四类：输入包各版本及其变更说明、评审纪要与确认人、交付AI时的交互记录与补充材料、回检结论与偏差处理结果。这些记录和需求工作项放在同一上下文中，交接时一并移交。ONES 支持围绕项目、工作项和 Wiki 页面组织研发协作内容，输入包可以作为工作项附件或 Wiki 文档存放，评审意见与状态流转在同一平台内留痕；ONES Assistant 智能助手能够理解项目、工作项和 Wiki 页面等工作上下文，围绕需求澄清提炼要点、待澄清问题与拆解建议。具体可用范围以团队实际开通情况为准。
