腾讯设计 Ardot × WorkBuddy：设计交付中的 D2C 全链路提效实战
上个月接了个费用管理模块的需求。按传统交付链路：出全场景设计稿、等评审、开发、走查、改、再走查……中间如果有需求变动，整个链条就得重来一遍，两三天就没了。
但这次不一样。我们探索并落地了通过 Ardot MCP 能力连接 WorkBuddy 的 D2C 模式，把这件事压到了 7.5 个小时。
结果对比如下：
| 协作场景 | 传统模式 | D2C 模式 | 提效 |
|---|---|---|---|
| 最终交付耗时 | 约 2-3 天 | 约 5-7 小时 | ≈72% |
| 需求调整后再交付 | 约 3 小时 | 约 0.5 小时 | ≈83% |
这套方法的核心价值在于：AI 直接从设计稿生成可运行的页面代码，设计师的意图在代码层面落地，免去了反复人工走查和跨角色对齐的拉扯；同时需求调整后不用重新走一遍全流程，改动成本大幅降低，协作周期明显缩短。
下面是我们跑通这套流程的具体做法和经验总结。
一、需求分类
不是所有需求都需要先出设计稿。我们把需求分成两类：
| 需求类型 | 要不要出设计稿 | 怎么做 |
|---|---|---|
| 标准化页面/模块（表格、卡片、常规表单） | 完全跳过 | 需求描述 + 规范文件，直接让 AI 生成 |
| 非标准化、高定制或复杂业务逻辑 | 只出关键界面 | 关键页设计 → AI 还原 → 补交互细节 |
判断标准很简单：**这个页面在你们产品里有没有同类参照？**有，就跳过设计稿；没有，才需要先把关键界面定下来。例如水印配置需求就属于第一类——本质是个标准表单，一张设计稿都没画。
二、规范先行
这是整套流程里最容易被忽略的一步。AI 生成的代码好不好，不取决于你的 Prompt 写得多漂亮，取决于它读到了什么规范。
我们通过 Ardot MCP 连接 WorkBuddy 后，沉淀了三个 Skill（可以理解成"写给 AI 的说明书"）：
① 设计规范 Skill：喂典型页面或设计规范，让 AI 沉淀出色彩规范、组件标准、布局模板和交互规范。
② 需求转设计稿 Skill：让 AI 读懂需求后，依次调用布局模板、填充业务组件。
③ 设计稿转代码 Skill：用组件映射表约束代码实现，保证跑出来的效果和设计稿一致。
三个可以合成一个，让 AI 按场景自己调用子 Skill；分开的好处是每次加载的上下文更少，运行效率更高。
Tips 1：开发代码库里通常已经有
DESIGN_GUIDELINES之类的规范文档，但它偏技术侧（样式工程、元素命名、可访问性），设计侧的 Token 往往不全。建议把开发文档和典型页面一起喂给 AI，让它抽出更完整的版本。
Tips 2：如果同时存在两份以上规范，一定要在规范文档里直接定义使用的优先级，方便 AI 按优先级遵循。
三、关键页设计
这一步只针对非标准化的需求。
快速出方案：设计期间可借助 Ardot AI / WorkBuddy 快速出稿试方向，同步评审决策，不用等一版精修稿出来才能讨论。
方向有争议时做 demo：用自然语言直接生成可交互的 demo，拿去收集真实反馈，方向定了再更新设计稿。这一步能挡掉后面大量的返工。
边界场景交给 AI 补：空状态、加载失败、极值……这些必须有但画起来最枯燥的场景，把清单丢给 AI 一次补齐。
Tips 3：需求有小改动、不影响框架布局的，别回头改设计稿，直接在后面调代码时一起解决；大改动一定要更新设计稿，从源头确保代码生成的准确性，避免因源文件差异过大导致大量调整。
四、设计稿转代码
核心原则：先搭框架，再填模块，最后抠细节。
第 1 步：搭页面框架
给 AI 设计稿链接 + 整页截图，让它结合 Skill 判断页面是要新建框架还是沿用现有框架，再复用现有标准组件库，快速搭建全局骨架。
第 2 步：还原框架内的模块
逐个模块向 AI 下达还原指令，明确模块间的排列关系，例如：上下排列还是嵌套，卡片内是左右分布还是上下、各占多少比例。
第 3 步：抠模块内的细节
间距、圆角、字重字号、交互状态。这一步 Prompt 一定要给具体值，比如"给这几个数字加等宽底色，颜色 #FFE492"，或者直接把元素属性截图发给 AI。
Tips 4：AI 还原的精细化程度受模型及场景等多个因素影响，高频还原细节问题需要重点检查的有：多层级模块嵌套、自适应布局、异形元素和渐变背景等。
第 4 步：人工走查兜底
规范能定基调，但防不住 AI 在微调时的"连带破坏"——你让它改 A 处，它顺手把 B 处也改了，走查是兜底。人工走查主要是 UI 细节，可以直接看生成的 html 文件，如卡片上下边距 padding: 16px 20px 值是否准确。
第 5 步：补充新场景规范
更新 Skill 或规范 MD 文档，让 AI 在后续迭代时形成良性闭环。在 WorkBuddy 里一句话就行："把本次新增的框架/模块等让 AI 直接补充进设计规范 Skill，主要应用于费用相关场景等……"
五、标准化需求
第二类需求走这条路，更快。
以水印配置为例，本质是个标准表单，可省略设计，直接在 WorkBuddy 里用自然语言生成，顺序：补齐新增 Tab 入口 → 优化界面细节 → 补充配置逻辑等。
六、交付落地
交付流程：
- 仓库授权配置——让本地和 WorkBuddy 能访问代码仓库，可以拉取和提交代码。
- 安装预览插件——把需求发布到测试环境，直接在测试环境里看效果。
- 发布测试分支并交付——测试环境验收通过后提交合并，开发同学补齐业务逻辑后正常发布至生产环境。
在上述流程中，设计师接手了"还原 UI"这段重复劳动，研发从像素级还原里解放出来，专注业务逻辑和架构。
总结
通过 D2C 工作流的实践落地，我们总结了以下几点经验：
1、需求阶段是起点，也是决定后续效率的关键。 在 D2C 模式下，AI 无法"脑补"模糊信息。需求文档要尽量"机器可读"，避免"大概""差不多"这类模糊表达；核心交互流程要先梳理通顺；空状态、加载态、极值等边界场景提前定义清楚，后续 Vibe Coding 才能一次性生成完善。如果原始需求不完整，可以投喂给 AI，指令它扮演"设计师"角色，反向补全缺失的异常流程与边界条件。
2、AI 需要明确的指令。 无论是结构化的 Prompt 还是 Skill 规范，越明确越稳定。Skill 的本质是"写给 AI 的说明书"，把团队的设计规范、组件标准提前沉淀好，AI 的产出就有了可依赖的基准，后续迭代也会越来越顺。
3、先框架后细节。 框架锚定方向，再填充细节，顺序反了会浪费大量时间。AI 处理底层逻辑时，先搭骨架再填模块最后抠细节，这个顺序能保证每一步都建立在上一步的基础上。
4、适配效果需提前定义，交付前必须系统走查。 边界场景下 AI 默认不做自适应，如需精准适配，建议将适配规范写入 MD 文档或 Skill 文件中。同时，AI 在生成代码时可能意外修改其他元素，最终交付前必须系统走查，拦截 AI 的小意外，保障最终视觉还原度与交互效果。
D2C 工作流模式，让我们从低效的产出方式、从无休止的"像素级"拉扯中抽离出来，打破专业壁垒，实现设计的直接落地，有更多时间探索更有创造力的事情。
立即体验
Ardot 是腾讯自研的 AI 设计工具，通过 MCP 协议让 AI 直接读写设计稿。四步开箱：
- 官网 ardot.tencent.com 注册（新用户可获 1000 Credits）
- 新建文件，点击右上角 MCP 配置，连接你的 IDE（支持 WorkBuddy、CodeBuddy、Cursor 等）
- 切换 AI 对话框快速生成设计稿
- 打开 IDE，输入"基于 Ardot 当前设计稿生成代码"，AI 自动读取上下文，像素级还原
支持云端 MCP，不用安装客户端也能体验，快来试试！