[AI架构师转型系列-7] 架构师核心能力

本篇回答一个问题： 跑完 MumuMall 这个项目，一个传统架构师身上到底长出了什么新能力？这些能力之间的关系是什么？怎么判断自己长到了哪一步？

先回顾一下前六篇——MumuMall 智能客服从零到上线的完整链路：

第1篇  认知：AI 不替代架构师，但重新定义架构师
第2篇  需求：AI 追问 20 个问题 → 结构化需求文档
第3篇  方案：Spec 三层 → AI 生成架构图 → AI 架构评审
第4篇  选型：模型对比 → Token 成本预估 → AI Coding 工具选型
第5篇  验证：Dify 原型验证模型选型、Token 预估、编排边界
第6篇  架构：多 Agent 拆分决策 → 阿里云部署 → 高可用验证

先给结论：AI 架构师的核心能力不是"会用 AI"，是一个四维能力模型

跑完 MumuMall，我意识到 AI 架构师的能力增长不是线性的——不是你从 L1 到 L2 到 L3 到 L4 一路升上去。是四个维度的能力在相互拉扯、交替生长。

需求的结构化能力
                   （说清楚要什么）
                        │
                        │
    组织的采纳推动能力  ←──┼──→  方案的概率性设计能力
    （让一群人用对AI）     │     （设计一个可能出错
                        │      但可控的系统）
                        │
                  系统的可观测性能力
                  （证明系统在变好
                   而不是在变差）

四个能力不是四个阶段，是四个同时存在、相互制约的维度。一个维度短板，其他三个维度就会被拖住。一个维度突破，会倒逼其他三个维度升级。

下面逐一展开每个维度——它是什么、怎么长出来的（对应哪篇）、判断标准是什么、最常见的错误是什么。

维度一：需求的结构化能力

是什么

不是"把需求写清楚"。是把业务意图翻译成 AI 可执行的规格。

传统架构师的需求分析，终点是一份人读的文档。AI 架构师的需求分析，终点是一份人机共读的 Spec——人用它验收，AI 用它执行。

这个能力包含三个子能力：

1. 追问能力：AI 追问你的同时，你也在追问 AI——"你漏了什么维度？"（第 2 篇）
2. 分层能力：把需求拆成业务 Spec / 架构 Spec / 模块 Spec 三层，每层有不同的读者和验证方式（第 3 篇）
3. 判断能力：判断一个场景适不适合用 AI、哪些部分适合、哪些部分必须走规则引擎（补充篇 A）

它怎么长出来的

怎么判断自己在这个维度上到了什么程度

这个维度上最常见的错误

• 把 Spec 写成"详细版 Word 文档"。Spec 的核心不是详细，是可验证——每个字段有类型、每个接口有契约、每个验收条件可自动化
• 什么都想用 AI。规则明确、容错率低的场景（比如退款金额计算），用 if-else 更可靠、更便宜、更可解释
• 以为 Spec写完就完了。Spec 是活的——模型升级了、业务变化了，Spec 要跟着迭代。第 3 篇写的 Spec，到第 6 篇上线前至少改过三轮

维度二：方案的概率性设计能力

它是什么

这是 AI 架构师与传统架构师最根本的区别。

传统架构设计是确定性的：输入 A → 输出 B。如果输出不是 B，那是 bug。

AI 架构设计是概率性的：输入 A → 输出 B 的概率是 85%。问题不是"为什么不是 100%"，而是"85% 够不够？不够的话，兜底策略是什么？"

这个能力包含三个子能力：

1. 模型选型能力：不是比 benchmark 分数，是比 failure mode 分布——这个模型在哪些场景容易出错？出错的方式是什么？（第 4 篇）
2. 验证驱动能力：不等开发实现，先用 Dify 搭原型跑数据，拿了数据再决定技术路线（第 5 篇）
3. 系统拆分能力：单 Agent 就像一个巨大的函数——出错范围不可控。拆成多个 Agent，每个只有一个小范围可能出错（第 6 篇）

它怎么长出来的

