功能需求澄清要把一句“需要支持某功能”拆成可核对的确认要素：触发条件说明功能在什么事件、状态或时间点被激活；输入输出说明数据来源、字段、格式和去向；业务规则与异常边界说明判断逻辑、优先级和失败处理；验收口径说明用什么场景、数据和结果判定完成。澄清的产出是一份双方确认的要素清单，可以直接交给研发和测试使用。
要点总览（TL;DR）
- 功能需求澄清要确认五类要素：触发条件、输入输出、业务规则与异常边界、验收口径，以及各要素的确认人与记录。
- 触发条件要落到触发源、前置状态、前置数据条件、频率与并发、不触发情形，用确认表逐项留痕。
- 输入输出要确认到字段级：来源、类型、必填性、取值范围、默认值、输出形态与接收方，以及缺失或格式不符时的处理。
- 业务规则要写清判断条件、计算方式、优先级和生效范围；异常边界要覆盖数据为空、超限、重复提交、并发冲突、权限不足和外部依赖不可用。
- 澄清完成的判断标准是五类要素均有确认记录、待定项已关闭或有责任人和关闭时间、验收场景能对应到确认要素，且研发和测试可直接使用。
先确认触发条件：功能在什么情况下被激活
触发条件回答的是“这个功能什么时候开始工作”。需求描述里常见的“系统自动处理”“用户可发起”都过于笼统，澄清时要落到具体的触发源和前置状态，让研发能判断代码在哪里介入、测试能构造出激活场景。
确认时按触发类型逐项过一遍，避免遗漏：
- 用户操作：点击按钮、提交表单、扫码、拖拽等具体动作，需明确入口位置和操作对象。
- 系统事件：订单创建成功、审批通过、库存低于阈值等内部事件，需说明事件由哪个模块发出。
- 定时任务：每日几点执行、每隔多久轮询，需说明时区、错过执行窗口时的补偿方式。
- 状态变化：单据从“待处理”变为“已确认”时触发，需列出状态流转的起点和终点。
- 外部接口回调：第三方支付结果、物流签收回传等，需说明回调来源、验签方式和重试约定。
触发类型确定后，继续确认前置状态与前置数据条件。例如“仅当合同处于生效状态且已上传附件时才允许发起结算”，这类条件要写成可判断的表达式，而不是“满足条件时”。同时记录触发频率与并发情形：单次操作、批量导入、高峰期多人同时提交，处理方式可能不同。不触发的情形同样要写清楚，比如“草稿状态不触发通知”“同一单据24小时内不重复触发”，抑制条件往往比触发条件更容易在开发阶段被忽略。
建议用一张触发条件确认表逐项留痕：
| 触发源 | 前置状态 | 前置数据条件 | 频率/并发 | 不触发情形 | 确认人 |
|---|---|---|---|---|---|
| 用户点击“提交结算” | 合同为生效状态 | 已上传结算附件且金额大于0 | 单次提交，允许重复提交需拦截 | 草稿状态、金额为0 | 需求提出方、产品 |
| 每日02:00定时任务 | 存在待同步单据 | 单据更新时间在昨日范围内 | 每日一次，失败后次日补偿 | 无待同步单据 | 产品、研发 |
这张表填完并由需求提出方确认，触发条件才算澄清到位。完成标志是：每个触发源都能对应到一个可观察的事件或时间点，前置条件可以用数据字段判断，不触发情形有明确列举。
输入输出怎么确认：字段、来源、格式与去向
输入输出的澄清要落到字段级。只写“读取订单信息、生成结算单”无法支撑开发和测试，需要说明每个字段从哪来、长什么样、到哪里去。
输入侧先确认来源类型：人工录入、系统带入、接口传入、文件导入。不同来源对应不同的校验责任，人工录入需要前端校验和提示，接口传入需要约定字段映射和失败处理，文件导入需要说明模板格式、编码和行数上限。随后逐个字段确认名称、类型、必填性、取值范围和默认值。例如“结算金额”是数值型、必填、保留两位小数、默认取合同金额，这类定义要写进清单，而不是留给研发猜测。
输出侧确认形态和接收方：页面展示、消息通知、文件导出、接口返回、状态变更。每种形态都要说明接收方和后续使用方式——导出的文件给财务对账，接口返回给下游系统入库，状态变更触发后续流程。输出格式同样要约定，包括字段顺序、日期格式、金额精度、空值表示方式。
输入缺失或格式不符时的处理也要在澄清阶段定下来：是阻断提交并提示具体字段，还是允许保存草稿、标记待补，或者用默认值兜底。不同选择影响交互设计和测试用例，必须由需求提出方确认。
| 字段 | 来源 | 类型 | 必填 | 格式/范围 | 输出去向 |
|---|---|---|---|---|---|
| 结算单号 | 系统生成 | 字符串 | 是 | 前缀JS+日期+4位流水 | 页面展示、导出文件 |
| 结算金额 | 人工录入 | 数值 | 是 | 大于0，两位小数 | 页面展示、接口返回财务系统 |
| 附件 | 文件导入 | 文件 | 是 | PDF，单个不超过10MB | 归档至文档库 |
字段清单完成后，请研发确认技术可行性、测试确认可验证性，输入输出部分即可关闭。
业务规则与异常边界：把判断逻辑和失败情形说清
业务规则是功能内部的判断逻辑，异常边界是规则遇到意外输入时的表现。两者在澄清阶段经常被一句“按业务规则处理”带过，结果在开发中反复返工。
业务规则要确认四件事：判断条件、计算方式、优先级、生效范围与生效时间。判断条件写成可执行的表达式，例如“客户等级为A且账期超过30天时进入人工审核”；计算方式说明公式、取整规则和精度；优先级说明多条规则同时命中时谁先执行；生效范围与生效时间说明规则适用于哪些组织、品类或时间段，以及规则变更后历史数据是否重算。
规则冲突时的处理顺序要单独确认。例如折扣规则与满减规则同时满足，是叠加、取最优还是按配置顺序执行，这类问题在澄清阶段定下来，可以避免上线后对账争议。
异常边界按情形逐条过：
- 数据为空：必填字段为空、关联对象已被删除时，阻断还是降级处理。
- 超限：金额超过上限、附件超过大小、批量条数超过阈值时的提示和截断方式。
- 重复提交：同一请求短时间多次到达，是幂等返回还是报错提示。
- 并发冲突：两人同时编辑同一单据，后提交者覆盖、锁定还是合并。
- 权限不足：无权限用户触发操作时，隐藏入口还是提示无权限。
- 外部依赖不可用：支付、物流、短信等第三方超时或报错时，重试次数、回退状态和人工介入入口。
每条异常都要写明提示文案方向、数据回退方式和人工介入路径。规则与异常边界的确认人和变更记录一并登记，后续规则调整时能追溯是谁在什么时间确认了哪一版。
| 规则/异常 | 判断条件 | 优先级 | 处理方式 | 确认人 |
|---|---|---|---|---|
| 大额结算审核 | 金额≥50万 | 高于自动通过规则 | 进入人工审核队列 | 财务负责人 |
| 重复提交 | 同一单号5分钟内再次提交 | — | 幂等返回首次结果，不重复生成 | 产品、研发 |
| 支付回调超时 | 第三方30秒未响应 | — | 标记待确认，每10分钟重试，3次后转人工 | 产品、研发 |
验收口径怎么写：场景、数据与判定结果
验收口径把前面确认的要素转成可执行的验证场景。写法上，每个场景包含输入数据、操作步骤和预期结果，预期结果要可观察、可对比、可复现。
场景来源覆盖三类：正常流程验证主路径；边界值验证临界条件，如金额刚好等于上限、附件刚好达到大小限制；异常路径验证前面确认的失败情形。每个场景标注它对应哪条触发条件、哪个字段或哪条业务规则，保证验收覆盖不是凭感觉挑选。
判定标准要具体到可对比的程度。“页面提示成功”不如“页面显示结算单号且状态为已提交，导出文件中金额与录入一致”。“系统正常处理”不如“5分钟内生成结算单，接口返回状态码200且下游系统可查询到该单”。涉及计算的场景，给出输入数据和期望计算结果，测试人员可以直接核对。
| 场景 | 输入数据 | 操作步骤 | 预期结果 | 对应确认要素 |
|---|---|---|---|---|
| 正常提交结算 | 生效合同，金额10万，附PDF附件 | 点击提交结算 | 生成结算单号，状态为已提交，导出金额10.00 | 触发条件-用户操作；输入输出-结算金额 |
| 金额等于上限 | 金额50万 | 提交结算 | 进入人工审核队列，页面提示待审核 | 业务规则-大额审核 |
| 重复提交 | 同一单号5分钟内提交两次 | 连续点击提交 | 仅生成一张结算单，第二次返回首次结果 | 异常边界-重复提交 |
澄清阶段无法确定的场景记为待定项，写明待定原因、影响范围和责任人，不要用模糊表述掩盖。验收口径表完成后，测试人员应能据此直接编写用例，不需要再回头询问需求含义。
角色分工与澄清交付物
澄清不是产品经理一个人的工作，各角色在不同要素上有确认责任。分工清楚，确认结果才有归属。
| 角色 | 主要职责 | 确认的要素 |
|---|---|---|
| 需求提出方 | 说明业务目标、触发场景与验收期望 | 触发条件、业务规则、验收期望 |
| 产品/需求分析人员 | 组织澄清会议、记录要素、维护待定项 | 全部要素的记录完整性 |
| 研发 | 确认输入输出可行性、异常边界可实现性 | 输入输出字段、异常处理方式 |
| 测试 | 确认验收场景可测、判定标准可复现 | 验收口径 |
澄清交付物包括三样：要素确认清单（触发条件表、输入输出字段清单、业务规则与异常边界清单、验收口径表）、待定项列表、确认记录。待定项列表要写明每条待定的内容、责任人、关闭条件和计划关闭时间；确认记录保留谁在什么时间确认了哪一版要素，后续需求变更时作为对照基线。
这些记录需要在工作项和文档中留痕并随需求流转。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，业务、产品经理与研发三个视角可以围绕同一需求同步状态与信息；澄清记录、待定项和验收口径可以挂在对应需求下，研发通过任务和工单承接开发测试，形成需求—任务—测试—缺陷的闭环。ONES Assistant 在需求澄清场景中可提炼要点、待澄清问题与拆解建议，帮助团队更快整理澄清输入，具体能力范围以实际产品配置为准。
示例：一条功能需求的澄清记录
以下为演示情景，用于说明五类要素如何落到同一份记录中，非真实项目案例。
原始需求描述：“合同管理系统需要支持结算单自动生成，方便财务对账。”
这句话无法直接开发。按要素逐项澄清后得到如下记录：
- 触发条件：用户点击“生成结算单”按钮触发；前置状态为合同生效且已上传结算附件；前置数据条件为结算金额大于0；同一合同24小时内不重复生成；草稿状态和金额为0时不触发。
- 输入输出：输入包括合同编号（系统带入）、结算金额（人工录入，数值，必填，大于0，两位小数）、附件（文件导入，PDF，不超过10MB）；输出为结算单页面展示、导出Excel文件给财务、接口返回结算单号给下游系统；金额为空时阻断提交并提示具体字段。
- 业务规则：金额≥50万进入人工审核，优先级高于自动通过；结算金额按合同金额减去已结算金额计算，保留两位小数；规则适用于全部合同类型，变更后历史单据不重算。
- 异常边界：重复提交幂等返回首次结果；两人同时编辑同一合同，后提交者提示“数据已更新，请刷新”；下游接口超时标记待确认并重试3次，仍失败转人工处理。
- 验收口径：正常提交生成结算单且导出金额一致；金额等于50万进入审核队列；5分钟内重复提交仅生成一张单；接口超时后单据状态为待确认。
这份记录在澄清过程中暴露了两个待定项：一是“已结算金额”的数据来源尚未确认由哪个系统提供，二是历史单据是否需要按新规则重算，需求提出方尚未答复。两项均登记责任人和关闭时间，在开发启动前关闭。这个例子说明，澄清记录的价值在于把模糊描述变成可判断、可测试的条目，同时把不确定的部分显性化。
完成检查：澄清可以结束的判断标准
澄清结束前逐项核对以下标准，全部满足才进入后续环节：
- 五类要素均有确认记录：触发条件、输入输出、业务规则、异常边界、验收口径各自有对应的表格或清单，且每项标注了确认人。
- 待定项已关闭或有明确安排：每条待定项要么已关闭，要么有责任人和关闭时间，且关闭时间不晚于开发启动。
- 验收场景可对应到确认要素：每个验收场景能指出它验证的是哪条触发条件、哪个字段或哪条规则，没有孤立场景。
- 相关角色已确认并留痕：需求提出方、产品、研发、测试对各自负责的要素完成确认，确认记录可追溯。
- 记录可直接使用：研发能据此判断实现位置和边界，测试能据此编写用例，不需要再回头询问需求含义。
检查中发现某类要素缺失或只有笼统描述，回到对应章节补充确认，不要带着空白进入开发。澄清记录随需求一起流转，后续需求变更时以它为基线更新，变更内容同样登记确认人和时间。
常见问题
澄清会上需求提出方说“按业务规则处理”，这种情况怎么继续推进？
把“按业务规则处理”拆成四个可回答的问题，逐个请需求提出方确认：判断条件是什么、怎么计算、多条规则同时命中时谁优先、规则适用于哪些范围和时间段。每个问题都要求给出可以用数据字段判断的表述，例如“客户等级为A且账期超过30天时进入人工审核”。如果对方当场答不上来，记为待定项，写明责任人、关闭条件和关闭时间，不要用笼统描述先占位。
验收口径由谁写、由谁确认？测试人员能否直接参与澄清？
验收口径通常由产品/需求分析人员起草，测试人员负责确认可测性和判定标准可复现，需求提出方确认验收期望。测试人员越早参与澄清越好：在确认触发条件和异常边界时，测试就能判断哪些场景需要构造数据、哪些判定标准无法观察，从而在开发前把不可测的表述改掉。验收口径表完成后，测试应能据此直接编写用例，不需要再回头询问需求含义。
澄清过程中发现的待定项，应该在开发启动前全部关闭吗？
原则上待定项的关闭时间不应晚于开发启动。确实无法在开发前确定的，要评估它影响的是哪个要素：如果影响触发条件或输入输出字段，通常需要先关闭再开发；如果只影响个别边界场景的提示文案，可以带着明确的关闭时间和责任人进入开发，并在对应场景的验收前关闭。无论哪种情况，待定项都要登记内容、责任人、关闭条件和计划关闭时间，避免在开发中口头消化。
需求澄清记录和需求文档是什么关系，需要重复维护吗？
澄清记录是需求文档的输入和对照基线，两者承担不同作用。澄清记录按触发条件、输入输出、业务规则与异常边界、验收口径逐项记录确认结果和确认人，重点在“确认过什么、谁确认的”；需求文档则是对需求的完整表述。实践中可以把澄清记录作为需求文档的附件或关联页面，需求变更时以澄清记录为基线更新，并登记变更内容和确认时间，避免两处各写一版、互相矛盾。
澄清记录需要在工具里留痕吗，用文档记录够不够？
用文档记录要素清单是可行的起点，关键要求是记录能随需求流转、可追溯到确认人和确认时间。当需求数量多、跨角色协作频繁时，把澄清记录挂在对应需求下、待定项作为独立条目跟踪，能减少信息散落。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，澄清记录、待定项和验收口径可以挂在对应需求下，研发通过任务和工单承接开发测试；ONES Assistant 在需求澄清场景中可提炼要点、待澄清问题与拆解建议，具体能力范围以实际产品配置为准。
