企业官网建设流程全解析

1. 从"画图工具"到"AI架构师"：next-draw.io想解决的到底是什么

我最初看到"next-draw.io"这个项目名，第一反应是：这不就是给draw.io加上AI能力吗？但深入琢磨之后发现，这事没那么简单。它表面上是一个画架构图的工具，实际上瞄准的是"架构设计"这个动作本身——尤其是从"产品需求"或"系统描述"直接生成"可落地的架构图"这条链路。

大家在日常工作中画架构图，最常见的痛点根本不是"不会用绘图软件"，而是"不知道画什么"和"画出来怕不对"。需要画微服务架构图、系统架构图、业务流程图的时候，脑子里可能只有零散的信息：有几个服务、中间件要接哪种、客户端走什么协议、数据落哪儿。把这些碎片整理成一张结构清晰、层级分明、关系正确的图，往往要来回改好几版。更别提在大型方案评审或者项目启动会上，一张高质量的架构图直接决定了甲方和你之间的沟通效率。

这个项目的价值就在这：把"AI理解业务描述→产出结构化架构设计→自动生成绘图语言→渲染成图→持续迭代修改"这条链路打通。换句话说，它想当的不是"画图的笔"，而是"帮你把架构设计出来的人"。

我根据标题、配套关键词和当前AI技术栈，梳理了这套工作流最适合的用户群体：

• 后端/服务端开发，要做微服务改造或新系统技术方案，需要快速产出架构图用于评审；
• 架构师/技术负责人，需要维护多套系统的架构文档，希望从描述性文档一键出图；
• 运维/DevOps工程师，梳理部署架构、中间件拓扑、可观测性体系时，需要准确的组件关系图；
• 产品经理/技术文档写作者，需要把业务逻辑或系统方案转成通俗直观的架构图，用于对外汇报。

下面我就从方案选型、核心实现、提示词工程、多AI协作、成果复用这几个维度，完整拆解这套"AI架构图设计工作流"该怎么搭建、每一步为什么那么选、实际跑的时候有哪些坑。之所以这个标题在网络上有这么多关联词（架构图软件、AI agent、多AI协作、AI编程提示词），本质上是大家在探索同一件事：AI生成架构图，到底能不能脱离玩具阶段，真正进入生产环境。

2. 方案选型：为什么不是"一句话出图"这么简单

2.1 核心技术链路拆解：从自然语言到拓扑结构

我在构思这套工作流的具体实现时，先画了一条主线：自然语言描述 → 结构化数据（JSON/知识点清单） → 绘图语言代码（Mermaid/Graphviz） → 渲染出图。这四步其实每一步都有独立的技术选型空间。

第一步，理解意图。这里通常用大模型来做，可选的有通义千问、DeepSeek、GPT等。判断标准就一个：中文理解能力和指令跟随能力是否够强。实测下来，DeepSeek在复杂约束条件处理上表现不错，通义千问的中文语义理解占优，而它们在处理"逐字遵循绘图规范"时都需要靠提示词来兜底——这也是后面我要重点展开的一环。

第二步，输出结构化数据。这一步容易被忽视。很多人直接让AI写Mermaid代码，结果生成出来的图能跑，但布局不合理、关系错乱，因为模型把"设计架构"和"写Mermaid语法"两件事混在一起做了。我建议让AI先输出一个中间产物，比如JSON，里面包含节点列表、节点属性、边列表、分组信息。这样做的优势在于：JSON是严格的数据结构，便于校验，也便于后续做布局优化；同时可以先人肉检查一遍"这些节点和关系对不对"，然后再决定要不要继续往下走。

第三步，生成绘图代码。有了结构化JSON之后，再让AI把它转成具体的绘图语言。这里我推荐用Mermaid，理由后面细说。这个阶段也不是简单地"翻译"，还需要处理布局、分组、层次、方向等视觉维度。

