baoyu-design 实战复盘：从技能解析到儿童英语 App 高保真原型

⚡一句话总览：baoyu-design 把 claude.ai/design 的设计引擎封装成一个本地 Agent Skill，让 Cursor / Claude Code / Claude Desktop 在编辑器里直接产出可交互、可版本化的高保真 HTML 原型。本文先拆解它的机制与能力边界，再用一个真实的儿童英语口语 App 原型（warm-growth-journey）完整复盘一次「从 PRD 到可演示原型」的全流程，最后诚实地聊聊它的局限与踩坑。

阅读对象：正在探索 AI 辅助设计的开发者、产品经理、独立开发者。

你会得到：一套可参考、可复现的工作方法，而不是又一次「AI 太强了」的惊叹。

1. 缘起：把一次真实实践沉淀成方法

最近我在本地用 baoyu-design + Opus 5 做 UI 原型：从一份产品 PRD 出发，直接跑出了 5 个高保真页面、配套的数字人与场景图，并且可点击、可逐元素迭代。整个过程几乎没有传统意义上的「画图」，更像是一场「对话 + 点选」。

体验足够反直觉，值得认真复盘。所以这篇文章想回答三个问题：

• 它是什么——一个 skill 如何让本地 agent 临时获得设计执行力？

• 它怎么用——一次完整的原型是如何被「跑」出来的？

• 它的边界在哪——哪些是真本事，哪些是需要人工兜底的幻觉？

2. baoyu-design 是什么

baoyu-design 把 claude.ai/design 的设计能力打包成一个可携带的 Agent Skill，运行在本地 agent（Cursor、Claude Code、Claude Desktop 等）中，直接在编辑器里产出自包含的 HTML mockup。

它的本质可以概括为一句话：让一套「懂设计的系统提示 + 工具集」寄生在你本地的大模型上，agent 于是临时获得了 claude.ai/design 级别的设计执行能力。

几个关键事实：

3. 核心能力解析

3.1 工作流：加载任务后的 7 步

按 README 描述，加载一个设计任务后的执行链路大致如下：

1. Agent 读取 SKILL.md 与 system-prompt.md；

2. 探测宿主环境（Cursor / Claude Code / Codex 等）；

3. 加载对应的工具引用表（tool maps）；

4. 依据任务激活内建子技能；

5. 在 designs/<project>/ 下生成 HTML；

6. 在 localhost:4311 起一个预览服务器；

7. 进入点选式可视化迭代（point-and-click）——你不必再用文字描述「把那个按钮往左挪一点」。

3.2 内建子技能矩阵

它内置了一整套按域分类的设计技能：

3.3 导入与导出

• 导入：Figma .fig（离线解码）、GitHub 仓库、已有 HTML/CSS。

• 导出：独立 HTML、PDF、可编辑 PPTX（含动画，用 Playwright + PptxGenJS 渲染）、MP4 视频，以及 Figma / Canva 交接。

3.4 逐元素动画：data-anim

原型不是静态截图——每个元素都能挂动画，通过 data-anim 属性配合触发控制实现：

<li data-anim="fade-in"  data-anim-trigger="click">第一点</li>
<li data-anim="fly-in"   data-anim-dir="right" data-anim-trigger="click">第二点</li>
<img data-anim="zoom-in" data-anim-trigger="with" src="chart.png">
<div class="ball" data-anim="path" data-anim-path="C 100 -200 300 -200 400 0"></div>

效果涵盖 fade / fly / wipe / float / split / bounce / zoom / wheel / spin / pulse / grow-shrink / path；时序上支持 trigger="click|with|after"，以及延迟、时长、顺序、重复、自动反转。这套机制让「原型」真正能演示交互与动效，而不只是看图。

3.5 设计系统与 Starter Components

• 设计系统放在 designs/ 下，agent 自动发现并让你选择主/辅系统，生成本地自包含副本，用 _d_meta.json 记录绑定关系，重开项目时自动恢复。

