从”会用 AI”到”架构 AI”：高级前端的认知升级
本文是【高级前端的 AI 架构升级之路】系列第 02 篇。 上一篇：高级前端的 AI 焦虑：你的经验到底还值不值钱 | 下一篇：AI 网关层设计：多模型路由、降级、限流、成本控制
这篇文章要解决什么
上一篇我们分析了 5 年前端的经验在 AI 时代的价值。结论是：你的架构能力和工程化思维比以前更值钱了。
但有一个前提——你需要完成一次认知升级。
大部分前端接触 AI 后，做的第一件事是：调一下 API、做个聊天界面、用 Cursor 写代码提效。这没什么问题，但这只是”用 AI”的层面。
高级前端需要到达另一个层面——“架构 AI”：AI 功能在我的系统里应该处于什么位置？怎么设计才能稳定、可控、可演进？
这两个层面的差距，不在技术细节上，而在思维模型上。
今天这篇就来聊：从前端架构师的视角看 AI 系统，需要建立哪些新的认知。
AI 不是一个”功能模块”，是一种新的系统交互范式
很多团队第一次做 AI 功能时，会把它当成一个普通功能模块来处理：
产品页面 → 调一个 AI 接口 → 把结果展示出来就像调一个翻译 API、一个地图 API 一样。写个 service 函数、做个错误处理、加个 loading 状态——前端的标准流程。
但真正做下去你会发现，AI 和传统 API 有根本性的不同：
| 传统后端 API | AI API |
|---|---|
| 确定性输出——相同输入 = 相同输出 | 概率性输出——相同输入可能得到不同结果 |
| 响应快——通常 < 200ms | 响应慢——通常 2-15 秒 |
| 成本可忽略——服务器资源 | 按 token 计费——每次调用都有真实成本 |
| 失败即失败——报错 or 成功 | 部分正确——可能回答了但答非所问 |
| 固定格式——JSON Schema 约束 | 格式不稳定——AI 可能输出意料之外的格式 |
| 无状态——每次请求独立 | 上下文依赖——对话历史影响输出质量 |
这些差异不是小细节——它们改变了你设计系统时的基本假设。
举个具体例子
假设你在做一个”AI 自动生成商品描述”的功能。
如果按传统思路：前端发商品信息 → 后端调 AI → 返回描述 → 前端展示。
上线后你会遇到这些问题：
- AI 有时候输出质量很差——怎么办？不能直接展示给用户吧？需要一个质量检测层。
- 同一个商品调两次，描述完全不一样——PM 说”每次点都不一样，用户会困惑”。需要缓存策略。
- 高峰期每秒几百个请求，Token 费用飙升——需要成本控制和限流。
- AI 偶尔输出敏感内容——需要内容审核层。
- 用户觉得等 5 秒太久——需要流式输出或预生成。
你看，一个”调 API 展示结果”的功能，在生产环境中展开后，变成了一个需要缓存、审核、限流、降级、监控的完整系统。
这就是 AI 和传统功能模块的根本区别——它引入了太多不确定性，需要从系统层面去应对。
四个需要重新理解的概念
从前端架构师转向 AI 架构，有四个概念需要你重新建立认知。
1. 非确定性系统
前端和后端的系统都是确定性的：点击按钮 → 发请求 → 得到固定结果。你的整个架构思维都建立在这个基础上——组件是确定性的（给定 props 渲染确定 UI）、状态管理是确定性的（dispatch action → 确定的新 state）。
AI 打破了这个基础。同一个输入，每次输出可能不同。
这意味着什么？
- 不能用传统快照测试——每次输出不同，测试怎么写？需要用”评估”（Evaluation）代替”断言”（Assertion）。
- UI 需要弹性设计——AI 输出长度不可预测，可能 10 个字也可能 2000 个字。你的界面布局必须能 handle 这种不确定性。
- 缓存策略不同——传统 API 相同入参可以直接用缓存。AI 接口是否该缓存？缓存多久？取决于场景。
2. 延迟敏感
前端开发者对延迟是有感知的——你知道 API 响应超过 300ms 用户就开始不耐烦。但 AI API 的延迟不是 300ms，是 3-15 秒。
这不是”优化一下就能解决”的问题，而是一个架构级的约束。你需要从一开始就围绕”高延迟”来设计：
- 流式输出是标配，不是可选项
- 乐观更新——能预测的部分先展示，AI 结果后补
- 预生成——用户可能需要的内容，提前异步生成好
- 渐进增强——先给快速结果（规则/缓存），后台跑 AI 慢慢替换
这些策略你在做前端性能优化时都用过（骨架屏、SSR、预加载），只是要用在新场景里。
3. 成本弹性
前端以前不太需要关心”调一次接口多少钱”。但 AI 时代，每一次 API 调用都在花真金白银。
GPT-4o 一次复杂对话的成本约 $0.01-0.05。看似不多，但如果你的产品每天有 10 万次 AI 交互，那就是 $1,000-5,000/天，一年百万美金级别的 AI API 费用。
这意味着架构设计时必须考虑：
- 模型分级——简单任务用便宜模型，复杂任务才上贵的
- Token 预算——每个用户/每个功能/每天的 Token 上限
- 缓存复用——相似请求是否可以复用之前的结果
- 批量处理——非实时需求攒一攒批量调用更便宜
前端要做的事也不少：显示用量统计、实现付费引导、做功能门控（免费用户限制 AI 次数）。
4. 输出质量不可控
调传统 API，你可以信任后端返回的数据是对的（如果不对，那是 Bug）。但 AI 的输出，你不能完全信任。
AI 可能：
- 答非所问——你问 A 它聊 B
- 编造事实——即”幻觉”（Hallucination）
- 格式错误——你要 JSON 它给你 Markdown
- 输出敏感内容——政治、色情、暴力等
这要求你在架构中加入一个**“AI 输出不一定对”的假设**，并设计相应的防护层：
- 输出格式校验（JSON Schema 验证）
- 内容审核（关键词过滤 + AI 审核）
- 人工审批（高风险操作需要人确认）
- 兜底方案（AI 失败时的降级策略）
从前端架构师视角看 AI 系统
既然你是前端架构师，我们用你熟悉的概念来类比，看看 AI 架构和你以前做的事有什么相似和不同。
像组件化，但更不确定
组件化的核心是封装和抽象：给定 props → 确定的 UI。你把复杂度封装在组件内部，外部通过接口交互。
AI 模块的封装思路类似：把 AI 调用封装成内部的黑盒，对外暴露确定的接口。但区别在于——盒子里面是不确定的。
传统组件: Input(props) → 确定的 Output
AI 模块: Input(prompt + context) → 不确定的 Output → 后处理 → 相对确定的 Output你需要在 AI 模块外面包一层”稳定层”——格式校验、重试、降级、默认值——让外部调用者感知到的是一个相对稳定的接口。
像微前端，但是资源共享的
微前端的核心问题是隔离和集成——多个子应用如何独立开发、统一部署。
AI 架构面临类似的问题：一个产品里可能有 5 个不同的 AI 功能（聊天、搜索、推荐、内容生成、代码辅助），它们：
- 共享 AI 网关（统一的模型调用入口）
- 共享 Prompt 配置中心（集中管理所有 Prompt）
- 共享成本预算（全公司的 Token 额度）
- 但各自有独立的业务逻辑和质量要求
这很像微前端里”共享基础设施 + 独立业务域”的架构模式。
像状态管理，但复杂 10 倍
前端的状态管理已经够复杂了——异步请求、乐观更新、缓存失效、跨组件通信。
AI 场景下的状态更复杂：
- 流式状态——回复还在生成中，状态在持续变化
- 分支对话——用户在第 3 轮修改了问题，后续回复全部失效
- 多 Agent 状态——3 个 AI 同时工作，各自有独立进度
- 可中断——用户随时可以”停止生成”
- 上下文窗口——对话太长时要压缩/裁剪历史
传统的 Redux/Pinia 方案 handle 不了这些。你需要设计 AI 专用的状态管理方案——这也是后面几篇会详细展开的内容。
技术选型心智模型：什么该用 AI、什么不该用
高级前端的一个核心能力是”知道什么不做”。在 AI 场景中，这个能力更加重要。
我用一个 2x2 矩阵来帮你判断：
AI 效果好
│
┌───────────────┼───────────────┐
│ │ │
│ ③ 谨慎用 │ ① 优先用 │
│ 效果好但贵 │ 效果好且值 │
成本高 ├───────────────┼───────────────┤ 成本低
│ │ │
│ ④ 不要用 │ ② 可以用 │
│ 又贵效果差 │ 便宜但效果一般│
│ │ │
└───────────────┼───────────────┘
│
AI 效果差① 优先用 AI（效果好 + 成本可控）：
- 内容生成（文案、摘要、翻译）
- 代码辅助（Review、补全、解释）
- 智能搜索（语义搜索 + 结果整理）
② 可以用 AI（成本低但效果一般，做为辅助）：
- 意图识别（用户想做什么？分类一下）
- 简单问答（FAQ 类，结合知识库）
③ 谨慎用 AI（效果好但成本高，需要 ROI 分析）：
- 复杂推理（多步骤分析、方案生成）
- 多模态处理（图片理解、文档解析）
④ 不要用 AI（效果差且成本高，用规则更靠谱）：
- 精确计算（数学运算、财务计算）
- 确定性流程（审批流、状态机）
- 实时性要求极高的场景（< 100ms 响应）
每一个 AI 功能上线前，都应该过一遍这个矩阵。
一个实际案例：我的架构决策过程
分享一个我在实际项目中的决策过程，帮你感受一下”架构 AI”和”用 AI”的区别。
需求：在内部管理系统中加入 AI 聊天助手，帮员工查询业务数据和操作流程。
“用 AI”的思路： 接一个 OpenAI API → 做个聊天界面 → 把系统文档丢给 AI 做 RAG → 上线。
“架构 AI”的思路：
- 模型选型：日常问答用 DeepSeek（便宜快速），涉及复杂数据分析时自动升级到 GPT-4o。
- 知识来源设计：静态文档 → 向量化 RAG；实时业务数据 → Tool Calling 对接数据库 API。
- 安全边界：AI 只能查数据，不能改数据。涉及敏感数据（薪资、客户信息）需要权限校验。
- 成本控制：每人每天 50 次对话上限，超限提示”请联系管理员”。
- 降级策略：AI 服务不可用时，自动降级为关键词搜索 + FAQ 匹配。
- 可观测性：记录每次对话的 Token 消耗、响应时间、用户满意度，用于持续优化。
- 前端体验：流式输出、打字机效果、Thinking UI 展示 AI 正在查询哪些数据源、支持”停止生成”。
两种思路的产出物完全不同。第一种是一个 Demo 级的聊天工具，第二种是一个可以在生产环境长期运行的 AI 系统。
总结
- AI 不是一个普通功能模块，它引入了非确定性、高延迟、按次计费、输出不可信等新约束，需要从系统层面设计。
- 四个新认知：非确定性系统（测试变评估）、延迟敏感（流式为标配）、成本弹性（Token 预算）、输出质量不可控（防护层必备）。
- 前端架构经验可以迁移：组件化 → AI 模块封装、微前端 → AI 功能集成、状态管理 → AI 状态方案。
- 用 2x2 矩阵判断什么该用 AI、什么不该——效果 × 成本。
- “用 AI”和”架构 AI”的差距不在技术细节，而在是否考虑了降级、成本、安全、可观测性等生产级需求。
从下一篇开始，我们进入实战——第一个主题是每个 AI 系统都需要的核心基础设施：AI 网关层。
讨论话题：你在项目中做过 AI 功能吗？是”调 API 展示结果”的模式，还是有完整的架构设计？遇到过哪些”用着用着才发现”的坑？评论区分享一下。