设计系统 AI 化的组织变革：设计师与工程师如何重新分工协作
一、引子：设计师和工程师的"翻译层"正在消失
传统设计-开发协作模型中有一层"翻译工作"——设计师出设计稿（Figma/Sketch），工程师把设计稿翻译成代码。这个翻译层消耗了大量时间，也是"设计稿和上线效果不一样"的根源。
AI UI 生成正在把这层翻译自动化。一个 Figma 设计稿扔进 Galileo AI，3 分钟出一版代码。这意味着协作模型中"翻译"这个环节从人工变成了半自动。设计师和工程师的工作边界需要重新界定。
二、AI 生成代码的边界
“从设计稿生成代码”并不等于设计和开发之间不再需要沟通。生成工具通常能识别颜色、间距和常见布局，却不知道一个按钮点击后应写入什么状态、失败时怎样恢复、权限不同的用户能否看到它。它也不会天然理解组件在多个产品中的复用边界。
因此，团队需要把交接物从一张静态设计稿改成一组可检查的约束：组件状态有哪些、哪些内容可编辑、空数据如何呈现、移动端如何折行、键盘如何操作，以及哪些字段属于敏感信息。设计师提供这些约束，工程师将其落实为组件 API、测试和数据模型。AI 可以加快第一版实现，但不能替代这层约定。
三、把流程改成短反馈回路
不要让 AI 在一个大需求里连续生成几十个页面，再集中评审。更稳妥的方式是选择一个高频组件做试点，例如筛选面板或用户卡片：设计师先给出状态和 Token，工程师限定技术栈与数据接口，工具生成候选代码，双方在同一天完成视觉、交互和可访问性检查。试点通过后，再把可复用的 Prompt、组件模板和检查项放进仓库。
这会留下可追踪的记录：哪类需求适合生成，哪些问题会反复出现，生成结果是否真的减少了返工。没有这些记录，所谓效率提升很容易只是把沟通时间挪到后面的修复阶段。
四、新分工模式
设计师的新角色
常规页面的重复标注可以减少，但复杂状态和交互仍需要明确说明。设计师的工作会更集中在：
工程师的新角色
重复样式可以交给工具起草，但生成的 CSS 仍要经过工程审查。工程师的重点会转向：
可以减少、但不能默认省掉的工作
- 重复的尺寸标注可以由 Token 和检查工具承担
- 常规 CSS 可以由工具起草，再由工程师核对结构和可访问性
- 有分歧的交互仍应回到用户任务和测试结果，而不是只看生成效果
五、协作流程建议
01. 设计师在 Figma 中定义组件 + Token（设计意图）→
02. 提交到 AI 生成流水线 →
03. AI 生成代码 + 视觉差异报告 →
04. 设计师审核视觉还原度 →
05. 工程师审核代码质量和性能 →
06. 合并 + 自动化测试通过 →
07. 部署上线
六、上线前的共同检查
每次由 AI 参与的界面变更，建议至少检查：设计 Token 是否被复用；加载、空态和错误态是否存在；表单是否有 label、焦点和错误提示；窄屏及长文案是否溢出；生成代码是否绕过既有权限、埋点和组件规范。把这份清单放到 PR 模板里，比依赖某次评审更可靠。
团队还应明确生成代码的归属：谁对合并后的质量负责、谁维护 Prompt 模板、发现视觉回归后由谁修复。没有责任边界，工具只会增加一条难以追溯的交接链。先把这些小问题定下来，协作效率才会稳定下来。
工具的版本、输入素材和关键约束也应随 PR 记录。出现问题时，团队需要能够复现当时的生成条件，而不是靠记忆猜测是哪一次操作引入了差异。