• starter-components/ 提供一批起手骨架：设备外壳、浏览器、社媒模板、可平移缩放画板（pan-zoom canvas）、幻灯片/动画/图表/文档/文件/3D 舞台、tweaks 面板、可填充图片位。

4. 它解决了什么问题

对我而言，它的价值集中在四点：

1. 本地零依赖：数据不出仓库，天然适合有保密诉求的产品设计（比如我这次做的家庭内部 App）。

2. 产物自包含、可版本化：一个 HTML 就是一份完整原型，能 diff、能回滚、能进 PR 评审。

3. 点对点迭代：不用描述「那个东西」，直接点元素改，反馈闭环极短。

4. 从文字到高保真的跨度大：PRD → 可演示原型，省掉了一整轮 Figma 手工活。

🎯

适用场景：早期产品探索、内部工具 / 家庭项目的快速原型、给非设计背景的开发者一个「够用的设计起点」，以及把已有 Figma / HTML 快速二次加工。

5. 实战复盘：warm-growth-journey 儿童英语 App 原型

产物路径：designs/warm-growth-journey/，创建于 2026-07-25，_d_meta.json 标注 status: needs-review。

这一节是全文重点——把「我是怎么用它跑出一个真实原型的」讲透。

5.1 起点：从 PRD 到设计方向

产品是一款家庭内部版 Android 儿童英语口语学习 App，面向三个角色：姐姐（11 岁）、弟弟（7 岁）、家长。约束非常明确：竖屏优先、家庭内部使用、半写实数字人教师、不做社区 / 排行榜 / 付费商城。

在进入高保真之前，我先基于完整 PRD（Docs/20260720/PRD-...-MVP-v1.0.md）让模型产出了三套视觉方向：

• 方案 A：暖光成长叙事型（Warm Growth Journey）

• 方案 B：沉浸式 AI 未来课堂

• 方案 C：模块化学习操作系统

最终选定方案 A 进入高保真——它的气质是「温暖、可信、陪伴、成长」，避开了过度游戏化和冰冷科技风。这正是 baoyu-design 「前端美学方向（frontend aesthetic direction）」子技能的典型用法：先定调，再做稿。

提示词：

@Docs/20260720/PRD-家庭儿童英语口语学习App-MVP-v1.0.md ,此文档是需求prd文档；

@Docs/PrototypeDesign/D12-方案A-暖光成长叙事型.md ，此文档是邀请国际顶尖互联网科技公司资深的UI/UX资深设计师给出的一个方案；

使用 /baoyu-design ,按照'D12-方案A-暖光成长叙事型.md'方案，帮我设计方案中5个页面的高保真原型页面

5.2 跑通流程：一次完整的 DesignCanvas

原型用 React + ReactDOM 组织，结构是 DesignCanvas → DCSection → DCArtboard → PhoneBezel → Screen。app.jsx 把 6 个画板分成三组：

// 412 × 892 的 Android 竖屏外壳
function App() {
  return (
    <DesignCanvas>
      <DCSection title="P01 · 儿童端首页">
        <DCArtboard label="P01 · 姐姐首页"><PhoneBezel><ScreenHome personaKey="sister" /></PhoneBezel></DCArtboard>
        <DCArtboard label="P01 · 弟弟首页"><PhoneBezel><ScreenHome personaKey="brother" /></PhoneBezel></DCArtboard>
      </DCSection>
      <DCSection title="P02–P04 · 学习闭环">
        <DCArtboard><PhoneBezel><ScreenClassroom /></PhoneBezel></DCArtboard>  {/* 数字人课堂 */}
        <DCArtboard><PhoneBezel><ScreenRoleplay /></PhoneBezel></DCArtboard>   {/* AI 情景对话 */}
        <DCArtboard><PhoneBezel><ScreenPractice /></PhoneBezel></DCArtboard>   {/* 练习 */}
      </DCSection>
      <DCSection title="P05 · 家长中心 / 周报">
        <DCArtboard><PhoneBezel><ScreenParent /></PhoneBezel></DCArtboard>
      </DCSection>
    </DesignCanvas>
  );
}

