企业官网建设流程全解析

干过架构设计这行的都有体会：需求评审会上大家讨论得热火朝天，回头整理架构图的时候，又得对着白板照片一点点重画。改一处模块划分，连带影响所有关联关系，一张图能磨一个下午。后来我干脆试着把大语言模型当成一个“系统分析师”来用，直接跟它描述业务需求，让它先拆解系统边界、识别核心模块和依赖关系，再输出结构化的图表代码，一键渲染成专业架构图。这条路子实测下来，把画图的时间从小时级压缩到了分钟级，而且图的质量比手工整理还要规范。

这篇文章就围绕这个实践展开，适合想把 AI 引入系统设计流程的开发者、架构师，也适合正在学习系统设计的同学参考。我会把完整的提示词设计、技术选型、工具链搭建、常见坑位一次说清楚。

1. 为什么要把 AI 变成“系统分析师”：从口头需求到架构图的链路拆解

1.1 传统画图方式的最大瓶颈不是“画”，而是“想”

先说我观察到的现象。很多团队画架构图，真正的耗时大头根本不是鼠标拖拽那几下，而是脑子里得先把关系理顺：系统跟外部系统之间有哪些交互？核心业务模块应该拆成哪几个？数据流是同步还是异步？权限校验该放在网关层还是业务层？

这些问题想不清楚，画出来的图就是一张“线一团乱、框一大片”的废图。而要理清这些问题，又得去翻需求文档、看接口定义、找业务方确认边界。等这一套信息收集完，时间已经过去大半。

更讨厌的是需求变更。业务方今天说“加一个消息通知模块”，后天说“用户系统要支持多租户”，每动一次，整个图的模块划分、依赖关系就要联动调整。手动改图的时候，最容易漏掉的就是“改了 A 模块却忘了连带 B 模块的依赖箭头”。这种错漏在评审会上被指出来，相当尴尬。

所以我把目标定得很明确：不是去找一个“自动画图工具”，而是找一个“能帮我把架构想清楚”的助手。大语言模型恰好擅长做这件事——它能在上下文里同时处理角色、系统、交互、约束这些信息，并输出结构化的分析结果。关键是它的输出可以直接映射成图表描述语言。

1.2 核心路径：自然语言 → 结构化架构模型 → 渲染成图

整个做法的核心链路并不复杂：

自然语言需求 → AI 做架构分析 → 输出结构化图表描述代码 → 渲染器生图

这里面最关键的一步是第二步到第三步的转换。我在这里做的设计决策是：不要让 AI 直接给“一张画好的图”，而是让 AI 先给出“架构分析结论”，再按照我的格式要求输出图表描述代码。

这样做的好处很明显：

第一，架构分析是可审查的。AI 说“系统分为 Web 端、API 网关、用户服务、笔记服务、搜索服务”，我能逐条判断这个拆分合不合理，而不是拿到一张密不透风的图脑补。

第二，分析结论和图表互为印证。文档里如果写着“用户服务负责登录鉴权”，那架构图里就该有对应的模块和依赖关系。AI 输出的文字分析可以作为图的补充说明，图又反向验证分析有没有遗漏。

第三，后续迭代维护非常轻量。需求变了，我只需要在对话里追加一句“把消息通知模块加进来”，AI 会在原有基础上做增量修改，而不是让我从头再来。

这其实就是把“系统分析师”的工作方式搬进了 AI 交互流程里：先调研需求，再拆解边界，最后用图说话。

1.3 动嘴皮子背后的可操作前提

标题说“动动嘴皮子”，并不是夸张。实际上语音输入只是交互入口之一，真正让这件事成立的前提有三个：

一是大语言模型具备足够的架构常识。它知道什么是微服务、什么是消息队列、什么是 CDN、什么是网关，不需要你从零教起。

二是图表描述语言把“图”变成了“代码”。只要 AI 能输出符合语法的代码，渲染就是水到渠成的事。所以选哪种图表描述语言，直接决定了 AI 的输出质量和渲染难度。

三是提示词把“怎么做分析”说清楚了。模型不会自动知道你想要 C4 分层还是 UML 类图，不会主动去识别系统边界。这些约束必须写进提示词里。

把这三个前提落实之后，你会发现所谓“动嘴皮子”，本质是你负责说出业务意图，AI 负责把意图翻译成被架构师认可的表达形式。你的很多专业能力依然要用在“评审”和“决策”上，只是画图这个纯体力活，彻底交出去了。

