从"会用 AI"到"架构 AI"：高级前端的认知升级

从"会用 AI"到"架构 AI"：高级前端的认知升级

这篇文章要解决什么

上一篇我们分析了 5 年前端的经验在 AI 时代的价值。结论是：你的架构能力和工程化思维比以前更值钱了。

但有一个前提——你需要完成一次认知升级。

大部分前端接触 AI 后，做的第一件事是：调一下 API、做个聊天界面、用 Cursor 写代码提效。这没什么问题，但这只是"用 AI"的层面。

高级前端需要到达另一个层面——"架构 AI"：AI 功能在我的系统里应该处于什么位置？怎么设计才能稳定、可控、可演进？

这两个层面的差距，不在技术细节上，而在思维模型上。

今天这篇就来聊：从前端架构师的视角看 AI 系统，需要建立哪些新的认知。

AI 不是一个"功能模块"，是一种新的系统交互范式

很多团队第一次做 AI 功能时，会把它当成一个普通功能模块来处理：

产品页面 → 调一个 AI 接口 → 把结果展示出来

就像调一个翻译 API、一个地图 API 一样。写个 service 函数、做个错误处理、加个 loading 状态——前端的标准流程。

但真正做下去你会发现，AI 和传统 API 有根本性的不同：

这些差异不是小细节——它们改变了你设计系统时的基本假设。

举个具体例子

假设你在做一个"AI 自动生成商品描述"的功能。

如果按传统思路：前端发商品信息 → 后端调 AI → 返回描述 → 前端展示。

上线后你会遇到这些问题：

1. AI 有时候输出质量很差——怎么办？不能直接展示给用户吧？需要一个质量检测层。
2. 同一个商品调两次，描述完全不一样——PM 说"每次点都不一样，用户会困惑"。需要缓存策略。
3. 高峰期每秒几百个请求，Token 费用飙升——需要成本控制和限流。
4. AI 偶尔输出敏感内容——需要内容审核层。
5. 用户觉得等 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\text{。看似不多，但如果你的产品每天有}10\text{万次}AI\text{交互，那就是}$1,000-5,000/天，一年百万美金级别的 AI API 费用。

这意味着架构设计时必须考虑：

• 模型分级——简单任务用便宜模型，复杂任务才上贵的
• Token 预算——每个用户/每个功能/每天的 Token 上限
• 缓存复用——相似请求是否可以复用之前的结果
• 批量处理——非实时需求攒一攒批量调用更便宜

前端要做的事也不少：显示用量统计、实现付费引导、做功能门控（免费用户限制 AI 次数）。

4. 输出质量不可控

调传统 API，你可以信任后端返回的数据是对的（如果不对，那是 Bug）。但 AI 的输出，你不能完全信任。

AI 可能：

• 答非所问——你问 A 它聊 B
• 编造事实——即"幻觉"（Hallucination）
• 格式错误——你要 JSON 它给你 Markdown
• 输出敏感内容——z治、瑟琴、暴力等

这要求你在架构中加入一个**"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"的思路：

1. 模型选型：日常问答用 DeepSeek（便宜快速），涉及复杂数据分析时自动升级到 GPT-4o。
2. 知识来源设计：静态文档 → 向量化 RAG；实时业务数据 → Tool Calling 对接数据库 API。
3. 安全边界：AI 只能查数据，不能改数据。涉及敏感数据（薪资、客户信息）需要权限校验。
4. 成本控制：每人每天 50 次对话上限，超限提示"请联系管理员"。
5. 降级策略：AI 服务不可用时，自动降级为关键词搜索 + FAQ 匹配。
6. 可观测性：记录每次对话的 Token 消耗、响应时间、用户满意度，用于持续优化。
7. 前端体验：流式输出、打字机效果、Thinking UI 展示 AI 正在查询哪些数据源、支持"停止生成"。

两种思路的产出物完全不同。第一种是一个 Demo 级的聊天工具，第二种是一个可以在生产环境长期运行的 AI 系统。

总结

1. AI 不是一个普通功能模块，它引入了非确定性、高延迟、按次计费、输出不可信等新约束，需要从系统层面设计。
2. 四个新认知：非确定性系统（测试变评估）、延迟敏感（流式为标配）、成本弹性（Token 预算）、输出质量不可控（防护层必备）。
3. 前端架构经验可以迁移：组件化 → AI 模块封装、微前端 → AI 功能集成、状态管理 → AI 状态方案。
4. 用 2x2 矩阵判断什么该用 AI、什么不该——效果 × 成本。
5. "用 AI"和"架构 AI"的差距不在技术细节，而在是否考虑了降级、成本、安全、可观测性等生产级需求。

从下一篇开始，我们进入实战——第一个主题是每个 AI 系统都需要的核心基础设施：AI 网关层。

讨论话题：你在项目中做过 AI 功能吗？是"调 API 展示结果"的模式，还是有完整的架构设计？遇到过哪些"用着用着才发现"的坑？评论区分享一下。