设计交付之后，才开始面对真实设备。

同一份设计，并不自动得到同一个结果

字体支持、设备性能和渲染实现会改变最终体验。双端走查需要记录设备条件与复现步骤，而不是只用截图指出“和设计稿不一样”。

原始项目作品集

历史实例：创作预览与消费端怎样保持同一意图

对着图看这几处

• 左侧创作预览，右侧百度 App 消费端；比较标题、正文与图片的对应关系。
• 它说明跨端验收要看实际链路，不把这张历史图当成 Samer PAG/SVGA 的问题截图。

一次格式回调，暴露了设计的运行条件

上半年工作记录里，VIP 标识、座驾与主页装扮的 PAG 物料在部分低端 Android 机型出现卡顿或渲染异常。设计侧推动回调为 SVGA，不是因为某个格式普遍更好，而是当前资源、设备与接入条件下需要更稳妥的交付。

这个取舍把画质与性能放进同一个决策：如果只验收设计软件里的观感，格式问题会在最晚、最难改的时候才出现。后续应在制作前用代表性素材跑通端上样例。

已修复、待调研，需要用不同状态说清

Android 字体当时仅支持 Normal/Bold 的限制被记录并推动研发调研；YYEVA 动态礼物边缘黑边也推动 Android 侧研究。资料没有证明这两项已经彻底修复，因此不能在复盘里一并写成完成。

159 个问题闭环，具体说明了什么

v1.0.0 两轮双端走查共修复 124 条 Case；v1.1.0 再闭环 35 条，共 159 条。这说明有具体问题被跟进与复验，不等于缺陷率下降 159%，也不能单独代表所有体验问题都已覆盖。

两轮的意义不同：第一轮暴露主要偏差，第二轮检查修复有没有造成新的问题。仅把截图交给研发，还没有完成设计侧的复验责任。

1. 01

   复现

   记录设备、系统、构建、素材和操作路径。

2. 02

   定位

   区分设计规则、素材导出和渲染实现问题。

3. 03

   修复与复验

   保留预期、实际、负责人和复验结果。

4. 04

   回写规则

   把格式、字重与设备例外写入组件和交付清单。

AI 可以参与交付，但不能代替设备

Figma MCP 与 AI Coding 的 H5 探索，是减少设计到实现重复劳动的一条路径。它没有取消字体、渲染、资源与交互状态的真实检查。

自动化视觉走查是下一阶段方向，而不是当前已经上线的基础设施。可以先从少量高风险组件和固定状态建立回归集，再决定是否扩展。

格式选择是体验和工程之间的取舍

动效格式需要同时考虑视觉还原、运行性能和接入成本。PAG、SVGA 等方案应结合真实设备验证，需要时给出回退方案。不能把某个格式在一个样例里的成功，当作全部场景的保证。

把复验结果带回规则

一次问题修复如果只停留在聊天记录，下个版本可能再出现。把字重限制、素材导出要求和已知兼容问题沉淀到组件与交付清单里，才能减少重复损耗。

原始项目作品集

另一处对照：发布成功之后，端间语义是否一致

对着图看这几处

• 两端都要清楚告知提交状态和下一步，但布局不必机械相同。
• 图中文字关于流失的描述是当时设计目标，不作为本次补充的量化效果。