[AI架构师转型系列-4] 架构师需要掌握的AI方案能力

本篇你将学到：

• 帮客户做模型选型——不只比准确率和价格，还要考虑多模型组合、降级策略、上下文窗口管理
• 算 Token 成本——不止显性的推理费用，还有缓存策略、隐性成本、多 Agent 成本归属
• 建立 AI Coding 工具的选型方法——不是帮团队钦定某个工具，是教会怎么评估和实测
• 部署平台的选择逻辑——原型到生产的演进路径，以及什么时候该换引擎
• 把客户的焦虑转化成可执行的采纳路线图

前三篇讲了什么？用 AI 做需求澄清、用结构化三层法写方案、用 AI 画架构图。这三件事都围绕一个核心——架构师自己的工作方式怎么变。

但从这篇开始，视角要转了。

客户不会问你"你方案怎么写的"。客户问你的是："我们团队适不适合上 AI？用哪个模型？花多少钱？数据安全怎么办？"

架构师在 AI 时代的第二个核心能力，不是自己怎么用 AI，是帮客户判断怎么采纳 AI。这篇文章就用 MumuMall 这个真实场景，把架构师要回答的问题一个一个拆开。

第一问：模型选哪个——Qwen、DeepSeek，还是别的？

MumuMall 的智能客服需要一个大模型。选哪个？

架构师不能只说"ChatGPT 最好"，也不能只说"国产化必须用国产模型"。客户要的是有依据的对比。

云端 API vs 私有化部署

这是第一个决策分叉。两种路线，差异巨大：

MumuMall 的场景怎么选？日均 5000 次咨询，每次咨询约 3 轮对话，每轮约 2000 Token（输入 + 输出）。一天 3000 万 Token，一个月约 9 亿 Token。

算一笔账：

• 云端 API（Qwen-Max）：9 亿 Token × ¥0.04/1K = ¥3,600/月
• 私有化部署（一台 A10 GPU 服务器）：硬件约 ¥8 万（一次性），电费 + 运维 ¥2,000/月

结论：MumuMall 日均 5000 次咨询的场景，云端 API 明显更划算。但如果日调用量超过 10 万次，或者 MumuMall 要求用户数据不能离开内网，私有化就变成必选项。

这是架构师的判断——不是"哪个模型好"，是"你的场景应该选哪个"。

几个主流模型的实际表现

选模型之前，先搞清楚哪些模型适合客服场景。拿 MumuMall 实际 FAQ 做一组对比测试：

测试方式和结果：

取 MumuMall 20 条真实 FAQ（退换货政策、物流查询、促销规则、生鲜售后），每条用同一 Prompt 测试五个模型的回答准确性、完整性、是否产生幻觉。

MumuMall 的选择逻辑：

• 如果追求性价比且能接受云端：DeepSeek-V3。成本是 Qwen-Max 的 1/20，准确率仅差 2 个百分点
• 如果要求数据不能离开内网 + 预算有限：Qwen2.5-7B + Ollama。一台 T4 服务器不到 3 万，客服场景够用。但准确率只有 80%——需要更完善的 RAG 和人工兜底
• 如果追求最佳中文效果且预算充裕：Qwen-Max。92% 准确率 + 开箱即用的阿里云生态

架构师的价值不是"推荐哪个模型"，是告诉客户 "你的场景下，这个模型的优势和代价是什么"。

思考题：选模型没这么简单

上面给出了清晰的对比和结论，但真实场景往往更复杂。以下几个问题没有标准答案，值得你在做选型决策前想一想：

1. 该用单一模型还是多模型组合？

智能客服的四个环节——意图判断、知识检索排序、回答生成、转人工判断——对模型的要求完全不同。意图判断需要快（延迟 < 500ms），对推理深度要求低；回答生成需要准，对延迟容忍度高一些。一个思路是：意图判断用便宜的轻量模型（如 Qwen2.5-7B），回答生成用强模型（如 Qwen-Max 或 DeepSeek-V3）。

问题是：多模型组合增加了系统复杂度。模型之间的切换逻辑怎么写？意图判断错了导致路由到错误的下游模型，谁来兜底？什么时候该拆多模型、什么时候老老实实用一个模型？怎么判断拆的收益是否大于复杂度的成本？

2. 模型挂了或超时，是降级还是直接转人工？

