AI Design-to-Code 工作流

1. 整理设计结构

我的 AI 设计工作流从 Figma 开始。以美团跑腿「帮取送」体验改版为例，我先整理图层、布局、变量和组件，再用 design.md、product.md 和 tech.md 承接设计、产品与工程要求，逐步推进前端实现。

设计文件需要表达元素之间的关系。 地址属于哪个信息组，价格与下单操作如何关联，内容变长时谁应该伸缩，都需要在设计阶段确定。

让图层对应信息结构

我按照页面、区域、模块、组件和内容组织图层。订单确认页包含地址摘要、物品信息、配送服务和底部操作区；地址摘要内部再区分取件与收件。每层容器都有明确职责，同组内容应当需要一起阅读、变化或响应操作。

命名围绕业务用途展开，例如 订单确认/地址摘要 或 AddressSummary。同一概念在页面、组件库和代码中保持一致；清理默认名称、废弃图层和无意义嵌套，保留真正的布局边界。

用 Auto Layout 表达排列规则

设置 Auto Layout 时，我会逐层确认方向、间距、内边距和对齐方式。取收信息纵向排列，图标、地址与编辑入口横向排列；组件负责内部留白，页面容器负责模块之间的距离。

正文换行或辅助信息隐藏后，周围内容应沿规则重新排列。角标与浮层可以脱离正常布局，但要明确依附的容器和占位关系。普通内容则通过布局规则定位。

2. 提前定义响应式行为

绑定全局 Token 和建立组件变体之后，还要在 Figma 中设置尺寸行为、绑定响应式变量，并检查父子容器的配合。响应式的重点，是说明界面在什么条件下、按什么规则变化。

分别判断宽度和高度

每个元素都需要分别判断横向与纵向的 Fixed、Hug contents、Fill container，以及必要的最小和最大尺寸。内容卡片通常横向填充、高度随内容增长；图标保持固定尺寸；按钮宽度则取决于操作层级。

例如地址摘要：角色标识占据稳定空间，正文填充剩余宽度，编辑入口保留操作区域。长地址先换行，再撑高卡片。父容器需要提供可用宽度，文本所在的中间容器也要允许增长，避免内部裁切。

让变量绑定落到具体属性

• 内容变化：长地址、多行备注、标签增减，通过换行、内容撑开和布局方向处理。
• 空间变化：屏幕或父容器变窄，通过 Fill、最小与最大尺寸、间距分配处理。
• 场景变化：设备、密度或服务主题变化，明确变量模式、组件状态和布局的切换条件。

页面边距、卡片 padding、模块 gap 和圆角应绑定对应变量；存在多套取值时，再用模式组织。变量模式可以从父级继承，实现时仍需写清浏览器断点或业务触发条件。

同时检查宽度与真实内容

跑腿项目以移动端为主：448px 及以下铺满可用宽度，更宽屏幕保持 448px 居中；页面左右边距使用 space-8。字号与图标保持稳定，优先让容器伸缩和文字换行。

我在规范中列出 320、375、390、414、448px 五种检查宽度，并搭配长地址、大金额和多行说明。需要逐项约定换行、截断、图片比例与缺省状态；底部固定栏预留安全区，正文留出避让空间。画板高度只作为展示结果。

3. 建立清晰的 Token 体系

Token 把设计值变成可以命名、引用和维护的规则。我会先判断用途与变化范围，再决定哪些值应该共用。

用稳定语义命名

现有规范用 brand-primary 表达品牌和主操作，用 text-primary、text-secondary 区分信息层级，保价色则命名为 insurance-primary。保价绿有独立的保障语义，使用范围需要保留。

命名时统一词汇与分隔方式：同一概念固定使用 primary，状态统一使用 disabled，避免 new、final 等临时名称。Figma 名称与代码名维护对应关系；调整命名时，同步更新设计源、说明和实现。

区分基础值与使用意图

后续我会按需完善三层引用：color/yellow/500 保存基础色值，color/action/primary 表达主要操作；按钮需要独立调整时，再增加 button/primary/background。这是一组分层示例，现有项目沿用已确认的命名。