第四步，渲染与迭代。渲染端我建议用Mermaid Live Editor本地跑，或者mermaid-cli直接生成SVG/PNG。迭代环节是整个工作流里最容易被低估的，因为AI生成的第一版几乎一定不符合预期，需要围绕"改布局""改关系""补节点"做多轮对话，这也决定了你提示词设计上要留好迭代的口子。

2.2 绘图语言怎么选：Mermaid、Graphviz还是PlantUML

这三个是架构图领域最常见的三套"代码化绘图"方案，不少朋友一直在纠结到底选哪套。我是这么看的：

我在这套AI工作流里优先选择Mermaid，倒不是因为它功能最强，而是因为：AI生成Mermaid的成功率更高。原因在于Mermaid语法规则相对收敛，上下文长度敏感度比Graphviz好，Transformer类模型更容易"顺着语法走完"。而且Mermaid的可视化效果好、风格偏清新，适合直接放方案PPT里面，不用再做美化。Graphviz我保留给那些节点数量超过30个、层级深、自动布局难度大的场景。

2.3 为什么要让AI"分步走"而不是"一键生成"

现在市面上的AI画图工具很多都能"一眼生成架构图"，我为什么还要强烈建议分步走？答案是：可分步校验、可控修改、可追溯。

架构图本质上是一种"观点的可视化"。同一个系统，在不同人眼里有不同的架构边界；同一个需求，在不同阶段关注的粒度也不一样。如果AI一步出图，你只能接受或推翻，中间没有校准的机会。但如果分步走，第一步出了"节点和关系"，你可以先看逻辑是否正确；第二步出了"布局和细节"，你可以只改视觉层面的问题；第三步出了问题，还能精准定位是哪个环节导致的。项目里实际跑下来，让AI分步骤出图的成功率和返工率，远优于一步到位。

这个方案还带来一个额外好处：中间产物是可以复用的。JSON数据结构可以二次输入给其他AI系统（比如做多AI协作时传给另一个模型做审查），Mermaid代码可以直接放进文档系统，甚至你可以在JSON阶段用脚本自动检查--比如检查是否有孤立节点、是否缺少必要的连接线。这类自动化校验做多了以后，AI就不容出那些"看起来合理实则矛盾"的架构关系。

3. 环境准备与工具选型：一套完整可复现的AI架构图工作台

3.1 大模型选型评测：中文语义理解与指令跟随怎么平衡

在我实际搭建这套环境之前，先花了不少时间在模型选型上。强迫自己做一个横向评测表格出来，因为"指令跟随能力"是AI架构生成质量的生死线。选型指标的优先级是这样的：

1. 中文能力：是否理解"XX能力对齐ISO"这类口语化和行业黑话；
2. 遵循输出格式：能否严格按照"只输出JSON""不要解释"这类命令执行；
3. 上下文长度：能否容纳一个完整的中型系统描述（多模块+多个接口）；
4. Token成本：如果是高频使用场景，成本选择非常关键。

在这个标准下，我最终锁定了三个备选：

• 通义千问Max版本：中文理解强，擅长把口语化需求转换成正式结构描述，适合需求分析的初始阶段；
• DeepSeek V3：在结构化输出和逻辑推理方面表现优秀，单参数推理成本低，适合批量生成节点关系；
• Claude或GPT-4级别（能力可达前提下）：英文文档、复杂边界校验更强，适合做架构语义安全性审查。

就这套AI架构图工作流而言，我的实际建议是"双模型协作"：一个是"设计模型"，负责把描述转成JSON，另一个是"绘图模型"，负责把JSON转成Mermaid。这样做的好处在于两个阶段对模型的能力偏好不同，而且一旦某一个阶段频繁出错，你可以只替换那个环节的模型，不用把整条链路推翻。

3.2 渲染与迭代环境：本地还是在线

渲染环境我同时备了两套。开发调试阶段用本地的@mermaid-js/mermaid-cli，优点是可以命令行批量渲染，还能把SVG、PNG输出整合进CI/CD流程，适合把"架构图生成"做成团队基础设施的一部分。演示和快速预览阶段，直接用Mermaid Live Editor，改完代码立即看效果。

