设计辅助Agent：如何0-1搭建R2D工作流

让 AI 像一个靠谱的实习生一样，从读 PRD 到出交互稿，全链路辅助设计师。 更多把设计师从「重复搬砖」里解放出来，让设计师能把更多的时间投入设计决策的思考。

#01 交互设计师的时间都去哪了？

作为交互设计师，在实际项目中总是有一些重复的工作占用了我们的精力——重复沟通、组件填入……导致花在「真正需要设计师判断力」的事情上相对有限。这不只是效率问题——当 GenUI（生成式 UI）正在成为行业趋势的时候，这个矛盾会被急剧放大。

交付范式的迁移 “text”>大语言模型（LLM）正在重塑设计协作的流程 —— 从传统的「设计师交付像素级设计稿，开发人员手动还原」，逐步演进至「设计师表达结构化意图，由 AI 自动生成 UI」。在这一浪潮中，Google推出的Stitch一度成为热议焦点——它生成的页面在视觉一致性上确实令人惊艳，也让我们对它在闪购这类高频迭代业务中的应用抱有期待。但经过实际验证后，我们发现 Stitch 目前既无法接入我们日常依赖的内部组件库，也难以100%还原品牌设计规范，这意味着它产出的界面再“好看”，也只是一座空中楼阁——缺乏可维护性、无法复用、更谈不上基于现有产品视觉体系做出创新。

目标

基于此，我们希望在行业转型窗口期内，打通一条AI辅助的全链路工作流——覆盖从需求到交互稿的全过程，并确保最终交互稿具备投入生产的可能性。

围绕这一目标，我们将整个探索过程拆解为三个阶段，每个阶段解决一个关键命题，逐层递进：

• STEP 1：怎么让产出更符合交互逻辑？——让 AI 先学会”画对”，产出符合交互逻辑的设计稿
• STEP 2：怎么更像实际产出？——在交互成立的基础上，让 AI 直出交付级还原度的设计稿（组件、规范全对齐）
• STEP 3：怎么提升复用性？——固化流程能力，提升工作流复用性，实现链路的稳定调用与规模化产出

 

#02 搭建过程

从设计师的动作序列出发

第一步先回到设计师的日常，把「从接到 PRD 到交付交互稿」拆成具体的动作序列：

拆完之后，我们做了一件关键的事——为每个步骤打上两个维度的标签：标准化程度和设计判断密度。从评估结果来看，大部分设计步骤呈现出“高标准化 + 低判断密度”的特征，这意味着它们天然适合被转化为 SKILL。

步骤	标准化程度	设计判断密度	Skill化适配度
读 PRD 提取要点	高	低	非常适合
推导交互流程	中高	中	适合
画布局骨架	中	中高	适合
填内容选组件	高	低	非常适合
补异常态写说明	高	低	非常适合
AB 方案 + 埋点	中高	中	适合

写几个Skill，6个还是1个？

设计稿产出本身过程较多，步骤复杂，因而在产出skill前，我们对方案架构进行了思考，并最终选择Plan B——基于流程步骤，串联上下游产出，并分别输出对应的skill。

Skill产出 “text”>基于多skill的架构，最终产出共五个skill

1.PRD需求理解SKILL：从 PRD 提取非药推荐的业务目标、场景、功能清单——识别核心用户场景分析，设计目标与设计策略

2.交互流程推导SKILL：推导用户从搜索到购买的全链路——识别关键分支：起送价是否满足

3.页面框架SKILL：基于场景行为分析——页面框架的多方案尝试（按分类分组 vs 智能去重）

4.组件映射填充：基于页面框架和 .design 中已沉淀的组件样式——生成组件和字段填充的列表

5.交互逻辑补齐：基于前置分析的交互链路——补齐无结果、超时等异常态

实际测试下来，基于前期五个 Skill 产出的结构化需求，AI 已能稳定生成交互逻辑和页面排布与线上高度一致的设计稿。但问题也随之浮现——页面中的具体组件和视觉规范仍与线上存在明显出入。于是，第二阶段的探索重心便聚焦于此：如何让 AI 的产出从“结构对”进化到“视觉也对”。

Google Stitch 有一个值得借鉴的做法：通过 design.md 结构化文件定义颜色、字号、间距、组件规格等设计规范，AI 生成时强制参照，从而保证产出高度一致。借鉴这一思路本身没有问题，但当我们试图将其真正落地到业务场景中时，Stitch 的方案便暴露出了明显的短板——它对组件的限定过于宽泛，仅凭 Markdown 无法满足业务对严格设计规范及组件复用的要求（例如商品卡片的具体样式、状态及变体选择）。偶然间，我们在 GitHub 上发现了 stitch-kit 项目，它在 design.md 之外额外维护了一个 global.css，用于存储每次生成更新后的样式变量，确保前后一致性。这给了我们两个启发。

