[AI架构师转型系列-2] 架构师听懂客户需求

本篇你将学到：

• 用 AI 追问 20 个问题，把一句话需求变成结构化文档
• 用 Mermaid 画出需求澄清流程和系统上下文图
• 写一份有 MUST/SHOULD/NICE-TO-HAVE 优先级的需求文档
• 区分 AI 架构师和提示词工程师——你的价值在判断，不在写

Spec First，第一步到底做什么？

找个场景，老板说"我们客服忙不过来了，加个 AI 客服吧。"没有文档，没有需求列表，没有任何技术约束。

传统的做法是开始自己揣摩：老板大概是想让 AI 自动回答常见问题？要不要转人工？要不要查订单？要不要对接工单系统？然后打开文档开始写需求。写了一两天，拿去评审——开发发现有些场景没覆盖到，业务觉得指标定得不够准，老板也提了新的补充意见。

问题出在哪？一句话需求里隐含的信息太多，靠一个人闷头想，很难一次性想全。

AI 的角色：不是帮你写文档，是帮你问问题

把"我们客服忙不过来了，加个 AI 客服吧"扔给 AI Coding 工具。不要让它直接写方案，先让它追回。

我们可以问下AI。

关于业务边界：

客服渠道有哪些？只有 App，还是也有 Web 和小程序？日均咨询量大概多少？峰值在什么时段？客服团队现在几个人？

关于功能范围：

AI 客服要能做什么？自动回答常见问题就够了，还是要能查订单、改地址、取消订单？哪些操作绝对不能 AI 做——比如退款、比如补偿？

关于系统对接：

现有工单系统是什么？用户系统怎么拿用户信息？物流状态从哪查？这些系统的接口是 HTTP API 还是别的方式？

关于质量要求：

首次解决率的目标是多少？响应时间 SLA？什么情况下转人工——AI 连续两次没解决？还是用户主动说"转人工"？

关于安全和合规：

MumuMall 的用户数据能传给大模型吗？需要脱敏吗？有没有合规要求——比如金融支付类问题必须人工处理？

AI 追问了大概二十个问题。整个澄清流程可以总结为这张图：

这些问题质量怎么样？大部分是靠谱的。但有一个它没问到："生鲜品类退款规则复杂，AI 客服初期适合处理吗？"

这个问题 AI 不会主动想。因为 AI 不知道 MumuMall 卖生鲜。这就是架构师的价值——你知道 AI 漏了什么。

下一步：把所有答案变成一份结构化文档

假设老板回答了这些问题（或者你替老板回答了，因为你是架构师，你比老板更清楚系统的边界）。现在把回答输给 AI，让它输出一份结构化需求文档。

AI 的输出长这样：

功能清单

非功能需求

边界条件与风险假设

成功指标

这份文档不只是"写出来"，而是"能用"

和传统需求文档的区别在哪？

传统需求文档是 Word 写的，自由文本。每个人写法不一样，开发看完还要自己"翻译"——"这里说的'快速响应'到底是几秒？""客服渠道"到底包不包括小程序？"

这份结构化文档不一样。每个功能有 MUST/SHOULD/NICE-TO-HAVE 优先级。每个非功能需求有具体数字。每个边界条件有明确的处理方式。每个成功指标有测量方式。

开发拿到它不用猜。AI 拿到它可以直接生成代码骨架——这是我们下一篇要做的。

架构师在需求阶段就在想架构

需求文档写完不是终点。架构师和产品经理的区别在于——你拿到需求的那一刻，脑子里已经在画架构图了。

这个系统大概长什么样？不用很精确，但大骨架要有。把需求文档扔给 AI：

"基于这份需求，给一个 MumuMall 智能客服的初步架构。部署在阿里云上。用 Mermaid 画出来。"

AI 三十秒出了第一版：

这是第一版草图，不是最终架构。但你已经看到了关键决策点：

• SLB 在前面做流量分发——跨两个可用区，一个可用区挂了不影响服务
• ECS 上跑 Agent 服务——要选什么规格？几核几 G？
• Elasticsearch 做向量检索——知识库文档切片后存这里，不是直接读 OSS
• RDS 和 Redis——工单数据持久化走 MySQL，会话缓存走 Redis，读写分离
• VPC 和安全组——所有服务内网互通，对外只开放 SLB 的 443 端口

这些决策不是拍脑袋。下一篇 Spec三层会给出每一步的计算依据。比如：为什么选 ECS 而不是 Serverless？MumuMall 日均 5000 次咨询，常驻流量，ECS 预留实例比按量付费的函数计算便宜 40%。

架构师要掌握的三件事

看到这，你已经感受到了架构师在 AI 时代的核心能力变化。总结一下这篇你实际做了的三件事：

第一件：用 AI 做需求澄清。不是你写需求文档，是 AI 追问、你回答、AI 输出、你审核。你的价值不是撰写，是判断——追问全不全？边界够不够？有没有 AI 不知道但你知道的业务约束？

第二件：用 AI 写结构化方案。输出的不是 Word 文档，是结构化的功能清单 + 非功能需求 + 边界条件 + 成功指标。每个数字有依据，每个边界有处理方式。开发拿到不用猜，AI 拿到可以直接生成代码。

第三件：用 AI 画架构图。从需求直接生成初步架构——SLB 放哪、ECS 怎么部署、数据怎么存、网络怎么规划。不是 Visio 手绘半天，是 AI 三十秒出图、你审核调整。下一篇我们会让这张图变得更精确。

这三件事，传统方式加起来要 3-5 天。AI 加持下，一个小时。

架构师被替代的是"写文档"。被放大的是"判断"。

AI 能追问、能结构化输出、能帮你发现盲区。但它不知道 MumuMall 卖生鲜、不知道生鲜退款规则复杂——它没有你的业务上下文。

你的新角色不是"需求文档的撰写者"，是需求质量的守门人。AI 是扫描仪，你是法官。

Forbes 今年五月的文章说得很直白：别招提示词工程师，招 AI 架构师。提示词工程师的工作是"让 AI 输出得更好"——这个技能正在被 AI 自己替代。AI 架构师的工作是"定义 AI 该做什么、怎么验证它做对了"——这个能力 AI 替代不了。

本篇产出：MumuMall 智能客服结构化需求文档 + 初步云端架构草图。

下一篇：架构图还不够精确——Spec 三层给出每一步的决策依据。为什么选 ECS 而不是 Serverless？ECS 选什么规格？RDS 用什么版本？每个决策都有计算过程。架构图从草图升级为生产级。