AI 自动化交付

业务背景

现状困境

随着企业 SaaS 需求量暴增，这通常意味着批量、标准型的 B 端页面成为需求主体，产品经理和设计师在业务中的权重发生变化。大量可复用的组件和页面导致设计师彻底沦为画图工具，产品经理对设计的把控又到不了像素级，因此会出现原型多，设计稿多，但二者工作大量重复，甚至有经验的前端都并不需要二次出图。

设计师的挑战

那么 AI 时代的设计师是否可以参与到代码落地的部分？该参与到哪个阶段？

我们的答案是：设计师不必成为工程师，但可以成为「定义约束、交付结构」的人——把设计资产组织成 AI 可读、可复用的输入，让 AI 在约束内产出工程代码，设计师对结果做质量把关，而这也为接下来的工作带来巨大的挑战。

挑战	具体表现
业务量大，设计资源不足	传统「一张张画稿、一轮轮走查」的模式无法消化暴增的需求
设计规范在 AI 生成中失真	直接把设计稿丢给 AI，产出的代码不认组件、不认 Token，规范形同虚设
存量技术栈（Vue）对 AI 不友好	主流代码模型对 Vue 的还原质量与生态支持明显弱于 React，链路在最后一步卡死

AI 设计工程化

为什么是「AI 设计工程化」

前端的每次功能更新都称之为「工程」，因此交付可直接复用的「工程文件」则成了基础目标。我们探索了多个 AI 提效路径，发现其对应的产物和对设计师的要求各不相同，常用的技术选型如下：

路径	交付物	优势	局限
AI 辅助出图	设计稿	上手快，创意发散强	停留在图层交付，后续链路成本不变
AI 生成 HTML 单页	独立 HTML	直观、演示友好	无法进工程仓库，研发仍需重写
AI 设计工程化 本方案	React 工程组件代码	免转译、免标注切图、还原度接近 100%	需先沉淀变量/组件/规范资产
全自动 AI 研发	完整功能代码	上限最高	业务理解与质量不可控，幻觉风险大

可以发现选择「工程文件」作为交付物是图层面交付永远做不到的极致高效，对于大量重复的需求来说是极致的提升。

理由	说明
标准化	AI 直接产出的组件进入业务/组件/模板三个代码库，研发拿来即用，不再做「设计稿到代码」的转译
高效率	Token 与组件即约束，免标注、免切图，设计还原度接近 100%，走查与沟通成本趋近于 0
可沉淀	代码本身成为设计资产的一部分，可版本化、可复用、可回溯

工程化组件库

设计侧和前端侧同步工程化组件思维，将 Figma 设计资产彻底变量化，建立“基础层 → 语义层 → 映射层”三层架构，符合当前MCP版本支持的输入输出方式，方便精准匹配。

如果对建立设计工程感兴趣，可以前往查看《工程思维的组件化革新》。

Design to Code 映射

建立 Figma 组件与前端工程组件的映射表，每个组件的属性、尺寸、状态在两侧严格对齐，AI 还原时按映射表取组件。映射表同时约束了「哪些页面允许用哪些组件」，从源头杜绝规范外样式。

这种方式允许插件直接按规范生成界面，或者通过Figma MCP的方式还原设计稿。

Markdown 约束

将设计规范写成 AI 可读的 Markdown 约束，AI 在生成代码前将严格按照约束逐步落地，减少幻觉，提高生产效率。约束按四类组织：工程约束（Git 工作流）、设计约束（Design Token）、组件约束（组件与图标）、业务约束（页面排版布局）。

分层共建

AI 开发上下文很容易过长并出现幻觉，将约束分层控制可以更好的让 AI 了解清楚每次请求都做哪一部分的工作，这也是受限于各类模型的智能程度，分得越精准生成质量越好，将越符合诉求

分层维度	内容	维护方
Design Token	Design Token、Layout	设计系统侧统一维护
通用组件	基础组件、基础模板	设计系统侧统一维护
业务组件	业务组件、业务约束	各业务设计师独立维护
页面模板	页面模板、布局栅格	各业务设计师独立维护

设计工程

资产就位后，工程侧如何承接？由于 ABC 数字医疗云存量业务运行在 Vue 技术栈上，而主流代码模型对 React 的还原质量与生态支持明显更强。通过微前端方式渐进引入 React 子应用承载新页面：既不动存量业务的稳定性，又让 AI 产出的组件直接落在对 AI 友好的技术栈上，链路最后一步被打通。

随着沉淀的资产：变量、映射表与约束文档越完整，非工程角色的产出就越可控。在任务流中根据需求规模交付工程文件，简单的组件复用、不涉及到复杂循环的交互逻辑，界面样式可以由设计或者产品借助 AI IDE（如 Trae）与 Agent（CodeX、ZCode）直出。核心前后台逻辑仍由前端完成。

这一套跨职能的工作流风险极高，至少截至目前了解来看设计师非必要走到这一步。跨职能的交付必须配套工程护栏——只开放给标准化、低风险的 B 端页面；一律走 feature 分支 + PR，由 CI 卡住 lint、类型与规范命中，禁止直提主干，在约束与护栏之内，可以第一次真正「提交」自己的设计。

结束

效果与展望

目前此方案十分适配 B 端业务，它对所有角色都提出了更高的要求，产品需要更确定的方案，设计需要更稳定的设计系统，它要求岗位进行跨职能成长，这在前中期需要耗费大量的精力与心血投入，随着未来 AI 模型的不断成长，模型幻觉不断减少，或许能达成更高的设计提效，只是目前还无法完全跳过设计师，仍然需要设计师进行质量把控。

写在最后

这套方案已在个人主站（本站）完成简单自证：从 Figma 变量导出、Design Token 录入、IconPark 图标管线到 Astro/Tailwind 组件代码，全部由设计资产驱动 AI 协作产出。基于成本考虑其不算完全严谨，目标是为了证明其真实可行性、效果以及个人在此方向的可迁移能力。

如果未来此工作流会成为行业标配，那么此沉淀将会对所有团队内部的人均有显著提升，它让「设计资产 → AI → 工程代码」有可能成为团队的默认交付方式，而不是某个项目的特例。

感谢您阅读到此处，如果感兴趣可以下载下方的插件感受下简单的demo（CodeX 本人暂时没法验证，因为没有套餐了 >_< ）。