我故意画坏一张图，只为看它拦不拦：archify 与「验证优于生成」

一、装好之后我做的第一件事，是把图画坏

昨天装了个画架构图的工具，叫 archify。

装完我没急着用它画图。我做的事是——故意画坏一张图。

理由很简单。任何工具都会告诉你它成功的时候长什么样。官网的示例永远漂亮，README 的截图永远精致。那些东西说明不了任何问题。你只有故意做坏一件事，才知道这台机器是真的在检查，还是只是礼貌地点点头。

于是我拿它自带的一张 Web 应用架构图（Users → CDN → LB → API → PostgreSQL，旁边挂 Redis 缓存和 SQS 队列），动了两刀：

第一刀，把 Redis 挪到 API Server 身上，两个方块间距压到 38 像素。
第二刀，加一条从 PostgreSQL 横穿全图连回 Users 的线，让它途径 CloudFront、负载均衡、API Server 三个跟这条关系毫无关系的组件。

这种图画出来是什么效果，你大概能想象：字压字，线穿框，一团糊。

然后我让它校验。

它回了我六行。原样摘两条：

[clean-flow/edge-through-node]
connections[9] id "db-to-users" "db" -> "users" crosses component "lb"
on segment 0 [880, 337] -> [520, 337] (2px clearance)

[composition/label-route-clearance]
label "HTTPS" on connections[0] is 0px from connections[9] label "sync back"
(label rect [188, 317, 34, 14]; minimum 4px)

翻译成人话：第 9 条连线，从 db 到 users，在第 0 段、坐标 [880,337] 到 [520,337] 这一段上，穿过了 lb 这个组件，净空只剩 2 像素。第 0 条连线上的 "HTTPS" 标签，跟第 9 条连线的标签贴在一起了，间距 0 像素，而最小值是 4 像素。

我接着让它交付。退出码 1，HTML 文件没有生成。

不是"生成了但很丑"。是根本没有这个文件。

这就是我想聊聊的东西。

二、为什么让 AI 画图这件事，本身就有点荒唐

有一篇讲这个的文章，里面有句话我觉得说得极准：语言模型没有视觉皮层。它预测的是 token，不是像素。

这句话值得停下来想一想。

你让一个模型"画一张架构图"，它本质上在干什么？它在逐字吐出一串字符。你说"在 x=412, y=88 放一个节点，然后让这条线绕过三个其他节点"，它就得在脑子里——如果那能叫脑子的话——做碰撞检测和图布局，而且是盲着做，一个 token 一个 token 地做。

它看不见自己画出来的东西。

这就好比让一个背熟了棋谱但从没见过棋盘的人下盲棋。他能背出每一步的标准走法，但你问他"现在这个局面，马是不是被别住了"，他是真的不知道。

所以传统上有两条路，两条都不太好走：

第一条，让模型直接吐 SVG。 这就是纯粹的盲像素摆放。超过七八个节点就崩，而且崩得无声无息——你得到的还是一张图，只是一张烂图。没人会报错，因为没有错可报，坐标都是合法数字。

第二条，让模型吐 Mermaid。 好一些，至少布局交给了真正的引擎。但你把一个脆弱的语法交到了一个时不时会手滑的家伙手里。A -->|yes| B，多一个竖线，少一个括号，整个渲染直接炸掉——不是"这条边画错了"，是整张图都没了。

而且 Mermaid 的布局跑在无头浏览器里，重、慢，塞进 agent 循环里简直是受罪。

两条路的共同毛病是：都在让模型干它最不擅长的事。一个是空间推理，一个是刚性语法的零容错输出。

三、它的解法：不是让模型更小心，是改变分工

archify 的做法，说穿了就一句话——让模型干它擅长的（描述这张图是什么意思），把它不擅长的（这些东西该摆在哪）交给一个确定性程序。

具体是这样走的：

模型写一份带类型的 JSON（叫 Typed JSON IR），里面只有节点、关系、边界、语义类型。没有坐标。坐标是渲染引擎算的。

然后一个本地 Node 程序做三件事：按 schema 校验 → 算布局 → 渲染成单文件 HTML。渲染完还要再回头检查产物本身：SVG 是不是只有一个、坐标是不是有限值、箭头有没有意外变成斜线、标签有没有压到别的线上。

五道门全部通过，文件才落盘。任何一道不过，退出码 1，什么都不写。

听起来平平无奇对吧？编译器不都这么干吗。

对，就是编译器。 这就是我欣赏它的地方。

你从来不会指望编译器"尽力编译一下"。你要的是它明确告诉你第几行错了、错在哪。可在画图这件事上，我们居然忍了这么多年没有报错的工具——图烂了就烂了，顶多自己手动挪一挪。

四、有意思的不是它报错，是它的报错带尺子

我在上面贴的那两条诊断，重点不是"它报错了"。重点是它报的错里有数字。

再看几条我实测拿到的：

这不是"报错"，这是量尺。

工程师开会为一张图吵架，最缺的就是一把公认的尺子。你说"这个太挤了"，他说"我觉得挺好"，然后谁也说服不了谁。现在有了：8 像素、24 像素、16 像素、4 像素。都是数字，不用吵。

