用开源 AI 工具为任何项目绘制漂亮的架构图

凡是用拖拽工具画过系统架构图的人都懂那种感觉：挪一根箭头，整个版面崩掉；改一个服务名，得搬动三十个图形块；而"最标准"的那张图，永远躺在已经离职同事的电脑里。技术社区正在广泛分享一种新趋势：把 AI 与开源的图表即代码（Diagram-as-Code）工具结合，为任何项目生成美观、规范、可持续更新的架构图。

架构图到底值多少钱？

架构图是团队的通用语言：工程师一眼看出哪个服务在和哪个服务通信，管理者一眼明白系统为什么慢，客户一眼看到投资规模。一个缺少最新架构图的项目会付出这样的代价：

• 新员工要花几周才能理解系统，而不是两天
• 技术讨论退回到"凭感觉猜"，因为没有共同的地图
• 没人敢做改动，因为不知道自己改的部分会影响哪里

架构图最大的难题不是画出来，而是让它与系统同步更新。

Diagram-as-Code：用……文字画图

拖拽工具画图很快，但难以维护。图表即代码（Diagram-as-Code）的思路把流程倒了过来：你用结构化文本描述系统——"服务 A 通过 HTTP 调用 B，数据存在 PostgreSQL"——工具自动渲染出版式精美的图。这一类的常用开源工具有 Mermaid、PlantUML、D2 和 Diagrams。

这种方式带来的结构性收益：

• 架构图与源码同住在 Git 里： 每次架构变更都附带修改图表的提交，与代码一起评审
• 天然版本化： 想看一年前系统的架构图，不过是查看一个旧提交
• 绝对一致： 给服务改名只需一条查找替换命令，所有箭头自动更新
• 自动布局： 再没人需要为图形块之间的间距费神

AI 扮演什么角色？

让这股潮流爆发的关键，是 AI 补上了剩余两块拼图：

1. 从想法到图表

你用自然语言描述——"系统包含 Web 应用、API 网关、3 个微服务、Redis 缓存、PostgreSQL 和任务队列"——AI 立刻生成对应的图表代码。你要做的只是微调。拥有一张漂亮架构图的技能门槛，从"精通画图工具"降到了"能把自己的系统描述清楚"。

2. 从源码到图表

更进一步的方向：让 AI 阅读代码库，分析模块、服务、数据库之间真实存在的依赖关系，然后生成反映真实系统的架构图——而不是某个人记忆中的那个版本。对于缺乏文档的老项目，这是重建地图最快的办法。

四步流程，产出一张合格的架构图

1. 明确用途： 给客户会议看的图和给技术团队看的图不是一张。一张图只应回答一组问题。
2. 列出真实组件： 使用系统中真实的服务名、数据库名——一张名字"错得离谱还挺好笑"的图就是一张失败的图。
3. 生成再修改： 让 AI 生成初稿，然后修改代码，按领域增删、归组组件。
4. 随项目保存： 把图表文件提交进代码仓库，并规定架构变更与图表更新放在同一个拉取请求（Pull Request）里。

为什么选择开源工具？

• 不被供应商锁定：图表文件是开放文本，永远可读，不依赖任何一家公司的软件授权
• 没有按席位收费——看的人越多，相比商业工具省得越多
• 与流水线天然集成：在 CI 中生成图表，自动嵌入内部文档
• 庞大的社区意味着丰富的模板库：AWS 架构图标、Kubernetes、处理流程、关系型数据库模型，都有现成的标准图形

给越南技术团队的启示

在国内许多企业和项目团队里，架构图仍然是拖拽工具随手画出来的，零散存放，几个月后就过时了。转向图表即代码并结合 AI，是一次成本几乎为零、收益却是双份的改进：当下得到更漂亮的文档，未来收获完整的架构历史。对于需要与外国客户沟通架构的外包团队，文本形式的架构图还便于通过拉取请求（Pull Request）评审——正是大型合作方当下的工作方式。

结语

漂亮的架构图不再是画图高手的特权。借助开源的图表即代码工具和能把描述转成图表的 AI，任何项目团队都能维护一套常看常新的架构地图——而且像更新代码一样更新它。花一个下午完成初始搭建，你将在之后的岁月里省下无数个"解释系统"的小时。

资料来源：整理自 Facebook 技术分享，由 Wotech Electronics 编辑。

如果您的团队需要规范化架构文档与技术流程方面的支持，Wotech Electronics 随时愿与您的项目同行。