云端 API 不是 100% 可用。大促峰值流量翻 5 倍时，API 可能限流甚至拒绝服务。架构师需要提前设计降级策略：备选模型（主用 Qwen-Max，备用 DeepSeek-V3）？还是直接转人工？降级时用户能感知到吗——前一个问题 AI 还回答得好好的，下一个问题突然变笨了？

这个决策的关键变量是什么？是业务对延迟的容忍度？还是对回答质量的一致性要求？

3. 长对话的上下文窗口怎么管？

MumuMall 的客服对话不会永远是 3 轮。用户反复追问退换货细节、来回确认地址、退款金额谈不拢——对话可能拖到 10 轮以上。每轮对话都在往上下文窗口里塞东西。塞太少吃不准用户意图，塞太多 Token 费用暴涨。什么时候截断旧对话？用什么策略截断——按轮次截断、按语义摘要、还是两者结合？

4. 模型版本升级，你跟还是不跟？

云端模型的版本不受你控制。厂商升级模型后，你的 Prompt 可能突然表现不同——同一个 Prompt，新版本模型的理解方式可能变了。锁版本会牺牲能力提升和厂商的安全修复；不锁版本，每次升级都可能悄悄改变你的系统行为。

这个问题没有技术解法，它是一个流程问题：你怎么发现模型版本变了？怎么测出新版本对现有 Prompt 的影响？谁来负责这件事？

第二问：AI Coding 工具怎么选

MumuMall 的团队也要用 AI Coding。架构师的职责不是钦定某个工具，是建立一套选型评估方法，让团队不同角色选到适合自己的工具。

选工具之前，先问三个问题

第一个问题：谁在用？

不同角色对 AI Coding 的需求完全不同。开发者要的是补全快、调试准、语言生态好。架构师要的是方案生成能力强、能理解复杂的架构描述、评审意见有深度。产品经理要的是能把 PRD 快速变成可交互原型。

一句话：不是选一个"最好的工具"，是让每个人用上"最适合自己角色"的工具。架构师和开发者不需要统一工具。统一工具反而限制效率。

第二个问题：数据流向哪里？

这是最容易踩的坑，也是客户最关心的合规问题。选工具之前，必须搞清楚：你的代码和 Prompt 经过谁的服务器？有没有可能被用于模型训练？

判断框架很简单：如果一个项目涉及核心业务逻辑、客户数据、或合同约束的数据不出境条款，优先选数据在国内处理的工具。如果是开源项目或非敏感的内部工具，数据合规约束就宽松得多。

第三个问题：团队现状能承受多大的切换成本？

一个新工具再好，如果团队要花两周上手、打断正在进行的迭代，就不值得立刻切换。评估切换成本看三样：现有工作流能不能兼容？团队有多少人已经用熟了某个工具？迁移后第一个迭代会不会明显变慢？

评估方法：不是看榜单，是拿自己的任务实测

市面上的工具对比榜单每天都在变。今天 A 比 B 强，下周版本更新可能就反过来了。榜单是别人的结论，不是你的判断。

架构师应该做的事：拿自己团队的真实任务，去测两到三个备选工具，记录实测结果，再做决策。

就三件事：

1. 挑一个典型任务——比如"给智能客服的工单查询模块写接口定义"或"把上篇写的业务方案生成代码骨架"
2. 在两个候选工具上跑同一个任务，对比产出质量、理解偏差、需要人工改动的量
3. 拉上团队里最抗拒换工具的那个人一起测——他如果觉得好用，推广阻力就小了一大半

实测花不了半天。但测完之后，你做的是自己的判断，不是转发别人的结论。架构师的信誉来自判断力，判断力来自亲手验证。

思考题：工具选完只是开始

工具选型只是第一步。真正麻烦的问题出现在工具落地之后：

1. AI 生成的代码，验收标准跟人写的能一样吗？

人写的代码，架构师 Code Review 有成熟的 Checklist：命名规范、错误处理、性能隐患、安全漏洞。AI 生成的代码，还得多看一样——AI 有没有"自作主张"？比如你让它写一个工单查询接口，它自作聪明加了一个"自动关闭工单"的逻辑，代码质量很高，但做的事不是你让它做的。

这不是 bug，是偏差。审人写的代码是"查漏补缺"，审 AI 写的代码是"查伪造"。Code Review 的工作量到底是升了还是降了？有没有办法让 AI 生成代码时主动标记"这里我做了超出指令范围的设计决策"？

2. 团队规范怎么变成 AI 的"肌肉记忆"？

