让 AI 像一个靠谱的实习生一样，从读 PRD 到出交互稿，全链路辅助设计师。 更多把设计师从「重复搬砖」里解放出来，让设计师能把更多的时间投入设计决策的思考。
1. 背景：交互设计师的时间都去哪了？
作为交互设计师，在实际项目中总是有一些重复的工作占用了我们的精力——重复沟通、组件填入……导致花在「真正需要设计师判断力」的事情上相对有限。这不只是效率问题——当 GenUI（生成式 UI）正在成为行业趋势的时候，这个矛盾会被急剧放大。
1.1 交付范式的迁移 & 竞品探索进度
大语言模型（LLM）正在重塑设计协作的流程 —— 从传统的「设计师交付像素级设计稿，开发人员手动还原」，逐步演进至「设计师表达结构化意图，由 AI 自动生成 UI」。在这一浪潮中，Google 推出的 Stitch 一度成为热议焦点——它生成的页面在视觉一致性上确实令人惊艳，也让我们对它在闪购这类高频迭代业务中的应用抱有期待。但经过实际验证后，我们发现 Stitch 目前既无法接入我们日常依赖的内部组件库，也难以 100%还原品牌设计规范，这意味着它产出的界面再“好看”，也只是一座空中楼阁——缺乏可维护性、无法复用、更谈不上基于现有产品视觉体系做出创新。
1.2 目标
基于此，我们希望在行业转型窗口期内，打通一条 AI 辅助的全链路工作流——覆盖从需求到交互稿的全过程，并确保最终交互稿具备投入生产的可能性。
围绕这一目标，我们将整个探索过程拆解为三个阶段，每个阶段解决一个关键命题，逐层递进：
- STEP 1：怎么让产出更符合交互逻辑？——让 AI 先学会”画对”，产出符合交互逻辑的设计稿
- STEP 2：怎么更像实际产出？——在交互成立的基础上，让 AI 直出交付级还原度的设计稿（组件、规范全对齐）
- STEP 3：怎么提升复用性？——固化流程能力，提升工作流复用性，实现链路的稳定调用与规模化产出
2. 搭建过程
2.1 从设计师的动作序列出发
第一步先回到设计师的日常，把「从接到 PRD 到交付交互稿」拆成具体的动作序列：
拆完之后，我们做了一件关键的事——为每个步骤打上两个维度的标签：标准化程度和设计判断密度。从评估结果来看，大部分设计步骤呈现出“高标准化 + 低判断密度”的特征，这意味着它们天然适合被转化为 SKILL。
| 步骤 | 标准化程度 | 设计判断密度 | Skill 化适配度 |
| 读 PRD 提取要点 | 高 | 低 | 非常适合 |
| 推导交互流程 | 中高 | 中 | 适合 |
| 画布局骨架 | 中 | 中高 | 适合 |
| 填内容选组件 | 高 | 低 | 非常适合 |
| 补异常态写说明 | 高 | 低 | 非常适合 |
| AB 方案 + 埋点 | 中高 | 中 | 适合 |
2.2 写几个 Skill，6 个还是 1 个？
设计稿产出本身过程较多，步骤复杂，因而在产出 skill 前，我们对方案架构进行了思考，并最终选择 Plan B——基于流程步骤，串联上下游产出，并分别输出对应的 skill。
2.3 Skill 产出 & 效果
基于多 skill 的架构，最终产出共五个 skill
- PRD 需求理解 SKILL：从 PRD 提取非药推荐的业务目标、场景、功能清单——识别核心用户场景分析，设计目标与设计策略
- 交互流程推导 SKILL：推导用户从搜索到购买的全链路——识别关键分支：起送价是否满足
- 页面框架 SKILL：基于场景行为分析——页面框架的多方案尝试（按分类分组 vs 智能去重）
- 组件映射填充：基于页面框架和 .design 中已沉淀的组件样式——生成组件和字段填充的列表
- 交互逻辑补齐：基于前置分析的交互链路——补齐无结果、超时等异常态
实际测试下来，基于前期五个 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 的完整生成链路基本成型
2.4 二期迭代效果验证
实测后，组件的应用率和整体效果有了较大的提升——组件资产和设计规范基本符合线上交付需要。
2.5 提升复用性
为了进一步提升工作流的可复用性，我们重点针对模型幻觉问题进行了解决。
2.5.1 双层效果复查，确保流程稳定
针对 AI 幻觉可能引发的流程不稳定或节点遗漏，我们重点做了两层防护：
- 第一层，AI 自检：在每个 Skill 中内置示例参考和完整性检查脚本，AI 生成完毕后自动对照该 Skill 的产出标准进行自检，若完整性不足则触发重新生成；
- 第二层，设计师复核：增设设计师判定机制，AI 自检通过后，主动请求设计师进行二次确认，确保关键节点不留盲区。
2.5.2 链接 Mastergo，搭建 AI 与设计工具的闭环通路
在 AI 生成 UI 的过程中，遇到组件缺失或需要创新时，仅靠文字描述控制效率偏低，且受限于模型能力，效果也难以保证。为此，我们引入了一套基于图像编辑的兜底机制：
① AI 产出的界面（HTML 代码格式）可一键转化为可编辑的 MasterGo 稿件；
② 设计师在 MasterGo 中手动调整后，通过 MCP 将修改同步回传至 Agent。
由此形成「AI 生成 → 人工精修 → 回流迭代」的高效控制闭环。
3. 迭代复盘
回顾整个迭代过程，我们经历了三个关键转折，也沉淀出三点核心经验：
- 转折一：从「一键生成」到「分步协作」 —— 核心认知是：AI 的反馈单元应当缩小，无需追求一步到位。人对局部问题的判断力，远强于对整体问题的把控力。
- 转折二：从「结构正确但视觉错误」到「design.md 驱动」 —— 核心认知是：数据源质量 > 模型能力。一份精准的 design.md，比一个更强的模型更能决定最终产出质量。
- 转折三：从「规则全都喂给 AI」到「顺序与耦合度有讲究」 —— 核心认知是：先给具体实现（组件参考），再给抽象约束（规范规则），效果远优于一股脑全塞给 AI。我们称之为「食材」与「菜谱」的关系——先让 AI 看到食材，再教它如何烹饪。
4. 现状&价值
现阶段的能力边界较为明确——design.md``component patterns``global.css 中沉淀的设计规范和组件仅限于部分项目，各 Skill 节点中的 reference 也仅覆盖少数业务线。换言之，我们完成的是一次「窄场景下的深度验证」，距离「开箱即用的通用提效工具」还有一定距离。
但在这条”窄路”上，我们至少初步搭建了 AI 与设计师协作的基本范式。它不追求替代设计师，而是要求设计师站在更高的维度——从”怎么画”转向”怎么定义”，对结构意图、规范约束和产出判断提出更高要求。
同时，这个范式也帮我们厘清了长期需要持续沉淀的核心资产：
- design.md —— 自家的设计规范（颜色/字号/间距/组件/动效）
- 布局模式库 —— 常用的页面布局模式和适用场景
- 组件映射规则 —— 组件库的 AI 可消费描述
- 历史项目 Reference —— 已验证的优秀设计案例
- 交互模式库 —— 标准交互模式（跳转/弹窗/加载/错误处理）
这些资产积累得越厚，AI Agent 能覆盖的交互场景也就越广——从一个按钮的局部更新，到整个页面的改版，再到跨链路的多屏联动，渐进式地扩展它的能力边界。
这才是一条可持续走下去的路。 🆃