等到全部开发完成，再让设计师集中挑“这里差两像素”，通常已经太晚。组件实现错了，几十个页面都会跟着错；真实接口一接入，空状态、错误和长数据才暴露；上线前只对截图，又会漏掉完整操作。设计走查应该伴随开发推进，越早发现系统性问题，修复成本越低。
01 设计走查不是视觉验收的另一种叫法
它要确认设计意图是否被完整实现，包括信息层级、交互反馈、业务状态、响应式、可访问性、内容和视觉。纯粹比较颜色与间距，只能发现表面差异；只走业务流程，又可能让品牌和组件逐渐失真。
02 建议设置五个检查节点
| 节点 | 重点检查 | 为什么不能更晚 |
|---|---|---|
| 1. 基础组件完成时 | 字体、颜色、间距、按钮、表单、弹窗和布局容器 | 组件错误会被复制到所有页面 |
| 2. 首条端到端流程完成时 | 入口、输入、提交、结果、返回与恢复 | 先验证实现方式是否正确，再批量开发 |
| 3. 真实接口联调时 | 加载、空、失败、权限、长数据和时序 | 静态Mock无法暴露真实状态 |
| 4. 预发布环境 | 多设备、浏览器、缩放、内容、埋点与性能 | 上线前最后一次完整复测 |
| 5. 正式上线后 | 生产配置、缓存、字体、第三方脚本与真实数据 | 测试环境通过不代表生产环境一致 |
03 第一次走查先看系统性问题，不要从某个图标开始
若字体加载方式、容器宽度、间距Token或按钮组件实现错误，后面每一页都会出现同样偏差。第一轮应优先检查基础组件、栅格、响应式和交互模式。系统性问题一旦确认，由开发修复底层，不要在几十个页面逐项贴补丁。
04 一定要用真实数据和真实角色
设计稿常使用完美数据：名称短、金额整齐、列表有三条、用户有全部权限。走查时需要准备长文本、空数据、极值、过期内容、接口失败、不同角色和多语言。B端系统还要检查数据范围、字段级权限、操作记录和状态冲突。
截图对得上，只能证明某一瞬间相似；完整任务跑得通，才接近真实还原。
05 先固定走查基准，避免双方看到的不是同一个页面
开始走查前要统一环境、版本、浏览器、视口、账号角色、测试数据和设计稿版本。设计师在1440px桌面看到的问题，可能在开发的缩放比例或旧缓存中完全不同。建议每轮走查在任务开头写明基准，并为关键页面保留标准截图或录屏。
- 确认预发布地址与构建版本，禁止同时在多个旧环境记录问题。
- 准备普通用户、管理员、无权限用户等代表性账号。
- 使用真实或脱敏的长数据、空数据、失败数据，不只看默认Mock。
- 明确本轮检查范围：结构、状态、响应式还是视觉细节。
- 记录设计文件的页面、组件和版本，避免修复后找不到依据。
06 问题必须分级，否则所有人都会把自己的问题标成“紧急”
| 级别 | 定义 | 示例 | 处理要求 |
|---|---|---|---|
| P0 阻塞 | 核心任务无法完成或存在重大安全风险 | 无法登录、支付错误、越权访问 | 阻止上线，立即修复并复测 |
| P1 高风险 | 业务结果、数据或关键体验明显受损 | 提交无反馈、金额显示错误、关键状态缺失 | 上线前修复 |
| P2 一般体验 | 不阻塞任务，但造成理解或操作成本 | 焦点不清、长文本溢出、交互反馈弱 | 排入当前版本或明确计划 |
| P3 视觉细节 | 对任务影响较低的局部差异 | 轻微间距、非关键图标偏差 | 集中修复，避免打断主线 |
07 每条问题要写到别人能复现
| 字段 | 填写示例 |
|---|---|
| 环境 | 预发布 / Chrome 136 / Windows / 1440px |
| 页面与角色 | 订单详情 / 财务管理员 |
| 复现步骤 | 从订单列表进入详情，点击“退款”，提交空原因 |
| 预期结果 | 字段显示错误并聚焦，弹窗不关闭 |
| 实际结果 | 弹窗关闭且页面无反馈 |
| 证据 | 截图或短视频，并标注位置 |
| 级别与负责人 | P1 / 前端 / 计划在本周版本修复 |
“这里不对”“和设计稿不一样”不是可执行问题。记录越具体，开发越容易定位，复测也越客观。若涉及设计本身需要调整，应建立新的设计决策，而不是把所有差异都归为开发Bug。
08 一次走查不要同时检查所有维度
可以按层次推进：先结构与流程，再状态与权限，再响应式与可访问性，最后视觉细节。复杂项目可分角色、模块或平台检查。每次都要明确范围和通过条件，否则会议容易变成设计师现场浏览页面，问题散落在聊天记录里。
09 设计、产品、开发和测试分别负责什么
| 角色 | 主要责任 |
|---|---|
| 设计 | 检查信息层级、组件、状态、响应式、内容呈现与视觉一致性 |
| 产品 / 业务 | 确认业务规则、角色权限、文案和验收优先级 |
| 开发 | 说明实现限制、定位原因、修复方案与影响范围 |
| 测试 | 建立可重复场景，验证问题关闭并进行回归 |
| 项目负责人 | 控制范围、排期和上线门槛，处理争议与遗留项 |
10 问题关闭不等于开发说“已修复”
- 在指定环境按原步骤复测，确认问题确实消失。
- 检查修复是否影响相同组件、其他角色和其他尺寸。
- 更新设计文件、组件或规范，避免下一次继续使用旧规则。
- 若暂不修复，记录原因、风险、负责人和计划版本。
- 上线后抽查正式环境，确认资源、缓存和第三方配置没有产生新差异。
11 走查质量可以这样复盘
观察系统性问题占比、同类问题重复次数、从发现到关闭的时间、上线后漏出缺陷，以及哪些设计说明最常被误解。目标不是让问题单越来越长，而是让下一轮开发更少产生同类问题。
常见问题
设计走查应该从开发到什么程度开始？
基础组件或第一条完整流程可运行时就应该开始。越早确认实现方式，越能避免错误被复制。等到全部页面完成才走查，成本最高。
设计师需要检查代码吗？
不一定。设计师主要验证表现和行为，开发负责代码质量。但对设计Token、组件映射、响应式和可访问性，双方需要共同确认实现规则。
项目时间很紧，哪些步骤不能省？
至少保留基础组件检查、核心端到端流程、真实接口状态和上线前多设备复测。视觉细节可以分级，但关键任务、权限和错误恢复不能跳过。
设计走查和测试验收有什么区别？
测试更关注功能是否符合需求和是否存在缺陷；设计走查关注设计意图、交互、状态、响应式和视觉是否完整落地。两者重叠但不能互相替代。
相关服务与进一步咨询
链接复制成功
