文章目录 / 点击展开
设计交付不是发一个 Figma 链接就结束。前端真正需要的是可判断的规则：哪些组件可复用，断点如何变化，长文本和错误状态怎么处理，素材从哪里来，验收时看什么。AI 可以把这些信息从设计稿与说明中整理成清单，但不能从截图猜出不存在的交互和业务规则。
先确认交付范围与事实来源
明确本次涉及页面、用户流程、设计版本、组件库版本、目标设备、浏览器范围和上线优先级。颜色、间距、字体和组件行为以哪一份 token 或代码实现为准，也要在交付前写清。
若设计稿与现有组件能力不一致，记录差异、业务影响和决定，而不是让开发在实现时自行猜测。设计系统的长期维护可参考 AI 辅助设计系统文档。
第一步：按任务拆分页面状态
先从用户任务而非视觉分区出发，列出进入、加载、空数据、成功、错误、权限不足、超长内容、网络中断和完成后的状态。每个状态明确触发条件、可见信息、可执行动作和恢复方式。
根据以下页面任务和设计说明整理交付状态表。
每项包含：触发条件、页面内容、用户动作、组件、文案、响应式变化与待确认项。
不能从资料确认的交互标记为待确认，不要自行补全。状态表比单张高保真稿更能避免上线后才发现“没有数据时显示什么”。
第二步：明确组件和内容规则
对每个页面标注使用的组件、变体、可编辑字段、图标、素材和禁用用法。说明按钮在何时显示、禁用或进入加载状态，表单错误如何定位，标签和提示信息的最大长度如何处理。
文案不能只留占位符。至少提供正常、超长、错误和空状态示例，中文与英文等不同长度内容要提前测试。产品文案的统一规则可衔接 AI 产品文案系统教程。
第三步：把响应式写成规则而非缩放图
定义各断点下的内容优先级、栅格、间距、导航、表格、侧栏和操作按钮变化。例如侧栏何时下沉、长表格如何横向处理、主操作何时全宽、筛选项如何折叠。不要只提供桌面和手机两张图，中间宽度同样需要稳定规则。
验收时至少检查窄屏、常见桌面宽度、文字放大和超长数据。每个固定高度区域都要有溢出处理，避免动态内容把相邻模块推坏。
第四步：整理素材和实现说明
列出图片、图标、视频、字体和下载资源的来源、格式、尺寸、裁切规则、授权和替换位置。优先使用真实产品截图或有信息价值的素材，不用模糊装饰图掩盖缺失内容。
对复杂交互提供短说明或演示，而不是要求开发从静态图推断动画、延迟和错误反馈。AI 可生成实现说明初稿，仍需设计和开发共同确认。
第五步：共同走查而不是单向验收
开发完成后，设计、开发和内容负责人按真实任务走查页面。先核对信息层级和主要动作，再检查状态、响应式、键盘、焦点、对比度、素材和文案。问题应记录页面位置、预期、实际、影响和负责人。
AI 可以根据截图和规格列出观察项，但无法替代真实交互测试。无障碍和可读性专项可使用 AI 界面评审清单 补充。
第六步：发布后维护差异记录
将已确认但暂不实现的差异单独记录，避免它们在后续版本中被误认为“设计错误”。组件、断点和内容规则变化时同步更新设计库、代码和文档，并标记受影响页面。
发布后从真实反馈中发现新状态，例如用户输入异常格式、网络慢、内容量超预期。把这些情况回写到状态表，交付质量会随版本逐步提高。
设计交付检查清单
- 是否明确页面范围、设计版本和组件事实来源。
- 是否覆盖加载、空、错误、权限和超长内容状态。
- 组件、文案、图标和素材是否有明确来源与规则。
- 响应式是否说明断点下的内容优先级与布局变化。
- 素材是否包含格式、授权、尺寸和替换说明。
- 是否用真实任务共同走查实现页面。
- 差异和后续维护项是否有责任人与版本记录。
常见问题
设计稿很完整，为什么还需要状态表
高保真稿通常只展示理想状态。状态表把加载、失败、权限和边界内容变成可实现、可验收的规则。
AI 能自动把 Figma 设计转成生产代码吗
可以辅助生成起点，但组件语义、业务状态、响应式和无障碍仍需要工程实现与验证。
交付问题应该由设计还是开发解决
先按事实来源定位：设计规则不清由设计补充，代码与规则不一致由开发修复，业务状态缺失则由产品与相关负责人决定。