AI 写代码、生成 UI 早已不是难题，但设计与研发两端产物互不相认，设计师重画、前端重写成了常态。本文借一套汽车 HMI 界面 Demo，实测 C2D 与 D2C 两条链路：代码能否反向导回画布精修，设计稿能否一键转成可部署代码，拆解 AI 时代设计与研发的打通路径。

AI 已经把设计与研发的两端各自解决了大半——生成代码、生成 UI 都是共识能力。

但两端的产物互不相认：AI 写出来的 HTML 进不了设计工具，设计稿转出来的代码回不到画布。设计师还得照着 Demo 重画一遍，前端还得照着设计稿重写一遍。

这次借着一个来自用户的需求：一套汽车 HMI 界面 Demo，把两条链路各走了一遍，做了次真实验证。

双链路实践

验证链路：

• 链路一（C2D）：在 WorkBuddy「日常办公」模式下，先用对话生成可运行代码，再反向导回 Ardot 画布精修。
• 链路二（D2C）：在 WorkBuddy「设计创意」模式下，先在画布产出设计稿，再一键转成可部署的前端代码。

两条链路的整体差异如下图，后文逐项展开说明。

链路一 · C2D：从能跑的 Demo 回到设计稿

对话驱动 · 先生成代码，再反向导入设计测试工具：WorkBuddy（Ardot MCP）+ Ardot场景：WorkBuddy【日常办公】模式

为什么需要”从代码回到设计稿”？这个方向乍看是反的——代码不是终点吗，为什么还要退回去？

但在真实工作里，需要”退回去”的场合比想象中多：

1. AI 生成的 Demo 改不动：微调间距、配色都要重新生成，或照着截图重画一遍，每次小改都等于推倒重来。
2. 线上有页面，却找不到设计稿：接手改版只剩线上代码，源文件丢失或从未交付。以前只能对着截图重描，现在可以把页面直接导回画布。
3. 历史资产进不来：Sketch、Axure 文件无法直接导入，老项目资产断档。但大多能导出网页原型，走这条链路即可拿回一份可编辑的设计稿。
4. 设计稿早就和线上不一致：前端微调后设计稿未回写，逐渐过期。反向导入一次，就能拿到与线上一致的版本，继续迭代。

这四种情况的共同点是：手上已经有能跑的东西，缺的是一份能改的设计稿。本次实践对应的是其中最贴近日常的场景：不先打开设计工具慢慢画，而是先用一句话把想法跑起来。整个过程在 WorkBuddy 里几乎全靠对话推进，共四步，其中第三步「HTML 反向导回 Ardot」是这条链路真正的关键步骤。

1. 先让 AI 确定需求，而非直接产出成品

我给 AI 的要求是：产出一套通用提示词模板，使后续生成的 UI 都能保持一致的设计调性。

它的输出不是一张图，而是一份结构化的模板文件。

2. 套到真实需求，直接生成能跑的单文件 Demo

将需求套入模板后，AI 一次性产出了包含粒子、能量环、折线图、引导线、数字动画的单文件 Demo——这些原本需要工程师写不少代码的效果，直接出现在产物里。

后续通过对话反复微调：标签居中、数字与单位对齐、字号字距行距。

这里印证了一个判断——当模板层足够稳定，对话层就只剩对细节的微调，而非对方向的反复重做。

AI 的能力分布是：0→1 增加内容很强，精细化调整偏弱。所以把稳定性前置到模板层是关键，细节调整则留到第三步导回设计稿之后再做。

3. 关键跃迁：HTML 反向导回 Ardot，变回设计稿

如果只到“能跑的原型”，链路一仍属常规做法。

真正让它成立的是这一步：把这份 HTML 反向导回 Ardot，让它重新变成一份可编辑的矢量设计稿。

这一步目前依赖 WorkBuddy 连接 Ardot MCP，两个前提：

1. 下载 Ardot 客户端并完成 MCP 连接；
2. 选用能力较强的模型（本次测试用的是当前主流的两款大模型）。

具体怎么连？ 最省事的办法是直接在 WorkBuddy 里问它「如何连接 Ardot MCP」，它会一步步告诉你。也可以查阅官方文档：docs.ardot.tencent.com/ardot-mcp.html

提示词怎么写？ 可以让 AI 帮忙总结，提供大致的思路结构。如果面对的是完整代码库，建议针对代码库结构专门打磨一版提示词。

4. 回到画布精修，产出高保真交付资产