本地环境搭建很简单，Node.js环境下执行安装，然后写一个批量渲染脚本，读取所有*.mmd文件并输出对应图片即可。你可以把脚本挂到Git钩子上，实现文档提交后自动重新渲染架构图。

• 版本注意：Mermaid语法在v10和v11有些细节变化，建议固定一个版本，避免团队协作时因为渲染差异对不上。
• 中文字体处理：本地渲染如果遇到中文乱码或缺失字体，需要显式指定--fontFamily参数。
• 自动渲染时机：只要架构图对应的JSON或Mermaid文件发生变化，脚本就要重新执行，否则文档里的图和描述容易脱节。

3.3 提示词工程：AI绘画出的核心关键

真正决定AI架构图质量上限的，不是模型，而是提示词。这一步我建议重点打磨，因为同样的模型，提示词水平不同，产出质量能差出"一眼假"和"直接能上场"的距离。

我总结了一套"AI架构图提示词模板"，核心思路是让模型明确自己的角色、任务输入、输出格式和约束条件，四件套缺一不可。后面会给出可直接复制的完整模板。需要提醒的是：AI生成架构图纠错的成本很高，与其让它自由发挥再返工，不如在提示词里提前把"雷"排干净。后续我会把踩过的坑列成检查清单，方便大家照着抄作业。

4. 实操过程：从文字描述到可发布架构图的完整工作流

4.1 角色设定与任务描述的写法

很多人写提示词的时候只写"帮我生成架构图"，这个我试过，效果不稳定。真正重要的是给AI一个明确的角色定义，并告诉它任务的上下文。

实际项目里我用的角色设定模式是：

你是一位经验丰富的系统架构师，熟悉微服务设计、分布式系统、云原生架构。你擅长将非结构化的业务描述转化为清晰、准确的系统架构模型。请注意，你的输出必须严格遵循给定的数据格式，而且只输出数据，不要输出任何解释性内容。

角色设定的背后逻辑是：大模型在推理时会根据不同角色调整知识结构的激活权重。当你把它设定为"资深架构师"时，它对微服务、消息队列、缓存、负载均衡这些架构组件的语义理解会明显更到位。这一点我在测试多轮后可以确认，重要性排在整个提示词的第一档。

任务描述要精确到"清单式"，包含三个要素：输入是什么、输出是什么、输出格式是什么。最好是明确写出"不要输出与数据无关的文字，包括示例、注释、总结"。这样能最大限度避免模型"跑题"。

4.2 第一轮生成：业务描述转结构化JSON

真正的第一步，是把一段非结构化的、口语化的系统描述转换成结构化JSON。我在提示词里定义的目标JSON结构是：

{ "system_name": "系统名称", "nodes": [ { "id": "节点唯一标识", "name": "节点显示名称", "type": "类型（如 service/database/mq/cache/gateway）", "description": "简要功能描述", "group": "所属分组" } ], "edges": [ { "from": "源节点id", "to": "目标节点id", "label": "关系描述（如HTTP调用/异步消息/读写数据）" } ], "groups": [ { "id": "分组唯一标识", "name": "分组名称", "description": "分组维度的业务含义" } ] }

这个结构的价值在于：它把架构图里最核心的三个要素（节点、边、分组）拆清楚了。节点标识用英文ID而不是中文名，是为了后续生成Mermaid时避免中文ID带来的兼容性问题。type字段是给后面布局和视觉设计用的，比如服务节点用矩形、数据库用圆柱。edges的label字段不仅能画线，还能在线上标注"RPC调用""异步事件"这样的语义，让图的信息密度高出一个量级。

我第一次跑这个步骤的时候，用的是通义千问。输入一段约500字的系统描述，输出效果相当不错，节点识别准确，关系也能对上。但有一个共性问题：它倾向于把节点数量压得很少，希望用一个大而全的模块去概括很多东西。这和我们想要呈现的"细粒度架构图"有冲突。对策就是在提示词里显式加一句"节点覆盖所有功能模块和依赖组件，不要合并同类项"。

