更新时间： 2026年10月17日
原型验收不是看页面“像不像成品”，而是验证目标用户能否完成关键任务、团队能否解释状态和边界。用墨刀原型组织页面与交互后，按同一份任务脚本评审，结论才可复现。
一、把“验收通过”拆成四类标准
| 类别 | 需要确认 | 通过条件 |
|---|---|---|
| 任务 | 用户目标、入口、完成结果 | 按脚本完成且无关键阻断 |
| 交互 | 点击、输入、跳转、返回 | 每个动作有明确反馈 |
| 状态 | 加载、空、错、禁用、成功 | 状态出现条件和恢复方式清楚 |
| 交付 | 标注、链接、版本、负责人 | 研发能定位页面和规则 |
二、写一份可执行的任务脚本
以“新用户注册并完成首个项目”为例，脚本应写出前置条件、操作步骤和观察点：打开注册页；输入已注册手机号；查看错误提示；改用新手机号获取验证码；创建项目；返回工作台确认项目存在。每一步都记录预期结果，不能只写“体验注册流程”。
- 准备正常、已存在、格式错误和网络失败四组数据。
- 沿主路径操作一次，再从每个关键节点走一条异常路径。
- 记录阻断点、歧义点和可接受的小缺口，标明复现步骤。
- 评审结束将结论绑定到页面或交互节点，并指定处理人。
三、用三张表收口结论
- 问题表：记录页面、复现步骤、实际结果、预期结果和严重级别。
- 状态表：列出每个页面需要覆盖的加载、空、错误、权限和成功状态。
- 交付表：记录页面链接、标注、接口依赖、版本和确认人。
验收结论不要只写“通过”。建议使用“通过、带条件通过、阻断”三种状态；带条件通过必须写清未完成项、负责人和复验时间。
四、发布前抽查
- 随机让产品、设计、研发各执行一遍主任务，比较是否得到相同结论。
- 检查关键按钮是否可发现，长文案和错误提示是否遮挡内容。
- 核对版本号、评论和导出资源是否指向同一份原型。
- 将最终结论和未决项一并交付，避免把未验证的假设写成实现要求。
五、把评审结论转成研发可执行项
对每个阻断问题补充影响范围、处理建议和复验条件。例如“验证码错误后按钮仍可点击”应写成：输入错误验证码时显示错误提示，保留手机号，按钮进入可再次获取状态；复验时使用错误、过期和已使用三组验证码。研发拿到的是行为规则，而不是“优化一下验证码体验”的模糊意见。
六、原型验收结果的保留方式
| 结论 | 适用场景 | 必须附带 |
|---|---|---|
| 通过 | 主路径和关键状态均满足要求 | 版本、脚本、确认人 |
| 带条件通过 | 有明确不影响本期上线的缺口 | 缺口、负责人、复验时间 |
| 阻断 | 任务无法完成或规则未确认 | 复现步骤、影响、解决方案 |
把结论放在原型版本或评审记录中，并为每个问题保留页面锚点。这样后续改动可以快速核对是否解决原问题，也避免把未验证的假设直接带入开发。
把主流程和异常路径跑通后，再把本页的复现记录与交付结果放在同一份版本记录中，后续评审可以直接追踪。
案例：用“支付失败”脚本验收订阅原型
以订阅购买为例，先写清验收对象：新用户选择套餐、完成支付、支付失败后再次尝试。任务脚本要包含入口、测试数据和结束条件，例如“在网络中断后仍能看见失败原因，并能回到支付页重试”。不要只截一张成功页面。
- 准备一个未订阅账号和一个已订阅账号，分别检查可见套餐与权限。
- 依次执行正常支付、余额不足、重复点击和返回上一页四条路径。
- 在原型中给每个异常状态编号，记录触发条件、提示文案和恢复动作。
- 让产品、设计和研发各自复述一次结论，分歧写入问题单并指定负责人。
| 验收证据 | 合格条件 | 交付物 |
|---|---|---|
| 任务录屏或操作记录 | 关键路径可复现 | 脚本、账号与版本号 |
| 状态清单 | 正常、异常、加载均有说明 | 状态编号与页面锚点 |
| 问题结论 | 每条缺口有优先级和负责人 | 评审记录与复验日期 |
当所有阻断项关闭后，再把验收结论同步到研发任务；未解决但不阻断的体验问题要保留在版本记录中，避免“通过”被误解为没有任何缺口。
