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

公众号名称：沐然云计算

作者名称：吕昭波

发布时间：2026-06-08 23:38

本篇你将学到：

• 用 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 的输出长这样：

功能清单

优先级	功能	说明
MUST	知识库检索问答	用户输入自然语言 → AI 从产品文档/FAQ/退换货政策中检索 → 生成回答
MUST	转人工客服	AI 连续两轮没解决 / 用户主动说"转人工" → 完整传递上下文给人工
SHOULD	工单状态查询	用户输入工单号或手机号 → 查询工单当前状态和处理人
SHOULD	敏感操作拦截	退款/大额补偿/账户注销 → AI 直接转人工，不处理
NICE-TO-HAVE	创建新工单	用户在对话中直接创建工单，无需跳转到工单系统

非功能需求

维度	要求
并发量	支持 500 QPS（峰值时段），日常 100 QPS
响应时间	首次响应 < 3 秒，知识检索 < 2 秒
可用性	99.9%，跨可用区部署
数据安全	用户手机号、地址脱敏后传给 LLM；支付/密码类信息不传给 AI
可观测	每次对话记录：意图分类、检索命中率、转人工率、Token 消耗

边界条件与风险假设

场景	处理方式
知识库检索不到相关内容	返回预设话术："抱歉，我暂时没找到相关资料，试试换个问法？"
用户输入无意义内容	返回引导话术："您是想了解退换货流程、查询订单，还是转人工客服？"
生鲜品类退款	AI 暂不处理，统一转人工（该品类退款规则复杂，需人工判断）
支付问题	AI 不处理任何支付相关操作，转人工
大促期间流量翻 5 倍	弹性伸缩自动扩容，最低保障 2 台实例

成功指标

指标	目标值	测量方式
首次解决率	≥ 60%	AI 对话后 2 小时内用户未再次咨询或转人工
用户满意度	≥ 4.0/5.0	对话结束后的满意度评分
转人工率	< 30%	转人工次数 / 总咨询次数
响应时间 P95	< 3 秒	SLS 日志统计

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

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

传统需求文档是 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 用什么版本？每个决策都有计算过程。架构图从草图升级为生产级。

---

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