Huashu Design 开源解读：当设计能力被写成一个 Agent Skill
大家好，我是若风。
这两天我看了一个很有意思的开源项目：alchaincyf/huashu-design。
说实话，第一次看到它的介绍，我的直觉反应是：这是不是又一个“让 AI 生成漂亮网页”的 Prompt 包？现在这类项目太多了，标题都很猛，实际打开以后，经常还是紫色渐变、圆角卡片、emoji 图标那一套。
但把代码拉下来读完，我发现它不是这个路子。
Huashu Design 更像一套被封装成 Skill 的设计操作系统：SKILL.md 负责给 Agent 下设计纪律，references/ 负责在不同任务里补充专业知识，assets/ 提供 HTML / React starter components，scripts/ 再把最终产物导出成 MP4、GIF、PDF、PPTX，并用 Playwright 做验证。
它有点像把一个比较会带人的设计负责人，写进了一个 Agent Skill 里。
截至我调研时，GitHub 页面显示这个项目大约有 14.8k Star、2k Fork，仓库最新提交是 2026 年 5 月 22 日；README 里也明确写了 2026 年 5 月 14 日起改为 MIT License，个人和商业使用都免费。安装方式很简单：
npx skills add alchaincyf/huashu-design但这篇文章不想写成安装教程。
我更想聊的是另一个问题：为什么一个“设计 Skill”会在短时间内拿到这么多关注？它到底把哪件事想明白了？
先说结论
Huashu Design 的核心价值，不是“让 AI 画得更好看”，而是把设计交付拆成了一条可执行的工程链路。
这条链路大概有 4 层：
| 层次 | 仓库里的对应部分 | 解决的问题 |
|---|---|---|
| 设计纪律 | SKILL.md | 让 Agent 不要一上来就凭空画，而是先确认事实、资产、场景和边界 |
| 专业知识库 | references/*.md | 按动画、幻灯片、PPTX、评审、设计风格、视频导出等任务加载细节 |
| 产物组件 | assets/*.jsx / assets/*.js | 提供 Stage/Sprite、设备外壳、Deck、变体画布、旁白舞台等可复用骨架 |
| 导出验证 | scripts/* | 把 HTML 变成 MP4、GIF、PDF、PPTX，并用 Playwright 检查白屏、控制台错误、截图 |
所以它不是“写一段单点 Prompt”，而是“把设计交付流程拆成可执行系统”。
它更像一个“设计生产流水线”：前面管需求和上下文，中间管表现形式，后面管导出和验收。
如果用一句话概括：
Huashu Design 把“AI 做设计”从灵感型生成，往流程型交付推了一步。
这也是我觉得它值得拆的地方。因为 AI 设计最麻烦的从来不是生成一张“看起来还行”的图，而是连续稳定地交付：今天做 App 原型，明天做发布动画，后天做 PPT，最后还要能导出、能验证、能修改。
它不是 Figma 插件，而是 Agent 工作流
很多设计工具的默认假设是：用户坐在画布前，拖、点、改、对齐。
Huashu Design 的默认假设反过来：用户在终端或 Agent 对话里，说清楚目标，然后让 Agent 产出一个可运行的 HTML 作品。
README 里列的能力很宽：交互原型、HTML 幻灯片、时间轴动画、设计变体、信息图、设计方向顾问、5 维度专家评审。交付物也不是单一图片，而是 HTML、MP4、GIF、可编辑 PPTX、PDF、PNG、SVG 这些更接近真实工作流的东西。
这个定位挺关键。
它不是要替代设计师的所有工作，也不是把 Figma 变成命令行版。它解决的是另一类需求：当你不想打开图形界面、不想手动搭框架，但又想让 Agent 交付一个能演示、能录屏、能继续改的设计物时，Skill 该怎么约束 Agent。
这就是为什么它在 README 里反复强调“HTML 是工具，不是媒介”。
做幻灯片时，不要像网页。
做动画时，不要像 Dashboard。
做 App 原型时，不要像说明书。
这句话背后其实是一个很朴素的判断：AI 最容易犯的错误，不是不会写 HTML，而是把所有东西都写成同一种“AI 网页味”。Huashu Design 想解决的，正是这种媒介错位。
第一层：事实和资产先行
我读 SKILL.md 时，最先注意到的是它的“核心原则 #0”：事实验证先于假设。
这个原则说得很硬：只要涉及具体产品、技术、事件、人物的存在性、发布时间、版本号、规格参数，就必须先搜索验证，不能靠记忆乱说。README 里也把这个原则放进了 Core Mechanics：具体产品或技术出现时，先确认存在性、发布状态、版本和关键规格。
为什么一个设计 Skill 要这么强调事实？
因为高保真设计最怕“主角画错”。
比如你给一个真实品牌做发布动画，Logo、产品图、UI 截图、颜色、字体，任何一个关键资产错了，后面的动效再丝滑也没意义。Huashu Design 的核心资产协议把这件事拆成 5 步：问、搜、下载、验证和提取、固化成 brand-spec.md。
这里面有两个很值得学的点。
第一，资产优先级高于风格词。 它认为品牌识别主要靠 Logo、产品图、UI 截图，色值和字体只是辅助。这个判断非常对。很多 AI 设计失败，就是因为只抽了几个颜色，然后用通用图形硬凑，最后看起来谁都像。
第二，上下文要落盘。 找到的 logo、产品图、UI 截图、色值、字体，不是只在对话里说一句“我知道了”，而是写成 brand-spec.md。这一步很工程化，也很重要。因为 Agent 的上下文会漂，落盘才会变成后续文件可以复用的约束。
这套逻辑其实不只适合设计。
任何 AI Agent 工作流，只要涉及真实世界对象，都应该先把事实和资产固化下来。否则你不是在交付，是在赌模型记忆。
第二层：用 references 做按需知识库
Huashu Design 的仓库里有一组很扎实的 references/ 文档。
我数了一下，里面包括动画最佳实践、动画坑点、设计风格库、内容指南、幻灯片、可编辑 PPTX、评审指南、视频导出、旁白流水线、工作流、验证流程等 20 多个文件。主 SKILL.md 不会把所有细节都塞进去，而是根据任务提醒 Agent 去读对应文档。
这点也很像一个成熟工程项目的设计。
主提示词负责原则和路由，子文档负责专业细节。
比如做动画，就读 references/animations.md、animation-pitfalls.md、video-export.md；做幻灯片，就读 slide-decks.md、editable-pptx.md；需求太模糊，就进入设计方向顾问模式，从 design-styles.md 里的 5 个流派、20 种设计哲学里挑 3 个方向。
这个结构比“一个超长 Prompt 管所有事”更稳。
因为不同任务的评判标准不一样。App 原型要看交互和状态；PPT 要看叙事节奏和页面层级；动画要看时间、镜头和导出；信息图要看数据和排版。把这些知识拆成可读的 reference，Agent 才有机会在合适的场景里调用合适的纪律。
从这个角度看，Huashu Design 的开源价值不只是它能生成什么，而是它示范了一种 Skill 的组织方式：
主 Skill 定义人格和流程，references 定义领域知识，assets 定义可执行骨架，scripts 定义交付出口。
第三层：HTML 不是网页，而是统一中间格式
Huashu Design 选择 HTML 作为核心产物，这个选择很有意思。
HTML 的缺点很明显：它不是 Figma 文件，不是 AE 工程，也不是 Keynote 原生格式。你想做图层级精修，它不如专业设计软件顺手。
但 HTML 对 Agent 太友好了。
它是文本，可生成、可 diff、可版本管理；它能直接跑在浏览器里；它能用 CSS Grid、字体、图片、视频、Canvas、SVG、React 组件组合视觉；它还能被 Playwright 截图、录屏、导出。
所以 Huashu Design 不是把 HTML 当“网页”，而是把它当一个统一中间格式。
这就解释了 assets/ 目录的意义。
animations.jsx 提供 Stage + Sprite 时间片模型，暴露 useTime、useSprite、interpolate、Easing 这些接口，让 Agent 可以像写轻量 Remotion 一样做动画；ios_frame.jsx、android_frame.jsx、macos_window.jsx、browser_window.jsx 提供设备或窗口外壳；deck_stage.js 和 deck_index.html 服务 HTML deck；design_canvas.jsx 用来做多变体并排比较；narration_stage.jsx 则面向带旁白的长动画。
这些组件不是业务组件，而是产物骨架。
它们的作用，是让 Agent 不必每次从零发明“怎么做一个 iPhone 外壳”“怎么做时间轴”“怎么做幻灯片翻页”。一旦这些底座稳定，设计质量就不只依赖单次生成运气。
这也是它和普通 Prompt 包的区别。
Prompt 包更多是在教模型怎么想。
Huashu Design 还给了模型一套可以直接拿来用的手和脚。
第四层：导出链路才是交付分水岭
很多 AI 设计 demo 到最后会卡在一个尴尬问题：看起来不错，但怎么交付？
你能发一个截图，能发一个 HTML，已经算不错。但真实工作里，用户经常要的是 MP4、GIF、PPTX、PDF，甚至是可编辑文本框，而不是一张扁平图片。
Huashu Design 在 scripts/ 里补了这层。
render-video.js 用 Playwright 打开 HTML，再通过浏览器录制和 ffmpeg 转成 MP4。它还处理了一个很实际的问题：React/Babel 编译、字体加载、首帧渲染会造成录屏前几秒黑屏，所以脚本会等页面设置 window.__ready，再计算需要裁掉的时间。animations.jsx 里的 Stage 组件也会在录制模式下强制不循环，避免视频结尾又跳回第一帧。
convert-formats.sh 负责 MP4 到 60fps 插帧和 GIF；add-music.sh 给视频加背景音乐；export_deck_pdf.mjs、export_deck_pptx.mjs、html2pptx.js 则把 HTML 幻灯片导到 PDF 或 PPTX。
尤其是 html2pptx.js，它不是简单截图塞进 PPT，而是读取 DOM computed styles，把文本、图片、形状、列表、占位元素转换成 PowerPoint 对象，并检查尺寸匹配和内容溢出。这意味着导出的 PPTX 至少保留了继续编辑的可能性。
这一步很关键。
因为“AI 能生成”到“团队能使用”，中间差的往往就是导出、验证、可修改。
没有导出链路，作品只是浏览器里的表演。
有了导出链路，它才开始接近交付物。
第五层：验证流程把审美变成质量门
Huashu Design 还有一个值得注意的地方：它把验证写进了 Skill。
references/verification.md 里要求每次产出 HTML 后做浏览器渲染检查、控制台错误检查、多视口检查、交互检查、幻灯片逐页检查。仓库里的 scripts/verify.py 也很直接：用 Playwright 打开 HTML，截图，抓 console warning / error，报告 JavaScript 错误。
这听起来不性感。
但非常实用。
AI 生成的 HTML 最常见问题，不是“审美差一点”，而是白屏、脚本报错、字体没加载、窄屏崩、动画录出来有黑帧、Deck 翻页挂掉。靠模型自信地说“完成了”没有用，必须让浏览器说话。
这也是我看完项目后最认同的一点：
设计 Agent 不应该只追求生成能力，还应该自带验收能力。
很多时候，最后 1 分钟的 Playwright 检查，能省掉后面 1 小时返工。
和 Claude Design 的关系
README 里很坦诚地写了它和 Claude Design 的关系：核心资产协议的哲学来自 Claude Design 流传出的系统提示词启发。作者的判断是，Claude Design 是更好的图形工具，而 Huashu Design 想让“图形工具”这层消失。
这个对比挺准确。
如果你已经在 Claude.ai 里做图形编辑，需要直接操作画布、拖拽、导 Figma，那 Claude Design 这种产品形态更自然。
但如果你的工作流主要在终端、代码仓库、Agent 对话里，Huashu Design 这类 Skill 形态就更顺手。它的结果是文件，过程是文本，验证是脚本，导出是命令。
换句话说：
| 维度 | Claude Design | Huashu Design |
|---|---|---|
| 产品形态 | 浏览器里的图形产品 | 可安装到 Agent 的 Skill |
| 操作方式 | GUI 编辑 | 对话 + 文件生成 |
| 核心产物 | 画布内容 / 设计稿 | HTML / MP4 / GIF / PPTX / PDF |
| 适合人群 | 想直接操作视觉画布的人 | 想把设计交付纳入 Agent / 代码工作流的人 |
| 关键优势 | 图形交互直接 | 可复用、可脚本化、跨 Agent |
这不是谁替代谁的问题。
更像两条不同路线：一条把 AI 放进设计工具，一条把设计流程写进 AI Agent。
适合什么场景
我会把 Huashu Design 放在这几类场景里优先考虑。
第一，产品发布动画。 如果你要把一个产品概念、功能流程、发布信息做成 30 到 60 秒的动效，Stage + Sprite + 导出脚本这套链路很适合。
第二，交互原型。 特别是 App 原型、Web 原型、状态驱动的多屏流程。HTML 比静态图更容易表达点击、切换和流转。
第三，演示幻灯片。 对技术分享、产品提案、内部汇报来说，HTML deck 加 PPTX 导出很有吸引力。先用浏览器做高自由度设计，再导出给传统办公流程。
第四，设计方向探索。 当需求很模糊，直接做一个最终稿风险很大。它的设计方向顾问模式，会先给 3 个差异化方向，再让用户选，这比“我随便做一个好看的”靠谱得多。
第五，设计评审。 5 维度专家评审虽然不能替代专业设计总监，但它能帮团队把主观审美拆成哲学一致性、视觉层级、细节执行、功能性、创新性几个维度，至少讨论起来不至于只剩“好看/不好看”。
不适合什么场景
它的边界也很清楚。
第一，它不是生产级 Web App 框架。 SKILL.md 里也写了，不适合需要后端的动态系统、生产级网站、SEO 网站。这些还是应该回到正常前端工程。
第二，它不适合图层级精修。 README 里明确说，不支持图层级可编辑的 PPTX 到 Figma 往返。HTML 可以截图、录屏、导出，但不是 Figma 文件。
第三，它不适合极复杂视觉特效。 3D、物理模拟、粒子系统、Framer Motion 级复杂动画，都超出它的舒适区。你可以硬做，但那就不是它最划算的用法了。
第四，完全没上下文的高保真设计会降级。 这也是项目自己承认的限制：从零做品牌，质量可能只有 60 到 65 分。因为高保真设计本来就不是从空气里长出来的。
这个诚实很重要。
好的工具不是声称自己什么都能做，而是知道什么时候该停下来问用户要素材。
我最喜欢它的 3 个设计判断
第一，把“不要 AI slop”写成明确规则。
它不是抽象地说“做得高级一点”，而是列出反模式：紫色渐变、emoji 图标、圆角加左边框、SVG 人脸、Inter 当 display 字体、凭空画产品图。越具体，Agent 越容易执行。
第二，把设计师工作流拆成 Junior Designer 模式。
不是上来就憋一个大招，而是先写假设、占位、推理说明，尽早 show 给用户，再进入真实组件、变体和细节打磨。这个流程很像真实团队里带新人：先确认方向，再投入大工作量。
第三，把输出验证当成默认动作。
很多 Prompt 工程只管生成，不管运行。Huashu Design 把 Playwright 截图、console 检查、多视口、逐页检查写进流程，这让它更像一个可交付工具，而不是灵感玩具。
真正值得借鉴的不是设计，而是 Skill 工程
看完这个项目，我觉得它最值得借鉴的地方，反而不只是“怎么让 AI 做设计”。
更重要的是：一个复杂 Skill 应该怎么组织。
它不是一个孤零零的 SKILL.md。
它有主提示词，有按需引用文档，有 starter components，有导出脚本，有验证脚本，有 demos，有测试 prompts。它把“Agent 应该怎么想”和“Agent 可以用什么工具”放在同一个仓库里。
这很像未来很多 AI 工作流的形态。
不是每个任务都要做成 SaaS。
有些能力，更适合做成一个可安装、可读、可改、可版本管理的 Skill。它不需要复杂后端，不需要账号系统，不需要数据库。它只需要把人的专业判断、文件模板、执行脚本和验收标准组织好，然后交给 Agent 去跑。
从这个角度看，Huashu Design 是一个很好的样本。
它证明了一件事：当 AI Agent 开始真正进入工作流，开源项目的形态会变得更“混合”。
既不是纯代码库。
也不是纯文档。
而是提示词、组件、脚本、知识库、案例和验证流程的组合体。
最后说两句
如果你把 Huashu Design 当成“AI 设计神器”，可能会有点期待过高。
它不是魔法按钮。
但如果你把它当成一个开源的 Agent Design Workflow，就会发现它很有启发：它没有把希望全部寄托在模型审美上，而是把上下文、资产、组件、导出、验证这些笨功夫都写进流程里。
这恰恰是 AI 工具从 demo 走向交付时最需要的东西。
我觉得它最有价值的一句话，不是“打字，回车，一份能交付的设计”，而是另一层潜台词：
好设计不是被模型凭空生成出来的，而是被一套正确的上下文和流程约束出来的。
这也是所有 Agent Skill 最该学习的地方。
评论互动