AI 系统架构

AI 系统架构：给产品经理的四层地图

面试官问："你负责的 AI 系统长什么样？"——你只答得出"接了一个大模型 API"吗？

或者拿到"给客服做一个 AI 助手"的需求，你能不能说清：这个方案落地要动哪些层？每层要花多少钱？哪些层是团队还没想清楚的？

回答这些问题，你需要一张四层地图：业务、应用、技术、数据。每一层回答不同的问题，产品经理在每一层有不同的动作：

• 业务层：为什么做、值不值
• 应用层：用户怎么用、越界怎么办
• 技术层：模型怎么跑、怎么不翻车
• 数据层：燃料从哪来、合不合规

本文把这张地图给你，并教你怎么用它。它有三个典型使用时刻：

• 讲清系统：面试或汇报时，用四层描述你负责的 AI 系统
• 判断落地：拿到一个新 AI 方案，快速判断要动哪些层、哪些层没想清楚
• 体检找薄弱：对现有产品逐层过一遍，找出最薄弱的层

为什么 PM 要懂架构

架构不是技术同学的专利。不懂架构的 PM，会在三个时刻吃瘪：

• 可行性：拍脑袋要"AI 自动生成周报"，技术层却告诉你私有化部署的模型做不到——你需要在立项前就判断技术层能不能做
• 成本：同样功能，用大模型 API 一个月几万块，还是微调小模型更划算？成本由每一层的选择决定，而选择需要 PM 参与
• 演进：上线三个月后要"加一个场景"，动哪一层？要"换更强的模型"，又动哪一层？没有地图，每次改动都是盲盒
• 沟通：跟工程师聊需求，你说"用户体验"，他说"参数规模"，中间缺的就是分层语言——四层是 PM 与技术的共同词汇

一个常用的类比：像盖楼。

地基不牢，楼再漂亮也会塌；但"住人"才是盖楼的目的。四层都重要，只是 PM 参与的方式不同。

四层地图

1. 业务架构：AI 嵌入在哪里

它是什么：AI 能力如何嵌入业务流程与价值链——在哪个环节取代人、在哪个环节增强人。它回答"这个 AI 用在流程哪一步、省了什么、如何量化"。

PM 的动作：

• 选场景：挑价值链上最痛、数据最多、容错率最高的环节切入
• 定义业务指标：不是"回答准确率"，而是"工单平均处理时长下降多少"
• 算投入产出：人力节省 × 单价 vs 模型调用成本——ROI 算不清，项目立不住

典型问题："客服 80% 的工单是重复咨询，AI 放在自动回答环节，能省多少人力？"

典型案例：

• 客服：工单路由（判断转给哪个组）、回复建议（增强人工）、自动解决（取代人工）
• 营销：文案生成（增强）、投放策略（增强）、A/B 优化（取代人工试错）

常见误区：把 AI 当万能胶，想一次替代所有人工环节。正确姿势是从一个成本最高、路径最清晰的环节切入，跑通再扩。

2. 应用架构：用户看到什么

它是什么：用户接触的层——交互形态、能力编排、护栏三件套。

• 交互形态：对话、画布、Agent……不同形态决定用户的心智模型
• 能力编排：模型调用、工具调用、Agent 流程，决定 AI 能完成多复杂的任务
• 护栏：内容审核、兜底话术、限流与降级，决定 AI 越界时怎么办

PM 的动作：定义交互与能力边界、错误路径、控制权设计——用户何时接管、AI 何时让位。怎么设计 Agent 产品、怎么做全生命周期管理，见 Agent 产品 与 AI 产品开发生命周期（CC/CD）。

典型问题："用户看到什么、AI 越界了怎么办？"——没有护栏的 AI 客服，会在用户骂人时对骂回去。

常见误区：只堆交互功能，不设护栏。护栏不是上线前补的"安全措施"，而是交互设计的一部分——它决定 AI 的失败方式，而失败方式是用户体验。

3. 技术架构：模型怎么跑

它是什么：模型层（API / 微调 / 开源部署）+ 推理服务（延迟 / 吞吐 / 成本）+ 评测与监控（评测集 / 线上指标 / 回滚）。

PM 的动作：

• 模型选型：能力 × 成本 × 延迟的三角权衡，怎么挑 API 见 模型 API 选择
• 评测体系建设：没有评测集就换模型，等于闭眼开车，见 评估与评测
• 回滚预案：新模型上线翻车，能不能 5 分钟退回旧版本？

典型问题："换模型影响什么？"——不止效果，还有延迟、单价、评测集重跑、提示词重调。

常见误区：只盯模型能力榜单，不看延迟与成本。榜单第一的模型不一定是你这个产品的最优解——能力、成本、延迟永远三者权衡。

4. 数据架构：燃料从哪里来

它是什么：训练 / 评测 / 反馈数据闭环 + 知识库（私有知识怎么注入，见 RAG）+ 隐私脱敏与合规。

PM 的动作：

• 定义数据采集与标注需求：什么数据值得标、谁来标、标准是什么
• 设计数据飞轮：用户行为 → 发现失败案例 → 回填评测集 → 改进模型 → 更好的用户行为
• 合规前置：数据从哪来、能用吗、脱敏了吗——见 合规

典型问题："数据从哪来、怎么闭环、合规吗？"——很多 AI 项目死在"想用数据时发现没存"，或"合规没过、上线被叫停"。

常见误区：上线后再补数据。数据采集通道要从产品第一天就设计好——用户行为不记录，飞轮就永远转不起来。

四层关系与 PM 的抓手

四层不是四个孤立的抽屉，而是相互咬合的系统。下面这张表把每层的核心问题、PM 的抓手和站内延伸页汇总在一起，可以当速查卡用：

两个关系要点，记住它们能省很多会议：

• 上层（业务）定方向，下层（技术、数据）定成本与上限：业务层决定做什么，但技术层决定能不能做，数据层决定能做多好。方向再对，下层不给力也落不了地——这也是 AI 项目常见"业务画饼、技术背锅"的根源
• 改产品时从上层往下找影响，评估时从下层往上找风险：加一个新场景，先看业务层影响，再顺藤摸瓜看应用、技术、数据要动什么；反过来评估一个方案，先查数据合规与技术可行性，风险从下层往上层排查

典型 AI 产品的分层速览：AI 客服

用一个例子把四层串起来——AI 客服：

1. 业务架构：客服是成本中心，目标是降本（自动解决率）与体验（响应时长）；AI 放在"自动回答 → 解决不了转人工"的流程环节
2. 应用架构：对话窗口 + 工单流转 + 人工接管按钮；护栏包括敏感内容拦截、兜底话术（转人工）、限流
3. 技术架构：API 大模型 + 评测集（拿历史工单建种子集）+ 线上指标（自动解决率、转人工率、投诉率）+ 回滚预案
4. 数据架构：历史工单做 RAG 知识库；用户点踩、转人工等行为回填错误案例，形成回答与路由的修正闭环；数据脱敏后再用

看，一个"接个大模型 API"的需求，实际是四个层的系统工程。哪一层没想清楚，上线就会在哪一层出问题。

收尾

现在再看你负责的 AI 系统：能画出哪一层最薄弱吗？如果画不出来，本文开头的面试问题你可能还答不好——四层地图不是考试知识，是开工前的检查清单。

记住这个顺序：向上定方向（业务），向下定成本（技术、数据），中间的应用层是 PM 的主战场。四层没有哪层"不重要"，只有哪层"没想到"。

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用