2. 实现方案与工具选型：Mermaid、PlantUML 与 Structurizr DSL 对比

2.1 三种架构描述语言的定位差异

要落地这个方案，先得选对“输出语言”。我实际对比了三种，分别是 Mermaid、PlantUML 和 Structurizr DSL。三者的核心区别在于设计目标不同。

Mermaid 是一个轻量级的图表描述语言，语法类似 Markdown，最大的优势是渲染简单，很多代码托管平台原生支持，写进 Markdown 文档里直接能预览。它支持的图类型非常全：流程图、时序图、状态图、甘特图、类图都有。缺点是它对“架构模型”的约束很弱，它只负责画图，不负责保证图在逻辑上是一套严谨的架构模型。

PlantUML 是老牌的图表描述语言，特别适合 UML 类图、时序图、用例图，在高龄技术团队中使用率很高。它的语法比 Mermaid 稍繁琐，渲染依赖 Java 运行时，好处是 UML 建模能力强，输出图表的专业感很足。如果团队做的是接口设计、类关系建模，PlantUML 更老练。

Structurizr DSL 是这三者里最“架构师向”的：它专门为 C4 模型设计，通过代码定义系统上下文、容器、组件、部署层级，并且强调“图”只是架构模型的视图之一。它既能产出一张上下文图，也能基于同一个模型切出各种视角的图。缺点是学习曲线最陡，而且它的生态更多面向团队级架构治理，个人快速画图反而有点重。

我的选择逻辑是：个人快速生成、嵌入文档、迭代频繁的场景，优先用 Mermaid；团队级架构建模、需要从多视角看同一套系统的时候，用 Structurizr DSL；PlantUML 保留在 UML 专项图的场景里。

2.2 为什么我把 Mermaid + C4 分层作为主路线

最终我把主路线定为 Mermaid，并且配合 C4 模型的思维去组织图。这个选择的理由很实际：

Mermaid 的语法简单，AI 输出的结果很少出现语法错误。PlantUML 如果输出用例图，缩进和括号错一个，渲染就直接报错。Mermaid 虽然也有语法要求，但容错性明显好一截，就算有点小问题，人工看一眼也能快速修掉。

Mermaid 能直接嵌进 Markdown 文档，这对“架构图随文档走”的习惯太友好了。我写完分析记录，图就在旁边，不用额外维护一个图形文件。

再说 C4 模型。这是我在提示词里经常借用的分析框架：Context（上下文）、Container（容器）、Component（组件）、Code（代码）。C4 的核心思想是分层表达，每一层只画当前视角需要看到的内容，这样能有效避免架构图变成一团乱麻。

跟 AI 配合的时候，C4 的价值格外明显。我可以先让 AI 生成系统上下文图，确认整体的边界；再让它把某个关键容器展开成组件图，深入局部；每一层都是一张独立图，看得清楚，改得也方便。这比让它一口气生成一张“包罗万象”的大图聪明得多。

2.3 完整工具链与最小环境准备

整套工具链其实很轻，不需要太重的安装配置。我本地用的工具组合如下：

大语言模型的对话接口是基础，可以是商业 API，也可以用本地部署的开源模型。V3 级别的对话能力完全够用，不一定追最新旗舰。

渲染 Mermaid 图则很简单：推荐从简到繁三种方式，第一种是直接在支持 Mermaid 渲染的在线编辑器里粘贴代码生成；第二种是本地安装命令行工具，比如用 npm 安装 mermaid-cli，把 Mermaid 编译成 SVG 或 PNG；第三种是图形界面工具，Chrome 插件或部分 Markdown 编辑器里面的预览插件都可以直接渲染。

我的个人习惯是：本地编码阶段用命令行工具生成图片，因为我需要批量产出多张架构图，并且在脚本里自动维护；跟业务方评审的时候改用在线编辑器，快速演示，改起来不用重新编译。

# 用 npm 安装 mermaid-cli（需要有 Node.js 环境） npm install -g @mermaid-js/mermaid-cli # 将一份 mmd 文件渲染成 PNG mmdc -i input.mmd -o output.png -w 2048

基于这套工具链，AI 输出的 Mermaid 代码可以直接落盘成.mmd文件，再一行命令变成高清图片。我在后面实操章节会给出完整的调用示例和详细步骤。

3. 核心实操：让 AI 按“系统分析师”的方式输出架构图

3.1 提示词设置的三个关键维度：角色，格式，迭代

