设计系统 AI 化的组织变革：设计师与工程师如何重新分工协作

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