4.3 第二轮生成：JSON转换成Mermaid代码

拿到可靠的JSON之后，第二步就是转Mermaid。这里我设计了一套固定模板，让AI严格按模板输出。模板长这样：

flowchart TB subgraph gateway-layer["接入层"] A[API Gateway] --> B[Auth Service] A --> C[Rate Limiter] end subgraph business-layer["业务层"] D[Order Service] --> E[Order DB] D --> F[Payment Service] F --> G[Payment DB] end subgraph middleware-layer["中间件层"] H[消息队列] I[缓存集群] J[搜索引擎] end B --> H D --> I F --> J

这套模板的要义是：

• flowchart TB表示从上到下布局，适合层级分明的架构图。如果架构是横向的分层结构（比如接入层在左、数据层在右），可以改为LR；
• subgraph用于分组，对应JSON里的groups。分组的好处是一眼看出"这一块是接入层""这一块是数据层"，对评审和交流极其友好；
• 节点ID和显示名称分开：Mermaid里节点ID[显示文本]，ID用英文，显示文本用中文。这样既不破坏语法，又能展示中文；
• 关系行统一用A --> B，如果要在线上标注关系语义，可以写成A -- "HTTP调用" --> B。

我在实际生成过程中发现，AI转出来的Mermaid代码经常存在两个问题：一是节点ID与显示文本混淆，二是有时候会自动加一些Mermaid不支持的修饰符。所以我在提示词里加了一条"只输出纯Mermaid语法，不要使用任何扩展图形属性，只保留基础节点、分组、连线"，能极大降低渲染失败率。

4.4 第三轮：渲染出图与视觉优化

Mermaid代码生成后，拿到Live Editor里渲染只是第一步。真正"能拿得出手"的架构图，还需要经过多轮视觉优化。我整理了几条高频优化项：

• 方向优化：默认TB是上下布局，但如果你系统里有"客户端→接入→业务→数据"这样的单向链路，TB是最佳选择；如果是展示系统间平等交互，建议改LR左右布局；
• 线标签优化：如果线条太多导致图面拥挤，可以先用无标签线，等确认核心关系后再逐步补标签；
• 分组内节点数量均衡：不要让某个subgraph里挤了10个节点而另一个只有1个，这样视觉上严重失衡，建议在生成JSON时就要求按职责把节点均分到组里；
• 使用click指令、classDef样式做高级美化：这属于进阶玩法，但MVP阶段可以不用。

一个非常实用的提醒：AI生成的图可以做"局部放大"思路优化。比如核心链路（下单→支付→履约）单独作为一个子图铺开大节点，非核心依赖（监控、告警、日志）收敛为一个小型节点组。这种"视觉引导"本质上就是架构师自己在画图时的构图习惯，把这个要求写进提示词里，出图质量会明显提升。

4.5 直接抄作业：面向生产环境的完整提示词模板

前面讲了很多原则，下面给一个我实际用了很久、效果稳定的完整提示词模板。可以直接复制到你的AI工作台里，替换方括号内容即可。

角色：你是资深系统架构师，精通分布式系统、微服务、云原生架构设计。你擅长把非结构的业务描述转化为准确完整的系统架构图。 任务： 1. 接收用户在【系统描述】里提供的关于某系统架构的说明。 2. 分析该系统涉及的所有组件，包括但不限于：客户端、网关、业务服务、数据库、消息队列、缓存、搜索引擎、第三方依赖、监控系统等。 3. 输出一个严格格式化的JSON结构，包含节点列表、关系列表、分组列表。 4. 节点覆盖所有功能模块，不要合并同类项。 5. 关系必须覆盖所有必要依赖，并在label标注关系类型。 6. 分组合理，建议按接入层、业务层、数据层、中间件层、基础设施层划分。 输出要求： - 只输出JSON，不要任何解释、Markdown代码块标记、注释。 - JSON结构必须符合给定示例，不要增加或删减字段。 - 如果描述的信息不足，请默认补全合理的架构组件，并保持通用性。 【系统描述】 {在这里粘贴你的系统描述} 【输出示例】 {在这里粘贴JSON示例结构}

