设计评审验证确认之间有什么区别

做产品的人常遇到这种场面：会上有人说「这个评审过了就没问题了」，结果上线还是出岔子。问题多半出在把评审、验证、确认当成了同一件事，谁来签字、签的是哪一层、没通过该退回到哪一步，全糊在一起。这篇把三个环节拆开讲：各自回答什么问题、进出的材料是什么、什么情况下可以跳过、什么情况下千万别省。

做产品的人常遇到这种场面：会上有人说「这个评审过了就没问题了」，结果上线还是出岔子。问题多半出在把评审、验证、确认当成了同一件事，谁来签字、签的是哪一层、没通过该退回到哪一步，全糊在一起。这三件事看着都像「检查」，其实问的问题完全不同：一个问方案对不对，一个问做得对不对，一个问用起来对不对。

这篇把三个环节拆开讲：各自回答什么问题、进出的材料是什么、谁该拍板、什么情况下可以跳过、什么情况下千万别省。读完你至少能拿着一张清单去排会、去分派责任，而不是每次靠谁嗓门大来定流程。

三个词被混用，代价出在哪

最典型的混淆是拿评审签字当成交付凭证。方案评审本质是对着一份还不够完善的稿子挑问题，通过只代表「方向可以往下走」，不代表东西已经做对、更不代表用户会买账。一旦把这三层压成一次会，后面出事时没人说得清是哪一层没做。

评审

对着方案稿问「这个思路可行吗、约束考虑全了吗」，回答的是方向问题

验证

对着写下来的要求逐条核对「做出来的东西符合要求吗」，回答的是符合性问题

确认

放到真实使用场景里看「在预期条件下能达成预期用途吗」，回答的是可用性问题

• 把评审签字当交付凭证：签字只说明方向认可，不代表实现正确、更不代表用户接受
• 把验证通过当用户认可：内部测试全过，真实场景里照样可能没人用
• 责任人模糊：三个环节到底谁提、谁执行、谁裁定说不清，出问题只能互相推
• 记录混在一份文档里：事后复盘分不清是要求写错了，还是实现做偏了，还是场景没覆盖

设计评审：什么时候开、拿什么开

评审的输入应该是可讨论的方案稿，比如结构图、接口约定、原型、约束清单，而不是已经写完的完成品。拿完成品来评审，本质上是在做验收，提的意见要么代价巨大要么没人敢改，会议就退化成通报。

1. 确认输入是稿不是成品检查材料里有没有明确的可选项、待定项和约束条件；如果只有一套已经落地的实现，说明时机已过，改做变更评估
2. 挑在改起来还便宜的阶段开判断标准很简单：现在改这个方案的代价，是否明显低于改完之后再回头改；答案是否定的话，评审收益很小
3. 会前把反对意见收一遍发给参会人并要求书面回填顾虑点，现场只处理分歧，不现场做阅读理解，这样能省掉大量空转时间
4. 会上必须有人拍板指定一位决策人，对每条分歧给出结论、责任人和时限，写在会议记录里，而不是散会各回各家

不适用的情况也要说清：如果需求本身还没定、关键决策人压根不在场，这会开了也只是记录一堆意见，直接改成小范围对齐更省时间。评审不是流程里必须打卡的环节，它服务于「趁早发现方向问题」这个目的，目的达不成就没必要硬开。

验证：对着写下来的要求逐条核对

验证的核心动作只有一个：把要求变成可测的条目，再逐条给出通过或不通过的结论。这里的关键不是测试本身，而是要求有没有写到可测的程度。「界面要流畅」没法验证，「列表滚动到某位置不出现停顿」才能验证。

要求写得含糊，验证就只能靠感觉，最后变成「我觉得差不多」。所以先修要求的可测性，再谈验证手段。典型手段包括检查表、测试用例、走查，以及用工具跑质量与速度相关的检测；具体工具和当时可用的检测项，可以到站内的工具目录和速度检测页面看当时的情况。

• 每条要求对应一条可复现的检查记录，能被人按步骤重现
• 结论只有通过与不通过两种，不允许「基本通过」这种中间态
• 顺利路径之外的异常输入、边界值、重复操作必须覆盖
• 验证的执行方最好不是写要求的人，避免自己给自己打分
• 未通过项要有明确的回退去向：是改实现，还是改要求

