0、先破后立：别再把一致性验收当"截图叠一叠"，那只验到了皮；真正决定口碑的是状态、交互、可读性这些细节。
很多团队验收 UI，一上来就盯着间距、颜色、圆角，像在做找不同。结果页面看起来差不多，一用就露馅：按钮禁用态不对、加载时抖一下、错误提示像系统弹窗、键盘操作卡死、弱网下完全没反馈。设计和代码的一致，最后会体现在一句话上：用户用起来是不是同一种产品。这篇只讲能落地的验收办法，不讲玄学。
1、交付：一致性验收要先把"对照物"交齐，否则你验的是空气。
一句话中心论点：没有可对照的交付物，就没有可执行的验收。
最少要有四样东西，缺一项都容易扯皮：
- 设计源：最终稿链接（页面、组件、状态都在同一个入口里）。
- 规格口径：token/间距/字号/颜色/圆角等基础规则的文字说明或表。
- 组件清单：项目里实际可用的组件列表（Button、Input、Modal、Table...），以及每个组件支持的状态。
- 验收入口：可访问的测试环境 + 路由清单 + 账号权限说明（不然"我这打不开"能聊半天）。
交付物齐了，验收就从"对感觉"变成"对清单"。
2、可控：一致性不是"做到一模一样"，而是"差异有规则、问题可定位"。
一句话中心论点：能控制的差异才是可接受的差异。
建议把差异分三类，验收时直接贴标签：
- 允许差异（OK） ：跨端系统控件差别、字体渲染差异、少量像素抖动（例如 1px 以内），前提是文档写明。
- 必须一致（Must） ：品牌主色与层级、组件形态、交互反馈、错误与权限状态、关键间距节奏。
- 禁止差异（Blocker） ：误触风险（危险按钮不明显）、信息误导（成功/失败状态相反）、可访问性缺失（键盘不可达、对比度不足导致看不清）、权限绕过。
这样做的好处是：每个问题都能落到一个类目里，不会变成"我觉得严重/你觉得还行"。
3、复现：验收必须可复现；复现的核心不是"你看到了没"，而是"别人能不能稳定重现"。
一句话中心论点：一致性问题要能复现到"某组件在某状态下"。
推荐你把验收过程写成"状态驱动"的路径，而不是"页面驱动"的路径：
- 组件维度复现：在 UI Playground（组件展示页）里复现问题，能最快定位是组件错还是页面拼装错。
- 状态维度复现：同一组件至少拉齐这些状态：default / hover / active / focus / disabled / loading / error / empty。
- 数据维度复现：三种数据包必测：正常数据、极长文本（溢出）、空数据（为空态）。
- 环境维度复现：弱网、暗色模式（若支持）、不同缩放（浏览器 90%/110%）、不同分辨率断点。
你会发现，一旦按"组件×状态×数据×环境"写清楚，80% 的一致性争论会自动消失。
4、成本：别把验收做成"全页面逐像素巡检"，那会把团队拖进无底洞；要用抽样与高风险优先。
一句话中心论点：一致性验收的省钱策略，是先抓"高频+高风险"，再补"低频+装饰"。
实用做法：
- 先验组件，再验页面：组件对了，页面自然少错；反过来会越验越多。
- 高风险清单优先：登录/注册、支付/下单、删除/解绑、权限相关页面，优先级永远最高。
- 抽样验收：同类型页面抽 20% 做深度验收，其余跑"快速清单"。
- 问题回灌：同类问题出现两次，就升级为规则或组件修复；别每个页面都修一遍。
记住一个很现实的结论：验收不是为了"零差异"，是为了"零意外"。
5、安全：一致性验收里，最该严的是"误操作防线"和"信息展示边界"，这两块一错就出事故。
一句话中心论点：界面一致性也带安全属性，尤其是提示、权限、敏感信息。
验收时强制检查：
- 危险操作是否显著：删除/清空/发布等按钮颜色、文案、二次确认是否符合规范；默认焦点有没有落在危险按钮上。
- 权限态是否统一：无权限是隐藏还是置灰，提示语是否一致，是否会泄露不该看到的字段。
- 敏感信息是否脱敏：手机号、证件、地址、金额等展示规则是否一致；复制、下载、截图提示是否按规范。
- 错误提示是否克制：不能把内部错误堆栈、表名路径直接吐给用户；同时又要给排查留证据（错误码、traceId）。
这块宁愿严格一点，也别用"先上线再说"赌运气。
6、体验对齐：从像素到体验，关键是"反馈及时、操作连续、信息层级稳定"，用户不会为你的对齐难度买单。
一句话中心论点：体验对齐检验的是"用起来顺不顺"，而不是"看起来像不像"。
建议把体验对齐拆成五个可验点：
- 反馈：点击后 200--500ms 内是否有响应（loading、骨架、按钮忙碌态）。
- 连续性：弹窗打开/关闭是否突兀；列表刷新是否跳动；布局是否抖动（尤其 loading 切换）。
- 可读性：信息层级是否清晰；关键数据是否被弱化；长文本折行、溢出、省略号策略是否一致。
- 可操作性：键盘 Tab 顺序、回车触发、Esc 关闭弹窗、焦点回收是否符合规范。
- 容错：空态是否告诉用户下一步；错误态是否给出可执行动作（重试、联系管理员、返回）。
这些点不靠审美，靠检查路径。验收时让测试按脚本走一遍，问题会很快暴露。
快速测评清单（照着跑，十几分钟就能看出"像素对齐"还是"体验对齐"）
- 对照物齐不齐：设计源、token 口径、组件状态表、测试环境入口是否一键可达。
- 组件优先是否落实：问题能否在 UI Playground 复现到具体组件，而不是只在某页面"玄学出现"。
- 状态是否齐全：hover/focus/disabled/loading/error/empty 有没有缺；缺一个就记为一致性风险。
- 数据边界是否过关：极长文本、空数据、超多行列表时布局是否稳定，是否溢出遮挡。
- 弱网体验是否有反馈：请求慢时是否有骨架/加载态，按钮是否防连点。
- 交互细节是否一致：弹窗焦点、Esc 关闭、Tab 顺序、回车提交是否符合规范。
- 危险操作是否安全：危险按钮样式与二次确认是否到位，默认焦点是否安全。
- 权限与敏感信息：无权限提示是否统一；敏感字段是否按规则脱敏。
- 差异分类是否可执行：每个问题能否归到 OK/Must/Blocker，不再靠"各执一词"。
- 问题是否回灌：同类问题是否升级为规则或组件修复，而不是在多个页面重复打补丁。