怎么判断自己在这个维度上到了什么程度

这个维度上最常见的错误

• 用 benchmark 选模型。MMLU 高 2 分跟你的客服场景几乎没关系。选模型唯一正确的方式：用你的真实数据测
• 原型验证只跑 happy path。真正有价值的是边界场景——用户的退换货描述写错了、同一句话问了两次、App 切到后台又回来
• 多 Agent 拆分过早。单 Agent + 好的 Prompt + 好的知识库，能解决 80% 的问题。拆分增加延迟、增加故障点、增加调试复杂度。只在单 Agent 明确瓶颈时才拆
• 忘了兜底。概率性系统最怕的不是出错，是静默出错——Agent 自信地给了错误答案。每一层都要有"我不知道"的出口

维度三：系统的可观测性能力

它是什么

不是"加监控"。是设计一套让 Agent 行为可审计、可比较、可拦截的评估体系。

传统 SRE 看三个东西：CPU、内存、错误率。AI 架构师还要看三个东西：检索质量、生成质量、行为一致性。Agent 可能 CPU 很闲、内存很空、没有报错——但回答质量在静默下降。

这个能力包含三个子能力：

1. 定义"好"：什么算一次成功的对话？用户说"谢谢"就算？24h 内没有再次咨询就算？人工回访确认才算？——这个定义本身就是架构决策
2. 离线评估：建黄金测试集，每次变更跑 Ragas/TruLens，分数下降就拦截。但离线评估的分数和线上真实满意度之间的 gap，谁来监控？
3. 在线监控：Token 消耗趋势、单次对话成本、转人工率波动——不只是看绝对值，是看趋势的斜率

它怎么长出来的

EvalOps 的四层 + 一层

这个维度上最常见的错误

• 离线评估和线上数据分布不一致。测试集是上个月的产品文档，但产品文档已经更新了。测试集就像牛奶，会过期——需要定期更新
• 只设阈值，不设趋势告警。"忠实度 < 4.0 拦截"是好的，但忠实度从 4.8 连续三天降到 4.5 也应该告警——它可能比跌破 4.0 更早暴露问题
• 忘了"谁评估评估工具"。Ragas 忠实度评分本身可能不准。需要定期抽样人工复核——抽出 20 条 Ragas 评分和人工评分做对比，计算评估工具的准确率
• 成本监控缺失。Prompt 改了一句话，每次对话多传 2000 token，一个月多花 ¥800——没有人注意到

维度四：组织的采纳推动能力

它是什么

不是"写规范、推规范"。是设计一套让 AI 能力在组织中扩散而不失控的约束条件。

一个架构师自己能搭 Agent，这是维度二。让 10 个团队各自搭 Agent、各自不出事、出了问题能快速定位——这才是维度四。

这个能力包含三个子能力：

1. 段位诊断：判断一个团队在 AI 采纳的哪个阶段——不是看他们用没用 AI Coding，是看他们卡在哪个环节（需求说不清？选不对模型？拆不好 Agent？上线后没人管？）
2. 采纳路线图设计：给客户的 POC→MVP→生产框架。但这不是一个项目管理框架——每个阶段的决策点都是 AI 特有的（见下文）
3. 约束条件设计：不是规定"必须用什么工具"，是规定"无论用什么工具，上线前必须过哪几关"

给客户的采纳框架——AI 特有的决策点

重新看 POC→MVP→生产，这次不是看"做什么"，是看每个阶段的真正决策点：

POC

• 表面上在验证：这个场景 AI 能解决吗？
• 真正在验证：这个场景的不可预测性边界在哪？用户的意图是可枚举的（查订单状态、查物流、问退货政策…），还是开放的（"这个衣服适合我吗"、"推荐一个礼物"）？开放意图占比超过 30%，Agent 架构和纯意图路由完全不同
• 决策点：不是"准确率达标了吗"，是"模型的 failure mode 是你能接受的吗"

MVP