AGENTS.md 或 .cursorrules 这类项目级指令文件，是架构师把团队规范嵌入 AI 工作流的核心手段。但规范写到多细才算够？太粗，AI 理解偏差大；太细，指令文件变成没人维护的过时文档——跟传统 Wiki 一样的宿命。

一个思考方向：规范不是写一次就完事的，它应该随 AI 的实际产出持续迭代。架构师 Review AI 生成的代码时，发现的每类重复性偏差，都应该回写进规则文件。这不是技术问题，是"谁来维护、多长时间维护一次"的流程问题。你团队里有这个人吗？

第三问：Token 会花多少——成本预估

客户最关心的是钱。架构师不能回答"看情况"，要给有依据的预估。

MumuMall 智能客服 Token 消耗预估

假设：日均 5000 次咨询，每次 3 轮对话。每轮包含意图判断（200 Token）+ 知识检索（500 Token）+ 回答生成（800 Token）+ 可能的改写（200 Token）。

单次咨询：

月度成本 = 5000 × 30 × 4680 = 7.02 亿 Token/月

这张表给客户看，决策就清楚了。

• 预算极紧、接受 80% 准确率 → Qwen2.5-7B 自建，月费 ¥1,000
• 追求性价比 → DeepSeek-V3，月费 ¥140，简直不要钱
• 数据不能出国、预算中等 → Qwen-Max 云端或 Qwen2.5-72B 自建
• 数据不能出国、追求最佳 → Qwen-Max

注意：DeepSeek-V3 虽然便宜，但调用走的是 DeepSeek 官方 API，数据经其服务器。如果 MumuMall 的用户数据不能给第三方，这个选项直接排除——不是技术问题，是合规问题。

思考题：算清楚 Token 账，才算到一半

上面的预估是一个理想化的线性模型。真实世界的成本结构比这复杂得多：

1. 缓存能省多少钱，值得多少复杂度？

System Prompt（角色设定、输出规范、安全边界）每次对话都原样发给模型，这部分 Token 完全是重复消费。LLM 厂商普遍支持 Prompt 缓存——缓存的 Token 按原价 10%-30% 计费。但缓存有规则：必须放在 Prompt 的最前面、内容必须逐字符完全一致、命中有概率性。

架构师的决策不是"要不要开缓存"，是：System Prompt 写多长才划算？太长，命中的那部分便宜了，但挤占了对话上下文；太短，AI 行为约束不够。而且缓存策略会影响 Prompt 的迭代方式——你不敢随便改 System Prompt，每次改动都会清空缓存。稳定性 vs 灵活性，怎么取舍？

2. "隐性成本"可能超过推理成本

Token 费用是最显眼的。显眼之外，还有一笔账容易被忽略：

• RAG 知识库的存储和检索成本。Elasticsearch 实例、向量数据库、OSS 存储——它们按实例规格或存储量收费，不按调用量。但它们是 AI 系统能跑的前提
• 日志和可观测数据的存储成本。Agent 的推理链、每次 Tool 调用、Token 消耗明细——这些数据要存下来才能做质量分析和故障排查，存得越多越贵
• 模型评测的 Token 消耗。每次换 Prompt、换模型、上线新功能，你都要跑一轮评测——评测本身也在消耗 Token

一个经验数字：隐性成本往往占到推理成本的 30%-50%。给客户报的 ¥5,000/月，上生产可能变成 ¥7,500。架构师如果只报 Token 费用、不提隐性成本，生产阶段客户看到账单会回来找你。

3. 多 Agent 系统里，成本怎么拆？

智能客服是四个 Agent 协作——Orchestrator 做意图判断，Knowledge Agent 做知识检索，Ticket Agent 管工单，Escalation Agent 管转人工。一次用户对话可能走 2 个 Agent，也可能走 4 个。账单上只有一笔：调了 LLM 多少次、花了多少 Token。

但客户想知道的是：我的钱花在哪了？是花在回答生成上（产生价值），还是花在意图判断上（产生开销）？还是花在改写——Agent 第一次没搜到，换个关键词重新搜——这些 Token 完全是浪费？

成本不拆清楚，你就没办法回答"这个 AI 系统值不值得继续花钱"。架构师不只是算总账的人，是设计成本归属模型的人。

第四问：Dify 怎么部署

MumuMall 用 Dify 做原型验证（下一篇会展开）。架构师要先设计 Dify 的部署方案。

三种部署方式：

MumuMall 的推荐路径：

• 原型阶段 → Dify Cloud。零成本，当天就能演示
• MVP 阶段 → Docker 自建（ECS 单机）。数据不出公司，¥200/月
• 生产阶段 → Docker 自建（高可用）。配合阿里云 RDS + Redis，多实例部署

