让 Agent 画一张架构图，九成会得到一坨方块字符。三五个框还能忍，再往上就是等宽字符挤在同一条线上打架。visual-explainer 想改掉这个默认动作：它让 Agent 交出一个网页，图是手绘感的线，字号会随屏幕变，点开就能读。
这个技能 1 万 Star、MIT 许可，作者 nicobailon。我在隔离沙箱里读了它全部 132 个文件，把自带的三个校验跑了一遍，又写了一批故意出错的页面喂给它。结论分成两半：它在「格式对不对」上是个真正的闸门，五个错误页面全部拦下；换成「话说没说清」，它基本不管。
它到底在做什么
普通技能教你「怎么干」，这个技能管「怎么交付」。你描述一个系统，它不让 Agent 在终端里排版，而是让它写一个 HTML 源文件，再跑一条命令把它变成成品网页，最后用无头浏览器把页面打开看一遍。
关键在于中间那步。技能自带一个样式包（也就是 kit，一套预置的字体、配色、图形零件和脚本），渲染时整包内联进成品页面，所以单个网页能脱离仓库独立打开。我做出的测试页 1,382 字节，渲染后 53,489 字节，多出来的全是内联样式，约 39 倍。
页面骨架长这样：一句主标题、一张首图、几段图注和短段落。技能文档给的规矩很硬——一张图只讲一个结论，结论写进图注；正文只做标签，一段不超过三行。这条规矩和大多数人的习惯相反：我们习惯先写一堆解释，最后补张图。
它准备了四种版式（仪表盘、蓝图、纸面、杂志），全部分别渲染过一次，没有一种报错。还带了十个现成指令，覆盖差分审阅、方案审阅、状态机、幻灯片、视频导出这些场景。
| 环节 | 你要做的 | 它替你做的 |
|---|---|---|
| 写源文件 | 描述系统、挑版式 | 提供图形零件与绘图规则 |
| 渲染 | 跑一条命令 | 内联样式、展开数据标签、算出图形坐标 |
| 自检 | 看它列的清单 | 用浏览器按手机与桌面两个宽度检查 |
实测：三个自带校验全绿，零依赖就能跑
先交代边界。全部操作在一次性沙箱里完成：只读的系统根目录、临时家目录、仓库落在独立挂载点，跑完即弃。技能本体是 0.14.0 版，15,794 行，5.5 MB。
它自带三个校验脚本，我都跑了一遍：
| 校验 | 查什么 | 结果 |
|---|---|---|
| 版本一致性 | 七个清单文件里的版本号是否相同 | 通过，全部为 0.14.0 |
| 样式包一致性 | 模板页里的副本是否与主文件一致 | 通过，2 个页面 |
| 状态机契约 | 18 个模型跑出的状态是否符合文档 | 通过，18 个模型 4 个页面 |
三关全绿，而且都是同一个作者写的测试——这只能说明它自洽，说明不了它有用。所以我接着测了更实际的两件事。
第一件，渲染需要装东西吗。我把依赖目录整个挪走，只留系统自带的 Node，渲染照样成功。这意味着任何人拿到这个技能，不需要装任何第三方库就能出页面。同一份源文件渲染两次，产物的指纹完全一致，也就是说同样的输入不会给你两个不同结果。含浏览器检查的完整渲染耗时 2.9 秒。
第二件，它会不会自己骗自己。这是我最关心的地方。技能文档说渲染完会「在浏览器里看一遍页面」，我造了五个坏页面扔进去。
五个格式错误，五个全拦下
这是全文最值得说的部分。它列出的问题不是「某某属性不合法」这种空话，而是直接报出行号和后果：
| 我造的错 | 它的反应 |
|---|---|
| 柱状图给了负值 | 报「柱状图从零起算」，并拒绝写文件 |
| 数值列太长，挤爆刻度 | 报两条错误：超出上限、超出可显示宽度 |
| 图里的文字没设颜色 | 报「在深色版式下会变成黑字看不见」 |
| 页面放了一个超宽元素 | 报「在手机和桌面两个宽度下都横向滚动」 |
| 图中标签字号压到 6px | 报「实际只有 10.5px，必须 12px 以上」 |
最后一条最能说明设计取向。视觉上的毛病写规则写不完，但它退了一步：图里的字小到看不清，一定读不懂，那就只守这一条，用真实渲染尺寸去量。这也是它为什么要开浏览器——字号在样式表里写 6px，实际渲染出来可能是别的数。
拒绝写文件这个细节也值得记一笔。格式错时会直接不产出产物，而不是先写出来再警告你。我确认过，报错的那次确实没生成文件，退出码为 1。
它放过的三件事
同一批测试里，有三类问题它一声不吭：
图注漏了，它只记账。 我把一张图的图注整段删掉，渲染依然成功，只在摘要里多了一句「2 张图，其中 1 张没有图注」。视觉检查报零问题。可技能文档自己写着「一张图一个结论，结论在图注里」——最核心的规矩，恰恰没有闸门。
字体用了它明令禁止的，它不管。 文档里列了不许用的字体（其中包含一款几乎人人都在用的无衬线字体），我把它设成唯一字体，视觉检查照旧报「无问题」。这类审美规则只存在于文字里，没有落到代码上。
标题贴住下一段，它也不管。 代码里确实写了间距检查，但只在特定条件下触发，我构造的紧贴场景没被判定。
这三条合起来指向同一件事：它能验证「画得出来、看得清」，验证不了「说得对、够好看」。前者是几何与渲染问题，可以计算；后者需要判断，它交给了读页面的你。
和同类比，适合谁
和 Mermaid 比，它不是同一种东西。Mermaid 让你写文本、由库画出标准流程图，胜在能进文档、能被版本管理；visual-explainer 的产物是独立网页，胜在排得开、能放数据图和小倍数对比，代价是它不能塞进 Markdown 文档里。
和我们之前评过的 Archify 比，那款专攻架构图，把代码仓库画成系统地图；visual-explainer 是通用版面，图只是页面的一部分。和 Anatomy 那类插图技能比，后者追的是图好不好看，它追的是页面能不能把一件事讲完。
适合的人：经常要把「一次代码改动」「一份方案」「一个状态机」讲给同事，又不想在终端里排 ASCII 表的人。也适合把它当 Agent 的出图后端，它带了一个通用接口，别的工具可以调它的两个动作——准备和渲染。
不适合的人：只想在 Markdown 里嵌一张流程图，那 Mermaid 更省事；想要能导进 PowerPoint 的精美演示，它的导出是尽力而为，HTML 才是正品；机器上完全没有浏览器或不想装无头浏览器的，视觉检查会直接跳过，闸门等于没有。
还有一点要说清：它的评测目录虽然跟着仓库，但明确写着不随包发布。也就是说，这个技能没有内置的评分基准，你没法直接比较两个版本的输出好坏，只能像我今天这样自己造样本。
我的判断
放观察清单，值得试，但别指望它替你把关内容。
它的真正贡献不在「画得好看」，而在把「渲染后自检」变成了流程的一环——这是多数 Agent 技能都没做的事。技能大多只给写作规范，写完就交，对错全靠模型自觉。visual-explainer 的做法是：规范写在文档里，能算的落成闸门，算不了的留给读者。
这也解释了它为什么始终没突破万星量级。它解决的问题真实，但偏工具向，不像那些讲「省一半 token」的技能容易传播。如果你常做技术沟通，它省下的是每次手工排版的十几分钟。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：