很多人用 AI 画架构图失败，第一步就错在提示词太笼统，比如直接丢一句“帮我画一个在线笔记系统的架构图”。模型确实能给你画，但画出来通常是一张不规范的“大杂烩”——图表里堆了十几个框，又放数据库又放缓存又放第三方登录，谁也不挨着谁，关系箭头也很随意。

要让它产出符合系统分析规范的图，提示词里必须把三样东西讲清楚：

一是角色定位。明确告诉 AI 它是“系统分析师”，熟悉 C4 模型，职责是先分析需求，再输出架构模型相关的图表代码。角色定位能让模型自动带入“分析-建模”的思维，而不是只当一个画图工具。

二是输出格式约束。必须告诉它输出什么语言的代码、使用什么图类型、节点和关系怎么组织。更高级一点的做法是同时给一两个“输出示例区”，你不用展示完整例子，只要给一小段符合预期的代码片段，它就能照着这个风格输出。这就是 few-shot 的力量，实测下来能显著减少格式跑偏。

三是迭代机制。不要指望一次对话拿到完美成图。正确的做法是分几步：先让 AI 输出系统角色的清单和系统边界描述；再让它基于确认无误的边界生成上下文图；进一步细化到关键模块时，再用对话让它单独展开子模块。这样既不会信息量爆炸，又能让你在每一步都做人工把关。

3.2 一个完整实战：为在线笔记系统生成上下文图

我用一个完整的例子走一遍流程。假设需求是：“做一个在线笔记应用，用户可以在 Web 端和 Android 端浏览笔记、写笔记，支持标签分类、全文搜索、多人协作，管理员可以管理用户权限。”我没有给它任何结构化的技术约束，完全模拟“动嘴皮子”描述需求的状态。

我的提示词如下：

你是一名资深系统分析师，熟悉 C4 架构模型和 Mermaid 语法。 请先基于需求做架构分析，再从系统上下文视角生成 Mermaid 的 flowchart 图。 需求：做一个在线笔记应用，用户可以在 Web 端和 Android 端浏览笔记、写笔记， 支持标签分类、全文搜索、多人协作，管理员可以管理用户权限。 要求： 1. 先输出文字分析：外部角色、外部系统、期望的系统功能边界。 2. 再输出 Mermaid 代码：以 system context 视角，展示主系统与外部角色、外部系统的关系。 3. Mermaid 图使用 flowchart LR，每个节点用类名 + 说明的格式，箭头标签写明交互类型。

这里我做了三个设计。第一，要求“先输出文字分析”，是为了让它在画图之前先梳理边界，而不是直接闷头画。第二，要求“以 system context 视角”，防止它越级画出太细的容器组件。第三，指定 flowchart LR 和节点格式，避免输出的结构五花八门。

AI 给我的分析结果大致如下：

外部角色：普通用户、管理员。 外部系统：第三方邮件服务（用于注册/找回密码）、对象存储服务（用于存储笔记附件）。 系统功能边界：笔记管理、多端同步、标签分类、全文搜索、协作共享、用户与权限管理。

这段分析本身质量很好，尤其是把“对象存储服务”作为外部系统识别出来，说明模型理解了附件存储不应该塞进主服务内部。确认分析无误后，它输出了下面这段 Mermaid 源码（我这里用纯文本形式展示，方便复制）：

flowchart LR User["普通用户"] Admin["管理员"] NotesSys["在线笔记应用"] EmailSvc["第三方邮件服务"] ObjectStore["对象存储服务"] User -->|HTTP/HTTPS 访问<br/>Web/移动端| NotesSys Admin -->|后台管理操作| NotesSys NotesSys -->|发信请求 SMTP| EmailSvc NotesSys -->|附件上传/下载| ObjectStore

把这段代码复制进渲染器，出来的就是一张清晰的上下文图：两个外部角色从左侧指向主系统，主系统向右伸出两条依赖线，指向两个外部系统，箭头标签也写清楚了交互协议。这张图拿去给业务方看，没有任何技术压力，也把系统边界讲得明明白白。

3.3 从上下文图到容器图：让 AI 分层细化架构

上下文图只解决了“系统外长什么样”的问题。评审通过后，下一步就是往内一层走：容器图。容器图展示主系统内部由哪些可部署的单元组成，以及它们之间的调用关系。

我继续追加一轮对话：