而且它在回执里还会附上一堆测量指标：最短线段 54px、最短内部段 104px、最大折弯数 3、标签最小净空 20px。它真的在量，不是拍脑袋。

五、我自己跑的那一轮实验

光看别人的示例不算数。我把五种图各交付了一次，用的都是它自带的例子：

交付回执里还有一样东西我很喜欢：源文件和成品各给一个 SHA-256。源文件 3,793 字节，成品 715,216 字节，两个哈希都在。意思是——你拿到的这张图，跟这份 JSON 是一对一的，可以复现，可以对账。

然后是我最想验证的那件事：坏图到底能不能交付出去？

答案是不能。退出码 1，目标路径下空空如也。它叫"原子交付"：先在临时目录渲染检查，全过才原子替换目标文件。半成品永远不会出现在你眼前。

六、它不干什么 —— 这部分我觉得比前面都重要

一个工具值不值得信，看它敢不敢说自己不干什么。

它不解析 Mermaid 语法。 README 里明明白白写着"自动 Mermaid 解析不在产品范围内"。它接受 Mermaid 输入，但那是让模型读懂你的拓扑再重写一份 IR，不是机械转译。

它不是通用绘图编辑器。 不是 draw.io，不是 Mermaid 换肤，不做所见即所得。

校验通过不等于好看。 这句是它自己写的：截图回执里那个字段永远写着 visualReview: "pending"。意思是——截图是给你看的证据，不是"我检查过了，很漂亮"的声明。

就这一条，我对这个项目的信任度翻了一倍。一个敢在自己的回执里写"待人工复核"的工具，比一个给你打满分的工具诚实得多。

交互不会编造拓扑。 成品里的搜索、聚焦、上下游追踪、路径探查，全都只复用你写进去的节点和关系。它甚至专门声明：图上能走到，不等于运行时真的影响得到。可达性是可达性，影响是影响，两码事。

一个我自己踩到的坑

还有件事得说，这是我实测发现的，说明书里埋得很深。

IR 里有个字段叫 meta.quality_profile，决定用哪档标准检查。我把它删掉，再跑校验——它照样报"通过"，一个错没有。

但它用的档位从 showcase 悄悄降到了 standard。

我做了个对照：同一张坏图（就是那条穿越三个组件的线），

• standard 档：抓出 4 条问题
• showcase 档：抓出 6 条问题

两档都拦住了，都没放行。 所以降档的代价不是"放行坏图"，是"少看两眼"——那多出来的两条，一条是 14px 的局促拐角，一条是 0px 的标签净空。都是不影响大局、但难看的毛病。

这个区别我得说清楚，不能吓唬人。但教训是真的：字段写错或者漏写，工具不会大声提醒你，它只是安静地降低标准。 你得自己盯着那行档位。

七、说点数字，然后我要泼盆冷水

我自己去 GitHub API 查的，2026 年 8 月 28 日当天：

• 25,455 star，1,636 fork，53 个未关闭 issue
• 项目创建于 2026 年 4 月 15 日，满打满算四个半月
• JavaScript，MIT 协议

网上有篇介绍说它 700 多 star，那是老黄历；另一篇说 23,547，那是上周的数。日均涨一百多，对这么个新项目来说算是相当猛。

然后我要泼冷水了。

两万五千个人点赞，跟这张图对不对，一点关系都没有。

这是我在这行待久了最想说的一句话。Star 数是 popularity，不是 correctness。我不会因为两万五千人点了赞就相信一个工具——我只相信我自己跑出来的那六行诊断、那个退出码 1、和那个空空如也的目录。

那些数字唯一能告诉你的，是"值得花半小时自己试一下"。仅此而已。

八、回到更大的那件事

聊了半天画图，其实我想说的是一件更普遍的事。

过去两年，大家遇到 AI 干不好一件事，第一反应都是调 prompt：再强调一遍，再给个示例，再让它"仔细检查"。

但有些事不是态度问题，是结构性问题。模型没有视觉皮层，你把 prompt 写得多漂亮，它还是看不见。

这时候正确的做法不是让它更小心，是改变分工——把活拆成两半，它擅长的那半留给它，它不擅长的那半交给确定性的程序。

这个思路一点都不新鲜。编译器就是这么想的，数据库就是这么想的，类型系统就是这么想的。我们早就不指望程序员不写 bug 了，我们造工具去拦。

画图这个领域，只是晚了很多年才有自己的"编译器"。

archify 未必是最后的赢家。它有 53 个未关闭 issue，路线图上下一个大版本还在稳定 IR 格式，说明地基也没完全定。它画的图好不好看，这件事最终还得你的眼睛说了算，机器量不出来。

但方向我认为是对的：别再让模型证明它小心，让它只负责它真正懂的那部分。

九、最后

一张图好不好看，眼睛说了算。
一张图对不对，得有人拿尺子量过才算。

这两件事，以前我们只做了第一件。

就这么回事。

附：本文所有实测数据均在本机跑出（Node v22.22.2，archify v2.16.0-dev.0）。如果你想自己复现那个"画坏"的实验，改一下 JSON 里 components 的坐标和 connections 数组就行，几分钟的事。看别人跑一百遍，不如自己跑一遍。