[AI架构师转型系列-3] AI反思提升质量、直接生成Mermaid-Drawio架构图省时间、多渠道获取资料扩展广度

公众号名称：沐然云计算

作者名称：吕昭波

发布时间：2026-06-09 23:39

本篇你将学到：

用结构化三层法（业务/架构/模块）写方案，替代传统 Word 方案文档

每个选型决策写出”为什么选它、为什么不选别的”

用 AI 生成 Mermaid 架构图，并自动做架构评审

用三版产出的实际差距理解”方案的结构化程度决定 AI 产出质量”

上两篇做了什么？第一篇建立了”AI 在重新定义架构师”的认知。第二篇用 MumuMall 项目演示了第一步——AI 追问二十个问题，把”加个 AI 客服”变成了一份结构化需求文档，顺便用 AI 生成了第一版云端架构草图。

今天做第二步：把需求变成一份可执行的技术方案。

为什么这一步是关键？因为传统方案和 AI 时代方案的分水岭就在这里。

传统做法：拿到需求，打开 Word，开始写方案。背景、目标、技术选型、架构设计、部署方案……写到第五页开始怀疑”这个选型对不对”，写到第十页开始担心”评审会的时候会不会被问住”。写了 3 天，评审 2 小时，开发拿到后说”这个接口定义不清晰”。

问题不是你不会写方案。问题是 Word 是人看的，不是 AI 能执行的。

架构师写方案，读者是谁？以前只有一个读者——人。开发、评审、客户。现在多了一个读者——AI。你写完方案，下一秒钟就可能把它扔给 AI 去生成代码、生成架构图、生成评审报告。

但传统 Word 方案是自由文本。你写”系统需支持高并发”，开发理解为”加个缓存”，运维理解为”配个弹性伸缩”，AI 理解不了。而结构化方案——每个需求有优先级，每个指标有数字，每个接口有输入输出定义——AI 读得懂，开发没歧义，你能快速验证。

这套写方案的方法，我叫它”结构化三层法”。不是什么新概念——说白了就是把方案按三个维度拆开写，每一层写得足够精确，精确到 AI 可以直接执行。

以 MumuMall 智能客服为例，三层怎么写。

第一层：业务方案（What——做什么，为什么）

先把第 2 篇的结构化需求翻译成业务方案。这不是重写，是换一种格式——让 AI 和开发都能直接消费：

项目: MumuMall 智能客服 Agent版本: v1.0场景:  - 用户咨询退换货流程 → AI 从知识库检索政策 → 生成回答  - 用户查询工单状态 → AI 调工单 API → 返回状态和处理人  - AI 连续两轮未解决 → 转人工，携带上下文  - 用户主动要求转人工 → 即时转接成功指标:  首次解决率: ≥ 60%（对话后 2h 内未再次咨询或转人工）  用户满意度: ≥ 4.0/5.0  转人工率: < 30%  响应时间 P95: < 3s边界条件:  - 生鲜退款、支付异常 → 直接转人工，AI 不处理  - 用户手机号/地址 → 脱敏后传给 LLM  - 大促峰值流量翻 5 倍 → 弹性伸缩自动应对不做的:  - AI 不自主发起退款或补偿操作  - 不处理账户注销、密码修改等敏感操作  - 不存储用户完整对话记录（仅保留脱敏日志）
项目: MumuMall 智能客服 Agent
版本: v1.0
场景:
- 用户咨询退换货流程 → AI 从知识库检索政策 → 生成回答
- 用户查询工单状态 → AI 调工单 API → 返回状态和处理人
- AI 连续两轮未解决 → 转人工，携带上下文
- 用户主动要求转人工 → 即时转接
成功指标:
首次解决率: ≥ 60%（对话后 2h 内未再次咨询或转人工）
用户满意度: ≥ 4.0/5.0
转人工率: < 30%
响应时间 P95: < 3s
边界条件:
- 生鲜退款、支付异常 → 直接转人工，AI 不处理
- 用户手机号/地址 → 脱敏后传给 LLM
- 大促峰值流量翻 5 倍 → 弹性伸缩自动应对
不做的:
- AI 不自主发起退款或补偿操作
- 不处理账户注销、密码修改等敏感操作
- 不存储用户完整对话记录（仅保留脱敏日志）

注意最后一栏”不做的”。传统方案很少写”不做什么”，但结构化方案要求写清楚边界。AI 不知道你的业务约束，边界不写清楚，AI 就可能越界。

第二层：架构方案（How——怎么实现，选什么）

这是架构师的核心战场。把业务方案扔给 AI，加上技术约束：