这套提示词的妙处在于：先是明确角色，再是任务拆分，最后是输出约束。模型几乎不可能跑偏。我还在这个基础上加了一个"后置校验"步骤：每个JSON输出之后，不要直接进渲染，先用脚本或者人工扫一眼，检查：节点是否有空ID；边是否引用了不存在的节点；分组是否包含未被分组的节点。这三条是最常见的低级错误。

5. 实战项目：用这套AI架构图工作流搭建微服务电商系统

5.1 需求场景描述

我拿一个微服务电商系统来完整走一遍流程，这样讲起来比较直观。假设项目经理给的原始描述是这样的：

"这个平台要支持用户在小程序端和PC端下单，订单模块负责创建订单、取消订单、查询订单，支付模块接微信支付和支付宝，商品模块维护SKU和库存，用户模块管理登录注册和收货地址。后端服务之间通过HTTP和消息队列通信，数据库用MySQL，缓存用Redis，搜索走Elasticsearch，整个系统要部署在K8s集群里。"

把这段描述丢给AI（我用的是DeepSeek），配合上面的提示词，输出来的JSON我已经整理简化了，大概长这个样子：

{ "system_name": "微服务电商平台", "nodes": [ { "id": "client-mp", "name": "小程序端", "type": "client", "group": "接入层" }, { "id": "client-pc", "name": "PC端", "type": "client", "group": "接入层" }, { "id": "gw", "name": "API网关", "type": "gateway", "group": "接入层" }, { "id": "auth", "name": "鉴权服务", "type": "service", "group": "接入层" }, { "id": "order", "name": "订单服务", "type": "service", "group": "业务层" }, { "id": "payment", "name": "支付服务", "type": "service", "group": "业务层" }, { "id": "goods", "name": "商品服务", "type": "service", "group": "业务层" }, { "id": "user", "name": "用户服务", "type": "service", "group": "业务层" }, { "id": "order-db", "name": "订单库", "type": "database", "group": "数据层" }, { "id": "payment-db", "name": "支付库", "type": "database", "group": "数据层" }, { "id": "goods-db", "name": "商品库", "type": "database", "group": "数据层" }, { "id": "user-db", "name": "用户库", "type": "database", "group": "数据层" }, { "id": "redis", "name": "缓存集群", "type": "cache", "group": "中间件层" }, { "id": "mq", "name": "消息队列", "type": "mq", "group": "中间件层" }, { "id": "es", "name": "Elasticsearch", "type": "search", "group": "中间件层" }, { "id": "k8s", "name": "Kubernetes集群", "type": "infra", "group": "基础设施层" } ], "edges": [ { "from": "client-mp", "to": "gw", "label": "HTTPS" }, { "from": "client-pc", "to": "gw", "label": "HTTPS" }, { "from": "gw", "to": "auth", "label": "鉴权调用" }, { "from": "gw", "to": "order", "label": "HTTP分发" }, { "from": "gw", "to": "payment", "label": "HTTP分发" }, { "from": "gw", "to": "goods", "label": "HTTP分发" }, { "from": "gw", "to": "user", "label": "HTTP分发" }, { "from": "order", "to": "order-db", "label": "读写MySQL" }, { "from": "payment", "to": "payment-db", "label": "读写MySQL" }, { "from": "goods", "to": "goods-db", "label": "读写MySQL" }, { "from": "user", "to": "user-db", "label": "读写MySQL" }, { "from": "order", "to": "mq", "label": "异步消息" }, { "from": "payment", "to": "mq", "label": "异步消息" }, { "from": "order", "to": "redis", "label": "库存预热/会话缓存" }, { "from": "goods", "to": "es", "label": "商品索引同步" } ], "groups": [ { "id": "access", "name": "接入层" }, { "id": "biz", "name": "业务层" }, { "id": "data", "name": "数据层" }, { "id": "middleware", "name": "中间件层" }, { "id": "infra", "name": "基础设施层" } ] }

