baoyu-design：在本地编码 Agent 上运行 Claude Design

把设计流程搬进本地 Agent

baoyu-design 做的不是又一个网页版设计工具，而是把 Claude Design 的方法、工艺约束与交付流程整理成一套可安装的 Agent Skills。它面向 Cursor、Claude Code、Codex，以及任何能够读写本地文件、运行命令和打开浏览器预览的编码 Agent。安装后，用户仍然在熟悉的项目目录里工作：需求进入对话，HTML 落到仓库，预览跑在本机，设计稿可以提交、比较和继续修改。

这个项目重新打包了 Anthropic 用于 claude.ai/design 的设计能力，但它是社区独立维护的项目，不隶属于 Anthropic，也没有得到官方背书。理解这一点很重要：它复用的是设计方法论和本地工作流，不是把托管网站的账号、云端 Artifact 或服务端工具原样搬下来。项目采用 MIT 许可证，当前仓库以 JavaScript 为主，同时有中英文 README、更新日志和五套可被 Agent 读取的技能说明。

先澄清，再选择正确的产物类型

入口技能 baoyu-design 首先读取 system-prompt.md。这份文档承载设计流程和工艺标准，是整套技能的核心约束。随后，它根据当前环境加载对应的工具说明：Claude Code、Cursor 和 Codex 各自有提问、预览、截图、调试与校验的方式，不能假设所有 Agent 都拥有同一种浏览器接口。

面对新任务时，Agent 会先确认设计上下文、输出保真度、需要探索几个方向，以及项目要保存到哪里。如果用户给出截图、设计系统、Figma 导出文件或代码库，它会先读取真实材料；没有上下文时则会主动索要，避免从空白想象开始。接着，Agent 才按照产物类型加载专项说明：高保真界面、交互原型、线框图、幻灯片、移动端原型、文档、动画、研究报告、HTML 邮件、图表或 3D 对象。这个路由步骤决定了后续是生成单个页面、多文件幻灯片、画布还是数据仪表盘。

输出会集中放在 designs/<project>/。Agent 通过本地 HTTP 服务展示结果，并尽量在浏览器里完成一次真实校验。相比只生成一张静态截图，这种流程保留了页面结构、交互、字体、图片和可修改源码，用户可以直接指出预览中的某个元素并要求修改，Agent 再去改对应的 HTML、CSS 或数据文件。

五套技能，分别解决不同交付问题

主技能 baoyu-design 负责自包含 HTML，包括界面稿、落地页、原型、移动应用画面、打印文档、动画和演示文稿。它适合“页面就是最终产物”的工作，所有必要资源会被收进项目目录，方便版本控制和直接预览。其余四套技能则把 claude.ai 的 Artifact 类型拆成各自的文件格式和本地编辑器。

claude-slides 用 project/deck.json 管理页序、主题、字体和章节，每张幻灯片是一份独立的 HTML。用户可以在本地幻灯片编辑器里放映、改字、拖动、插入图片和图形，也可以导出 PDF、独立 HTML 或 PowerPoint。claude-design 用 canvas.json 与多个 .dc.html 设计组件组织画板，支持并排评审、原型播放、全屏查看以及 PNG、PDF、HTML 导出。

claude-design-system 面向设计系统本身，保存 token、品牌说明、组件预览、字体与素材分组。它可以从现成组件库导入，把真实组件安装、打包并挂进本地预览；也可以从代码、Figma 文件或已有说明中整理出可消费的系统。claude-dashboard 则接收 CSV、TSV 或 JSON 数据集，页面上的图表、数字和表格必须能通过 Sources 面板追溯到具体数据行。它明确使用附加文件而不是实时数据库连接，因此更新数据的方式是重新提供导出文件并让页面重算。

文件就是人与 Agent 的协作界面

四套 Artifact 技能的共同点不是某种视觉风格，而是“同一份源文件，两个编辑入口”。Agent 写入 deck.json、canvas.json、token 文件或仪表盘数据，本地编辑器立即显示变化；用户在编辑器里改文案、拖动元素或调整参数，保存结果仍回到原文件。这样就不必在网页编辑器和仓库之间来回复制，也不会出现“模型生成的版本”和“人最终修改的版本”各存一份的问题。

每个技能都带有 scripts/artifact.mjs，提供打开、校验、上传素材和读取设计系统等命令。编辑器是预构建的本地页面，不需要额外部署服务。幻灯片和画布的 Node.js 要求是 20 及以上，仪表盘要求 22 及以上；主技能的多文件预览可以用 Python 3 的静态 HTTP 服务完成。依赖很轻，但并非零环境要求：Agent 必须能够执行 Node 或 Python，并访问本地浏览器或等价的可视化校验工具。