“MumuMall 日均 5000 次咨询，峰值出现在大促期间（翻 5 倍）。部署在阿里云上。需要给出技术选型和拓扑，说明为什么选这个。”

AI 输出了第一版架构方案。我逐条审核、补充后长这样：

计算层

产品	规格	数量	为什么选它
ECS	ecs.g7.xlarge（4C8G）	2 台起步，弹性伸缩至 8 台	常驻流量日均 5000 咨询，g7 是通用型性价比最优。选 ECS 不选 Serverless 的原因：按 MumuMall 日均 100 QPS 常驻流量计算，函数计算按调用次数 + 时长计费，一个月约 ¥3200；ECS 预留实例一个月 ¥1800。流量稳定时 ECS 便宜 40%+
SLB（ALB）	标准型	1 个	应用层负载均衡，支持基于 URL 的路由（后续多 Agent 拆分会用到）和 WebSocket

数据层

产品	用途	为什么选它
Elasticsearch 8.x	知识库向量检索	MumuMall 产品文档 + FAQ 约 500 篇，切片后约 5000 个向量。ES 自带向量检索能力，不需要额外部署向量数据库。检索延迟 < 50ms
RDS MySQL 8.0	工单表、用户表	工单数据强一致，必须走关系型。读写量不大（日均 5000 次查询），2C4G 基础版够用
Redis 7.0	Agent 会话状态、Memory 缓存	Agent 对话需要保持上下文。Redis 存当前会话状态（< 1MB/会话），TTL 30 分钟自动过期

AI 层

产品	用途
百炼（通义千问 Qwen-Max）	Agent 的 LLM 调用——意图判断、回答生成
OSS	知识库源文件存储（产品文档 PDF/FAQ/退换货政策）

网络层

VPC: 172.16.0.0/16├── 可用区 A 交换机: 172.16.1.0/24（ECS、RDS 主库）├── 可用区 B 交换机: 172.16.2.0/24（ECS、RDS 备库）└── 安全组:    ├── SLB 安全组: 公网 443 开放    ├── ECS 安全组: 仅接受 SLB 和内网流量    └── 数据库安全组: 仅接受 ECS 安全组流量
VPC: 172.16.0.0/16
├── 可用区 A 交换机: 172.16.1.0/24（ECS、RDS 主库）
├── 可用区 B 交换机: 172.16.2.0/24（ECS、RDS 备库）
└── 安全组:
├── SLB 安全组: 公网 443 开放
├── ECS 安全组: 仅接受 SLB 和内网流量
└── 数据库安全组: 仅接受 ECS 安全组流量

每一行选型都写了”为什么”。这是一份合格的架构方案——不只说选什么，还说为什么不选别的。

第三层：模块接口定义（Detail——每个功能模块的输入输出）

这一层最容易被忽略，但它决定了 AI 能不能精准执行。以 MumuMall 智能客服的四个功能模块为例：

Tool 1: search_knowledge_base  职责: 从知识库中检索相关文档片段  输入:    query: string（用户问题原文）    top_k: int（返回片段数，默认 5）  输出:    results: [{doc_id, title, content_snippet, score}, ...]  错误处理: 检索无结果 → 返回空数组，由 Agent 走降级话术
Tool 2: query_ticket  职责: 根据工单号或手机号查询工单状态  输入:    ticket_id: string（可选）    user_phone: string（可选，脱敏后查询）  输出:    ticket: {id, status, created_at, handler, detail} | null  错误处理: 查询不到 → 返回 null，Agent 提示"未找到工单"
Tool 3: create_ticket  职责: 创建新工单  输入:    user_phone: string（脱敏）    category: string（退换货/物流/支付/其他）    description: string  输出:    ticket: {id, status: "created", created_at}  错误处理: 创建失败 → 返回 error，Agent 建议用户稍后重试或转人工
Tool 4: escalate_to_human  职责: 转人工客服，携带上下文  输入:    session_id: string    reason: string（转接原因）    context_summary: string（AI 已了解的信息摘要）  输出:    result: {status: "transferred", queue_position: int, estimated_wait: int}
Tool 1: search_knowledge_base
职责: 从知识库中检索相关文档片段
输入:
query: string（用户问题原文）
top_k: int（返回片段数，默认 5）
输出:
results: [{doc_id, title, content_snippet, score}, ...]
错误处理: 检索无结果 → 返回空数组，由 Agent 走降级话术