5.2 从JSON到Mermaid：完整转换过程与细节打磨

拿到JSON之后，我直接扔给AI让它转Mermaid。在提示词里同样要强调"只输出Mermaid代码"。

这一版本跑下来的效果，骨干关系已经正确，但有一个不大不小的视觉问题：所有节点都不在分组里，属于扁平排列。这种情况在团队评审时很吃亏，因为无法一眼看出层与层之间的边界。于是我要求AI把JSON里的group字段对应成Mermaid的subgraph，同时把基础设施层的节点（比如k8s）也做成一个分组放到最外层。

最终生成的Mermaid代码可以参考下面这个优化版本：

flowchart TB subgraph access["接入层"] client-mp["小程序端"] --> gw["API网关"] client-pc["PC端"] --> gw gw --> auth["鉴权服务"] end subgraph biz["业务层"] order["订单服务"] --> order-db[("订单库")] payment["支付服务"] --> payment-db[("支付库")] goods["商品服务"] --> goods-db[("商品库")] user["用户服务"] --> user-db[("用户库")] gw --> order gw --> payment gw --> goods gw --> user end subgraph middleware["中间件层"] mq["消息队列"] redis["缓存集群"] es["Elasticsearch"] end subgraph infra["基础设施层"] k8s["Kubernetes集群"] end order -- "异步消息" --> mq payment -- "异步消息" --> mq order -- "库存预热/会话缓存" --> redis goods -- "商品索引同步" --> es

5.3 渲染后的调整话术：用什么指令让AI改布局

渲染出的第一版，通常能看，但总有细节想调。这里我整理了高频调整指令，直接照着用：

• "把客户端节点移到最上面，数据层放在最下面"，对应提示词就是：加一行"客户端节点作为source，数据节点作为sink"；
• "XX服务和XX服务之间有两条连线，请合并成一条并标注两种关系"，防止线太多；
• "网关和业务服务之间不要直接连接，改成网关分发给各服务"，这影响的是分层语义描述；
• "把XX节点放到XX分组的下一层"，用于调整subgraph内层级嵌套。

我这套实操下来，最关键的一句话是："如果调整后依然不符合上述约束，请重新检查你的输出是否遵守JSON示例，不要自行发挥。"它能大幅减少AI在迭代中偷偷加戏的问题。

6. 多AI协作与Agent化：从单一生成到架构图设计自动化

6.1 用什么方式让多个AI角色协同处理架构图

如果只是自己单机用，单一模型方案完全够。项目如果要往"团队级工程化"走，多AI协作是绕不开的方向。核心逻辑是拆分成三个角色：

1. 需求分析师（用通义千问）：负责把业务描述拆成准确的需求条目，输出给下游；
2. 架构设计师（用DeepSeek）：接收需求条目，产出JSON结构化架构设计；
3. 绘图工程师（用Claude级或GPT-4级模型）：接收JSON，产出Mermaid代码，同时做语法校验；
4. 质检员（独立模型实例或规则脚本）：检查节点完整性、检查边引用合法性、检查分组归属。

多AI协作在工程上的落地抓手是"结构化中间产物"——每一层模型只对上一层的输出负责，不跨层通信。这个设计能避免模型间互相污染上下文，也便于单独优化某个角色的能力。

6.2 用AI Agent工作流把"生成架构图"变成团队基础设施

顺着多AI协作的思路，再往前走一步，就是AI Agent工作流。架构图的生成不应该只发生在个人笔记本上，它应该成为团队文档系统的一部分。我的想法是做一个Agent，它具备下面这些能力：

