制定用户故事编写规范，先确定一份可直接填写的故事字段模板，再明确谁写、谁评审、何时算完成，最后用一两个真实需求试点，并按评审问题清单迭代。规范的作用是让不同成员写出的故事能被同样地理解和验收，篇幅控制在一页以内即可。本文聚焦需求表达环节，不展开架构设计与界面绘制。
要点总览（TL;DR）
- 规范的核心是一张字段定义表：角色、目标与业务价值、验收条件、优先级与估算口径为必填，依赖与关联文档按条件填写，必填项控制在六到七个。
- 制定顺序是梳理问题样本、确定字段模板与写作句式、约定验收条件写法、确定评审与变更规则、试点后发布版本，每步都有可检查的完成标志。
- 分工遵循谁受益谁定义故事、谁实现谁参与评审、谁维护谁负责发布与培训，规范维护人需明确到人并负责版本记录。
- 验收条件要能被测试人员转化为测试用例，结果有明确观察对象；目标与价值要落到具体行为，避免口号式描述。
- 规范发布后用抽样检查验证执行：字段完整性、验收条件可测试性、评审与变更留痕、版本与培训覆盖，不通过项计入下一版修订。
一份可用的用户故事规范包含哪些字段
规范的骨架是一张字段定义表。字段的作用是让写作者知道填什么、评审者知道看什么、测试者知道验什么。字段数量以支撑评审和验收为准，超出这个范围的内容可以放到需求说明文档里，不必塞进故事本身。
建议的最小字段集如下表。必填项控制在六到七个，其余作为选填，避免模板过重导致填写流于形式。
| 字段名 | 填写要求 | 必填/选填 | 示例 |
|---|---|---|---|
| 故事标题与编号 | 标题用动宾结构概括一个可交付的用户能力；编号由系统或规范统一分配，保证可追溯 | 必填 | US-104 会员在订单页使用优惠券抵扣金额 |
| 角色（谁使用） | 写明具体使用者或使用方，避免只写“用户”；涉及多角色时分别列出 | 必填 | 已登录的注册会员 |
| 目标与业务价值（为什么做） | 说明角色要完成什么动作、达成什么结果，以及该结果对业务的意义 | 必填 | 在结算时直接抵扣，减少因优惠不可用而放弃下单的情况 |
| 验收条件（怎样算完成） | 用可观察、可判定的语句逐条列出，每条对应一个可测试的场景 | 必填 | 优惠券有效期内且满足门槛时，结算页显示抵扣后金额 |
| 优先级与估算口径 | 优先级用统一档位（如高/中/低）并写明判定依据；估算注明单位与参与估算的角色 | 必填 | 优先级：高（影响当期活动上线）；估算：3 人日，由开发在评审会上共同确认 |
| 依赖、假设与非功能约束 | 列出前置依赖、成立假设，以及性能、权限、兼容性等约束 | 选填（存在时必填） | 依赖优惠券服务接口上线；假设单用户同时仅可使用一张券 |
| 关联文档与设计稿 | 指向原型、规则说明或数据字典的位置 | 选填 | 规则说明见需求文档第 3 节 |
必填与选填的划分需要在规范中写清楚，并说明选填字段在什么条件下转为必填。例如“依赖”平时可以不填，一旦故事涉及外部系统或跨团队交付，就必须填写，否则评审不通过。这样的条件规则比笼统要求“尽量填全”更容易执行。
从零制定规范的五个步骤
制定规范本身是一个小项目，按顺序推进可以避免一开始就陷入格式争论。每一步都有明确的输入、动作和输出，完成标志是下一步能够顺利开始。
第一步：梳理现有需求文档的问题样本
输入是团队近期的需求文档和故事列表。动作是抽取十到二十条真实故事，标注其中的问题类型，例如目标空泛、验收条件无法判定、角色缺失、依赖未说明。输出是一份问题清单，按出现频次排序。完成标志是团队对“最常出现的三类问题”达成一致，这三类问题将成为规范重点约束的对象。
第二步：确定字段模板与写作句式
输入是上一步的问题清单。动作是据此确定字段集，并为角色、目标、价值三个字段约定写作句式，例如“作为［角色］，我希望［完成什么］，以便［获得什么价值］”。句式的作用是降低起步难度，允许在表达清楚的前提下灵活调整。输出是模板初稿。完成标志是能用模板把一条历史故事重新填写一遍，且信息没有丢失。
第三步：约定验收条件的表达方式
输入是模板初稿。动作是确定验收条件的写法规则：每条对应一个场景，包含触发条件、操作和可观察结果；涉及数值的写明具体阈值和单位；避免“良好”“流畅”“尽快”这类无法判定的词。输出是验收条件写法示例与反例对照。完成标志是测试人员能仅凭验收条件设计出测试用例。
第四步：确定评审与变更规则
输入是模板与验收条件规则。动作是约定故事进入开发前必须经过的评审环节、参与角色、通过标准，以及故事在开发中发生变更时如何记录原因和影响。输出是评审规则与变更记录要求。完成标志是团队能说清“一条故事从提出到进入开发要经过哪几个状态”。
第五步：试点后修订并发布版本
输入是完整的规范草案。动作是选取一两个真实需求，按规范完整走一遍编写、评审和验收，收集参与者的反馈，修订后发布第一版并标注版本号与生效日期。输出是正式发布的规范文档。完成标志是规范有版本记录、有明确的维护人，且下一批故事已按新规范编写。
角色分工与各环节交付物
规范能否执行，取决于每个环节是否有人负责、有物可交。分工的原则是：谁受益谁定义故事，谁实现谁参与评审，谁维护谁负责发布和培训。
| 角色 | 主要职责 | 在故事生命周期中的交付物 |
|---|---|---|
| 产品负责人 | 定义故事的角色、目标与业务价值，确定优先级，对故事是否进入开发负责 | 填写完整的故事条目、优先级判定依据、需求背景说明 |
| 业务方 | 提供业务规则与使用场景，确认价值描述是否符合实际业务 | 业务规则说明、场景补充、对价值描述的确认意见 |
| 开发人员 | 参与评审，评估技术可行性与依赖，给出估算 | 估算结果、依赖与约束补充、技术风险提示 |
| 测试人员 | 评审验收条件是否可测试，将其转化为测试用例 | 验收条件修改意见、测试用例、验收结论 |
| 规范维护人 | 维护模板与规则，记录版本变更，组织培训与答疑 | 规范文档及版本记录、培训材料、评审问题汇总 |
规范维护人这一角色常被忽略。缺少维护人时，模板会在几个月内被各自修改成不同版本，评审标准随之松动。维护人不必是管理者，可以是熟悉需求流程的产品或测试骨干，关键是要有明确的版本发布动作和问题收集渠道。
当故事数量增多、评审记录分散在多个文档中时，规范落地还需要一个承载字段和流转的载体。ONES 支持将需求以工作项形式管理，故事字段可作为工作项属性随状态流转保留；ONES Assistant 智能助手能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关项目数据和团队知识回答问题并执行后续操作，也可按指令将 PRD 拆解为需求和任务并按模块分配负责人（示例指令的实际效果以使用环境为准）。规范中的字段定义与评审规则仍需团队自行确定，工具承担的是记录与流转。
示例：一条符合规范的用户故事
下面用一条完整故事展示各字段如何填写，并对照常见问题说明修改思路。
完整示例
标题与编号：US-104 会员在订单页使用优惠券抵扣金额
角色：已登录的注册会员
目标与业务价值：会员在结算时选择可用优惠券并直接看到抵扣后应付金额，减少因不清楚优惠是否生效而放弃下单的情况。
验收条件：
- 会员持有有效期内且满足使用门槛的优惠券时，结算页展示“可用优惠券”入口及抵扣金额。
- 选择一张优惠券后，应付金额在 1 秒内更新为抵扣后数值，并显示抵扣明细。
- 优惠券已过期或不满足门槛时，该券置灰并提示不可用原因。
- 同一订单仅允许使用一张优惠券，重复选择时替换前一张。
优先级与估算口径：优先级高，依据是当期促销活动上线时间；估算 3 人日，由开发在评审会上共同确认，单位为开发人日。
依赖与约束：依赖优惠券服务提供可用券查询接口；假设优惠券规则由运营后台配置；非功能约束为结算页在常用网络环境下金额刷新不超过 1 秒。
常见问题与修正对照
| 常见写法 | 问题 | 修正写法 |
|---|---|---|
| 作为用户，我希望系统更好用 | 角色笼统，目标空泛，无法判断做什么 | 作为已登录会员，我希望在结算时使用优惠券抵扣金额 |
| 优惠券功能体验流畅 | 验收条件不可测，无法判定通过与否 | 选择优惠券后应付金额在 1 秒内更新并显示抵扣明细 |
| 提升用户满意度 | 价值描述停留在口号，无法对应具体行为 | 减少因不清楚优惠是否生效而放弃下单的情况 |
验收条件的可验证性体现在两点：一是每条都能被测试人员转化为至少一个测试用例；二是结果有明确的观察对象，如页面元素、金额数值、提示文案。做不到这两点的条目，应改写或拆分为更小的条件。
规范落地后的完成检查
规范发布不等于被执行。建议每两到四周抽样检查一批故事，按下表逐项核对，任一项不通过时按对应动作处理，并把问题计入下一版规范的修订输入。
| 检查项 | 核对内容 | 通过标准 | 不通过时的处理 |
|---|---|---|---|
| 故事字段完整性 | 必填字段是否齐全，条件必填字段是否按规则填写 | 抽样故事中必填字段缺失为零 | 退回补充后再进入评审，并在团队内说明缺失类型 |
| 验收条件可测试性 | 每条验收条件能否转化为测试用例，是否存在模糊措辞 | 测试人员对抽样故事无“无法测试”的反馈 | 由测试人员提出修改意见，产品负责人修订后重新确认 |
| 评审记录与变更留痕 | 评审是否有参与人、结论和时间记录；开发中的变更是否记录原因与影响 | 抽样故事均有评审记录，变更可追溯 | 补录记录，并在下次评审中重申留痕要求 |
| 规范版本与培训覆盖 | 当前使用的是否为最新版本；新成员是否接受过规范说明 | 版本号与生效日期清晰，新成员已完成一次规范讲解 | 由维护人发布更新说明并安排补训 |
检查结果建议形成简短的月度小结，只记录三类信息：本次抽样数量、不通过项分布、下一版规范的修订点。小结篇幅控制在一页内，重点是让修订有依据，而不是增加汇报负担。当连续两次抽样中某类问题不再出现，可以将其从重点检查项中移出，把检查精力放到新出现的问题上。
常见问题
团队规模很小，也需要这么完整的字段模板吗？
可以按最小集裁剪。角色、目标与业务价值、验收条件三项是评审和验收的基础，建议保留；优先级与估算口径在需要排期时补上。字段减少后，规范中仍要写清哪些字段在什么条件下必须填写，例如涉及外部系统交付时补依赖字段，避免裁剪变成随意省略。
历史故事已经按旧格式写了很多，规范发布后要全部重写吗？
不必。常见做法是以规范生效日期为界，新故事按新规范编写；仍在开发中的故事在下次变更时顺带补齐必填字段；已交付的故事保留原样，仅在需要回溯验收依据时补充关键信息。这样既控制返工量，也让规范从新需求开始真正执行。
验收条件和测试用例是什么关系，写到什么程度算够？
验收条件描述业务上怎样算完成，测试用例描述具体怎么验证。判断标准是测试人员能否仅凭验收条件设计出用例：每条条件对应至少一个可执行场景，结果有明确观察对象，如页面元素、金额数值或提示文案。涉及数值时写明阈值和单位，涉及状态变化时写明触发条件。
规范维护人由谁担任比较合适？
维护人不必是管理者，熟悉需求流程的产品或测试骨干都可以。关键职责是维护模板与规则、记录版本变更、组织培训并收集评审中的高频问题。缺少这个角色时，模板容易被各自修改成不同版本，评审标准随之松动。建议同时约定版本发布节奏，例如每季度集中修订一次。
用工具承载故事字段和评审记录时要注意什么？
工具承担记录与流转，字段定义和评审规则仍需团队自行确定。ONES 支持将需求以工作项形式管理，故事字段可作为工作项属性随状态流转保留；ONES Assistant 智能助手能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关项目数据和团队知识回答问题并执行后续操作，也可按指令将 PRD 拆解为需求和任务并按模块分配负责人（示例指令的实际效果以使用环境为准）。选型时重点确认字段能否按规范配置、评审结论与变更原因能否留痕。
