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

本篇你将学到：

• 用结构化三层法（业务/架构/模块）写方案，替代传统 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 不自主发起退款或补偿操作
  - 不处理账户注销、密码修改等敏感操作
  - 不存储用户完整对话记录（仅保留脱敏日志）

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

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

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

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

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

计算层

数据层

AI 层

网络层

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 都定义了输入类型、输出结构、错误处理。开发拿到这个，不需要猜"查询不到工单返回什么"——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 输出的评审结果：

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

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

这一篇的核心

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

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

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

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