“筛选要好用”“手机上也要漂亮”“功能已经做完了”，这些话在讨论中很常见，却很难作为交付依据。提出需求的人以为已经讲清，执行的人也觉得完成了，最后验收时才发现双方想的不是同一件事。
解决办法不是给需求文档增加更多形容词，而是分清三件事：用户要达成什么、系统应该怎样表现、用什么方式检查。用户故事、业务规则和验收标准分别承担这三个任务。
先写目标，给实现保留讨论空间
用户故事可以采用这样的句式：“作为某种角色，我希望完成某个目标，以便获得某种价值。”例如：“作为新客服，我希望找到岗位相关资料，以便在咨询前完成准备。”这是虚构的教学情境。
这句话没有决定必须使用下拉框、卡片还是智能推荐。因为用户要的是找到资料，而按钮长什么样只是可能的实现办法。过早把目标写成界面方案，会让团队错过其他选择。
用户故事也不是完整规格。它开启讨论，不能代替数据来源、筛选逻辑、权限、异常处理等具体规则。
把“好用”拆成前提、动作和结果
验收标准可以借用 Given / When / Then，即“给定前提／当发生动作／则出现结果”。不必拘泥于英文格式，关键是每条约定都能观察、能检查，失败时也知道差在哪里。
以课程岗位筛选为例，先约定标签由谁维护，未选择时显示什么，多种条件如何组合，清除后是否重置结果。没有说清的规则应列为待确认，不能让执行者各自猜测。
| 序号 | 检查场景 | 一条可核对的验收约定 |
|---|---|---|
| 1 | 正常筛选 | 给定课程已有岗位标签，选择某岗位后，只展示匹配内容。 |
| 2 | 清除条件 | 已有筛选条件时执行清除，恢复约定的默认结果并清掉选中状态。 |
| 3 | 没有结果 | 没有匹配内容时，说明当前无结果，并提供可用的清除入口。 |
| 4 | 手机操作 | 在团队约定的测试屏宽下，筛选可操作，正文没有横向溢出。 |
| 5 | 权限边界 | 无管理权限的使用者不能修改课程，直接请求接口时也要被服务端拒绝。 |
这些约定是示例，不是现成业务规格。实际标签、默认排序、文案和测试尺寸，需要结合系统现状确认。
不要只验收顺利的一条路
功能在有数据、网络正常、账号权限正确时能用，只说明一种条件成立。空结果、输入变化、移动端和权限边界，同样属于使用过程。
尤其要区分“界面不显示按钮”和“服务器不允许操作”。隐藏按钮可以改善界面，却不能单独构成权限控制。验收时需要检查服务端对直接请求的授权判断，避免把可见性当成安全性。
检查范围也要留下记录。例如，完成了桌面筛选测试，不等于所有手机尺寸都验收过；测试环境通过，不等于正式网站已经发布。把执行、验收与上线分开，团队才知道还剩哪一步。
小改动可以简洁，复杂流程必须补足约束
PRD（产品需求文档）的价值在于减少歧义，不在于页数。一个小改动可能一页就够；涉及复杂流程时，还应写清数据、依赖、错误处理、性能和回退安排。
同时写出范围外事项。例如，这次只增加岗位筛选，不重做课程内容，也不开发个性化推荐。这样可以防止一个小故事在执行中不断膨胀，最后没有清楚的结束条件。
用 AI 补漏，用证据确认完成
可以请 AI 从正常、异常、边界和权限四个角度检查草案。它提出的规则应当作为建议或待确认问题，不能因为文字完整就变成业务承诺。
验收前留一份简短检查表：故事目标是否清楚？关键规则是否确认？是否覆盖空结果和权限？验证的是哪个版本、哪个环境？哪些项目尚未检查？
当“完成”后面有了对应的条件、动作和证据，讨论就不再停留在“我觉得可以”。双方能看到的是同一份交付约定，也更容易处理后续变化。
本文依据颜词魔方《用户故事与验收：把需求变成可执行方案》加工整理；原课程访问需登录。示例未对应真实项目的测试结果或上线承诺。
转载请注明：三五二萌文网 » “做得好”如何验收？把一句需求写成可检查的交付约定