继续做下一步：将“在线笔记应用”展开为容器图。 候选容器包括 Web 应用、Android 应用、后端 API 服务、数据库、搜索引擎、消息队列。 请先说明每个容器的职责，再输出 Mermaid 的 container 视角图。 要求：容器之间标注通信方式和数据流方向，数据库不直接暴露给客户端。

这里我给了候选容器列表。这是一个取舍：既利用模型的常识做初步拆分，又加了自己的约束，确保结果符合真实技术场景。模型输出的容器拆分如下：

Web 应用：面向浏览器的单页应用，处理渲染与用户交互。 Android 应用：移动端原生应用。 后端 API 服务：处理业务逻辑，提供 REST API。 主数据库：存储用户、笔记、标签等核心业务数据。 搜索引擎：提供全文索引与检索能力。 消息队列：解耦笔记更新与搜索索引重建，异步处理协作通知。

然后输出的容器图源码大致是这样的：

flowchart TB WebApp["Web 应用"] AndroidApp["Android 应用"] ApiSvc["后端 API 服务"] MainDB[("主数据库")] SearchEngine["搜索引擎"] MQ["消息队列"] WebApp -->|REST/JSON| ApiSvc AndroidApp -->|REST/JSON| ApiSvc ApiSvc -->|SQL| MainDB ApiSvc -->|写入索引任务| MQ MQ -->|异步消费| SearchEngine ApiSvc -->|查询请求| SearchEngine

这里我刻意让 AI 加了主数据库的存储符号格式，渲染出来是一个圆柱体，一眼就能看出“这是数据库”。容器之间只有 API 服务跟数据库、搜索引擎发生关系，客户端永远不直连数据层，这是我对它的约束生效的体现。

到这一步，“动嘴皮子”的价值已经非常明显了：一轮对话让系统边界和分析结果全部落成图形，而且每一层的图都是可以直接评审交付的。接下来我再走一遍完整的工程化流程，讲清楚怎么把这条链路变成日常可用的“系统”。

4. 工程化落地：渲染环境搭建与常见问题排查实录

4.1 把随机对话变成可靠产出的工程化步骤

对话式生成有个问题：每次生成的图质量不稳定。有时候标点符号多了一个，渲染器就不认了；有时候节点命名不统一，同一个意思一会儿叫“ApiService”一会儿叫“ApiSvc”。

要把这套流程从“偶尔好玩”变成“日常可靠”，需要加一道工程化约束：设定“代码生成规范”。我习惯在提示词末尾追加一段固定模板，强制 AI 遵循。这个模板包括：节点命名规则、箭头语法、子图分组、输出纯净代码（不要加前后解释）。

我给出一份可以直接复制的规范模板：

[Mermaid 代码规范] - 使用 flowchart LR 或 TB，不要使用 graph 旧语法。 - 节点命名统一用大写驼峰，如 User、NotesSys、ApiService。 - 箭头标签用简短动词短语，如 "HTTP 调用"、"异步写入"。 - 涉及数据库节点时使用括号形式渲染圆柱体。 - 只输出 Mermaid 代码，不附加任何说明。

这个模板写进提示词尾部之后，AI 产出的代码格式基本就稳定了。我再配合本地 CLI 批量渲染，就能保证每一张图都按同一风格交付，无论是写文档还是做汇报，观感都整齐。

4.2 踩坑记录：从渲染报错到边界失控的排查经验

再顺手的工具也有翻车的时候。我把自己实际碰到的典型问题和排查思路整理成了一张速查表，这些坑你在实操中大概率也会遇到。

这里面我觉得最容易忽视的是第一种：Mermaid 语法细节。很多团队用了 Mermaid 很久，偶尔还是会踩到箭头写错、标签中文空格这些细节坑。排障的关键是不慌，Mermaid 的报错信息虽然有时不够友好，但把出错代码逐行检查，重点看箭头符号和引号闭合，基本都能解决。

4.3 本地渲染脚本的完整配置参考

我习惯写一个简易脚本来完成“源码入库 → 批量渲染 → 输出归档”的工作流。下面是一个最小可用的做法，便于你直接套用。

先准备目录结构：

arch-docs/ ├── src/ # AI 产出的 .mmd 源文件 └── out/ # 渲染后的图片输出

然后写一个批量渲染脚本（用 Python 调用 mmdc 命令行）：

import os import subprocess src_dir = "src" out_dir = "out" os.makedirs(out_dir, exist_ok=True) for filename in os.listdir(src_dir): if filename.endswith(".mmd"): input_path = os.path.join(src_dir, filename) output_path = os.path.join(out_dir, filename.replace(".mmd", ".png")) # 额外加 2 倍宽度，保证导出图片清晰 subprocess.run([ "mmdc", "-i", input_path, "-o", output_path, "-w", "2048", "-b", "white" ], check=True) print("全部架构图渲染完成")