设计系统是一份有约束力的视觉契约

baoyu-design 对设计系统的处理比“把一组颜色贴进提示词”严格。选中某个系统后，导入脚本会把一份自包含、锁定版本的副本同步到项目的 _ds/<slug>/，接入所需的 CSS 与组件脚本，并在项目的 _d_meta.json 里记录绑定关系。项目再次打开时，Agent 先读这份元数据，再加载对应的系统提示，继续沿用同一组 token、字体、间距与组件。

多个系统也可以同时绑定，但必须有一个主系统负责整体观感，并在 token 冲突时优先；其他系统只提供特定组件。设计系统如果带有起始页面或组件，也可以作为新项目的种子。用户可以刷新系统、增加系统、切换主次或移除绑定，但每次变更都应重新审视项目里的页面，而不是悄悄退回自由发挥。

导入要保留来源，导出要说明边界

真实材料比文字描述可靠。技能支持三类导入来源：Figma 的 .fig 文件可以在本地离线解码，不需要 Figma 账号、API token 或 MCP；GitHub 仓库先通过 gh api 浏览目录树，再用 sparse checkout 只取需要的路径到项目外部临时目录，并记录仓库地址；已有 HTML/CSS 会被当作代码参考，读取实际样式表、颜色、字体、间距、圆角、阴影和交互状态，而不是仅凭截图猜测。

Figma 导入可以只挑组件转成 React 代码，也可以把整个 UI Kit 编成设计系统。后者会按语义重新组织组件，整理 token CSS，原样提取 SVG 与 PNG 素材，并生成规范卡片和品牌 README。导入后的设计系统可以编译成单个可交互的 preview.html，让审查者在同一页里检查组件、token 和使用说明。

导出同样不是“点一下就把网页变成任何格式”。PDF 与独立 HTML 延续浏览器里的设计；视频导出通过逐帧捕获动画生成 MP4；Figma、Canva 和交接流程输出的是可继续工作的材料。PowerPoint 有两种模式：截图版把每页压成整张图片，视觉最接近浏览器但不可编辑；可编辑版会把文本、形状和图片转换为 PowerPoint 原生对象。

可编辑 PPTX 只适用于由这套技能制作的、具有明确分页结构的幻灯片，不是任意网页的通用转换器。导出器先用 Playwright 启动无头 Chromium，加载运行中的页面，读取计算样式、字体、布局、图片与画布内容，再把 DOM 结构转换成 PptxGenJS 对象。标记为 data-anim 的元素还会被映射成 PowerPoint 原生动画，包括入场、退场、强调与运动路径。即便如此，它仍是近似重建：复杂滤镜、部分 CSS 效果和不同播放器的动画语义都可能与浏览器存在差异，签发前仍应在目标 PowerPoint 环境里检查。

安全边界和实践限制

项目在近期版本提升了设计系统导入的安全边界。导入时读取和复制的路径必须留在设计系统与项目目录内；指向外部的 @import、清单条目或符号链接会被跳过并报告。从 npm 组件库生成实时预览时，安装命令使用 --ignore-scripts，避免直接运行依赖包里的生命周期脚本。这些措施降低了素材导入变成任意本地文件访问或代码执行的风险，但不能替代用户对来源仓库、依赖和 Agent 工具权限的审查。

使用体验也有明确上限。技能依赖模型遵循长指令和设计判断，官方建议搭配能力较强的模型以获得更稳定结果；本地编辑器需要 Node，仪表盘需要更新的 Node 版本；多文件原型必须通过 HTTP 预览，不能依赖 file://；数据集是附加文件，不会自动刷新；浏览器里的精细视觉效果不一定能完整搬到可编辑办公文档。把 baoyu-design 当作一套高质量、可审查的本地设计工作流，比把它当成“所有格式无损转换器”更准确。

适合谁用

最直接的受益者是把编码 Agent 当作主要工作环境的开发者、独立产品团队和设计工程师。他们希望快速做出可交互页面、用真实组件库约束视觉、把设计稿纳入 Git，并且不想让人与 Agent 的修改分裂成两个版本。需要批量制作产品演示、研究报告、数据仪表盘或带讲解材料的团队，也能从四套 Artifact 技能的文件化协作中获益。

如果工作重点是精细的多人实时协作、云端素材管理或保证浏览器页面与 PowerPoint 完全逐像素一致，这套项目并不能替代专业设计平台。但在“让本地 Agent 真正参与设计制作、让每轮修改都能落到源码、让交付物可复现和可继续编辑”这条路径上，baoyu-design 给出了一个结构清楚且可检查的实现。它最有价值的部分不是某个单独的提示词，而是把澄清、上下文、产物路由、本地预览、设计系统、导出与校验串成了一条可重复执行的工程流程。