把设计交付接入编程 Agent 的开源技能

huashu-design 想把设计交付搬进程序员熟悉的 agent：输入需求，拿到网页、可点击原型、演示文稿或动画。它的重点不只是让 AI 写 HTML，而是把找素材、选方向、检查问题和导出文件串成一套流程。

3.0 最值得看的变化，是用六张缩略图筛出三个真实方向，再用参考板、风格样张和本机记录减少重复。不过，「3 到 30 分钟交付」「像大厂设计团队」仍是作者的宣传与自评，需要和 README 展示的案例分开看。

三个方向怎么才能不只是换配色

很多 AI 页面单独看还行，放在一起却像同一个模板。huashu-design 3.0 试图把差异放到开工前解决。

遇到模糊需求，它先澄清一轮，索要 logo、品牌色和参考作品，取齐内容必需的真实图片，再从三条路线各出两个候选：借鉴两位气质不同的设计师；拆解两件同媒介的优秀作品；用 date +%S 从风格分区抽取方向。

现实参照也不是报几个名字。scripts/ref_board.py 会先截图，让 agent 看过页面，再分析网格、字号比例和色彩分布。六个候选先排成一页缩略图，挑出质量够好、彼此有区别的三版做完整稿，其余三版留作备选。

先让用户看到差别，再让用户选择，比先问一个抽象风格名更有用。

底层有 84 种 HTML 原生风格：网页、PPT、信息图各 20 种，App、中文与东亚各 12 种，每种都有源码和样张。它们用纯 CSS 实现，不要求先生成图片。

作者为这次调整提供了三轮内部盲选记录：第一轮强制使用大隐喻，4 题只赢 1 题；第二轮增加避免默认外观的禁令，2 题全输；第三轮增加候选、样张和真实参考，同两道题都赢了。

这个结果支持「多提供可比较的选择」，但样本很小，不能据此认定所有设计任务都适用。README 也没交代完整评分标准和评审过程。

从 HTML 到交付文件，中间补了什么

对前端开发者，这套方案最容易理解的地方是：HTML/CSS 既是设计载体，也是渲染和导出的起点。

App 原型提供 iPhone 15 Pro 机身、状态栏和 Home Indicator，用状态驱动多屏切换，再通过 Playwright 自动点击测试。它能帮助确认页面是否连通，但可点击原型距离生产 App 还有业务逻辑、数据和工程集成。

演示文稿则走 HTML Slides 到可编辑 PPTX 的路线。html2pptx.js 读取 DOM 的 computedStyle，逐元素翻译成 PowerPoint 对象，导出真文本框，而非把整页截图塞进幻灯片。

动画采用 Stage + Sprite 时间片段模型，用 useTime、useSprite、interpolate、Easing 四个 API 组织时间与变化，支持 MP4、GIF、60fps 插帧和配乐成片。信息图则用 CSS Grid 排版，可导出 PDF 矢量、PNG 300dpi 和 SVG。

这些能力并非没有边界。作者明确排除了复杂 3D、物理模拟和粒子系统，也不支持到 Figma 的图层级编辑交接。README 一边强调 PPTX 文本可编辑，一边提醒产出的 HTML 不能直接拖进 Keynote 改文字位置。选用前应按最终接收软件验收，不能把「可编辑」理解成任意工具间无损流转。

原文说核心设计、渲染和导出链路 100% 本地运行、零网络零 key。这个范围需要看清：它不代表运行 agent 不需要模型服务；找真实素材、截线上参考作品也会联网。豆包 TTS、AI 看片评审则是可选云能力，放在 scripts/cloud/，首次调用需用 --yes 显式确认。

比风格库更值得借鉴的是检查与记忆

huashu-design 把主观审美和可核对的问题分开处理。

scripts/design_lint.py 检查图片损坏、文字过小、对比度不足、控制台报错等事实问题；全大写小标签等模板装饰属于黄灯提醒。三个版本是否只是换皮、是否撞上近期项目，则用 compare 和 ledger check 检查。这个体检不负责给美感打分。

README 另有五维专家评审，按哲学一致性、视觉层级、细节执行、功能性、创新性各打 0–10 分，输出 Keep / Fix / Quick Wins。两者用途不同：前者找可验证的缺陷，后者提供带判断成分的修改意见。

记忆也分两部分。scripts/learn.py 保存用户说过的偏好与教训，记录前会告知；外观账本记录项目的底色、色板、字体和版式骨架，下次开工主动避开重复。文件只存在本机 ~/.huashu-design/。

菜谱 App 案例就用了这条规则：最近 6 个交付里有 5 个采用无衬线标题，于是这次选择宋体。它解决的是跨项目单调，但对需要保持统一的产品系列，显然不能机械地「主动避开」。

涉及具体品牌时，流程要求先问、搜索、下载资产、用 grep 查色值，再写 brand-spec.md。比起只输入品牌名称，这能给 agent 提供实际约束。作者报告 v1、v2 各跑 6 个 agent，v2 的「稳定性方差」低 5 倍，不过没有说明指标定义和原始结果，暂时只能按内部实验结论理解。

我的判断

这套 skill 最有价值的是把设计过程变得可讨论：先有素材和参考，再比较方向；先暴露假设，再投入完整制作；最后用工具查明显问题。对已经习惯 Claude Code、Cursor、Codex、OpenClaw 或 Hermes 的开发者，这种工作方式确实能减少切换图形界面的成本。

但案例只能证明作者跑出过这些结果。3.0 发布时新跑了 6 道题，README 前五个案例是其中挑选出来的，虽然作者称方向由 agent 自选、没有插手，也不能据此推算普通用户的成功率和平均耗时。「早改比晚改便宜 100 倍」、空白品牌只有 60–65 分、整体是 80 分 skill，同样没有统一量表。

我更认可它作为设计起稿与代码交付流程的价值。它和图形工具相比的优势是贴近 agent，代价则是缺少直接操纵图层的交互。已有成熟设计系统的团队，也未必需要每次生成三个新风格，保持组件与品牌一致可能更重要。

能拿来做什么

• 做前端原型时，先限定关键屏幕、点击路径和必须使用的素材，让 agent 给出可比较的方向，再用 Playwright 验证主流程。视觉检查与交互检查都要保留。
• 做技术分享或发布演示时，先拿少量页面测试 HTML 到 PPTX 的导出效果，确认文字、图片和排版能在接收方软件中继续编辑，再扩成整套。
• 即使不安装，也可以把「截图参考、记录假设、展示变体、检查渲染」加入日常 AI 编程提示词；团队产品则应优先沿用已有设计规范。
• 准备试用时，可以使用下面的安装命令，并检查安装目录里的配套文件是否齐全。

npx skills add alchaincyf/huashu-design

要留意命令安装下来的内容：除 SKILL.md，还应有 references/、assets/、scripts/、demos/。原文称其中有 99 处配套引用；skills CLI ≤1.5.15 存在只同步单文件的 bug，已在 1.5.19 修复，缺目录时应先升级再重装。