这个脚本本身没什么难点，关键是两个参数：-w 2048保证图片在投影或文档里放大不糊；-b white保证背景纯白，避免透明背景在部分文档工具里显示成黑色。

我把 AI 每次生成的源码存进 src 目录，脚本一跑，out 目录里就是全部图片。之后写设计文档、做评审 PPT，直接引用这些图片就行，不用再手动截图。

5. 把“动嘴皮子”落到真实工作流：进阶技巧与扩展场景

5.1 让 AI 理解你的业务黑话：建立术语表

架构图专业与否，不只取决于图的连线，还取决于术语的表达。每个行业都有自己的业务语言，比如电商行业里的“SKU”“履约单”“拒付”，教育领域里的“班课”“课时包”“退费单”。如果你不把这些术语告诉 AI，它默认会用自己的通用词汇去表达，产出的图跟业务方认知对不上，评审会直接卡壳。

解决办法是在提示词里附加一个小型术语表，比如：

[业务术语表] - 课次预约：用户对一节具体的授课时间段进行的预约操作。 - 教师收入单：根据教师完成的授课记录生成的结算数据记录。 - 退款审批单：经过风控审核后产生的退款凭据。

加了这一块之后，AI 输出的节点命名和关系描述都会贴近业务习惯。我自己实测过，没加术语表的图，业务方看半天问“这是什么”；加了术语表之后，图直接变成评审材料，根本不需要额外解释。这其实就是用 AI 的“办事前先对齐概念”来模拟分析师进场前的业务调研。

5.2 维持架构图简洁的四个硬性约束

AI 生成的架构图最常见的翻车方式是“信息过载”：它恨不得把所有想到的东西都画进去，结果图上一百多个节点，几乎没法看。我的经验是对输出做四个硬性约束：

第一，用分层限制信息量。上下文图就只画角色与外部系统，不要出现具体的数据库名、缓存组件名。

第二，用数量限制节点。对话里明确要求“本节节点控制在 8 个以内”，如果多于 8 个，要求模型拆成子模块，子模块单独画图。

第三，用深度限制细化程度。按 C4 层级逐层推进，每一层只做当前粒度的事。比如画容器图时，不要展开到内部的代码类。

第四，用“一行一关系”限制连线。让模型尽量不画长距交叉箭头，交叉太多就把图拆开。Mermaid 的 subgraph 语法可以用来做视觉分组，把强相关的节点包在一起，可读性显著提升。

这四个限制看起来琐碎，但聚在一起的效果非常明显。我对照过同一个人同一个需求，不加限制的图一团乱麻，加了限制的图清晰专业，评审通过率高很多。

5.3 后续还能怎么玩：从静态图到评审文档的自动化

架构图画好只是第一步，把图的“数据价值”榨干才更有意思。我的后续扩展方向有三个：

第一个方向是让 AI 从同一套架构模型中生成不同视角的图。比如画完容器图后，让它生成“部署环境视角”的图，把容器映射到服务器、Kubernetes 节点上；或者让它生成“关键路径视角”的图，高亮连接登录、搜索这条主链。基于同一个模型多出几张视图，是 C4 思维最值钱的部分。

第二个方向是让 AI 把架构图“翻译”成接口清单或风险清单。我试过让它基于架构图源码列出“系统间集成点说明”，能直接作为接口文档初稿。虽然细节还需要人审，但框架性的工作确实省了。

第三个方向是定期用对话让 AI 对比“上个月架构图”和“这个月架构图”的差异，自动输出变更摘要。这其实是把架构治理中的文档维护工作也半自动化了。

我个人的体会是，这套做法真正的价值不只是“省时间”这么简单。它把架构设计的思考过程从个人的脑内变成可对话、可保存、可追溯的记录。你跟 AI 聊的每一轮分析，本质上都是一份带图的知识资产。下次团队里来新人，把这段对话和产出的架构图丢给他，他理解系统所需的时间会大幅缩短。

最后再分享一个小技巧：生成 Mermaid 图时，尽量把一条箭头的关系语义限定为一句话，比如“调用”、“写入”、“订阅”。不要用长难句这种歧义表达。图里的箭头就是系统的骨架，骨架清楚，后面细化填充什么事情都顺。