AI 生成架构图之后，怎样判断它是否可信？

把架构图想成一张城市地图。地图上的道路画得整齐，只能说明制图软件工作正常，不能证明道路真的存在，更不能证明车辆可以顺利通行。

AI 生成架构图也是如此。**AI 画图最容易解决的是好看，最难解决的是图上的关系没有被编出来。**一张图要进入工程沟通，至少要经过四层确认，分别是来源真实、结构不乱、屏幕可读和含义正确。

Archify 做了什么

普通绘图工具通常直接生成一张图片。图片保存了外观，却丢掉了节点、连线和坐标等结构信息。后来发现错误时，往往只能重新画一遍。

Archify 把架构图拆成一份结构化描述，再像编译程序一样处理它。输入包含节点、关系、坐标和视图；工具先做规则检查，最后输出 HTML、SVG 或 PNG。

这样做的好处很直接。架构图不再只是图片，也成为可以比较、检查和重新生成的工程产物。JSON 的修改记录可以回答“这次重构删掉了哪条依赖”，规则引擎可以回答“这张图有没有画坏”。

但它暂时不能回答“这条依赖在真实系统中是否存在”。如果输入的 JSON 本身就是模型猜出来的，校验器只能把这份猜测画得更规范。

真实测试结果

测试对象是一个本地股票分析项目。模块信息只取自项目的 README.md、package.json、src/ 和 data/，共整理出 10 个模块，包括行情源、数据摄取、评分引擎、AI 分析、报告生成、本地存储、持仓跟踪和通知推送等。

第一版架构描述没有通过校验。问题集中在三个地方，两条关系挤进同一条通道，文字压住节点边缘，连线穿过了无关容器。

根据诊断结果调整坐标和标签后，第二次 validate 与 deliver 均通过，9 项结构检查全部通过。它们检查了 SVG、坐标、箭头、标签间距、关系交叉、通道、容器边界、路径和图例间距。

这次测试说明，Archify 很擅长拦截“图面错误”。图线交叉、标签重叠、路径穿界等问题会在交付前暴露出来。

通过校验，仍然不等于可信

本次测试没有完成浏览器视觉检查，因为运行环境缺少可用的图形化或无头 Chrome。因此，移动端字号、画布缩放和真实视口中的交互体验仍然是 pending。

这揭示了一个容易混淆的边界。机器校验证明图纸符合规则；浏览器检查证明读者能够正常阅读；源码核对证明节点和关系有事实来源；工程师判断证明这些关系的含义没有被夸大。

四层证据缺一不可。源码中存在一个引用，不等于运行时一定会触发；一个测试环境中的 mock 链路，也不能直接画成生产环境的强依赖。

什么时候值得使用

只需在 RFC 中说明几个调用步骤时，Mermaid 或基础 Markdown 图表更加轻量。

需要维护几十个服务、比较架构版本，并要求每次修改都经过自动检查时，Archify 的结构化描述、规则校验和差异视图更有价值。

实际使用可以记住四步。先从源码确认事实，再用 Archify 检查结构；随后在真实浏览器中检查可读性，最后由熟悉系统的工程师确认语义。

Archify 能把“画得不对”提前变成失败项，却不能替工程师回答“系统到底是不是这样”。它最重要的价值，不是替人判断架构，而是把一张不可追溯的图片，变成一份可以持续验证的工程产物。

参考资料

Archify 官方仓库：https://github.com/tt-a1i/archify