用户故事评审时，最容易被跳过的是验收条件：正文写了角色和动作，读起来顺畅，评审者容易默认“大家都懂”，散会后才发现没人能说清怎样算完成。本文给出一条可操作的判断路径：先用四栏对照识别缺失属于哪种情况，再按证据排查原因，现场追问补齐，最后用可测试性和复查机制验证效果。
要点总览（TL;DR）
- 验收条件缺失的识别信号有三类：只有角色和动作、有验收栏但写的是“正常”“友好”等笼统词、验收条件与故事正文描述的对象不一致。
- 排查原因按顺序走：先查验收条件是否真的没写（可能写在关联文档或测试用例里），再查是否不可验证，最后查需求本身是否未澄清，每一步都要有可查证据。
- 评审现场按边界、异常、可观察结果三类问题追问；业务规则已清楚的当场补齐，规则本身没结论的退回澄清，并记录缺失类型、责任人和复查时点。
- 补齐后的验证标准是测试人员能直接把验收条件转成用例、评审者仅凭验收条件就能判定通过与否；两条都满足才算补齐有效。
- 减少复发靠小改动：模板固定验收条件栏并给填写示例、评审材料提交四栏对照表、评审检查项加入“验收条件是否存在且可判定”。
评审中如何判断验收条件缺失
判断验收条件是否缺失，先看用户故事能否回答一个具体问题：开发完成后，由谁、在什么条件下、观察到什么结果，就可以判定这条故事完成。回答不出来，就说明验收条件存在问题。评审者不必等到讨论技术方案时才察觉，逐条对照四栏即可快速定位。
四栏对照：把故事拆开看
评审前，把待评用户故事按“角色—动作—价值—验收条件”四栏拆开，逐条填写。前三栏通常来自故事正文，第四栏需要单独确认。任何一栏为空，或第四栏只有一句笼统描述，都标记为待补。这个动作可以在评审材料准备阶段完成，由故事作者或评审组织者提前填表，会上直接对照，避免现场才逐字读正文。
三类典型症状
- 只有角色和动作：故事写成“作为运营人员，我希望导出订单列表”，没有说明导出范围、字段、格式、权限或失败时的表现，评审者无法判断做到什么程度算完成。
- 无完成判定：有验收条件栏，但写的是“功能正常”“体验友好”“性能良好”这类词。它们表达的是期望，无法转成测试步骤，也无法判定通过与否。
- 验收条件与故事不匹配：验收条件描述的是另一个功能或另一个角色的行为，说明故事边界本身没有对齐，需要回到需求澄清。
区分完全缺失、不可验证与需求未澄清
三种情况的处置方式不同，评审时要分开标记。完全缺失指没有验收条件栏或内容为空，通常补写即可；形式存在但不可验证指有描述却无法判定，需要把笼统词替换为可观察结果；需求本身未澄清指写不出验收条件的原因是业务规则、边界或异常处理还没有结论，这时继续在评审会上补写只会产生假设，应退回澄清。区分方法很简单：试着把现有描述转成一条测试用例，转不出来且原因是“不知道业务上应该怎样”，归入需求未澄清；转不出来但原因是“描述太模糊”，归入不可验证。
评审前的准备清单
- 收集本轮待评故事，统一填入四栏对照表。
- 把验收条件栏为空、只有笼统词、与正文不一致的故事分别标色。
- 对标记为需求未澄清的故事，提前附上待确认的问题清单，避免会上临时发散。
- 约定本次评审的停止点：只处理能当场判定的缺失，需要业务决策的另行安排。
缺失的常见原因与排除证据
看到验收条件缺失，不要直接归因于“作者不认真”。缺失可能来自模板、流程、评审习惯或记录位置，不同原因对应不同改进动作。排查时按“先查是否真的没写，再查是否不可验证，最后查需求是否清楚”的顺序进行，每一步都用证据说话。
| 原因假设 | 验证证据 | 排除后的判断 |
|---|---|---|
| 模板未要求验收条件 | 查看当前用户故事模板字段，确认是否存在验收条件栏或填写说明 | 模板缺字段，优先改模板；模板有字段但未填，转向评审习惯问题 |
| 需求本身未澄清 | 查澄清记录、业务规则文档、与业务方的确认消息，看边界和异常是否有结论 | 无结论则归为需求未澄清，退回澄清而非会上硬补 |
| 评审只看正文不看验收栏 | 查历史评审意见和会议记录，看是否出现过对验收条件的讨论 | 长期未讨论，说明评审检查项需要加入验收条件 |
| 验收条件写在别处 | 查关联文档、评论、测试用例草稿、需求附件，确认是否已有可判定的完成标准 | 确实存在则补链接或迁移到故事内，避免评审时看不到 |
排查顺序与证据要求
第一步查“是否真的没写”。验收条件可能写在需求文档、原型说明或测试用例里，只是没有回到用户故事上。查关联文档和评论记录，能排除“写在别处”的假设。第二步查“是否不可验证”。如果验收条件存在但用了笼统词，问题在表达而非缺失，处置动作是改写。第三步查“需求是否清楚”。前两步都排除后，仍写不出可判定标准，通常是业务规则、权限边界或异常流程没有结论，需要业务方参与澄清。
把假设变成可核对的结论
每种原因假设都要配一条可查的证据，避免会上凭印象下结论。例如，认为“模板没要求”，就打开模板确认字段；认为“评审没看”，就翻最近几次评审记录看有没有验收条件相关意见。证据不足时，先记为待确认，不把它写成改进结论。这样做的直接好处是：后续改模板、改检查项或退回澄清，都有依据，不会出现“改了模板但缺失依旧”的情况。
评审现场按什么顺序追问和补齐
评审会上的目标不是把所有缺失一次补完，而是把能判定的当场补齐，把不能判定的转成明确的待办。追问按边界、异常、可观察结果三类问题展开，每类问题对应一种缺失类型，顺序推进可以减少来回拉扯。
三类追问问题
- 边界问题：“这个动作对哪些数据、哪些角色、哪些状态生效？范围之外的行为是什么？”用于补齐范围缺失，也用于发现故事边界不清。
- 异常问题：“输入为空、权限不足、数据冲突、操作超时的时候，用户看到什么、系统留下什么记录？”用于补齐异常路径，这类内容最容易在正文中被省略。
- 可观察结果问题：“完成后，测试人员打开哪个页面、看到哪条记录或哪个状态变化，就可以判定通过？”用于把笼统词替换成可判定标准。
当场补齐与退回澄清的分工
当场能补齐的，是业务规则已经清楚、只是没有写进故事的内容。评审者追问后，作者现场补充验收条件，其他人确认无歧义，即可标记为已补齐。需要退回澄清的，是追问后暴露出业务规则本身没有结论，例如异常情况下应该拦截还是放行、不同角色的权限如何划分。这类问题继续在会上讨论会拖长评审，应记录问题、指定澄清责任人，并约定复查时点。
停止点的设置很关键：每条故事最多追问到“能写出可判定标准”或“确认需要业务澄清”为止，不展开技术实现讨论。技术方案可以在验收条件明确后另行评审，混在一起会让验收条件问题被实现细节掩盖。
记录缺失项、责任人和复查时点
评审结束前，把未补齐的故事整理成缺失清单，至少包含故事标识、缺失类型、待确认问题、责任人和复查日期。缺失类型沿用前面的三类标记，便于统计哪类问题反复出现。复查时点建议与下一次评审或迭代计划对齐，避免清单长期挂起。评审记录与故事本身放在同一处，后续复查时能直接对照原始讨论。
如果团队使用 ONES，可以把用户故事放在项目工作项中，把评审记录和待确认问题放在关联的 Wiki 文档里，文档支持关联项目任务，页面树便于按迭代组织评审材料；成员可以在线添加注释和评论，评审中的追问和结论能留在对应页面上，版本记录也便于复查时回看当时的表述。这样做的目的是让缺失清单和故事状态在同一处可见，减少复查时找不到上下文的情况。
补齐后如何验证并减少复发
验收条件补齐不等于问题解决。验证的标准有两条：测试人员能否直接把验收条件转成测试用例；评审者能否仅凭验收条件判定通过与否。两条都满足，才算补齐有效。只满足一条，说明表达仍有模糊空间，需要继续改写。
补齐后的验证检查项
- 每条验收条件是否对应一个可执行的测试步骤，而不是一句期望。
- 是否覆盖了正常路径之外的至少一类异常或边界情况。
- 验收条件中的角色、数据范围、状态变化是否与故事正文一致。
- 是否存在“正常”“友好”“快速”等无法判定的词，若有是否已替换为具体结果。
- 测试人员阅读后能否独立判断通过与否，不需要再向作者口头确认。
复查机制与评审检查项
复查安排在补齐后的下一次评审或迭代启动前，由原责任人确认缺失项是否关闭。复查时重点看两类遗留：一是当时退回澄清的问题是否已有结论并写回故事；二是新补的验收条件是否通过上面的验证检查项。评审检查项中固定加入“验收条件是否存在且可判定”一条，作为故事进入开发前的必过项，能减少评审时只看正文的习惯。
模板和流程上的小改动
复发预防不需要大改流程，几个小改动就能见效。在用户故事模板中固定验收条件栏，并给出填写示例，例如“在什么条件下，执行什么操作，观察到什么结果”；在评审材料准备阶段要求提交四栏对照表；在评审记录中保留缺失类型统计，定期看哪类缺失最多，针对性调整模板说明或澄清节奏。模板改动后，用一轮评审验证效果：如果完全缺失的比例下降，说明模板和检查项起了作用；如果不可验证的比例仍高，则需要加强验收条件的写法示例和评审追问训练。
把这些动作放进同一套记录里，复查时能同时看到故事、评审结论和缺失清单。ONES Wiki 的模板库可以用于统一评审记录和缺失清单的格式，文档版本记录便于对比补齐前后的表述变化；ONES Assistant 可将自然语言指令转化为 ONES 中可追踪的工作，适合把复查待办转成可跟进的事项。工具承载的是记录和跟进，判断验收条件是否可判定，仍由评审者和测试人员按上面的检查项完成。
常见问题
验收条件写在需求文档或测试用例里，评审时还需要回到用户故事上补一遍吗？
需要，但动作是补链接或迁移，不必重写。验收条件写在别处时，评审者当场看不到，容易默认缺失或凭印象讨论。处置方式是在用户故事中标注验收条件所在位置，或把可判定的完成标准迁移到故事内，让故事本身能独立回答“怎样算完成”。迁移时保留原文档链接，避免后续维护出现两份不一致的表述。
评审会上业务方不在场，遇到需要澄清的验收条件怎么处理？
不在会上硬补。追问后如果暴露出业务规则没有结论，例如异常情况下拦截还是放行、不同角色权限如何划分，就把问题记入缺失清单，写明待确认问题、澄清责任人和复查日期，复查时点与下一次评审或迭代计划对齐。会上只处理业务规则已清楚、只是没写进故事的内容，这样评审时间可控，也不会把假设当成结论写进验收条件。
验收条件补齐后，由谁确认可以进入开发？
建议由测试人员和故事作者共同确认。测试人员判断能否直接把验收条件转成测试用例，作者确认补充内容与业务规则一致，评审组织者核对缺失清单中的该项是否关闭。团队使用 ONES 时，可以把用户故事放在项目工作项中，评审记录和待确认问题放在关联的 Wiki 文档里，文档支持关联项目任务，成员可以在线添加注释和评论，复查时能直接对照原始讨论（F1、F2）。
团队验收条件缺失反复出现，先改模板还是先改评审流程？
先用证据判断主因再决定。查模板字段，确认是否存在验收条件栏和填写说明；查历史评审记录，看是否长期没有讨论过验收条件。模板缺字段就先改模板并给填写示例；模板有字段但普遍未填，问题更可能在评审检查项和评审习惯，应把“验收条件是否存在且可判定”固定为故事进入开发前的必过项。改动后用一轮评审看缺失比例变化，再决定是否继续调整。
验收条件里出现“性能良好”这类词，算缺失还是算写得不好？
算形式存在但不可验证，处置动作是改写而非补写。判断方法是试着把它转成一条测试用例：如果转不出来且原因是描述太模糊，就归入不可验证；如果转不出来且原因是不知道业务上应该怎样，才归入需求未澄清。改写时把笼统词替换为可观察结果，例如明确在什么数据量、什么操作下，响应时间或页面状态达到什么程度。