这正是 baoyu-design 工作流的落地：澄清问题 → 收集上下文（PRD）→ 产出 HTML → 预览校验。模型不会一口气吐出一个页面，而是先用画板（artboard）把「信息架构」摆出来，再逐屏填充。

5.3 关键细节：我是怎么把它做「对」的

（1）Persona 分级：同一套代码，两种密度

这是我最喜欢的一点。姐姐和弟弟共用 <ScreenHome personaKey=...>，差异全部由 theme.css 的设计令牌（token）驱动——令牌注释里写着 from PRD §24，意味着每个设计决策都能追溯回需求文档：

:root {
  --growth: #4EAA68;      /* 成长绿：主按钮/进度/成功 */
  --sun:    #F4C85B;      /* 暖阳黄：奖励/成长星 */
  --soft-blue: #4C78A1;   /* 信息蓝：语音/数字人状态 */
  --cream:  #FBF8F1;      /* 暖白背景 */
  --btn-h: 52px; --mic-size: 72px; --yellow-tint: 0.12;
}
[data-persona="brother"] { --btn-h: 64px; --mic-size: 80px; --yellow-tint: 0.22; --title-size: 22px; } /* 弟弟：更大按钮、更暖 */
[data-persona="sister"]  { --btn-h: 50px; --yellow-tint: 0.08; --pad: 18px; }                          /* 姐姐：更密、更克制 */

效果非常直观——同一屏，弟弟端按钮更大、留白更暖、字号更大；姐姐端信息密度更高、装饰更克制。改一处令牌，两端同步变。 这种「用 token 做 persona 分级」的思路，比手工维护两套页面干净得多。

（2）图片生成：数字人与场景图从何而来

原型里用到了 7 张图（数字人教师正/侧面、餐厅场景、姐弟 hero、姐弟头像）。它们不是凭空出现的，而是先写图像生成提示词 → 再用图像生成能力产出 → 最后组装进页面。prompts/ 下保存了这些提示词，例如数字人教师正面（prompts/01-character-teacher-front.md）：

Semi-realistic, soft 3D render of a friendly female English teacher, about 30 years old. Shoulder-length dark brown softly wavy hair, gentle professional natural smile, light mint-teal blouse... Upper body mid-shot, centered... Soft bokeh classroom background in warm cream and soft green tones. Child-friendly but not cartoon, not uncanny valley...

提示词的关键技巧可以拆成三点：锁定风格词（semi-realistic / soft 3D）、明确负面约束（not cartoon / not uncanny valley / no text）、指定构图（mid-shot, 3:4 portrait）。这样同一个教师在正面 / 侧面两张图里才能保持较高的一致性。生成后的图落到 imgs/，再在 theme.css 里用 drop-shadow、定位等方式「贴」进课堂舞台与情景对话背景。

（3）逐元素迭代：点选式修改

baoyu-design 的预览支持点画板右上角全屏聚焦，以及在课堂 / 对话页点麦克风切换状态。麦克风的「听 → 处理 → 成功」用纯 CSS 动画模拟：

.mic-btn.is-listening  { animation: mic-pulse 1.4s ease-in-out infinite; }
.wave span { animation: wave 0.9s ease-in-out infinite; }   /* 5 根条形的语音波形 */

当我只想改「练习页那张推荐卡的圆角」或「家长页进度条的颜色」时，直接点元素 → 改 token/CSS → 预览即时刷新，全程不用描述位置。这就是 point-and-click iteration 的真实手感。

图片生成

这里得提一下，cursor中集成了各种model，包括Cursor 原生 GenerateImage技能，所以原型设计时用到的图片，都是使用的cursor的生图技能来生成。【以下内容是制定plan时，opus模型主动规划的】

先把每张图的最终 prompt 写入 prompts/NN-*.md，再用 Cursor 原生 GenerateImage 生成，产物移入 imgs/。统一风格块：半写实、轻 3D、柔和暖光、儿童友好但比例真实、奶油底调、无文字。计划 7 张：

