AI生成系统架构图教程：从需求文本到可编辑架构图

把一段需求交给AI，几秒钟得到一张结构完整的图并不难；困难在于判断这张图是否表达了正确的系统。AI可能补出不存在的服务、忽略故障路径，或把逻辑组件与部署节点混在同一层。因此，AI生成系统架构图的核心不是“画得快”，而是建立一套从输入、生成到评审的闭环。

一、AI生成架构图适合做什么，不适合做什么？

AI适合完成三类工作：把非结构化需求整理为组件清单；把清单转换为第一版图；根据反馈快速生成不同粒度或不同视角的候选方案。它尤其适合需求澄清会、方案讨论前的准备、现有文档可视化以及架构评审后的快速改图。

AI不适合独立决定安全边界、数据主权、容量目标、容灾等级、技术选型和合规结论。这些决策依赖真实业务、组织能力与运行数据。生成结果也不能直接视为现网架构，因为“看起来合理”不等于“能够实施”。

二、生成前先准备一份“架构输入合同”

提示词越长不一定越好，真正重要的是输入是否具备稳定结构。建议把需求整理成“架构输入合同”，至少包含以下八项：

1. 读者：业务负责人、开发、运维、安全或外部客户。
2. 目标：解释现状、评审方案、指导开发，还是说明部署。
3. 范围：图中包含哪些系统，不包含哪些系统。
4. 参与者：用户、角色、外部系统和第三方服务。
5. 核心组件：应用、服务、数据库、队列、网关和基础设施。
6. 关键链路：请求方向、数据流向、异步事件和回调。
7. 质量约束：可用性、性能、安全、成本、合规和恢复目标。
8. 表达要求：期望的视角、粒度、术语、颜色和输出格式。

输入合同的价值在于把“画一张专业架构图”转化为可验证的任务。缺少范围和读者时，AI最容易生成内容很多但无法评审的“大而全”图。

三、可直接复用的AI架构图提示词框架

下面的提示词不是固定答案，而是一份可替换变量的任务说明。先用真实信息填空，再根据生成结果追加约束：

请生成一张【视角：系统上下文/容器/组件/部署】架构图。
读者：【业务负责人/研发/运维/安全】
目标：【解释方案/评审边界/指导实施】
系统范围：【包含内容】；明确排除：【不包含内容】
参与者与外部系统：【列表】
核心组件及职责：【列表】
关键请求与数据流：【方向、协议或事件】
质量约束：【可靠性、安全、性能、成本、合规】
输出要求：所有连接线标注含义；区分系统边界和信任边界；
不确定内容使用“待确认”标记，不要自行补充具体产品或数字。

最后一句“不要自行补充”非常重要。AI面对信息缺口时倾向于补全，而架构评审需要的是暴露缺口。把未知项标成待确认，比生成一个貌似完整的错误组件更有价值。

四、AI生成系统架构图的6步实操流程

步骤1：只生成系统清单，暂时不要画图

先让AI输出参与者、系统、组件、数据对象和约束清单。团队确认清单后再生成图，可以减少图形完成后才发现范围错误的返工。

步骤2：选择一个视角和一个主要读者

面向业务先画系统上下文；面向开发再画容器或组件；面向运维单独画部署视角。不要把不同抽象层级塞进同一张图。

步骤3：生成结构初稿

要求AI按边界分组、标注组件职责，并给连接线增加动词，例如“提交订单”“发布事件”“读取库存”。仅写“调用”通常无法支撑评审。

步骤4：在Boardmix中继续编辑

将初稿放入可编辑画布，统一术语和图例，调整布局，并邀请开发、运维、安全等角色在同一版本上批注。图形编辑的目标不是美化，而是让问题更容易被指出。

步骤5：用关键场景走查连接

依次走查正常请求、登录失败、第三方超时、消息重复、数据库不可用和区域故障。每个场景都应能沿箭头说明“谁调用谁、失败后怎样处理”。

步骤6：记录假设和未决问题

把容量、SLA、数据保留时间、部署区域等未确认事项附在图旁。AI输出不确定项时，不要悄悄删除，而应转化为评审任务。

五、用三层视角避免“一张图讲完所有事情”

C4 Model将软件架构按系统上下文、容器、组件和代码等层级表达，并强调只使用真正有价值的层级。对大多数AI生成任务，三层已经足够：

• 上下文图：回答系统服务谁、依赖谁、边界在哪里。
• 容器/应用图：回答有哪些可独立运行的应用与数据存储，它们如何通信。
• 部署图：回答组件运行在哪里、如何扩缩容、如何隔离与恢复。

独特的做法是让AI对同一份输入分别生成三张图，而不是生成一张巨大总图。三张图共享术语和编号，既保持一致，又让不同读者看到合适的细节。

六、AI架构图必须通过的7项人工校验

1. 范围：系统边界是否明确，有没有把外部系统画成内部组件。
2. 职责：每个组件是否有单一且可理解的职责。
3. 关系：连接线是否有方向、动作、协议或数据含义。
4. 数据：数据所有者、读写关系和敏感数据路径是否清楚。
5. 安全：身份、权限、信任边界和外部入口是否表达。
6. 故障：超时、重试、降级、幂等和恢复路径是否可说明。
7. 权衡：可靠性、性能、成本和复杂度的取舍是否留下依据。

AWS Well-Architected使用运营、安全、可靠性、性能、成本和可持续性等维度持续评审架构。这里最值得借鉴的不是云厂商图标，而是“用问题检查设计”的方法。

七、AI生成架构图的5个常见失败模式

• 图形正确、语义错误：箭头整齐，却没有说明同步、异步、读或写。
• 自动补全不存在的组件：AI为了完整性添加缓存、队列或网关，但需求中没有依据。
• 混合抽象层级：同一张图同时出现业务系统、微服务、类和服务器实例。
• 忽略非功能需求：只表达正常流程，没有容量、安全、监控和故障恢复。
• 一次生成后不再维护：图与代码、部署和接口持续漂移，最终失去可信度。

解决办法不是反复要求“画得更专业”，而是指出哪条校验不通过，并让AI只修改对应部分。

八、怎样让AI架构图成为持续维护的团队资产？

架构图应该和需求、架构决策记录、接口文档及发布变更建立关系。建议为图标注负责人、适用版本、最后核验日期和变更原因；重大版本保留快照，小改动通过评论和历史版本追踪。

在Boardmix中，可以把图、评审问题、决策说明和待办放在同一画布，通过分享和评论让不同角色参与。真正的价值不是“团队一起画”，而是让设计假设、反馈和最终决策在同一上下文中可追溯。

九、AI生成架构图常见问题

AI可以直接生成生产级架构吗？

不建议。AI可以提供候选结构和初稿，但生产级设计需要真实容量、SLA、安全、成本、合规和团队能力数据，并经过相关负责人评审。

需求很少时，怎样避免AI胡乱补全？

要求AI先输出缺失信息和待确认问题，不允许添加未经输入支持的产品、数字和约束；确认后再进入绘图。

AI架构图应该画多细？

细节由读者和决策决定。业务讨论用上下文图，研发讨论用容器或组件图，运维和安全讨论用部署与信任边界图。

生成后第一件事应该检查什么？

先检查范围和边界。如果系统范围错了，后面的组件、连接和布局再精致也没有意义。