为什么不用 Dify Cloud 直上生产？因为 MumuMall 的用户对话数据包含手机号和订单信息。Dify Cloud 的数据存储在 Dify 服务器上——数据合规上是风险点。到生产阶段，必须切到自建。

思考题：选平台不是终点，换平台才是真正的考验

1. 从原型到生产，同一个平台一路走到底吗？

上面的推荐路径是 Dify Cloud → Docker 自建单机 → Docker 自建高可用。看起来是同一个平台的三个版本。但真实情况很可能是：原型阶段用 Dify Cloud 验证的是对话流设计——Agent 编排逻辑对不对、知识库检索效果好不好。验证通过后，生产阶段发现 Dify 自建高可用虽然架起来了，但它的版本升级策略、审批流程、权限体系跟公司现有的 CI/CD 体系接不上。

这个时候要不要换引擎？把编排逻辑从 Dify 迁移到 LangChain 或 Agent SDK，不是简单的"导出配置、重新导入"。编排流的DAG 结构、Prompt 模板的变量语法、Tool 注册方式——每个平台都不一样。架构师在原型阶段就要为这件事留后手：原型验证的产出物，能不能不绑定平台？

2. Dify 的自动编排（AI 生成工作流），你信多少？

Dify 支持"一句话生成工作流"——你描述业务逻辑，它自动画出 Agent 节点和连线。省时间，但生成的编排逻辑是一个黑箱。开发拿到这个编排流，没人能说清"为什么第三步之后是第四步，而不是第五步"。

编排和代码一样，可读性比"能跑"更重要。你愿意为可维护性牺牲多少生成效率？架构师怎么在"AI 快速生成"和"人类可维护"之间画一条线？

第五问：客户最焦虑的三个问题

和客户交流时，你会发现他们不是来学技术的。他们来是因为焦虑。架构师的价值不是消除焦虑，是把焦虑变成可执行的步骤。

焦虑一："AI 会不会让我的团队失业？"

回答：不会。但会让不用 AI 的团队失去竞争力。

给客户一个简单的判断框架：

• 重复性工作（写文档、做表格、回固定话术）→ AI 替代，让人做更有价值的事
• 判断性工作（方案设计、风险识别、技术选型）→ AI 辅助，人做最终决策
• 创造性工作（产品定位、用户体验、商业策略）→ AI 提供信息，人主导

焦虑二："我们数据安全怎么办？"

回答：分层处理。

焦虑三："从哪开始？花多少钱？"

回答：三步走，每步有明确成本。

客户需要的不只是技术方案，是从"现在什么都不懂"到"花多少钱、什么时候上线"的路线图。这是架构师的新核心能力。

这一篇的核心

架构师在 AI 时代的第二个能力跃迁：从**"自己怎么用 AI"升级到"帮客户判断怎么采纳 AI"**。

五个问题，架构师必须能回答——但每个问题往下挖一层：

1. 模型选哪个——不是"哪个最好"，是"你的场景下，哪个最合适、花多少钱"。往下挖：该不该用多模型组合？模型挂了怎么降级？长对话上下文窗口怎么管？版本升级跟不跟？
2. AI Coding 怎么选——不是替团队钦定工具，是建立选型方法：谁在用、数据流向哪里、切换成本多大。往下挖：AI 生成的代码谁来审、怎么审？团队规范怎么嵌入工具变成"肌肉记忆"？
3. Token 花多少——有计算公式，有月度预估，有成本对比。往下挖：缓存策略的经济账、隐性成本的占比、多 Agent 系统的成本归属——谁为"AI 废话太多"买单？
4. 部署平台怎么演进——原型用 Cloud、生产切自建，每个阶段有明确成本。往下挖：原型验证完发现平台不适合生产怎么办？编排逻辑能不能不绑定平台？AI 自动生成的编排可维护性够不够？
5. 客户焦虑怎么解——不是消除焦虑，是把焦虑变成可执行的 POC→MVP→生产三步路线图

每个问题都有一层"标准答案"，一层"往下追问"。标准答案够你通过评审会，往下追问的答案够你成为客户信任的那个人。

下一篇：选型做完了，方案设计完了。下一步不是动手写代码——是在 Dify 上 10 分钟搭一个原型，验证模型选型对不对、Token 预估准不准、编排逻辑通不通。验证完了再决定要不要用 LangChain 做生产级定制。