1. 数字人教师中近景半身（30 岁女性、深棕齐肩微卷发、浅青绿上衣、自然微笑）— P02 主视觉

2. 同一教师略偏一侧构图（让出关键词信息区）— P02 互动态

3. 餐厅场景背景 + AI 服务员角色 — P03 场景画布

4. 姐姐端主课程卡场景插画（餐厅点餐，接近真实生活）— P01

5. 弟弟端主课程卡场景插画（玩具商店，温暖绘本世界）— P01

6. 姐姐头像、7. 弟弟头像（柔光小头像，P01 顶部与 P05 家庭卡复用）

数字人相关三张用 1 号图作 reference_image_paths，保证形象一致（PRD §32.3 恐怖谷风险的应对是「统一人物标准、不频繁更换外观」）。

5.4 成果一览

最终产出 5 个页面（P01 含姐弟两个 persona 变体，共 6 个画板），全部为 412×892 Android 竖屏高保真，配套 7 张生成图与 7 份提示词。以下为原型 HTML 的实际渲染截图。

P01 · 儿童端首页（姐姐端 / 弟弟端）——同一屏代码，靠 persona token 切换密度：

P02 · 数字人互动课堂——半写实教师 + 字幕条 + 麦克风状态：

P03 · AI 情景对话——场景背景 + 任务浮层 + 对话气泡：

P04 · 练习——推荐练习卡 + 可展开模块：

P05 · 家长中心 / 周报——非考试化、不横向排名的成长视图。

设计画板总览：DesignCanvas 把多个 artboard 平铺在一块可缩放画布上——这正是 baoyu-design 最典型的产物形态。

6. 局限、边界与踩坑

诚实地说，它不是万能的。这一节是我踩过的坑和明确的边界。

1. needs-review 是硬约束，不是装饰。_d_meta.json 把产出标为 needs-review——baoyu-design 自己不保证设计正确，信息层级、文案、可达性、与 PRD 的一致性都必须人工过一遍。把它当「成品」直接交付是有风险的。

2. 图像生成的可控性与一致性有限。数字人正 / 侧面要看起来是「同一个人」，需要反复调提示词；场景图与 UI 色板（暖绿 / 暖黄）的统一也要手动约束。AI 出图不是确定性的，复现同一角色靠的是固定风格词 + 负面约束 + 构图参数，而不是运气。

3. 交互与数据是「模拟」的，不是真的。麦克风状态、对话气泡、进度数据都是 CSS 动画加 data.jsx 里的 mock 数据。它不是可运行的应用：没有后端、没有真实语音识别、没有状态管理。当原型演示可以，当产品骨架不行。

4. 对 Opus 级模型有依赖，成本不低。README 指明 best with Opus 4.8；我用 Opus 5 效果很好，但换到更小的模型，保真度和「一次到位率」会明显下降。大原型（多屏 + 复杂令牌）的 token 成本不低，值得在任务拆分上做规划，别一次性塞太多屏。

5. 移动端真机还原度需要单独验证。原型用 412×892 固定画框，字体走 Google Fonts（Nunito Sans，需联网），圆角 / 阴影 / 安全区在真机上还得另测。「在浏览器里好看」不等于「在手机里好看」。

6. 无构建是双刃剑。JSX 在浏览器端直接运行、改起来很轻，但代价是单个 HTML 会随原型变大而变重；超大原型的前端性能要心里有数。

7. 结语与选型建议

baoyu-design 给我的最大价值，是把「从需求到可演示高保真原型」这条路上的中间手工劳动几乎抹掉，同时把产出变成可版本化、可追溯（令牌挂回 PRD）、可逐元素迭代的工程产物——它让「设计」更像「写代码」，而不是「画图」。

🧭

一句话收尾：把它当成一个「住在本地 agent 里、产出工程化 HTML 的设计搭档」——你仍然是设计师 / 产品负责人，它负责把你的判断快速变成可看、可点、可改的东西。