我们先从一个真实案例说起。某天，老板找到你，直接抛下一句：“客服团队快扛不住了，给公司上线个智能客服系统吧。”就这么短短一句话，没有正式文档，没有明确需求，甚至没有给出任何技术约束。
多数人听到这类指令，第一反应是什么？往往会埋头琢磨：老板是不是只想让AI回复常见问题？要不要加入人工转接功能？是否要与订单系统对接？越想越陷入纠结，随后便打开文档，洋洋洒洒开始撰写方案。结果呢？忙活一两天，拿去内部评审——开发同事发现场景覆盖不全，业务方觉得关键考核指标设定错误，老板又临时冒出几个“新想法”。
问题究竟出在哪里？很简单，一句话需求背后隐藏的信息量太庞大了。一个人独自闭门思考，永远无法把所有细节统筹周全。
AI 的核心价值：帮你问出正确的问题，而不是直接替你写答案
还是那句“客服忙不过来，加个AI客服吧”。这时候，别急着让AI直接写方案。你的第一步，应该是让它“追着你不断提问”。
我们不妨看看，AI能够问出哪些有价值的关键问题：
* **关于业务边界**：客服渠道涵盖哪些？仅限于App，还是同时支持Web端和小程序？日均咨询量大概多少？峰值通常出现在几点？当前团队一共有多少人？ * **关于功能范围**：AI需要处理哪些任务？是只回复常见问答，还是需要支持订单查询、地址修改，甚至取消订单？哪些操作应划为红线，AI绝对不能碰——比如退款和赔偿？ * **关于系统对接**：现有的工单系统是什么？用户信息从哪里获取？物流状态又该如何查询？这些接口是HTTP API，还是其他协议？ * **关于质量要求**：首次问题解决率的目标是多少？响应时间的服务水平协议（SLA）设定了多少？在什么情况下必须转接人工——是AI连续两次无法回答，还是用户主动说出“转人工”？ * **关于安全与合规**：MumuMall的用户数据能直接传给大模型吗？是否需要数据脱敏？有没有必须遵守的合规红线——比如金融支付相关问题，必须由真人处理？你看，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：
三十秒，AI就能给出第一版架构草图：
这当然不是最终架构，但已经能让你看到关键的决策点了：
* **SLB** 在最前端做流量分发——跨两个可用区部署，单个可用区故障不影响整体服务。 * **ECS** 上运行Agent服务——接下来需要确定选什么规格？几核几G最合适？ * **Elasticsearch** 实现向量检索——知识库文档切片后存储于此，而非直接读取OSS。 * **RDS和Redis**——工单数据持久化走MySQL，会话缓存走Redis，实现读写分离。 * **VPC和安全组**——所有服务内网互通，对外只开放SLB的443端口。这些决策并非凭空拍脑袋。后续我们会一步步提供计算依据。例如，为何选ECS而非Serverless？MumuMall日均5000次咨询，属于常驻流量，ECS预留实例比按量付费的函数计算能节省约40%的成本。
架构师在AI时代，必须牢牢抓住这三件事
看到这里，你应该已经感受到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用什么版本？每个决策，都将附上完整计算过程。
