传统 App 架构，为什么不适合 AI 应用

网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

📣 公众号"Swift社区"，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

💬 微信端添加好友"fzhanfei"，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。

📅 最新动态：2025 年 3 月 17 日

快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

文章目录

• • 引言
  • [一、传统 App 的核心设计思想](#一、传统 App 的核心设计思想)
  • [二、AI 应用的核心变化](#二、AI 应用的核心变化)
  • [三、问题一：页面驱动 vs 意图驱动](#三、问题一：页面驱动 vs 意图驱动)
  • • 举个例子
    • 如果继续用传统架构
  • 四、问题二：业务逻辑分散在页面中
  • • [AI 需要"跨页面能力"](#AI 需要“跨页面能力”)
    • 正确的做法应该是
  • [五、问题三：流程是固定的，而 AI 是动态的](#五、问题三：流程是固定的，而 AI 是动态的)
  • • [AI 应用的特点](#AI 应用的特点)
    • 传统架构的问题
  • 六、问题四：缺乏"能力抽象"
  • • 如果没有能力抽象
    • 正确架构应该是
  • [七、问题五：UI 与逻辑强耦合](#七、问题五：UI 与逻辑强耦合)
  • • [AI 场景的问题](#AI 场景的问题)
  • 八、问题六：缺少统一调度中心
  • 九、本质问题总结
  • 十、那应该怎么改？
  • • [1 去页面中心化](#1 去页面中心化)
    • [2 服务能力化](#2 服务能力化)
    • [3 引入 Tool 层](#3 引入 Tool 层)
    • [4 增加 Agent 层](#4 增加 Agent 层)
  • 总结

引言

很多开发者在接入 AI 时，第一反应通常是：

"在原有 App 里加一个 AI 功能就好了。"

于是你会看到这样的实现：

新增一个 AI 页面
↓
调用大模型接口
↓
展示结果

一开始，这种方式看起来完全没问题。但随着功能变多，很快就会出现：

• AI 逻辑到处散落
• 业务服务难以复用
• 页面越来越重
• 代码越来越难维护

这时候你才会意识到一个本质问题：

不是你写错了，而是传统 App 架构本身就不适合 AI 应用。

一、传统 App 的核心设计思想

传统 App 的设计，本质是：

以页面（UI）为中心

典型结构：

Page → ViewModel → Service → Repository → Network

所有逻辑都是围绕：

页面触发 → 请求数据 → 展示结果

例如：

async onClick() {
  const data = await this.userService.getUserInfo()
  this.user = data
}

特点非常明显：

• 页面是入口
• 用户操作驱动流程
• 每个页面对应一个业务

这种模式在过去非常成功。

二、AI 应用的核心变化

AI 应用的核心，不再是页面，而是：

用户意图

流程变成：

用户输入一句话
     ↓
系统理解意图
     ↓
自动调用多个服务
     ↓
组合结果返回

例如：

"帮我安排一个周末旅行"

背后可能发生：

AI → 解析时间
AI → 查询天气
AI → 推荐景点
AI → 生成行程

注意一个关键点：

用户没有进入任何页面。

三、问题一：页面驱动 vs 意图驱动

传统架构：

页面 = 功能入口

AI 架构：

意图 = 功能入口

这两者是冲突的。

举个例子

传统方式：

搜索页面 → 调用搜索接口
订单页面 → 调用订单接口

AI 方式：

用户一句话：
"帮我查一下订单"

系统需要：

AI 判断 → 调用 OrderService

问题来了： Service 不再由页面驱动，而是由 AI 调用

如果继续用传统架构

你可能会写出这样的代码：

if (intent === "order") {
  return this.orderPage.getOrder()
}

问题：

• Service 被页面绑死
• 逻辑混乱
• 复用性极差

四、问题二：业务逻辑分散在页面中

传统 App 很多逻辑写在页面或 ViewModel 中：

async loadData() {
  const user = await api.getUser()
  const order = await api.getOrder(user.id)
  this.data = merge(user, order)
}

这种写法的问题，在 AI 场景下会被放大。

AI 需要"跨页面能力"

例如：

查询用户 + 查询订单 + 推荐商品

但这些逻辑分散在：

UserPage
OrderPage
RecommendPage

AI 无法复用。

正确的做法应该是

Service 层独立
AI 统一调度

否则你会发现：

AI 根本无法"组合能力"。

五、问题三：流程是固定的，而 AI 是动态的

传统 App：

流程是写死的

例如：

点击按钮 → 请求接口 → 展示结果

代码就是流程：

step1()
step2()
step3()

AI 应用的特点

流程是不确定的

同一句话：

"帮我安排一下今天"

可能变成：

查天气 → 推荐衣服 → 安排行程

也可能是：

查日历 → 提醒会议 → 推荐路线

传统架构的问题

你没法提前写好流程：

if (...) {
  stepA()
} else {
  stepB()
}

因为：

AI 的流程是运行时决定的。

六、问题四：缺乏"能力抽象"

传统 App 通常是：

页面 = 功能

例如：

SearchPage
OrderPage
ProfilePage

但 AI 需要的是：

能力（Capability）

例如：

搜索能力
支付能力
推荐能力

如果没有能力抽象

AI 就只能：

调用页面逻辑（错误）

而不是：

调用服务能力（正确）

正确架构应该是

AI → Tool → Service

示例：

export class OrderTool {
  async execute(userId: string) {
    return await orderService.getOrders(userId)
  }
}

七、问题五：UI 与逻辑强耦合

传统架构中：

UI = 状态 + 逻辑

例如：

@State loading: boolean = false

async fetch() {
  this.loading = true
  this.data = await api.getData()
  this.loading = false
}

AI 场景的问题

AI 调用逻辑时： 不需要 UI

但你的代码：必须依赖 UI

这会导致：

• 逻辑无法复用
• 测试困难
• 架构混乱

八、问题六：缺少统一调度中心

传统 App：

每个页面自己管逻辑

AI App：

需要一个统一调度中心

也就是：

AI Service / Agent

示例：

export class Agent {

  async run(input: string) {
    const intent = await this.parse(input)
    return await this.dispatch(intent)
  }

}

九、本质问题总结

传统 App 架构的问题，本质可以总结为一句话：

它是"页面驱动"的，而 AI 应用是"意图驱动"的。

对比一下：

维度	传统 App	AI App
入口	页面	意图
流程	固定	动态
调用方式	UI 触发	AI 调度
结构	页面分散	能力集中
复用	低	高

十、那应该怎么改？

简单来说：

1 去页面中心化

Page → Service  错误
AI → Service  正确

2 服务能力化

把所有功能拆成：

独立 Service

3 引入 Tool 层

AI → Tool → Service

4 增加 Agent 层

Agent = 调度中心

总结

很多开发者在做 AI 功能时，会遇到各种"诡异问题"：

• 代码越来越乱
• AI 功能难扩展
• 服务无法复用

但这些问题的根源，其实只有一个：

你还在用"传统 App 架构"做"AI 应用"。

AI 应用不是：

App + AI

而是：

AI + App

这意味着：

AI 不只是一个功能，而是整个系统的核心。