用户故事和验收条件经常被写在同一张需求卡里，却回答两个不同问题：故事说明谁要什么、为什么值得做，验收条件说明做到什么程度算完成。本文给出一份可直接照着填的完整范例——一条“导出对账单”的用户故事及其验收条件，并逐项解释填写理由、提炼可迁移规律。文中场景为演示情景，用于说明写法，不代表真实客户案例。
要点总览（TL;DR）
- 用户故事用“作为……我希望……以便……”写清角色、目标与价值，验收条件用可判定的场景条目写清前提、操作与预期结果，两者配对才完整。
- 完整范例以“按月导出账户对账单”为演示情景：故事卡填写角色、目标、价值与范围，验收条件覆盖正常导出、空数据、无权限、过程中断四类场景。
- 角色写到具体岗位而非泛称，价值句指向处境变化而非复述功能，验收条件写成第三人可独立复核的可观察结果。
- 迁移时按“定角色、定动作、定价值”替换故事句式，按“主路径加失败边界”拆分场景，再用三问检查故事与验收条件是否一一对应。
- 复杂计算规则、界面交互、非功能性指标和业务判断需要补充其他材料，示例不能替代与业务方的确认。
示例要解决什么问题：故事与验收条件各写什么
这份示例的目标是让读者看到一份“填完的样子”，再理解每一行为什么这样填。它包含两个交付物：一张用户故事卡，一份验收条件清单。两者配对使用，缺一方都会让需求表达失衡。
用户故事承担角色、目标、价值三要素。常见句式是“作为……我希望……以便……”。第一段锁定具体使用者，第二段写使用者想完成的事，第三段写这件事带来的价值。三要素齐全，团队才能判断这个需求值不值得做、做完对谁有用。
验收条件承担可判定的完成标准。它把故事中的“希望”翻译成若干可观察的场景，每个场景写清前提、操作和预期结果。判定口径要具体到第三人能独立复核：看到什么界面、得到什么文件、出现什么提示，都应是可观察的事实，而非“体验良好”“速度较快”这类主观描述。
需要说明的是，本文示例为演示情景，角色、业务背景和字段均为说明写法而设定，不指向任何真实客户或实际系统。读者迁移时应替换为自己业务中的真实角色与规则。
完整示例：一条“导出对账单”用户故事及其验收条件
以下示例设定一个演示情景：某对账岗位人员需要按月把账户流水整理成对账单，交给财务复核。示例仅用于展示填写方式。
用户故事卡（已填写）
| 字段 | 填写内容 |
|---|---|
| 故事标题 | 按月导出账户对账单 |
| 角色 | 负责月度对账的财务专员 |
| 目标 | 按选定月份导出该账户的完整流水对账单 |
| 价值 | 把手工整理流水的时间省下来，并让复核人拿到口径统一的原始记录 |
| 故事正文 | 作为负责月度对账的财务专员，我希望按选定月份导出该账户的完整流水对账单，以便减少手工整理流水的时间，并让复核人拿到口径统一的原始记录。 |
| 范围说明 | 本期覆盖单账户按月导出；多账户合并导出不在本期范围。 |
验收条件清单（已填写）
| 编号 | 场景 | 前提 | 操作 | 预期结果 |
|---|---|---|---|---|
| AC-1 | 正常导出当月对账单 | 账户当月存在流水记录，操作人已登录并具备导出权限 | 选择月份，点击“导出对账单” | 生成该月对账单文件，包含当月全部流水，条目数与流水列表一致，文件可正常打开 |
| AC-2 | 所选月份无流水 | 账户在所选月份没有流水记录 | 选择该月份，点击“导出对账单” | 提示“该月份无流水记录”，不生成空文件 |
| AC-3 | 无导出权限 | 操作人未获得导出权限 | 进入对账单页面 | 导出入口不可用，或点击后提示无权限，不产生文件 |
| AC-4 | 导出过程中中断 | 导出已发起，网络或会话中断 | 重新进入页面再次导出 | 可重新发起导出，已生成的部分文件不残留为可下载的完整对账单 |
这份清单覆盖了正常路径（AC-1）与三个异常路径：空数据、权限不足、过程中断。每条都写清了前提、操作和可观察的预期结果，复核人无需追问即可判断通过与否。
逐项解释：每个字段为什么这样填
角色写成“负责月度对账的财务专员”，而非“用户”或“财务人员”。具体使用者决定了后续验收条件里的权限、操作入口和数据范围；角色越泛，验收条件越难落到可判定的场景。角色不必写到姓名，但要写到能对应一类真实岗位职责的程度。
价值句写成“减少手工整理流水的时间，并让复核人拿到口径统一的原始记录”，而非复述“可以导出对账单”。复述功能只是把目标换个说法，无法回答为什么值得投入。价值句应指向使用者的实际处境：省下哪段时间、避免哪类返工、让谁拿到什么。示例中的价值包含效率与一致性两个方向，都对应可感知的结果。
验收条件写成可观察结果，是因为它要用于判定，而非描述愿望。“文件包含当月全部流水，条目数与流水列表一致”可以被核对；“导出体验流畅”无法被核对。判定口径越具体，开发、测试和业务方对“完成”的理解越一致，返工越少。
异常场景的取舍依据是发生概率与后果。空数据、权限不足、过程中断是导出类需求最常见的三类偏差，遗漏任何一类都可能导致上线后返工，因此纳入示例。若某类异常在业务上不可能发生，或已有统一机制覆盖，则不必逐条展开，可在范围说明中注明由既有机制处理。
故事与验收条件的对应关系体现在：故事中的“完整流水对账单”在 AC-1 中被拆成“全部流水、条目数一致、文件可打开”三个可核对点；故事中的“复核人拿到口径统一记录”对应文件内容与流水列表一致。验收条件不引入故事之外的新目标，故事也不留下验收条件未覆盖的承诺。
可迁移规律：换一个需求怎么照着写
故事句式的替换方法是先定角色、再定动作、最后定价值。把“财务专员”换成你业务中的具体岗位，把“导出对账单”换成该岗位要完成的一件事，把价值换成这件事省下的时间、避免的错误或交付给谁。三步填完，再回读一遍：价值句是否只是复述了动作？若是，继续追问“做完之后谁的什么处境改变了”。
验收条件的场景拆分思路是按“正常一次成功”加“可能失败的边界”展开。先写主路径，确认它能覆盖故事的核心承诺；再列出可能让主路径失败的条件，如数据为空、权限不足、输入越界、过程中断。每个场景独立成条，前提、操作、预期结果三段齐全，避免一条里塞多个判定点。
故事与验收条件的一致性检查可以做三问：故事里的每个目标，是否至少有一条验收条件对应？每条验收条件，是否都能追溯到故事中的某个词？验收条件里是否出现了故事未提及的新功能？三问通过，两者才算配对。
常见填写偏差及修正方向：角色写成“用户”，改为具体岗位；价值句复述功能，改为描述处境变化；验收条件写成“正确显示”“友好提示”，改为可观察的具体结果；一条验收条件包含多个场景，拆成多条；只写正常路径，补上关键异常；故事承诺了范围外的能力，移入范围说明或另立故事。
当这些内容需要进入团队协作流程时，故事卡与验收条件可以作为同一条需求的记录一起流转：需求提出人填写故事与价值，业务或测试方补充验收条件，评审时逐条核对一致性，开发完成后按验收条件逐项判定。ONES 支持在工作项中记录需求描述与验收标准，并随状态流转保留评审与完成记录，便于把上述填写与核对动作固定下来。
适用边界：什么情况下需要补充其他材料
示例方法适合表达目标清晰、判定点可观察的需求。遇到以下情形，需要在故事与验收条件之外补充材料。
- 复杂规则或计算逻辑：如费率计算、分摊规则、多条件组合判定，验收条件只能写结果，规则本身需要单独的业务规则说明或计算示例，否则开发无法还原口径。
- 界面细节与交互设计：布局、字段排布、交互反馈的具体样式，属于设计稿与交互说明的范围，本文示例不展开，验收条件中可引用设计稿作为判定依据。
- 需求内容本身的业务判断：需求是否合理、优先级如何排、范围如何取舍，属于需求分析与澄清的工作，示例只解决“怎么写清楚”，不替代“想清楚”。
- 与业务方的确认：示例中的角色、价值、异常场景取舍都需要业务方确认后才成立，示例不能替代沟通与签字确认。
- 非功能性要求：性能、容量、安全合规等指标需要单独的口径与测试方法，不宜塞进单条验收条件。
把示例当作填写起点，按上述清单判断是否需要补充材料，能让故事与验收条件在合适的范围内发挥作用，也避免用一份模板覆盖所有需求类型。
常见问题
用户故事一定要用“作为……我希望……以便……”这个句式吗？
这个句式是帮助写全三要素的工具，而非硬性格式。关键是角色、目标、价值三项信息齐全，团队能据此判断需求对谁有用、值不值得做。如果团队习惯用“背景—目标—价值”分段写，只要三要素清楚，同样可用。需要留意的是价值句容易退化成复述功能，写完回读一遍，确认它描述的是使用者处境的变化。
验收条件写多少条合适，异常场景要全部覆盖吗？
条数没有统一标准，判断依据是故事中的每个承诺是否都有对应判定点。通常先写一条主路径覆盖核心承诺，再按发生概率与后果补充关键异常，如空数据、权限不足、输入越界、过程中断。业务上不可能发生、或已有统一机制覆盖的异常，可在范围说明中注明由既有机制处理，不必逐条展开。异常场景过多时，考虑把故事拆小。
故事和验收条件由谁写、什么时候写？
常见做法是需求提出人先写故事与价值，业务或测试方在评审前补充验收条件，评审时逐条核对两者是否对应。验收条件在开发开始前确定，能减少对“完成”的理解分歧；开发过程中若发现遗漏场景，及时补充并同步相关方。具体分工可按团队习惯调整，关键是故事与验收条件在同一处记录、同步更新。
需求涉及复杂计算规则时，验收条件还能写清楚吗？
验收条件适合写可观察的结果，如“生成的对账单金额与流水汇总一致”，但计算口径本身需要单独的业务规则说明或计算示例来承载。做法是把规则文档作为验收条件的引用依据，验收条件中写明按哪份规则判定。若规则尚未确定，先完成规则澄清再写验收条件，避免用模糊表述掩盖口径分歧。
把故事和验收条件放进工具管理，有什么实际好处？
故事与验收条件作为同一条需求的记录一起流转，需求提出人填写故事与价值，业务或测试方补充验收条件，评审时逐条核对，开发完成后按验收条件逐项判定，评审与完成记录随状态保留。ONES 支持在工作项中记录需求描述与验收标准，并随状态流转保留记录，便于把填写与核对动作固定下来，减少散落在聊天记录和文档中的信息丢失。
