界面设计交给开发还差什么？把组件状态和布局规则标清楚

界面设计交给开发，除了页面截图，还要交付无法从图里推断的规则：组件有哪些状态、内容变长如何布局、哪些值来自真实数据、什么情况需要确认。把这些写在组件卡和布局说明中，再与研发逐项对齐。看起来完整的画面，不等于开发已经知道所有行为。

先用一个组件验证交付是否足够

挑项目中重复出现的卡片或按钮，尝试只按当前文件实现。如果仍要追问“最长标题几行”“没有图片怎么办”“点击后何时恢复”，说明交付缺少规则。不要先把整站全部标满像素，再发现根本不知道状态如何变化。

以下是本文自拟的课程卡片例子：包含封面、标题、讲师和学习按钮。正常画面只展示了资料完整的情况；交付还应说明封面缺失、课程标题很长、按钮不可用和内容正在更新时如何表现。这些行为要由业务和开发确认后写入，不能仅凭视觉偏好决定。

组件卡应当回答什么

“按钮灰色”只是画面，“当前没有权限时不可操作，并显示申请入口”才包含行为。无法确认申请流程，就明确标为待定，而不是交付一张实际上没有去向的按钮。

布局规则比孤立的像素值更有用

说明两栏何时变为一栏、卡片高度是否跟随内容、长标题是截断还是扩展、重要动作能否换行。若项目尚未约定适配范围，先让研发提供目标屏幕与技术限制。不要从一张桌面稿推断移动端一定自动适配。

可以这样写本文示例：“标题最多显示项目约定的行数；没有封面时使用批准的占位资源；讲师字段缺失不显示空标签；操作区随卡片底部对齐。”其中行数和对齐方式仍需按本项目确认，不能作为所有产品的固定标准。

画面样式和可实现组件分开验收

Lovart 中文站展示界面视觉方向，可用于准备视觉讨论稿。图片里的按钮、图标和导航仍可能只是像素；不能据此承诺已经生成可运行组件、代码或可编辑工程。实际设计源、资源格式和实现方式要另行核对。

把交付拆成“视觉已确认、行为已确认、资源已可用”三项。某张图很漂亮，但字段规则未定，仍可作为方向参考；不能直接标作全部完成。资源里有文字型图标时，另外确认接收方是否具备对应字体，避免实现后形状丢失。

安排一次以问题为中心的交接

• 用长标题、空字段和真实比例图片检查极端内容。
• 将正常与异常状态放在一起，核对重复组件是否一致。
• 让研发指出无法从文件确定的行为，形成待确认清单。
• 把决定回写到组件卡，再绑定到交付版本。

完成的标准是接收方能依据同一套规则继续实施，剩余问题有负责人和明确状态。多加一张效果图，不能代替一条缺失的布局或状态规则。