间距同样需要区分用途。页面边距与组件 padding 即使暂时都是 8px，也应记录各自职责；需要独立变化时，通过语义别名管理，避免修改一个基础值牵动所有位置。

明确主题和文字样式的边界

普通服务与「1 对 1 急送」通过 service-primary、service-bg 等变量管理订单级主题。切换服务时，指定的强调区域变化，重量控件、保价状态等区域仍遵循自己的颜色规则。

文字规范需要记录字体、字号、字重、行高、字距和颜色，区分标题、正文、注释与价格。变量维护复用数值，文字样式组织排版属性；交付前检查实际绑定，尤其核对 Auto 行高与固定行高的差异。

4. 完善组件契约

组件契约约定组件的职责、可变内容、尺寸行为和使用边界。地址组件负责一个确定角色的地址，载具胶囊负责配送载具切换；组件边界应当让变化可以被清楚管理。

将变体与内容属性分开

• 文本属性：管理标题、说明和业务内容。
• 布尔属性：控制图标或辅助区域的显示。
• 实例替换：替换图标、头像和嵌套组件。
• 变体：表达类型、尺寸、角色或状态的稳定差异。

取件与收件可以作为地址组件的角色变体，具体地址则属于数据。默认的 Property 1 需要逐步改为 role、service 或 state，并与代码属性保持一致，避免每换一段内容就增加一个变体。

补齐行为与代码对应

组件规范分别记录宽高行为与 referenceSize：导航栏横向填充、高度稳定，内容卡片随内容增长。参考尺寸用于核对密度，旧组件中与规范不一致的 Resizing 设置需要校正。

默认、选中、禁用、加载和错误状态按实际需要补齐。提交按钮处理中是否阻止重复点击、失败后是否保留输入，既要有对应外观，也要有产品规则。组件契约还应连接 Figma 节点、代码位置和属性映射，方便复用。

这些内容最终汇总进 design.md，与 Figma 一起维护：设计源保存可检查的结构，文档补足使用意图与实现边界。

5. 定义产品基线

product.md 说明功能如何运转。跑腿项目的核心链路是：选择服务、填写取收地址与物品、确认费用、提交订单、追踪配送、查看完成结果。每个页面记录入口、目标、信息、操作、规则与验收标准。

跨页面规则需要明确。例如「帮送」与「帮取」直接互切时，交换取收地址并同步角色；进入或退出「1 对 1 急送」时，地址保持不变。地址编辑保存后返回来源页，校验失败则保留输入并提示修正。

当前项目是体验验证原型，使用 Mock 数据；真实账号、支付、计价、定位与履约不在本期范围内。先收敛范围，再保留主流程所需的异常处理与可恢复性。

6. 组织 AI 渐进实现

实现时，三份文档提供共同约束，每次任务聚焦一组组件、一个模块或一条可验证的交互链路。输入包含对应设计节点、现有实现、业务规则和验收条件；复杂任务先确认方案与影响范围。

我用「触发—判断—变化—反馈—结果」组织任务。例如：

从「帮送」切换到「帮取」时，复用现有切换组件，更新选中态，并交换订单草稿中的取收地址与角色。切换急送时保持地址不变。返回首页或进入确认页后，地址摘要应与草稿一致。

tech.md 约定技术栈、数据层和修改边界：先读规范，只处理当前任务，复用组件与业务规则。实现后完成类型、代码、样式、关键规则测试与构建检查，再进入人工走查。

7. 验证体验与完成交付

我从三个层次检查结果：规则是否正确、界面是否符合设计、用户能否理解并完成任务。 走通主流程，核对跨页面数据与状态，再检查字体、间距、换行、安全区和操作反馈。

评审发现的问题进入下一轮任务：视觉偏差回到设计源核对，状态错误回到产品规则定位，重复实现回到组件边界处理。修正后同步设计与文档，每次提交保持一个明确目的。

下一步，我会补充键盘焦点、表单标签与错误反馈检查，并围绕送花等场景开展用户测试，记录任务完成情况、误操作和卡点。这些属于待验证环节，最终以真实观察为依据。

交付包含可运行版本、项目文件、运行说明、已实现范围和已知限制。实现中确认的规则继续回到 Figma、组件库和三份文档，让下一次迭代拥有更清晰的起点。