Tool 2: query_ticket
职责: 根据工单号或手机号查询工单状态
输入:
ticket_id: string（可选）
user_phone: string（可选，脱敏后查询）
输出:
ticket: {id, status, created_at, handler, detail} | null
错误处理: 查询不到 → 返回 null，Agent 提示"未找到工单"

Tool 3: create_ticket
职责: 创建新工单
输入:
user_phone: string（脱敏）
category: string（退换货/物流/支付/其他）
description: string
输出:
ticket: {id, status: "created", created_at}
错误处理: 创建失败 → 返回 error，Agent 建议用户稍后重试或转人工

Tool 4: escalate_to_human
职责: 转人工客服，携带上下文
输入:
session_id: string
reason: string（转接原因）
context_summary: string（AI 已了解的信息摘要）
输出:
result: {status: "transferred", queue_position: int, estimated_wait: int}

每一个 Tool 都定义了输入类型、输出结构、错误处理。开发拿到这个，不需要猜”查询不到工单返回什么”——null。AI 拿到这个，能生成精确的代码框架——下一篇会演示。

同一个需求，三种写法的差距有多大

到这里，做个对比。同一个”AI 客服”需求，三种写法，输给 AI 让它生成代码骨架：

版本 A，一句话：“做个智能客服。“AI 输出：一段泛泛的 Flask demo，没有 Tool 定义，没有错误处理，只有一个 /chat端点返回固定话术。

版本 B，半结构化：“做一个智能客服，支持知识库检索、工单查询、转人工。部署在阿里云上。“AI 输出：结构好了一些，有基本的目录结构，但 Tool 接口模糊——“查工单”传什么参数？返回什么？不知道。

版本 C，结构化方案——上面三层全给。AI 输出：完整的 FastAPI 项目，四个功能模块每个有 Pydantic Model、有错误处理、有类型标注。Dockerfile 写了。启动脚本写了。直接 uvicorn main:app就能跑。

方案的结构化程度差距，就是 AI 产出的质量差距。

这和一个道理是相通的：你给开发的需求越模糊，开发越容易做偏。你给 AI 的方案越精确，AI 的产出越接近你的预期。只不过面向开发的需求模糊了，开发会来找你确认。面向 AI 的方案模糊了，AI 不会问——它会猜，猜错的代价你自己承担。

最后一步：让 AI 评审你的架构

方案写完了，架构图也更新了。下一篇部署之前，先让 AI 做一次架构评审。

把架构方案和 Mermaid 图一起扔给 AI：

“基于这个方案和架构图，做一次架构评审。识别单点故障、安全风险、容量问题、成本优化点。”

AI 输出的评审结果：

风险项	严重程度	说明	建议
ECS 单点	⚠️ 高	当前 2 台 ECS，但未明确是否跨 AZ	确认弹性伸缩配置了可用区 A+B 均匀分布
RDS 单点	⚠️ 中	架构方案写的是基础版，无双机热备	建议升级为高可用版（一主一备跨 AZ），增加约 30% 成本
安全组	⚠️ 中	Elasticsearch 端口 9200 未限制来源	安全组规则限定为仅 ECS 安全组可访问
成本	ℹ️ 低	按量付费 ECS 月费 ¥3200，预留实例 ¥1800	MumuMall 稳定流量场景，建议购买预留实例
日志	ℹ️ 低	缺少 Agent 推理链追踪方案	下一篇接入 SLS + ARMS

每一条都有具体依据——不是”感觉不安全”，是”9200 端口未限制来源”。

这就是新评审方式：**AI 做扫描仪，广度覆盖不遗漏。架构师做法官，深度判断业务特有风险。**AI 扫出来的十条风险里，你可能觉得两条不重要、一条误判，但剩下七条确实有价值——而这些是你一个人逐条过 Checklist 容易漏掉的。

这一篇的核心

结构化三层法——业务方案定义边界和成功标准，架构方案定义选型和”为什么这么选”，模块接口定义每个功能模块的精确输入输出。

这三层合在一起，就是一份可执行的技术方案——能拿给客户看、能上评审会、能直接丢给 AI 生成代码骨架。

架构师的新角色不是”Word 方案的撰写者”，是方案的制定者和审核者。AI 可以根据需求生成方案初稿，但每一层都需要你判断——边界够不够？选型依据对不对？接口定义全不全？这份方案能不能直接拿去投标？能不能让客户一眼看懂你要怎么做、为什么这么选？

Forbes 那篇文章说 AI 架构师是”多 Agent 系统的总承包商”。总承包商不需要亲自画每一张图、写每一段代码，但需要知道每张图对不对、每段代码为什么这么写。

内容效果不满意？点此反馈