• 表面上在验证：Token 消耗、用户满意度、边界场景
• 真正在验证：failure mode 分布稳不稳定。灰度 10% 用户跑了两周，模型犯过的错里——哪些是改 Prompt 能修的、哪些需要换模型、哪些说明这个场景根本不适合 AI？
• 决策点：不是"满意度达标了吗"，是"剩下那些不满意的用户，我们有什么兜底策略"

生产

• 表面上在做：多 Agent 拆分、高可用部署、弹性伸缩、全量上线
• 真正在做：设计降级链路。模型 API 超时→返回什么？RAG 检索空→返回什么？Agent 陷入循环→怎么打断？
• 决策点：不是"系统稳不稳定"，是"每一层的兜底策略用户能不能接受"

怎么判断自己在这个维度上到了什么程度

这个维度上最常见的错误

• 把"团队用上 AI"等同于"团队变强了"。团队用 AI Coding 写代码，但写的 Spec 质量没有提升——代码生成更快了，但生成的代码还是基于模糊的输入。AI 放大了输入质量的影响：好的 Spec → 更好的代码，坏的 Spec → 更快的坏代码
• 没有退出机制。POC 跑不通？"再调调 Prompt 试试"。一个月过去了，还在调。架构师的判断力包括说"这个场景不适合 AI，我们换方案"
• 把 EvalOps 留到 L4。EvalOps 不是"组织做大以后的事"。L2 阶段就该建 50 条黄金测试集——它不需要技术平台，Excel 就能管

四维度

四个维度必须交替生长。只在一个维度上使劲，长出来的不是 AI 架构师，是四种"偏科"：

只卷维度一（需求结构化），不碰维度二（概率性设计）

→ 变成 Spec文档架构师。Spec 写得极其漂亮，三层分明，字段齐全。但从来没在 Dify 上跑过真实数据，不知道自己的 Spec 让 AI 产出了什么。问他"Qwen-Max 和 Qwen-Turbo 在你的场景上差多少"，答不上来。

只卷维度二（概率性设计），不碰维度三（可观测性）

→ 变成 调参架构师。Dify 上反复调 Prompt、换模型、改 top_k，每次调完手动测几条，"嗯，感觉好多了"。上线两周后，转人工率翻了倍，不知道从什么时候开始的，也不知道是哪次改动触发的。

只卷维度一二三（技术全能），不碰维度四（组织采纳）

→ 变成 独狼架构师。自己搭的 Agent 跑得飞起，但团队其他人不知道怎么用、不敢改、出了事只能找他。他休假那天，整个公司的 AI 能力跟着休假。

只卷维度四（组织推动），不碰维度一二三（技术落地）

→ 变成 PPT 架构师。给管理层画 AI 转型路线图，给客户讲 POC→MVP→生产，讲完让别人去落地。别人落不下去，他说"是执行力的问题"。

六个思维转变，重新解释

第 1-6 篇里发生了六次思维转变。当时是零散经历的，现在用四维模型重新看它们：

六个转变的底层是一个：执行正在被自动化，判断正在成为真正的稀缺能力。而判断的对象，从"这个设计对不对"变成了"这个系统在什么条件下会出错、概率多大、能不能接受"。

最后：回到你自己

MumuMall 只是一个案例。你手上的项目完全不同——业务不同、规模不同、技术栈不同。但这四个维度是通用的：

1. 你能把业务意图翻译成 AI 可执行的 Spec 吗？（维度一）
2. 你能设计一个可能出错但可控的 AI 系统吗？（维度二）
3. 你能证明你的系统在变好而不是在变差吗？（维度三）
4. 你能让一群人而不是你一个人做到以上三点吗？（维度四）

四个问题，按顺序问自己。哪个最早让你犹豫，那就是你当前的瓶颈。

回到第 1 篇的数据——窗口期就在现在

• 73%的架构决策已有 AI 辅助（McKinsey，2025）
• 到 2028 年，1/3 的企业软件将包含 Agentic AI（Gartner，2024 年仅 1%）
• 到 2030 年，80% 的企业将转向 AI 增强的小团队模式