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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

引言

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

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

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

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

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

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

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

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

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

传统 App 的设计，本质是：

以页面（UI）为中心

典型结构：

Page → ViewModel → Service → Repository → Network

所有逻辑都是围绕：

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

例如：

asynconClick(){constdata=awaitthis.userService.getUserInfo()this.user=data}

特点非常明显：

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

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

二、AI 应用的核心变化

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

用户意图

流程变成：

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

例如：

“帮我安排一个周末旅行”

背后可能发生：

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

注意一个关键点：

用户没有进入任何页面。

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

传统架构：

页面 = 功能入口

AI 架构：

意图 = 功能入口

这两者是冲突的。

举个例子

传统方式：

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

AI 方式：

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

系统需要：

AI 判断 → 调用 OrderService

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

如果继续用传统架构

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

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

问题：

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

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

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

asyncloadData(){constuser=awaitapi.getUser()constorder=awaitapi.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

示例：

exportclassOrderTool{asyncexecute(userId:string){returnawaitorderService.getOrders(userId)}}

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

传统架构中：

UI = 状态 + 逻辑

例如：

@Stateloading:boolean=falseasyncfetch(){this.loading=truethis.data=awaitapi.getData()this.loading=false}

AI 场景的问题

AI 调用逻辑时： 不需要 UI

但你的代码：必须依赖 UI

这会导致：

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

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

传统 App：

每个页面自己管逻辑

AI App：

需要一个统一调度中心

也就是：

AI Service / Agent

示例：

exportclassAgent{asyncrun(input:string){constintent=awaitthis.parse(input)returnawaitthis.dispatch(intent)}}

九、本质问题总结

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

它是“页面驱动”的，而 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 不只是一个功能，而是整个系统的核心。