本文用一条虚构的“订单取消”需求，完整演示用户故事与验收条件怎么写：先给出可直接参照的填写范例，再逐项解释角色、目标、价值、场景、前置条件、步骤和预期结果的填写理由，最后提炼可迁移到其他需求的步骤与自检清单。示例中的时限、退款比例等业务规则均为演示设定，落地时需按实际业务确认。
要点总览（TL;DR）
- 用一条虚构的“订单取消”需求做完整示范：用户故事写清角色、目标与价值，补充说明划定范围与假设，验收条件用场景式写法覆盖正常取消、超时不可取消、退款金额三类情况。
- 角色写到可识别的使用者（如“已下单但尚未收到货的买家”），目标写具体动作和关键信息，价值单独写业务收益，避免“用户”“提升体验”这类无法验收的表述。
- 验收条件从主流程出发推导分支与异常，每个场景按前置条件、操作步骤、预期结果三段组织，预期结果写成订单状态、页面文案等可观察事实。
- 迁移到其他需求可按四步执行：从业务事件定角色与目标、按主流程分支异常拆场景、用给定—当—那么组织、提交前按自检清单核对。
- 需求意图尚不清晰、涉及强合规或复杂计算规则时，需先澄清或补充规则表，示例中的时限与退款口径均为演示设定，落地按实际业务确认。
示例目标：这份示范要解决什么填写问题
这份示范要解决的问题很具体：很多人知道用户故事有“作为……我希望……以便……”三句话，也知道验收条件要写场景，但真正落到一条需求上，常常写出来角色是“用户”、价值是“提升体验”、预期结果是“功能正常”。本文要演示的，是把一条需求从模糊意图写到可验证结果的完整动作。
示例选取电商场景中的“订单取消”需求。选择它有两个原因：一是业务事件清晰，用户主动发起取消，系统需要判断能否取消并处理退款；二是它天然包含正常流程、边界条件和金额计算三类内容，足以展示验收条件如何拆分场景。
读者照着本文可以完成四类填写动作：
- 角色识别：从业务事件中找到真正发起动作、承担结果的使用者，写成可识别的角色。
- 价值表述：把“做什么”和“为什么值得做”分开写，让故事的目标与收益各自清楚。
- 场景拆分：从主流程出发，推导出分支和异常场景，形成一组覆盖完整的验收条件。
- 预期结果描述：把结果写成可观察、可判断的事实，而不是主观评价。
需要说明的是，以下内容为虚构演示情景，用于说明填写方法，不代表任何真实客户案例；示例中的取消时限、退款计算口径均为演示设定。
完整示例：订单取消需求的用户故事与验收条件
先看填写完成的样子。以下是一份前后自洽的范例，用户故事说明意图，补充说明划定范围，验收条件用场景式写法覆盖三类情况。
用户故事正文
作为已下单但尚未收到货的买家，我希望在订单详情页发起取消申请并看到预计退款金额，以便在不需要这件商品时及时止损，并清楚知道钱什么时候退回。
这条故事包含三个要素：角色是“已下单但尚未收到货的买家”，目标是在订单详情页发起取消并看到预计退款金额，价值是及时止损并明确退款时间。角色限定了适用人群，目标限定了操作入口和关键信息，价值说明了买家为什么愿意用这个功能。
补充说明：范围、假设与不在本次范围的内容
- 范围：覆盖待发货和已发货未签收两种订单状态的取消申请；取消成功后进入退款流程。
- 假设：订单已支付；系统能读取订单状态、支付时间和商品金额；退款走原支付渠道。
- 不在本次范围：已签收订单的退货退款、换货、部分商品取消、优惠券返还规则、客服人工介入流程。
补充说明的作用是防止读者把故事理解得过大。把“不做什么”写清楚，评审时就不会有人追问“那已签收的怎么办”，也能避免开发按自己的理解扩大实现范围。
验收条件：场景式写法
以下三个场景分别覆盖正常取消、超时不可取消和退款金额计算。每个场景都包含前置条件、操作步骤和预期结果。
| 场景 | 前置条件 | 操作步骤 | 预期结果 |
|---|---|---|---|
| 场景一：待发货订单正常取消 | 买家已支付订单，订单状态为“待发货”，下单时间在2小时内 | 1. 买家进入订单详情页；2. 点击“取消订单”；3. 选择取消原因“不想要了”；4. 确认提交 | 订单状态变为“已取消”；页面显示“退款申请已提交，预计1–3个工作日原路退回”；买家收到取消成功通知 |
| 场景二：超过取消时限 | 买家已支付订单，订单状态为“待发货”，下单时间已超过2小时 | 1. 买家进入订单详情页；2. 查看取消入口 | “取消订单”按钮置灰，旁边显示“订单已超过可取消时间”；买家无法提交取消申请 |
| 场景三：已发货订单取消与退款金额 | 买家已支付订单，订单状态为“已发货未签收”，商品金额100元，运费10元，下单时间在2小时内 | 1. 买家进入订单详情页；2. 点击“取消订单”；3. 确认提交 | 页面在提交前显示“预计退款110元（含运费10元）”；提交后订单状态变为“取消中”，待物流拦截成功后转为“已取消”并触发退款 |
这份范例的完整之处在于：用户故事回答了“谁、要什么、为什么”，补充说明回答了“做到哪、依赖什么”，验收条件回答了“怎么判断做对了”。三者合起来，开发和测试都能据此开展工作。
逐项解释：每个字段为什么这样填
范例只是结果，真正要学的是每个字段背后的填写判断。下面逐项拆解，并对照常见错误写法。
角色：写到可识别的使用者
范例中写“已下单但尚未收到货的买家”，而不是“用户”。原因是角色越具体，越能帮助团队判断这个功能为谁设计、在什么状态下使用。“已下单但尚未收到货”直接对应订单状态，也暗示了功能入口在订单详情页。写成“用户”看似省事，实际上把判断责任推给了读者，评审时容易出现“这个用户指谁”的争论。
常见错误写法是“作为用户，我希望能够取消订单”。这句话没有说明哪类用户、在什么订单状态下取消，导致后续验收条件无从推导。
目标与价值：动作和收益分开写
范例中“我希望”后面写的是具体动作和关键信息：在订单详情页发起取消申请并看到预计退款金额。“以便”后面写的是收益：及时止损、清楚知道退款时间。两者分开的好处是，目标可以被验收，价值可以被评估。如果目标写得太虚，比如“我希望取消订单更方便”，验收条件就只能写成“操作方便”，无法判断。
常见错误是把价值塞进目标里，写成“我希望通过一键取消提升用户体验”。这样既没有说清操作是什么，也把无法验证的“提升体验”当成了需求内容。
用户故事与验收条件的分工
用户故事说意图，验收条件说可验证的结果。范例中故事只提到“发起取消并看到预计退款金额”，没有写超时怎么办、退款怎么算；这些内容全部放进验收条件。分工清楚后，故事保持简短易读，验收条件承担细节，两者不重复也不冲突。如果故事里塞满规则，它会变成一份缩小的需求文档；如果验收条件只写“取消成功”，它又无法支撑测试。
预期结果：写成可观察的事实
范例中每个预期结果都能被直接观察：订单状态变为“已取消”、按钮置灰并显示提示文案、页面显示“预计退款110元（含运费10元）”。这些描述让测试人员知道该看哪里、看到什么算通过。相比之下，“体验良好”“提示友好”“退款及时”这类表述没有判断标准，不同人会有不同结论。
把主观表述改成可观察事实的方法，是追问“从哪里看到”“看到什么内容”“状态变成什么”。例如“退款及时”可以改成“提交后页面显示预计到账时间，退款状态可在订单详情页查看”。
边界场景：从主流程推导
三个场景不是随意凑出来的。场景一是主流程：状态正常、时间在时限内，取消成功。从主流程出发，问两个问题就能得到边界：如果时间超出时限会怎样，对应场景二；如果订单已经发货、涉及运费会怎样，对应场景三。这种推导方式可以复用到其他需求：先写最顺利的一条路径，再逐个改变条件，看结果如何变化。
常见错误是只写主流程，把异常留给开发临场决定；或者反过来，一上来就罗列十几种异常，却没有一条清晰的主流程作为基准。
可迁移规律：换一个需求怎么照着写
把上面的范例抽象成步骤，换一条需求也能照着填。以下四步按顺序执行，每步都有明确的产出。
第一步：从业务事件确定角色与目标
先找到需求对应的业务事件，比如“申请退款”“修改收货地址”“提交审批”。围绕事件问：谁发起这个动作，他在什么状态下操作，完成后得到什么。把答案写成一句话，角色取其中最具体的一类使用者，目标写成动作加关键信息，价值写成业务收益。产出是一条“作为……我希望……以便……”的完整句子。
第二步：按主流程、分支、异常三层拆场景
主流程是最顺利的一条路径，先写它。分支是条件变化但仍在正常范围内的路径，比如不同订单状态、不同商品类型。异常是应当被阻止或需要特殊处理的路径，比如超时、权限不足、数据缺失。每层至少检查一遍，确保没有遗漏关键条件。产出是一组场景清单，每个场景对应一个可独立验证的情况。
第三步：用“给定—当—那么”组织场景
把每个场景写成三段：给定（前置条件和初始状态）、当（用户执行的操作）、那么（可观察的预期结果）。这个结构与范例表格中的三列一一对应，好处是强迫作者把条件和结果分开，避免把操作和结果混在一句话里。产出是每个场景的完整描述，可以直接交给测试设计用例。
第四步：写完后的自检清单
提交评审前，逐条核对：
- 角色是否唯一且可识别，能否对应到具体的订单状态或使用者身份；
- 目标是否包含具体动作和关键信息，价值是否与目标分开；
- 每个预期结果是否可观察、可判断，是否还有“良好”“及时”这类主观词；
- 范围与不在本次范围的内容是否写清，假设是否列出；
- 主流程、分支、异常三层是否都有覆盖，边界条件是否从主流程推导而来；
- 用户故事与验收条件是否分工清楚，没有互相重复或矛盾。
这套写法落到协作工具里，可以把用户故事作为需求条目记录，把验收条件作为条目下的检查项或子项，评审时逐条确认状态。ONES 支持将 PRD 拆解为需求和任务并按模块分配负责人，ONES Assistant 也能围绕 PRD 质量检查提炼待澄清问题与拆解建议，帮助团队在录入阶段发现角色不清、结果不可验证等问题；相关操作在 ONES 权限体系内进行，过程可追踪。工具承载的是记录与流转，填写质量仍取决于上述判断。
适用边界：哪些情况不适合这样写
这套写法适合意图相对明确、可以通过操作和结果描述清楚的需求。以下情形需要调整，机械套用反而会掩盖问题。
需求意图尚不清晰时，先澄清再写。如果团队还在争论“要不要做这个功能”“用户到底遇到什么问题”，此时写用户故事只会把猜测固化成文字。应先做需求澄清，明确问题、目标用户和期望变化，再进入故事填写。
强合规、强计算规则的需求需要补充规则表。范例中的退款金额只涉及商品金额加运费，用场景描述足够。如果需求涉及阶梯费率、多条件叠加、税务口径或合规审批，单靠场景容易遗漏组合情况，应另附规则表或数据口径说明，场景只负责验证规则表中的关键组合。
界面细节与系统架构设计不在本文范围。范例中的“按钮置灰”“页面显示提示文案”是为了让结果可观察，并不构成界面设计规范。具体布局、交互样式和系统实现方式，应由设计和架构环节另行处理。
示例中的业务规则需按实际业务确认。2小时取消时限、运费是否退还、退款到账时间，都是为演示而设定的规则。读者迁移到自己业务时，应以实际业务规则为准，并在补充说明中写明规则的来源和适用范围，避免把演示设定当成通用标准。
常见问题
用户故事写多长合适，验收条件要不要写进故事正文里？
用户故事保持简短，通常三句话讲清角色、目标、价值即可，把规则细节留给验收条件。判断标准是：故事回答“谁、要什么、为什么”，验收条件回答“怎么判断做对了”。如果故事里开始出现时限、金额计算、状态流转，说明这些内容应该移到验收条件或补充说明中。反过来，如果验收条件只写“取消成功”，无法支撑测试设计，也需要补足前置条件和可观察结果。
一条用户故事配几个验收场景比较合适？
没有固定数量，判断依据是场景是否覆盖了主流程、关键分支和需要阻止的异常。以本文示例为例，主流程一个场景，时限边界一个场景，涉及金额和物流状态的一个场景，三个场景就能支撑开发和测试开展工作。如果条件组合很多，比如不同订单状态、不同支付方式、不同商品类型交叉，逐个写成场景会迅速膨胀，此时更适合先整理规则表，再用场景验证规则表中的关键组合。
示例里的“给定—当—那么”和表格三列是什么关系？
两者一一对应：给定对应前置条件，当对应操作步骤，那么对应预期结果。表格适合评审时横向对照多个场景，给定—当—那么适合逐条书写和讨论。团队可以先用三段式把每个场景写完整，再汇总进表格查看覆盖情况。无论用哪种形式，关键是把条件和结果分开写，避免把操作和结果混在同一句话里，导致测试时无法判断哪一步出了问题。
需求涉及审批流或多角色操作时，用户故事的角色该怎么写？
一条故事聚焦一个主要角色，即发起动作并承担结果的那个人。如果同一需求里还有审批人、客服等角色，可以拆成多条故事，或在补充说明中列出相关角色及其职责。例如订单取消需求中，买家发起取消是主故事，客服处理拦截失败后的跟进可以另写一条故事。角色拆开后，每条故事的验收条件更聚焦，评审时也更容易发现遗漏的角色和状态。
写完用户故事和验收条件后，在 ONES 里怎么记录和评审？
常见做法是把用户故事作为需求条目记录，补充说明写在条目描述中，验收条件作为条目下的检查项或子项，评审时逐条确认。ONES 支持将 PRD 拆解为需求和任务并按模块分配负责人，ONES Assistant 可围绕 PRD 质量检查提炼待澄清问题与拆解建议，帮助在录入阶段发现角色不清、结果不可验证等问题；相关操作在 ONES 权限体系内进行，过程可追踪。工具负责记录与流转，填写质量仍取决于角色、目标和结果是否写清楚。
