设计稿还原检查：像素对齐不是唯一标准
一、还原度不只看截图相似
前端交付常要做设计稿还原检查。截图对比能发现间距、颜色、字体、圆角这些偏差，但它不是全部。一个页面截图相似，可能响应式一塌糊涂；首屏看起来对，交互状态可能完全没做；静态像素对齐了，性能和可访问性可能很差。
设计稿还原检查要同时看视觉、状态、响应式和工程质量。
二、先定义检查层次
flowchart TD A[设计稿] --> B[静态视觉] A --> C[交互状态] A --> D[响应式断点] A --> E[可访问性] B --> F[还原报告] C --> F D --> F E --> F静态视觉只是第一层。按钮 hover、disabled、loading、错误态、空状态、长文本、暗色模式都应该进入检查范围。
design_check_scope: visual_diff: true interaction_states: true responsive_breakpoints: [375, 768, 1440] accessibility: true范围写清楚，设计走查就不会只盯一张截图。
三、截图对比要有容忍度
type VisualDiffConfig = { threshold: number ignoreRegions: string[] viewport: { width: number; height: number } }浏览器、字体渲染、抗锯齿都会造成细微差异。视觉对比需要合理阈值，并允许忽略动态区域，比如时间、头像、随机图。
但阈值不能太宽。太宽会漏掉真实偏差，太严会制造噪声。建议对核心组件阈值更严格，对内容区域稍微放宽。
四、AI 可以辅助解释差异
AI 可以读取 diff 图片和 DOM 信息，生成更接近人话的说明：某个按钮左边距偏大、标题字号不一致、移动端换行压住图标。它适合做“差异翻译”，不适合单独决定是否通过。
ai_visual_report: explain_diff: true group_by_component: true mark_severity: true require_human_acceptance: true还要把差异映射到组件。报告只说“右上角有偏差”不够，最好能指出UserMenu或PrimaryButton。这样开发者才能快速定位代码。
设计稿还原也要和 token 系统联动。颜色、字号、间距如果没有使用 design token，即使当前页面对了，后续维护也会变难。检查报告可以标注硬编码样式。
最后，不要让像素对齐压过用户体验。动效过慢、焦点不可见、键盘不可操作、长文本溢出，这些问题比 1px 偏差更值得优先修。
还原检查要接入验收流程。设计师确认视觉偏差，测试确认状态覆盖，前端确认 token 和组件实现。不要让一份截图 diff 报告同时承担所有角色的判断。
design_acceptance: designer_review: visual_and_spacing qa_review: states_and_responsive frontend_review: token_and_component如果团队有组件库，还可以把高频组件的还原检查前移到组件层。按钮、弹窗、表单项在组件层稳定了，业务页面就少很多重复偏差。
最后，报告要区分阻塞和建议。主流程按钮错位、表单不可用是阻塞；极小的抗锯齿差异可以记录但不阻塞。没有优先级的还原报告，会变成吵架材料。
五、总结
设计稿还原检查要覆盖静态视觉、交互状态、响应式断点、可访问性和 design token 使用。
像素对齐只是起点。页面能在真实状态下稳定、可用、可维护，才算还原到位。