• 监听文档仓库的变更事件，比如某个architecture.md文件更新了；
• 自动提取"系统描述"区块，触发AI生成JSON与Mermaid代码；
• 生成后自动渲染，把SVG、PNG回写到指定目录；
• 更新文档里的图表引用链接，并推送变更记录到协作群。

这个思路的副产品是"架构图版本管理"，每一版架构变化都有迹可循。实践下来，它还能自然形成一个"架构知识库"：每次迭代后的架构图配上当时的业务背景描述，后续再做同类系统设计时，可以直接拿历史数据做参考，让AI的起点一次次提高。

7. 常见问题与排查技巧实录

这套工作流跑得再顺，也难免遇到问题。下面列几个我实际踩过、也帮同事排查过的典型坑，附上对应解法。

7.1 生成的节点之间没有连线，拓扑是离散的

表现：Mermaid代码能渲染，但图里是一堆孤立的节点，只有子图结构没有连线关系。

排查思路：先回到JSON，检查edges数组，看是否为空或引用了不存在的节点id。大概率是描述阶段给出的关系信息太模糊。比如"订单模块和商品模块有关联"，AI难以判断关联类型，保险起见干脆不生成。对策有两条：一是在描述阶段就给足方向性信息，比如"订单服务调用商品服务查询SKU信息"；二是在提示词里增加一条"如果节点之间存在微弱的业务关联，请补全合理的默认关系并标注为依赖"。这一条能显著减少孤立节点。

7.2 Mermaid语法渲染报错，错误信息指向"unexpected token"

