一句话拿设计？huashu-design 先让 AI 出三版给你挑
“在你的 agent 里打一句话，拿回一份能交付的设计。”
这句是 huashu-design README 里的说法。听着有点大，像广告语。可把仓库看完以后，我反而觉得最值得讲的，不是这句口号。
它不是只教 AI 写几句漂亮 CSS，也不是让模型凭感觉画一个“科技风页面”。它做得最重的一件事，是不让 AI 太快给最终答案。
很多设计需求，一开始都很含糊。用户说“做个好看的页面”“做个产品介绍动画”“做个演讲 PPT”。这时候 AI 最容易装懂，直接开做。做完以后，用户才发现方向不对。
huashu-design 的解决办法很笨，也挺有效：先做三版看得见的真实方向，让人选。选完，再继续深入。
1. 它不是普通网页 Skill
huashu-design 的范围很宽。
README 里写得很清楚：它可以做交互原型、演讲幻灯片、时间轴动画、设计变体、信息图和专家评审。这些东西最后大多先落到 HTML 上，再根据需要导出 PNG、PDF、PPTX、MP4 或 GIF。
这点要先说清楚。
它不是生产级 Web App Skill。它也不是 Figma 插件。它更像一个在 agent 里工作的设计师工具箱：用 HTML/CSS/JS 做高保真视觉，再用脚本把它导成不同交付物。
所以它的重点不是“网页怎么写”。重点是：当用户只给一句模糊需求时，AI 怎么走一条比较像设计流程的路。
2. 最关键的一道门：三方向
huashu-design 的 SKILL.md 里，有一条很硬的规则：任何会产出新视觉设计的任务，都要先出三个方向初稿。
这三个方向不能只是文字描述。
网页、信息图、原型，要出真实 HTML 和截图。多页 deck，要出两页代表页。动画或宣传片，要出方向板，至少有真实静帧、色板和气质定位。
也就是说，它不让用户在“赛博极简、温暖手作、现代商务”这种文字标签里瞎选。文字选风格，其实很难选。每个人脑子里的“高级”“简洁”“活泼”都不一样。
把三版真实画面摆出来，用户才知道自己喜欢什么。
这一步看起来费时间，但省返工。设计这事，最贵的不是多做两张图，是一开始方向错了，后面越做越像在修一辆开错路的车。
3. 代码里怎么实现
这个仓库不是一个 SKILL.md 就完事。
README 还专门提醒，安装后要检查 references/、assets/、scripts/、demos/ 四个目录是不是都在。因为旧版 skills CLI 有过只同步单文件的问题，缺了这些目录，这个 Skill 基本就少了胳膊腿。
SKILL.md 管总流程。它把任务先分路：原型、PPT、动画、信息图、评审。只要是新视觉设计，都先走三方向硬门。
references/ 放的是做事手册。比如 brand-asset-protocol.md 写品牌资产怎么找；design-styles.md 放风格库；slide-decks.md、editable-pptx.md、video-export.md 分别管幻灯片、可编辑 PPTX 和视频导出。
assets/ 放可复用组件。比如 ios_frame.jsx、android_frame.jsx、browser_window.jsx、deck_stage.js、animations.jsx。它们不是拿来点缀页面的小素材，手机原型的手机框、幻灯片的 deck 舞台、动画的时间轴，都从这里出来。
scripts/ 才是很多硬活发生的地方。
fetch_images.py 负责找内容需要的真实图片。html2pptx.js 会读 DOM 的 computed style，再把 HTML 元素转成 PowerPoint 对象。export_deck_pptx.mjs 把 deck 导成 PPTX。render-video.js 和 render-video-seek.js 管视频导出，后者偏确定性逐帧渲染。verify.py 用 Playwright 做检查。design-gate-hook.sh 则像一个门卫：如果没选定方向，就别急着渲染。
这套分工很清楚：Skill 规则负责管流程，HTML 负责承载视觉，脚本负责导出和验证。
4. 为什么要先找真实素材
huashu-design 还有一个挺重要的判断：如果设计里出现具体品牌或产品，就要先找真实 logo、产品图、UI 截图和色值。
这不是形式主义。
AI 做设计时最爱偷的懒，是拿色块和抽象图形糊弄具体对象。你让它做一个产品发布动画，它不去找产品图，直接画一个黑底圆角小盒子，配一点蓝光。看起来也挺“科技”，但谁都不像。
huashu-design 的品牌资产协议要求先问用户有没有资产，没有就去官方渠道找。找不到也要诚实写 placeholder，不能假装已经有了。
这个规则很适合普通用户。因为小白不一定知道自己要提供 logo、色板、截图。Skill 把这个问题提前问出来，质量会差很多。
5. 公开反馈：强，但也不轻
公开反馈里，我看到两类声音。
第一类是“这个方向有用”。README 自己展示了很多 demo：iOS 原型、HTML slides 转 PPTX、motion design、信息图、专家评审。这些 demo 至少说明它在交付物链路上花了不少功夫，不只是写了一组文字规则。huashu-design README 也把跨 agent 使用和 MIT 协议写得很明确。
第二类是“门槛和稳定性还要磨”。Issue #47 专门补了安装自检和旧版 skills CLI 兜底说明，原因就是这个 Skill 依赖的目录太多，只装到 SKILL.md 会出问题。Issue #30 里也有人反馈安装失败后用手动方式解决。
体验层面也有真实问题。Issue #36 里有人说自己用不同模型尝试后，可视化效果和 demo 差距很大。这个反馈挺有价值：同一套 Skill，在不同 agent、不同模型、不同环境里，结果可能差很多。
还有一些更具体的坑。Issue #34 提到移动端显示和比例问题；Issue #32 则有人希望看到导出 PPT 的演示。
所以我不会把 huashu-design 说成一个“打开就稳定出大片”的产品。它更像一套很重的设计工作流，适合愿意让 agent 跑一段流程的人。你要的是十秒生成一张图，它可能显得麻烦；你要的是从方向、资产、交付、验证都管起来，它就有意思了。
6. 怎么装，怎么用
把这个 GitHub 地址给 AI：
https://github.com/alchaincyf/huashu-design
然后说：
请帮我安装这个仓库里的 huashu-design Skill。
装好后检查 references、assets、scripts、demos 这几个目录都在。
装好后，可以先用一个小任务试：
用 huashu-design 做一个 AI 笔记工具的落地页，先给我三版视觉方向，我选完再继续。
或者：
用 huashu-design 做一份 6 页演讲 deck。先出三版方向，每版给 2 页代表页。
如果你想测试它的强项，别只说“做个好看的页面”。给它一点真实内容，比如产品名、目标用户、必须出现的文字、喜欢和不喜欢的参考。它能问，但你给得越具体，三版方向越有比较价值。
7. 你可以这样写自己的 Skill
如果你要写一个“设计交付类 Skill”，可以从 huashu-design 抄这套骨架。
适用场景：用户想让 AI 做原型、PPT、信息图、动画、设计评审，而不只是写普通页面代码。
触发条件：用户说“做个设计”“做个 PPT”“做个原型”“导出视频”“给几个风格方向”。
输入：用户需求、目标受众、交付格式、品牌资产、参考链接、必须出现的内容、尺寸和限制。
输出：三版真实视觉方向、用户选定后的 HTML 原型、PPTX、PDF、MP4、GIF 或评审报告。
工作流：先澄清需求；再写一份足够具体的设计 spec；判断图片和品牌资产是不是必需；拿到素材后出三版真实方向；用户选定后再深入做；交付前用脚本导出并检查。
关键约束：不能让用户只看文字选风格；不能缺品牌资产就硬画；不能编数据；不能用坏 SVG 图标糊弄；不能跳过移动端或导出验证。
可选工具：图片抓取脚本、品牌资产索引、HTML 截图、PPTX 导出、视频逐帧渲染、Playwright 检查、设计 gate hook。
可改造方向：如果你写公众号文章生产 Skill，也可以借它的“三方向”思路。比如同一篇文章先出三个开头方向、两种结构方向、两种封面方向，让人先选味道，再进入细写。别让 AI 第一轮就假装自己已经懂了。
8. 我的判断
huashu-design 最有启发的地方，是它把“选择”留在了该留的地方。
AI 可以很快产出一版东西。快是它的本事，也是它最容易犯错的地方。设计早期更该先把几个不同方向摆出来，让人看着选，不要急着把第一版当答案。
这套 Skill 写得有点重，规则多，目录多，脚本也多。小任务会嫌它慢。
但如果你要交付的是 PPT、原型、动画、信息图这类视觉产物，它至少把几个关键问题提前挡住了：素材从哪来，风格谁来选，输出怎么导，结果怎么验。
这比一句“做得高级一点”靠谱多了。
