本文给出一份可直接对照填写的用户故事规范示例，用假设的在线课程报名场景，完整展示角色、目标、价值、验收条件、优先级、估算与依赖等字段的写法，再逐项解释填写依据和可迁移规律。示例为演示情景，不涉及真实客户与成效；需求内容本身的业务判断仍归需求分析与澄清。在ONES中，用户故事可作为需求工作项承载这些字段与状态流转，本文只讨论需求表示层面的规范。
要点总览（TL;DR）
- 一份规范的用户故事固定角色、目标、价值、验收条件、优先级、估算与依赖七类字段，本文用假设的在线课程报名场景完整填写一条作为范例。
- 验收条件按“给定—当—则”组织，控制在3–5条，覆盖主路径、边界情况与重复操作，每条只描述一个可判定的结果。
- 示例的结构可复用、内容需替换：把字段做成需求模板，并在进入开发前设置故事评审，检查角色可指认、验收条件可验证、依赖列全。
- 示例为演示情景，需求意图尚未明确时应先完成需求分析与澄清；复杂需求需拆成多条独立可验收的故事，架构与界面设计不在本文范围。
示例目标：这份用户故事范例要示范什么
这份范例的目标是让读者看到一条用户故事从字段填写到验收条件成型的完整样子，并能直接套用到自己的需求文档中。示例设定在一个假设的在线课程报名场景：平台提供课程浏览与报名功能，运营团队希望减少报名流程中的中途放弃。这个背景只用于让字段有具体所指，不代表任何真实客户、真实系统或真实业务数据。
示范范围集中在需求表示：一条故事应该包含哪些字段、每个字段写到什么颗粒度、验收条件如何组织成可判定的条目。读者可以对照示例逐项检查自己团队的故事卡，判断哪些字段缺失、哪些描述过于笼统。
以下内容不在本文示范范围内：系统架构如何设计、页面如何布局与绘制、需求内容本身是否值得做。这些属于架构设计、UI设计与需求分析澄清的工作，示例只负责把已经明确的需求意图规范地表达出来。
完整示例：一条用户故事的规范填写
以下是一条完整填写的用户故事，场景为假设的在线课程报名系统。示例中的角色、数值与依赖均为演示设定，用于展示字段之间的配合关系。
故事正文
故事标题：学员在课程详情页完成报名并收到确认
标准句式：作为已登录的学员，我希望在课程详情页直接提交报名并看到报名结果，以便在不离开当前页面的情况下确认自己已成功占位。
价值说明：学员提交后立即看到报名成功状态与课程开课时间，减少重复提交和客服询问；运营侧可观察到报名提交到结果展示的完整路径是否走通。
验收条件
验收条件采用“给定—当—则”的结构，每条都可独立判定通过或不通过：
- 给定学员已登录且课程有余量，当学员在课程详情页点击“立即报名”，则页面显示报名成功提示，并展示课程名称与开课时间。
- 给定学员已登录但课程余量为零，当学员点击“立即报名”，则按钮置为不可用并提示“名额已满”，不产生报名记录。
- 给定学员未登录，当学员点击“立即报名”，则跳转至登录页，登录完成后返回当前课程详情页。
- 给定学员已成功报名同一门课程，当再次进入该课程详情页，则显示“已报名”状态，重复提交不生成第二条报名记录。
辅助字段
| 字段 | 填写内容 | 说明 |
|---|---|---|
| 优先级 | 高 | 报名主路径，缺失则核心流程不可用 |
| 估算 | 5 故事点 | 团队相对估算口径，含前后端联调 |
| 依赖 | 登录态校验接口、课程余量查询接口 | 两项接口需先就绪，否则验收条件无法验证 |
| 关联需求 | 课程详情页信息展示 | 本故事在其基础上增加报名动作 |
逐项解释：每个字段为什么这样写
示例中的每个字段都承担一个判断任务：角色决定谁在用，目标决定要完成什么动作，价值说明为什么值得做，验收条件决定做到什么程度算完成，辅助字段决定何时做、做多大、受什么约束。下面逐项说明写法依据。
角色与目标：写到可指认的人与动作
角色写“已登录的学员”，而不是笼统的“用户”，因为登录状态直接影响验收条件的分支。目标写“在课程详情页直接提交报名并看到报名结果”，包含动作发生的页面与期望结果，读者不需要再猜。常见错误是把角色写成“系统”或“所有人”，把目标写成“优化报名体验”这类无法对应具体操作的说法。
价值说明：落到可观察的结果
价值段写的是学员看到什么、运营能观察到什么，而不是“提升用户体验”这类无法核对的判断。可观察结果可以是状态变化、记录生成、提示出现，也可以是流程节点是否走通。价值说明与验收条件相互呼应：价值里提到的“立即看到报名成功状态”，在验收条件第一条中有对应判定。
验收条件：写成可判定的条目
每条验收条件都包含前提、触发动作和预期结果三个部分，并且只描述一个可判定的结果。数量控制在3–5条，覆盖主路径、边界情况与重复操作。写法上避免“正常显示”“合理提示”这类模糊表述，改为写明显示什么内容、提示什么文案、是否产生记录。验收条件不描述实现方式，只描述可观察的行为。
优先级与估算：给出填写口径
优先级用团队统一的档位（如高、中、低），并附一句判断理由，说明它为什么处于该档位。估算使用团队约定的单位与口径，示例中的故事点只在该团队内部有意义，跨团队比较没有价值。依赖字段列出会阻塞验收的外部条件，写清具体接口或前置故事，便于排期时识别风险。
可迁移规律：从这条示例到你的规范
这条示例的价值在于结构可以复用，内容需要按业务替换。把示例拆开看，可以提炼出几条适用于多数需求场景的编写规律。
句式与字段结构的复用
固定“作为……我希望……以便……”的句式，并固定角色、目标、价值、验收条件、优先级、估算、依赖这组字段。团队可以把这套结构做成需求模板，新建故事时按字段填写，减少每次从零组织语言的成本。字段可以按团队习惯增减，但增减应在团队内统一，避免同一项目里出现多种格式。
验收条件的通用写法
验收条件优先覆盖三类情况：主路径能否走通、边界条件如何处理、重复或异常操作是否被正确拦截。每条只写一个判定点，用前提、动作、结果的结构组织。写完一条后自问：测试人员能否仅凭这条描述判断通过或不通过？如果不能，说明还需要补充具体内容。
团队内的统一与评审
规范落地需要两个动作：一是把模板固化到需求创建入口，让填写有统一起点；二是设置故事评审环节，在进入开发前检查字段完整性与验收条件可判定性。评审时重点看角色是否可指认、验收条件是否可验证、依赖是否列全，而不是讨论需求该不该做——后者属于需求分析与澄清环节。
需求状态流转中的承接
用户故事从草稿到可开发，需要经过澄清、评审、就绪等状态。团队可以约定：字段未填全的故事停留在草稿状态，验收条件通过评审后才进入就绪状态。这样规范不只是文档要求，而是与工作流绑定。在ONES中，用户故事可以作为需求工作项承载角色、验收条件等字段，并通过状态流转记录从澄清到就绪的过程，评审意见与字段修改留在同一工作项下，便于后续追溯。
适用边界：示例不能直接照搬的情况
这份示例是演示情景，用于说明字段写法，不代表任何真实项目的成效，也不能作为业务判断的依据。直接照搬前需要确认几个前提。
第一，示例假设需求意图已经明确。如果需求内容本身还在讨论阶段，例如报名规则是否应该限制名额、是否需要审核，应先完成需求分析与澄清，再进入故事编写。规范解决的是表达问题，不替代业务决策。
第二，复杂需求需要拆分。示例中的故事覆盖一条完整报名路径，规模适中。当需求涉及多个角色、多条流程分支或跨系统协作时，应拆成多条故事，每条保持独立可验收，而不是把全部内容塞进一条故事里。
第三，示例不覆盖架构与界面设计。验收条件描述可观察行为，不规定接口如何设计、页面如何布局。这些内容由架构设计与UI设计环节负责，故事只引用其结果作为依赖或验收前提。
第四，示例中的优先级、估算数值与依赖项仅在该演示场景下成立。迁移到自己的团队时，应使用团队自己的估算口径与优先级档位，依赖项按实际系统情况填写。把示例当作格式参照，而不是内容标准，才能让规范真正服务于需求表达。
常见问题
一条用户故事写多长、验收条件写几条比较合适？
篇幅以读者能准确理解为准，正文通常一段话讲清角色、目标与价值，不需要展开实现细节。验收条件建议3–5条，覆盖主路径、边界情况和重复或异常操作三类。条数不是硬指标，判断标准是每条都能被测试人员独立判定通过或不通过；如果一条里塞了两个结果，应拆开。
需求还没讨论清楚，可以先按这个模板写用户故事吗？
可以先记录初步意图，但不宜直接进入开发。模板解决的是表达问题，需求内容是否成立、规则如何设定，仍要在需求分析与澄清环节确认。一个可行的做法是：字段未填全或验收条件无法判定的故事停留在草稿状态，澄清完成后再补齐字段并提交评审。
团队已有需求文档，还需要单独写用户故事吗？
取决于团队的工作方式。用户故事适合承载单个可交付的需求切片，便于估算、排期和验收；需求文档适合承载背景、规则和整体方案。两者可以并存：文档说明为什么做和整体约束，故事说明这一条要做什么、做到什么程度算完成。关键是避免同一内容在两处维护出不一致的版本。
验收条件和测试用例是什么关系，需要写两遍吗？
验收条件描述需求完成的判定标准，测试用例描述如何验证。二者视角不同，但可以衔接：验收条件通过评审后，测试人员据此设计具体用例，补充数据准备、操作步骤和预期结果。这样验收条件不必写到用例的颗粒度，也不会在测试阶段重新猜测需求意图。
跨多个角色的需求，是写成一条大故事还是拆成多条？
优先拆成多条，每条对应一个角色的一条可独立验收的路径。例如报名场景中，学员提交报名、运营查看报名记录可以分别成条。拆分后每条故事仍保持角色、目标、价值、验收条件的完整结构，依赖字段写清彼此的前后关系。把多个角色塞进一条故事，验收条件会互相纠缠，评审和测试都难以判断完成状态。