• 除了design.md外，我们还可以另外给AI其他参考

• 在AI生成的读取顺序上，我们也有了新想法——可以先给AI看食材，再给菜谱。而不是让 AI 看着菜谱去发明食材。

如果把 AI 生成 UI 比作做菜——组件是食材，Design.md 是菜谱。

Stitch 原本的生成顺序是：先写菜谱（Design.md），再基于菜谱发明食材（组件）。这导致产出的界面始终无法匹配线上已有的设计规范和组件库。

而我们做的调整其实很简单：调换读取顺序——先通过 global.css 和 component patterns 告诉 AI 我们已有的食材（组件和规范），再让 AI 根据菜谱（Design.md）来烹饪。食材都是现成的，做出来的菜自然对味。

基于这两个思路，我对链路中的多个skill进行了针对性调整。

• 组件映射skill：优先读取.design沉淀
• 设计生成skill调整读取顺序（AI优先读取global.css, component patterns，再读design.md）

基于此，AI Agent的完整生成链路基本成型

二期迭代效果验证

实测后，组件的应用率和整体效果有了较大的提升——组件资产和设计规范基本符合线上交付需要。

提升复用性

为了进一步提升工作流的可复用性，我们重点针对模型幻觉问题进行了解决。

双层效果复查，确保流程稳定

针对 AI 幻觉可能引发的流程不稳定或节点遗漏，我们重点做了两层防护：

• 第一层，AI 自检：在每个 Skill 中内置示例参考和完整性检查脚本，AI 生成完毕后自动对照该 Skill 的产出标准进行自检，若完整性不足则触发重新生成；
• 第二层，设计师复核：增设设计师判定机制，AI 自检通过后，主动请求设计师进行二次确认，确保关键节点不留盲区。

链接Mastergo，搭建 AI 与设计工具的闭环通路

在 AI 生成 UI 的过程中，遇到组件缺失或需要创新时，仅靠文字描述控制效率偏低，且受限于模型能力，效果也难以保证。为此，我们引入了一套基于图像编辑的兜底机制：

① AI 产出的界面（HTML 代码格式）可一键转化为可编辑的 MasterGo 稿件；

② 设计师在 MasterGo 中手动调整后，通过 MCP 将修改同步回传至 Agent。

由此形成「AI 生成 → 人工精修 → 回流迭代」的高效控制闭环。

 

#03 迭代复盘

回顾整个迭代过程，我们经历了三个关键转折，也沉淀出三点核心经验：

• 转折一：从「一键生成」到「分步协作」 —— 核心认知是：AI 的反馈单元应当缩小，无需追求一步到位。人对局部问题的判断力，远强于对整体问题的把控力。
• 转折二：从「结构正确但视觉错误」到「design.md 驱动」 —— 核心认知是：数据源质量 > 模型能力。一份精准的 design.md，比一个更强的模型更能决定最终产出质量。
• 转折三：从「规则全都喂给 AI」到「顺序与耦合度有讲究」 —— 核心认知是：先给具体实现（组件参考），再给抽象约束（规范规则），效果远优于一股脑全塞给 AI。我们称之为「食材」与「菜谱」的关系——先让 AI 看到食材，再教它如何烹饪。

 

#04 现状&价值

现阶段的能力边界较为明确——design.mdcomponent patternsglobal.css 中沉淀的设计规范和组件仅限于部分项目，各 Skill 节点中的 reference 也仅覆盖少数业务线。换言之，我们完成的是一次「窄场景下的深度验证」，距离「开箱即用的通用提效工具」还有一定距离。

但在这条”窄路”上，我们至少初步搭建了 AI 与设计师协作的基本范式。它不追求替代设计师，而是要求设计师站在更高的维度——从”怎么画”转向”怎么定义”，对结构意图、规范约束和产出判断提出更高要求。

同时，这个范式也帮我们厘清了长期需要持续沉淀的核心资产：

1. design.md —— 自家的设计规范（颜色/字号/间距/组件/动效）
2. 布局模式库 —— 常用的页面布局模式和适用场景
3. 组件映射规则 —— 组件库的 AI 可消费描述
4. 历史项目 Reference —— 已验证的优秀设计案例
5. 交互模式库 —— 标准交互模式（跳转/弹窗/加载/错误处理）

这些资产积累得越厚，AI Agent 能覆盖的交互场景也就越广——从一个按钮的局部更新，到整个页面的改版，再到跨链路的多屏联动，渐进式地扩展它的能力边界。

这才是一条可持续走下去的路。

 

原文：
https://mp.weixin.qq.com/s/1uchBsXx-77Zol1iEtbBMg