确认：换到真实使用场景里再看一遍

确认的输入是真实场景和真实使用者的反馈，不是内部人员对着文档想象出来的场景。它关注的是「在预期使用条件下能不能达成预期用途」，包括误用、极端输入、以及团队压根没想到的用法。

实操上，确认最容易敷衍。常见的敷衍方式有三种：找几个同事试用几分钟就说验证完毕；只跑顺流程不碰异常操作；由写方案的人自己下结论。这三种都算不上确认。

1. 把场景来源写清楚每个确认场景都要注明来自哪类真实使用者、在什么情境下用；来源说不清的场景，先不纳入确认范围
2. 明确观察期和观察指标约定看多久、看什么信号；没有观察期的确认等于一次性演示，演示好看不代表长期可用
3. 让贴近使用方的人参与结论产品经理不能自己替用户确认；至少要有一线或真实使用方的角色参与判断
4. 写下不通过怎么办区分是现象要修，还是要求本身要改；后者要退回更早的环节，不要就地打补丁

谁签字、谁负责：角色分工对照

三个环节最怕的就是责任人模糊。评审通常由方案提出方主讲、跨职能角色挑问题、指定决策人拍板；验证由提出要求的一方定义标准，另一方能独立执行；确认的责任主体应当包含最终使用方或贴近使用方的角色。

一个可直接照做的做法：每个环节先写清「谁提出、谁执行、谁裁定、谁记录」这四件事，写不出来的话就先别排期。四件事里最容易被漏掉的是「谁记录」和「谁裁定」，前者导致复盘无凭据，后者导致会开完没人负责。

• 谁提出：不是提需求的人，而是这一环节要解决什么问题的定义者
• 谁执行：最好与提出方分离，避免自证清白
• 谁裁定：对分歧有最终决定权，且承担决定后果
• 谁记录：把结论、反对意见、回退去向写成可检索的文档
• 写不清四件事就先别排期，排了也是白开

顺序、回退与迭代：三者不是流水线

正常顺序是先评审再验证再确认，但这三个环节不是单向流水线，而是带回路的过程。发现要求本身有误时，要退回评审改要求，而不是硬着头皮把错误的要求验证到通过。

确认不通过往往暴露的不是实现问题，而是要求层面的问题：要求一开始就写得含糊，或者根本没有覆盖真实使用场景。这种情况下直接修现象容易反复，正确做法是顺着现象往上追，看是哪条要求没写清、哪个场景没被纳入评审范围。

• 同一类问题第一次出现：当作实现问题，修掉并补验证条目
• 同一类问题第二次出现：说明要求写错了，退回评审改要求
• 确认阶段反复推倒重来：优先怀疑场景来源不真实，而不是加测一轮
• 评审结论被反复推翻：检查是不是决策人一直没到场，讨论没有收敛点
• 判断标准很简单：同类问题第二次出现就退回到更早的环节，而不是加大检测力度

签字前的落地清单

把下面这张清单放到签字之前过一遍，能过滤掉大部分「签完才发现漏了」的情况。清单本身不复杂，难的是每次都不跳步。

• 评审：方案稿齐全、决策人到场、每条反对意见都落到责任人和时限上
• 验证：每条要求都能指向一条可复现的检查记录，结论只有通过与不通过两种
• 确认：场景来源真实、观察期明确、不通过的处置路径写在纸面上
• 留痕：三个环节分开存档，避免事后分不清哪一步是漏掉的
• 回退条件：任何一环不通过，先明确退回到哪一步，再动手改

存档方式建议按环节分目录，命名里带上环节名而不是日期或版本，这样半年后搜索时能找到。要对照站内对这些概念的整理和历史条目，可以到站内的指南中心查看当时的版本，避免与团队内部口径冲突。

常见踩坑与什么时候可以省一步

踩坑通常集中在三处：评审结论写成「基本没问题」这种没法执行的表述；验证只覆盖顺利路径，异常输入压根没测；确认由写方案的人自评，等于自己给自己发证。这三处只要出现一处，前面做的工作都会被打折。

可以省一步的情况：改动可秒级回滚、影响面局限在单点、没有对外承诺。不可以省的情况：涉及对外承诺、数据口径、合规要求，或者覆盖面广且回滚代价高。判断标准就一条：如果这一步漏了之后最坏结果无法快速撤回，那就别省。