hand-drawn-diagrams

hand-drawn-diagrams 技能概览

hand-drawn-diagrams 的作用

hand-drawn-diagrams 技能会把一段自然语言需求转换成手绘风格的 Excalidraw 图，再进行校验，并且可以交付编辑 URL 以及可导出的图片结果。它最适合那些想要“像草图、像说明图”，而不是“精致企业级矢量图”的用户。

适合哪些人

如果你需要快速做教学图、UX 流程图、架构说明图、漏斗图或页面线框稿，又不想手动搭布局，就可以使用 hand-drawn-diagrams 技能。它特别适合主要目标是快速、清晰地传达结构，而不是手工打磨每一个视觉细节的场景。

它为什么不一样

它的核心差异在于工作流：这个技能不只是“画一张图”，而是会先把需求路由到对应的图类型，再生成 Excalidraw 文件，同时支持动画和导出。也就是说，hand-drawn-diagrams 这套流程更像是从提示词直接产出可用成品，减少布局错误，而不是纯粹自由涂画。

如何使用 hand-drawn-diagrams 技能

安装 hand-drawn-diagrams

在常见的 agent 环境里，可以这样安装：

npx skills add muthuishere/hand-drawn-diagrams --skill hand-drawn-diagrams

如果你希望 PNG 和动画 SVG 的渲染更快，可以安装 chrome-devtools-mcp 并把它加入 Claude Code 的 MCP 配置。没有它的话，渲染可能会回退到 Playwright，速度更慢，而且可能还需要安装浏览器。

给技能更好的提示词

这个技能最适合在你明确说明图的用途、受众和路由线索时使用。像“帮我画一个 app 的图”这种弱提示词，通常只会得到很泛的结构。更好的写法例如：

• “创建一个移动端密码重置的 UX 流程图。展示入口、验证、错误恢复和成功状态。”
• “做一个事件驱动订单处理的技术说明图。重点突出 publish、queue、worker、retry 和 notification。”
• “为 SaaS 分析仪表盘做一个页面 mockup。只有在能提升网页感还原度时才使用克制的配色。”

这样的描述能帮助 hand-drawn-diagrams 的使用路径选对路由，并包含该出现的元素。

先阅读这些文件

先看 SKILL.md，然后是 workflow.md、AGENTS.md 和 references/index.md。如果你想更直接地提升输出质量，还应该查看 references/activation-routing.xml、references/fundamental-shapes.md 以及与你任务匹配的路由专属参考文件。如果你是在排查安装或执行行为，steps/ 目录下的文件通常比 README 更有用。

按照 3 步工作流执行

这个仓库的规则比较明确：先路由，再绘制，最后校验并交付。默认情况下，输出文件应生成在 /tmp/hand-drawn-diagrams/<slug>/，必需产物是 diagram.excalidraw 和 diagram.animationinfo.json。如果这两个文件有任何一个缺失，工作流就还没有完成。

hand-drawn-diagrams 技能 FAQ

hand-drawn-diagrams 适合任何图吗？

不适合。它最强的场景是结果需要有草图感、说明感的时候，尤其适用于教学、UX、技术说明、头脑风暴或页面 mockup 这类路由。如果你需要像素级精确的品牌设计，或者完全定制的插画，普通提示词或专门的设计工具可能更合适。

使用它需要懂 Excalidraw 吗？

不需要。hand-drawn-diagrams skill 的设计目标就是接收自然语言，并替你生成结构。你只需要把图的目的、主要部分和期望路由描述清楚，细节不必懂 Excalidraw。

最大的限制是什么？

这个技能更偏向清晰、路由和校验，而不是艺术自由度。它不适合你想要完全不受约束的创作构图、重度配色风格，或者刻意忽略路由规则的图。只有当任务本身有清晰阅读路径时，hand-drawn-diagrams guide 的效果最好。

它和普通提示词有什么区别？

普通提示词往往只会生成一段“图的描述”。hand-drawn-diagrams 则是为产出可用的 Excalidraw 成品而设计的，会包含工作流步骤、路由选择和面向导出的输出。这让它在你需要一个可以编辑、分享并继续迭代的结果时更可靠。

如何改进 hand-drawn-diagrams 技能

先说明路由，而不只是主题

提升效果最快的方法，是直接说清楚你要哪一种图。“解释我的 API”太笼统；“展示 request、auth check、handler、database 和 response 的技术说明图”就足够可执行。当前提示词如果写明 hand-drawn-diagrams for Diagramming 输出希望采用的结构，技能就能更准确地路由。

提供最少但有意义的结构

把受众、主要步骤或组件、以及必须出现的标签写清楚。如果你对布局有偏好，也要明确说出来：从左到右的流程、从上到下的过程、分组备注，或页面 mockup。这样可以减少来回调整，也能避免图形被错误模式带偏。

注意常见失败模式

最常见的问题是标签太长、节点太多，以及关系不够明确。如果第一次输出显得拥挤，就收窄范围并重述关键顺序。如果箭头变得杂乱，先简化流程，再要求重新渲染。想要改进 hand-drawn-diagrams 的使用效果时，少一点想法通常比多一点细节更有效。

用有针对性的反馈反复迭代

每次只要求一种修改：简化标签、调整路由、降低密度，或者在 mockup 场景里提高还原度。如果图已经接近目标但还差一点，就直接指出出问题的具体区域，不要把整个提示词重新发一遍。这样下一版更容易贴合原本的任务目标，也能让 hand-drawn-diagrams install 的选择在实际使用中真正体现价值。