结构化方案提升AI执行效率
本篇你将学到：
用结构化三层法（业务/架构/模块）写方案，替代传统 Word 方案文档
每个选型决策写出"为什么选它、为什么不选别的"
用 AI 生成 Mermaid 架构图，并自动做架构评审
用三版产出的实际差距理解"方案的结构化程度决定 AI 产出质量"
上两篇做了什么？第一篇建立了"AI 在重新定义架构师"的认知。第二篇用 MumuMall 项目演示了第一步——AI 追问二十个问题，把"加个 AI 客服"变成了一份结构化需求文档，顺便用 AI 生成了第一版云端架构草图。
今天做第二步：把需求变成一份可执行的技术方案。
为什么这一步是关键？因为传统方案和 AI 时代方案的分水岭就在这里。
传统做法：拿到需求，打开 Word，开始写方案。背景、目标、技术选型、架构设计、部署方案……写到第五页开始怀疑"这个选型对不对"，写到第十页开始担心"评审会的时候会不会被问住"。写了 3 天，评审 2 小时，开发拿到后说"这个接口定义不清晰"。
问题不是你不会写方案。问题是Word 是人看的，不是 AI 能执行的。
架构师写方案，读者是谁？以前只有一个读者——人。开发、评审、客户。现在多了一个读者——AI。你写完方案，下一秒钟就可能把它扔给 AI 去生成代码、生成架构图、生成评审报告。
但传统 Word 方案是自由文本。你写"系统需支持高并发"，开发理解为"加个缓存"，运维理解为"配个弹性伸缩"，AI 理解不了。而结构化方案——每个需求有优先级，每个指标有数字，每个接口有输入输出定义——AI 读得懂，开发没歧义，你能快速验证。
这套写方案的方法，我叫它"结构化三层法"。不是什么新概念——说白了就是把方案按三个维度拆开写，每一层写得足够精确，精确到 AI 可以直接执行。
以 MumuMall 智能客服为例，三层怎么写。
先把第 2 篇的结构化需求翻译成业务方案。这不是重写，是换一种格式——让 AI 和开发都能直接消费：
注意最后一栏"不做的"。传统方案很少写"不做什么"，但结构化方案要求写清楚边界。AI 不知道你的业务约束，边界不写清楚，AI 就可能越界。
这是架构师的核心战场。把业务方案扔给 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/退换货政策）
网络层
每一行选型都写了"为什么"。这是一份合格的架构方案——不只说选什么，还说为什么不选别的。
这一层最容易被忽略，但它决定了 AI 能不能精准执行。以 MumuMall 智能客服的四个功能模块为例：
每一个 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 做一次架构评审。
把架构方案和 Mermaid 图一起扔给 AI：
"基于这个方案和架构图，做一次架构评审。识别单点故障、安全风险、容量问题、成本优化点。"
AI 输出的评审结果：
风险项
严重程度
说明
建议
ECS 单点
⚠️ 高
当前 2 台 ECS，但未明确是否跨 AZ
确认弹性伸缩配置了可用区 A+B 均匀分布
RDS 单点
⚠️ 中
架构方案写的是基础版，无双机热备
建议升级为高可用版（一主一备跨 AZ），增加约 30% 成本
安全组
⚠️ 中
Elasticsearch 端口 9200 未限制