出现此类报错，八成的锅都在AI输出时带了额外字符。最常见的是输出里包含Markdown代码块标记```mermaid、行尾多余的逗号，或者节点ID用了中文。在提示词里强调"只输出Mermaid语法，不要Markdown包裹，不要额外说明文字"，能解决大部分问题。如果还是报错，检查一下引号：中文字符和英文引号混用也会触发解析错误。

7.3 AI生成的架构图"看起来对，但架构设计本身是错的"

这种问题最隐蔽，因为语法上完全没毛病。比如支付服务放在业务层，但订单服务又直接连接了支付数据库，这在实际系统里往往是要避免的——支付数据不应该被订单服务直接访问。这就要求"质检员"角色不能省。建议在提示词里要求模型输出时自检，也可以编写一个简单的规则脚本，去检查"数据库节点是否被多个服务直接引用"这类典型问题。

7.4 大图渲染后布局混乱，节点挤在一起

节点超过40个，或者分组结构复杂的时候，Mermaid默认布局会让人觉得杂乱。解法有很多，我自己最常用的是进一步拆分：把一张大图拆成"总览图（只画出层间关系）+ 分层详图（各层内部展开）"，并在文档中交叉引用，既保证清晰度，又能保持完整信息。另外可以在提示词里要求AI"优先确保层次结构清晰，减少不必要的跨层连线"。

7.5 提示词这么好用，还需要人工介入吗

说句实话，这套工作流再完善，也替代不了"架构评审"。AI帮你快速产出的是"候选架构图"，但方案的合理性、边界情况、成本权衡这些，最终还是得有经验的人来拍板。这也是我为什么要强调"分步产物"——每一步都方便人审，而不是到最后生成一张大图来赌运气。

8. 架构图成果的深度复用：AI不只帮你画，还帮你维护

8.1 从单一图片到结构化知识资产

当架构图以"JSON+Mermaid+图"三份产物形式沉淀之后，它的价值就远超一张截图了。JSON是机器可读的，可以接入系统做自动分析；Mermaid是文本可控的，可以直接放进Git做版本管理；图是给人看的，用于评审与文档展示。

我建议每个项目组建立这样一个目录结构：

• docs/architecture/
  • digital-platform.md系统描述文档
  • digital-platform.json结构化架构数据
  • digital-platform.mmdMermaid源码
  • digital-platform.png渲染输出图

这个目录本身就是一个轻量级架构资产库，配合CI/CD，任何一次架构变更都有理有据、有迹可循。

8.2 用架构图反哺其他AI场景：测试用例、产品文档、专利辅助链接

这套工作流的"后链路"潜力也很大。我可以举几个亲身试过的例子：

• 测试方向：把JSON喂给AI，自动生成微服务的集成测试点，比如需要mock哪些外部依赖、哪些服务间需要做契约测试，输出效率比人肉读文档翻代码快很多；
• 产品文档方向：把JSON用于生成面向新人的"系统模块说明"，图文对应，降低理解门槛；
• 专利辅助链接方向：架构图作为技术方案可视化素材，结合AI辅助生成技术效果描述，能帮研发把"系统创新点"讲得更清楚（注意只是辅助整理材料，最终提交仍需专业人士审核）；
• AI Agent化：让Agent在架构图发生变化时自动触发"影响面分析"，比如某个服务拆分，自动列出所有涉及调用链的服务，这个能力在大型系统演进中非常值钱。

8.3 后续扩展空间：从架构图到全链路系统设计

这套工作流未来可以很自然地延展到：从架构图扩展出时序图、部署图、C4模型图，甚至可以联动生成基于OpenAPI的接口文档框架。我自己的计划是把它变成一个"系统设计Copilot"：输入一个想法，产出架构图、接口清单、部署拓扑、测试要点。每个环节都独立生成、独立校验，最终合成为一份完整的技术方案手册。

9. 三十条经验总结：你在别处很难一次性看到的实操建议

把AI架构图方案推进到能稳定产出的状态，需要把很多小细节串起来。分享几条我个人最有体感的经验，按重要性排序：

1. 永远分步走，不要一步到位。把自然语言、JSON、Mermaid三个层次彻底分开，每层都能独立校验；
2. 创建"节点覆盖清单"提示词，减少AI习惯性合并节点的问题；
3. 中英文ID分开管理：ID用英文，显示文本用中文，这两个概念不能混；
4. 使用"只输出XXX"这类强约束指令，拒绝任何解释性内容；
5. 首次出图后先看构图再改关系，不要一上来就调细节；
6. 对用户描述中缺失但有必要的组件（如K8s、网关、监控）要求AI"默认补全并标注默认"；
7. 多模型配合时，模型切换点放在JSON之后，而不是自然语言之后；
8. 排查错误时，永远先问"哪一层出了问题"：是描述层、模型层，还是渲染层；
9. 写文档时优先用文本型架构图（Mermaid），这样每次改动都有diff可看，评审效率高得多；
10. 本地渲染要固定Mermaid版本，避免把时间浪费在莫名其妙的兼容问题上。

记得我在第三轮迭代时，最崩溃的一次是把AI生成的Mermaid代码粘到Live Editor，渲染全红，排错排了20分钟。后来发现只是输出里多了一个反引号。从那以后我总结出一个铁律："AI输出必须过校验脚本，不能直接信任。"后来我在提示词模板里加了一条："如果输出中包含Markdown代码块标记，视为非法。"这类小修补积累多了，工作流的稳定性才会越来越接近生产级。

另外，必须强调一个安全底线：AI生成架构图可以用来提升效率，但在任何严肃的对外环境中，都不能让未经人工审核的AI产物直接作为正式材料。架构设计涉及系统部署、数据流转、安全边界等关键内容，人审这一步永远不能省。这也是从业者最基本的职业素养。

如果后面再把Agent化做深一点，还可以在每次方案生成后自动推一个"架构风险提示"——比如"订单库被超过三个服务直连，请确认是否引入数据服务层""支付服务和用户服务之间存在跨层调用，请判断合理性"。到那个阶段，AI架构图工具就不只是画图工具了，它会变成一个真正懂得架构设计的助手。

最后说一句我自己的体会：画架构图从来都不是目的，理解系统的关键链路和数据流才是。AI帮我们省掉的是从"语言"到"视图"的翻译成本，但"什么叫好的架构"这个判断，永远需要人来掌舵。