业务需求澄清要问得全、记得准、收得住，可以准备三份配套材料：访谈提纲负责把目标、范围、规则、约束、边界五类信息问出来；访谈记录模板逐条保留受访人原话、澄清结论和待确认项；澄清检查清单在访谈后核对信息是否闭合。下面给出可直接复制填写的空白表格、字段填写口径、必填与选填规则、一份完整示例，以及按项目裁剪和维护模板的方法。
要点总览（TL;DR）
- 业务需求澄清可配套三份材料：访谈提纲负责问全目标、范围、规则、约束、边界五类信息，记录表负责保留原话与待确认项，检查清单负责判定信息是否闭合。
- 访谈记录中，编号、需求编号、受访角色、原话摘录、澄清结论、责任人为必填；填写待确认项时，责任人与截止时间同时转为必填。
- 检查清单只有满足判定标准才勾选闭合，部分满足按未闭合处理；未闭合项须指定负责人和截止时间，不直接进入需求评审。
- 模板可按需求类型裁剪板块、按访谈轮次续编记录编号，并通过版本号、字段变更和历史记录处理规则保持长期可追溯。
可复制空白模板：访谈提纲、记录表与检查清单
三份表格分别承担提问、留痕和验收。建议先复制访谈提纲，在访谈前按需求类型删减或补充问题；访谈中同步填写记录表；访谈结束后用检查清单逐项判定，未闭合项转入待确认跟踪。
表1 业务需求澄清访谈提纲（空白）
| 板块 | 编号 | 主问题 | 追问方向 | 期望获取的信息类型 |
|---|---|---|---|---|
| 目标 | Q1 | 这项业务需求希望解决什么问题？ | 问题出现的频率、影响的人群、当前的处理方式 | 业务问题描述、期望结果 |
| 目标 | Q2 | 需求完成后，用什么指标判断它达到了预期？ | 指标口径、统计周期、当前基线值 | 成功标准、衡量口径 |
| 范围 | Q3 | 这次要覆盖哪些业务环节、角色和地区？ | 起止环节、涉及岗位、是否含上下游 | 范围清单、涉及对象 |
| 范围 | Q4 | 哪些内容明确放在本次范围之外？ | 后续计划、替代处理方式 | 排除项、边界说明 |
| 规则 | Q5 | 业务处理需要遵循哪些规则和审批要求？ | 规则来源、例外情形、审批层级 | 业务规则、审批链 |
| 规则 | Q6 | 数据口径和计算方式以哪份文件为准？ | 口径版本、争议处理方式 | 数据定义、口径依据 |
| 约束 | Q7 | 时间、预算、合规或系统方面有哪些硬性限制？ | 截止时间来源、必须满足的条款 | 约束条件、限制原因 |
| 约束 | Q8 | 依赖哪些外部团队、系统或供应商？ | 依赖交付时间、对接人 | 依赖清单、风险点 |
| 边界 | Q9 | 哪些情况属于本次不处理、由其他流程承接？ | 承接方、交接方式 | 职责边界、交接约定 |
| 边界 | Q10 | 需求变更时由谁判断、按什么流程处理？ | 变更触发条件、决策人 | 变更边界、决策机制 |
表2 业务需求澄清访谈记录（空白）
| 编号 | 需求编号 | 受访角色 | 原话摘录 | 澄清结论 | 假设与待确认项 | 责任人 | 截止时间 |
|---|---|---|---|---|---|---|---|
| R1 | |||||||
| R2 | |||||||
| R3 | |||||||
| R4 | |||||||
| R5 |
表3 业务需求澄清检查清单（空白）
| 检查项 | 对应板块 | 判定标准 | 是否闭合 | 证据位置 | 负责人 |
|---|---|---|---|---|---|
| 业务问题与期望结果已明确 | 目标 | 能用一句话描述问题及期望变化 | □是 □否 | ||
| 成功标准有口径和基线 | 目标 | 指标、周期、基线值三项齐全 | □是 □否 | ||
| 覆盖范围已列清单 | 范围 | 环节、角色、地区均有明确列举 | □是 □否 | ||
| 排除项已确认 | 范围 | 至少列出一项明确不做内容 | □是 □否 | ||
| 业务规则与审批要求已记录 | 规则 | 规则来源和例外情形可追溯 | □是 □否 | ||
| 数据口径有依据文件 | 规则 | 口径版本和依据文件已注明 | □是 □否 | ||
| 硬性约束已识别 | 约束 | 时间、预算、合规、系统限制均有记录 | □是 □否 | ||
| 外部依赖已登记 | 约束 | 依赖方、交付时间、对接人齐全 | □是 □否 | ||
| 职责边界已划清 | 边界 | 不处理事项有承接方和交接方式 | □是 □否 | ||
| 变更处理机制已确认 | 边界 | 决策人和触发条件明确 | □是 □否 |
字段说明：每个字段记录什么、怎么填
三份表格的字段在空白表、说明和示例中保持同名同义。填写时把握一个原则：提纲字段服务于“问什么”，记录字段服务于“留下了什么证据”，清单字段服务于“能否判定闭合”。
访谈提纲字段
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 板块 | 问题所属的信息类别 | 固定使用目标、范围、规则、约束、边界五类，便于与检查清单对应 |
| 编号 | 问题在提纲中的唯一标识 | 按板块首字母或顺序编号，记录表中引用同一编号 |
| 主问题 | 一次访谈必须问到的核心问题 | 用一句完整问句表达，指向一个信息类型，避免一题多问 |
| 追问方向 | 主问题回答不充分时的深入路径 | 列出2至4个具体追问点，如频率、影响人群、当前处理方式 |
| 期望获取的信息类型 | 该问题应产出的信息形态 | 写清是清单、口径、规则还是约束条件，方便判断回答是否到位 |
访谈记录字段
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 编号 | 记录条目的序号 | 与提纲问题编号建立对应关系，可一题多条 |
| 需求编号 | 本条记录所属的需求标识 | 沿用需求池或需求单中的编号，保证可回溯 |
| 受访角色 | 提供信息的人员岗位 | 记录角色而非仅记姓名，便于判断信息权威性 |
| 原话摘录 | 受访人对问题的原始表述 | 尽量保留原词，尤其是业务术语和数量表述，不做概括改写 |
| 澄清结论 | 访谈双方确认后的理解 | 只写已确认内容；存在分歧时写明分歧点，不写成结论 |
| 假设与待确认项 | 尚未证实的前提和未解决的问题 | 每条待确认项单独一行，写明需要谁确认、确认什么 |
| 责任人 | 负责跟进该待确认项的人 | 填写具体角色或姓名，避免写“相关同事” |
| 截止时间 | 待确认项的解决期限 | 写具体日期，与需求计划节点对齐 |
检查清单字段
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 检查项 | 需要核对的信息点 | 一项只检查一个信息点，表述为可判断真假的陈述 |
| 对应板块 | 检查项归属的信息类别 | 与提纲板块一致，确保五类信息都有检查项覆盖 |
| 判定标准 | 判定闭合的具体条件 | 写清需要哪些要素齐全，如“指标、周期、基线值三项齐全” |
| 是否闭合 | 检查结果 | 只有满足判定标准才勾选“是”，部分满足按“否”处理 |
| 证据位置 | 支撑判定的记录出处 | 填写记录表编号或文档章节，便于复核 |
| 负责人 | 对该检查项负责的人 | 未闭合项必须指定负责人并同步截止时间 |
必填与选填：哪些字段不能空
必填字段决定这份记录能否作为后续设计、评审和验收的依据。选填字段用于补充背景，缺失不影响澄清结论成立。团队可以在模板说明中固定这份清单，避免每次访谈凭经验判断。
| 表格 | 必填字段 | 选填字段 | 说明 |
|---|---|---|---|
| 访谈提纲 | 板块、编号、主问题 | 追问方向、期望获取的信息类型 | 主问题缺失会导致信息类别漏问；追问方向可随受访人熟悉程度现场取舍 |
| 访谈记录 | 编号、需求编号、受访角色、原话摘录、澄清结论、责任人 | 假设与待确认项、截止时间 | 无待确认项时后两列可空；一旦填写待确认项，责任人和截止时间同时转为必填 |
| 检查清单 | 检查项、判定标准、是否闭合、负责人 | 证据位置 | 证据位置在记录表可定位时建议填写，用于复核和交接 |
必填项空缺时按以下方式处理：
- 访谈现场无法获得的必填信息，在记录表中标注“待补充”，并立即指定责任人和截止时间，不留下无主的空行。
- 澄清结论无法达成一致时，记录双方各自表述，将条目状态标为“存在分歧”，提交给需求提出方或业务负责人裁决。
- 检查清单中判定为“否”的条目，不得直接进入需求评审，需先补齐信息或将未闭合项作为风险显式列出。
- 同一需求连续两轮访谈仍有必填项空缺时，升级至需求负责人，由其决定补充访谈、缩小范围还是暂缓推进。
填写示例：一次完整的业务需求澄清记录
以下为演示情景，用于说明三份模板如何配合使用，人物和业务内容均为虚构。背景：某零售企业计划优化门店补货申请流程，业务方为区域运营主管，访谈时长约一小时，访谈人为需求分析人员。
示例背景与受访角色
需求编号REQ-0142，主题为“门店补货申请流程优化”。受访角色为区域运营主管，另有门店店长在第二轮访谈中补充一线操作细节。本次为第一轮访谈，重点确认目标、范围和主要规则。
按提纲提问得到的记录
| 编号 | 需求编号 | 受访角色 | 原话摘录 | 澄清结论 | 假设与待确认项 | 责任人 | 截止时间 |
|---|---|---|---|---|---|---|---|
| R1（对应Q1） | REQ-0142 | 区域运营主管 | “门店现在补货靠微信群报数，经常漏单，店长也不知道申请到哪一步了。” | 当前补货申请通过即时通讯群提交，缺少统一入口和状态反馈，漏单和进度不透明是主要问题 | 待确认漏单发生频率及影响门店数量 | 需求分析人员 | 3月12日 |
| R2（对应Q2） | REQ-0142 | 区域运营主管 | “希望补货申请当天能被仓库看到，漏单率降下来。” | 成功标准初步定为申请当日送达仓库、漏单率下降；具体指标口径待定 | 漏单率当前基线值和统计周期需运营数据支持 | 区域运营主管 | 3月15日 |
| R3（对应Q3） | REQ-0142 | 区域运营主管 | “先做华东区的直营门店，加盟店这次不动。” | 本次范围覆盖华东区直营门店的补货申请环节，加盟门店不纳入 | 华东区直营门店清单待运营提供 | 区域运营主管 | 3月14日 |
| R4（对应Q4） | REQ-0142 | 区域运营主管 | “退货和调拨还是走原来的流程，这次只管补货。” | 退货、调拨明确排除在本次范围之外，继续沿用现有流程 | 无 | — | — |
| R5（对应Q5） | REQ-0142 | 区域运营主管 | “单店单次超过五万元要区域经理审批，这个是财务定的。” | 补货申请金额超过五万元需区域经理审批，规则来源为财务制度 | 需取得财务制度文件编号作为规则依据 | 需求分析人员 | 3月13日 |
| R6（对应Q7） | REQ-0142 | 区域运营主管 | “六月底前要上线，赶在旺季之前。” | 上线时间约束为六月底，与旺季备货周期相关 | 需确认该时间是否可调整 | 需求负责人 | 3月18日 |
| R7（对应Q9） | REQ-0142 | 区域运营主管 | “仓库那边的入库流程不归我们管，你们得找仓储团队。” | 仓库入库环节由仓储团队承接，本次仅需明确交接接口 | 需与仓储团队确认交接方式和对接人 | 需求分析人员 | 3月20日 |
检查清单的闭合判定结果
| 检查项 | 对应板块 | 判定标准 | 是否闭合 | 证据位置 | 负责人 |
|---|---|---|---|---|---|
| 业务问题与期望结果已明确 | 目标 | 能用一句话描述问题及期望变化 | 是 | 记录R1 | 需求分析人员 |
| 成功标准有口径和基线 | 目标 | 指标、周期、基线值三项齐全 | 否 | 记录R2 | 区域运营主管 |
| 覆盖范围已列清单 | 范围 | 环节、角色、地区均有明确列举 | 否 | 记录R3 | 区域运营主管 |
| 排除项已确认 | 范围 | 至少列出一项明确不做内容 | 是 | 记录R4 | 需求分析人员 |
| 业务规则与审批要求已记录 | 规则 | 规则来源和例外情形可追溯 | 否 | 记录R5 | 需求分析人员 |
| 数据口径有依据文件 | 规则 | 口径版本和依据文件已注明 | 否 | 本轮未涉及 | 需求分析人员 |
| 硬性约束已识别 | 约束 | 时间、预算、合规、系统限制均有记录 | 是 | 记录R6 | 需求负责人 |
| 外部依赖已登记 | 约束 | 依赖方、交付时间、对接人齐全 | 否 | 记录R7 | 需求分析人员 |
| 职责边界已划清 | 边界 | 不处理事项有承接方和交接方式 | 否 | 记录R7 | 需求分析人员 |
| 变更处理机制已确认 | 边界 | 决策人和触发条件明确 | 否 | 本轮未涉及 | 需求负责人 |
示例中十项检查有四项闭合、六项未闭合。未闭合项均已在记录表中对应到责任人和截止时间，下一轮访谈可围绕成功标准口径、门店清单、财务制度依据、仓储交接和变更机制继续追问。记录中的待确认项需要持续跟踪，团队可以把每条待确认项建成协作工具中的工作项，与需求编号关联，并在文档中保留访谈记录原文。ONES Wiki 支持使用模板库一键创建制式化文档，页面组可关联项目，使需求与文档互相对应；成员可以在线添加注释和评论，页面版本可随时查看与回滚，适合承载访谈记录和检查清单的留痕。ONES Assistant 可围绕用户反馈洞察、PRD 质量检查等场景提炼要点和待澄清问题，在整理访谈材料时作为辅助手段，具体可用范围以实际启用情况为准。
调整与维护方法：按项目规模裁剪模板
模板的价值在于稳定复用，前提是能随项目变化调整。裁剪时保持五类信息不缺失，减少的是问题数量和记录粒度；维护时保持字段名称和判定标准一致，避免不同项目各用一套口径。
按需求类型裁剪提纲板块
- 流程优化类需求：保留全部五个板块，规则板块重点追问审批链和例外情形。
- 数据报表类需求：加强规则板块的数据口径问题，约束板块补充数据源可用性和更新频率。
- 小型内部工具需求：可合并目标与范围板块，各保留一个主问题，约束和边界板块不删减。
- 合规相关需求：约束板块增加法规条款来源和审计要求，边界板块明确合规审查的承接方。
多轮访谈时记录表的续填方式
- 每轮访谈使用同一需求编号，记录编号按轮次续编，如第一轮R1至R7，第二轮从R8开始。
- 上一轮未闭合的待确认项在新一轮访谈前整理成追问清单，访谈后在同一记录表中更新结论，保留原记录行不做覆盖。
- 受访角色变化时新增记录行，不合并不同角色的表述，便于区分信息权威性。
- 每轮结束后重新执行检查清单，记录闭合项数量的变化，作为是否可以进入评审的判断依据。
模板版本与字段变更的记录方法
| 维护动作 | 记录内容 | 示例 |
|---|---|---|
| 版本编号 | 模板名称、版本号、生效日期 | 需求澄清访谈模板 v1.2，2025年4月生效 |
| 字段变更 | 新增、删除或改名的字段及原因 | 记录表新增“假设与待确认项”，用于区分结论与推断 |
| 判定标准调整 | 检查项判定条件的变化 | 成功标准由“有指标”改为“指标、周期、基线值三项齐全” |
| 历史记录处理 | 旧版本记录的保留和对照方式 | 旧版本记录保留原字段，新访谈统一使用新版本 |
维护节奏上，建议每个季度或在完成若干次访谈后集中复盘一次：统计检查清单中反复未闭合的检查项，判断是提纲问题设计不足还是业务方信息确实缺失；对高频空缺的选填字段，评估是否转为必填或直接删除。模板版本变更后，在团队文档中保留变更记录，新项目直接引用最新版本，历史需求沿用其访谈时的版本，保证记录可追溯。
常见问题
访谈时受访人只能给出模糊回答，记录表该怎么填？
把模糊表述如实放入“原话摘录”，不要替受访人补全成结论。“澄清结论”只写双方已确认的内容；未确认的部分拆成具体待确认项，写明需要谁确认、确认什么，并指定责任人和截止时间。若同一问题追问后仍无法明确，将该条目标注为存在分歧，提交需求提出方或业务负责人裁决。
五万元审批这类业务规则，记录到哪一层才算够用？
规则记录需要能追溯到来源和例外。至少写清规则内容、规则来源（如财务制度文件编号）、适用条件和例外情形。仅有口头转述时，把“取得制度文件作为依据”列为待确认项，由责任人跟进；在依据补齐前，检查清单中对应项按未闭合处理。
多轮访谈后，旧记录中的结论被推翻，应该修改还是新增？
保留原记录行，新增一条记录写明新结论、变化原因和确认人，并在旧行标注被哪条记录更新。检查清单按最新一轮重新判定，闭合项数量变化作为能否进入评审的依据。这样既保留访谈过程，也避免历史信息被覆盖后无法追溯。
访谈记录和待确认项放在文档里，如何避免跟进遗漏？
访谈记录适合保留原话和结论，待确认项则需要逐条跟踪。可以把每条待确认项建成协作工具中的工作项，与需求编号关联，指定责任人和截止时间；文档侧保留记录原文和检查清单。ONES Wiki 支持使用模板库一键创建制式化文档，页面组可关联项目，使需求与文档互相对应；成员可以在线添加注释和评论，页面版本可随时查看与回滚，适合承载访谈记录与检查清单的留痕。ONES Assistant 可围绕用户反馈洞察、PRD 质量检查等场景提炼要点和待澄清问题，在整理访谈材料时作为辅助手段，具体可用范围以实际启用情况为准。
小型项目也要保留全部五个板块吗？
可以合并问题数量，五类信息不宜缺失。小型内部工具需求可将目标与范围各保留一个主问题，约束和边界板块保留原问题；合规相关需求反而要在约束板块增加法规条款来源和审计要求。裁剪后仍用同一份检查清单验收，确保目标、范围、规则、约束、边界都有对应检查项。
