开发拿到一张图，最怕的是不确定：这个间距到底是多少？按钮有哪些状态？图标是SVG还是PNG？字体是否可用？你越不确定，开发越只能猜，猜错就返工。好的交付不是把文件丢过去，而是把“实现所需的信息”一次给全。
同一套UI在不同屏幕、不同语言长度下表现差异巨大。交付时至少写清三个边界：支持哪些尺寸、最小可用宽度是多少、文案最长会到什么程度（尤其是按钮/标签）。
只交付一个“默认态”，上线后一定会补。你可以不做花哨动效，但常规状态要齐全，尤其是按钮、输入框、开关、列表项。缺一个就会在联调阶段被补回，且大概率改到你最忙的时候。
命名的目的不是好看，是能检索与复用。建议用“模块/功能/状态”结构命名，例如 Button/Primary/Default、Input/Search/Focus。开发看到命名就能快速定位。
很多“看起来不对”的问题来自半像素与缩放。交付前检查关键元素是否落在整数像素网格上，1px线条尤其要注意。你在设计端对齐了，开发实现才会稳定。
图标优先SVG（可缩放、易换色）；位图素材按投放端选择PNG/WebP；印刷或矢量稿可用PDF。交付时写清“这类资源用什么格式”，并附上导出规范（倍数、命名、是否裁切透明边）。
如果有设计规范，就用颜色Token（如 Primary/Success/Text/Border），不要只写#3A7BFF。这样开发能在主题/暗色模式/多端一致性上更容易维护。
用到的字体是否可商用？开发端是否能加载？字重是否齐全？如果字体不可用，提前给替代字体与降级方案。否则最后往往变成“上线前统一替换”，风险极高。
建议每次交付附一页说明：页面列表、关键交互、资源下载路径、组件清单、边界条件、已知风险。写得越短越好，但必须可执行。开发不需要读长文档，只需要知道怎么做不会错。
页面：【页面A/页面B】
适配：【尺寸/最小宽度/最长文案】
组件：【按钮/输入框/弹窗】（状态齐全）
资源：图标SVG、图片2x WebP/PNG（命名规则：xxx_2x）
颜色/字体：按Token实现；字体替代方案：【…】
备注：【已知风险/待确认点】
交付做得好，能让团队把时间花在“做对产品”而不是“对齐细节”。把这8个点当成固定检查项，你会发现返工和来回确认会明显减少。