一次转入Ardot画布效果 +简单细化微调效果

越强的模型，一次转换的精细度越高；若代码库足够完整，组件信息也能一并带入 Ardot 画布。

转入后，再在画布内做简单细化与微调，即可产出高保真交付资产。

链路二 · D2C：从画布出稿一键转代码

画布驱动 · 先出设计稿，再导出代码测试工具：WorkBuddy + Ardot场景：WorkBuddy【设计创意】模式

为什么需要”设计稿直接出代码”？这个方向的痛点更熟悉，几乎每个设计师都经历过：

1. 还原度只能靠人盯：走查→修改循环 N 次，2px 间距、色值档差全靠肉眼逐页比对。
2. 小改动要跑全流程：圆角 16→12 只需几分钟，却要提需求、等排期、等发版。
3. 设计稿能否真的跑起来：设计师验证不了。 原型里的交互是”演的”，真实滚动、响应式、状态切换只有代码能回答。
4. 规范停在文档里：落不进代码。 变量表、间距体系定好了，研发靠手抄，抄一次偏一点。

这些情况的共同点是：设计已经确定了，缺的是一条不失真的交付通道。链路二是链路一的镜像方向：不先写代码，而是进入「设计创意」模式——Ardot 画布直接内嵌在对话旁，边聊边看设计稿实时长出来。共四步，核心是第三步的 D2C 转码。

1. 给参考图，让 Ardot 画布实时出稿

与链路一思路一致，支持图生 UI 或文生 UI，目的是通过参考图或文字描述快速积累设计 Demo 方案。本次直接采用图生 UI。

2. 在画布里进行细化、精修

这一步的真正价值不在后续“D2C 转码”那一瞬间，而在于在那之前，设计稿已经是一份高质量、可自由调整的资产。

转码只是把这份资产“翻译”成代码。若设计稿本身粗糙、不可调，再聪明的转码也救不回来。

AI 目前擅长快速生成，但要达到可落地的设计水平，仍需多轮对话修改 + 快速手动精修。

3. 关键跃迁：D2C 一键把设计稿转成代码

这一步能跑顺，前提是 Ardot 对图层结构已有结构化的表达。

也就是说，D2C 之所以保真，靠的是设计稿本身用规范结构（Auto Layout、嵌套、Token 引用）画出来的。设计稿的规范度，直接决定 D2C 保真度的下限。

生成效果综合稳定可控，支持 HTML、React、Vue 等多种格式，可在 Ardot 小助手内预览，或下载完整代码包。

4. 拿到代码包，补动效、部署上线

转码完成后得到的是包含 HTML、CSS、JS 与资源的完整代码包。

它可下载到本地，也可导入 WorkBuddy / CodeBuddy 继续补动效、做联调，最后部署。

原本静态的设计稿，就此变成可真实承载业务、可复用的代码资产。

总结：两条链路非互斥，分治不同阶段

走完两遍后，最直接的判断是：两条链路解决的并不是同一个问题，不存在二选一。

链路一

• 回答“想法能不能被快速看见”——把一个模糊的早期需求，短时间内变成可讨论、可比稿的实体；
• 它同时也解决另一类问题：已经有能跑的页面、却没有可编辑设计稿时，把资产还原回画布。

链路二

回答“成果能不能干净地交付落地”——把一份方向已确认的设计稿，结构化地翻译成可上线代码。

前者关心“早期”，后者关心“后期”。实践中按阶段选用即可：早期用 C2D 快速验证方向，后期用 D2C 干净交付。 过程中也可以灵活切换链路，做内容生成与细节编辑。

待建设

C2D 侧（链路一）

• 提示词模板仍靠人工打磨，尚未形成“写一次、处处用”的标准化方法；
• 产出质量强依赖模型当前能力，换模型或版本升级，同一份模板的结果都可能出现波动。

D2C 侧（链路二）

• 细节精度仍有缺口，目前还无法直接上线使用；
• 暂不支持绑定变量表导出，Token 与变量的双向映射尚未打通。

演进方向

持续优化转码精度

Ardot 联动 WorkBuddy / CodeBuddy 的设计转代码、代码转设计能力已在开发中，包括精度优化与 Token 变量的相关转换。

双向闭环常态化

目标是让设计系统与代码库互为镜像，任何一端的改动都可以双向同步——既能识别代码里的设计规范，也能识别设计里自带的样式和变量，而不是靠人把两边对齐。