同一份设计，并不自动得到同一个结果
字体支持、设备性能和渲染实现会改变最终体验。双端走查需要记录设备条件与复现步骤，而不是只用截图指出“和设计稿不一样”。
历史实例：创作预览与消费端怎样保持同一意图
- 左侧创作预览，右侧百度 App 消费端；比较标题、正文与图片的对应关系。
- 它说明跨端验收要看实际链路，不把这张历史图当成 Samer PAG/SVGA 的问题截图。
一次格式回调，暴露了设计的运行条件
上半年工作记录里，VIP 标识、座驾与主页装扮的 PAG 物料在部分低端 Android 机型出现卡顿或渲染异常。设计侧推动回调为 SVGA，不是因为某个格式普遍更好，而是当前资源、设备与接入条件下需要更稳妥的交付。
这个取舍把画质与性能放进同一个决策：如果只验收设计软件里的观感，格式问题会在最晚、最难改的时候才出现。后续应在制作前用代表性素材跑通端上样例。
| 检查项 | 需要的证据 |
|---|---|
| 视觉还原 | 同一素材的端上对照，不比较不同设计 |
| 运行表现 | 明确设备、版本、播放条件与异常 |
| 接入与回退 | 格式支持、替换成本、失败时如何降级 |
已修复、待调研，需要用不同状态说清
Android 字体当时仅支持 Normal/Bold 的限制被记录并推动研发调研；YYEVA 动态礼物边缘黑边也推动 Android 侧研究。资料没有证明这两项已经彻底修复，因此不能在复盘里一并写成完成。
| 问题 | 记录支持的状态 | 设计侧动作 |
|---|---|---|
| PAG 低端机异常 | 推动格式回退 | 调整交付格式并联动研发 |
| 字重限制 | 待技术方案调研 | 记录差异，不假装字重已完整支持 |
| YYEVA 边缘溢出 | 推动 Android 调研 | 定位框架差异并留存复现条件 |
159 个问题闭环，具体说明了什么
v1.0.0 两轮双端走查共修复 124 条 Case；v1.1.0 再闭环 35 条，共 159 条。这说明有具体问题被跟进与复验，不等于缺陷率下降 159%，也不能单独代表所有体验问题都已覆盖。
两轮的意义不同：第一轮暴露主要偏差，第二轮检查修复有没有造成新的问题。仅把截图交给研发，还没有完成设计侧的复验责任。
- 01
复现
记录设备、系统、构建、素材和操作路径。
- 02
定位
区分设计规则、素材导出和渲染实现问题。
- 03
修复与复验
保留预期、实际、负责人和复验结果。
- 04
回写规则
把格式、字重与设备例外写入组件和交付清单。
AI 可以参与交付，但不能代替设备
Figma MCP 与 AI Coding 的 H5 探索，是减少设计到实现重复劳动的一条路径。它没有取消字体、渲染、资源与交互状态的真实检查。
自动化视觉走查是下一阶段方向，而不是当前已经上线的基础设施。可以先从少量高风险组件和固定状态建立回归集，再决定是否扩展。
格式选择是体验和工程之间的取舍
动效格式需要同时考虑视觉还原、运行性能和接入成本。PAG、SVGA 等方案应结合真实设备验证，需要时给出回退方案。不能把某个格式在一个样例里的成功，当作全部场景的保证。
把复验结果带回规则
一次问题修复如果只停留在聊天记录，下个版本可能再出现。把字重限制、素材导出要求和已知兼容问题沉淀到组件与交付清单里，才能减少重复损耗。
另一处对照：发布成功之后，端间语义是否一致
- 两端都要清楚告知提交状态和下一步，但布局不必机械相同。
- 图中文字关于流失的描述是当时设计目标，不作为本次补充的量化效果。
交付闭环，不是把问题交出去，而是确认设计意图真正留下来了。
来源与展示边界
根据阶段工作总结与项目实践整理；省略内部评价、人员信息与经营指标。