网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。 公众号“Swift社区”每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。 微信端添加好友“fzhanfei”与我直接交流不管是项目瓶颈的求助还是行业趋势的探讨随时畅所欲言。 最新动态2025 年 3 月 17 日快来加入技术社区一起挖掘技术的无限潜能携手迈向数字化新征程文章目录引言一、传统 App 的核心设计思想二、AI 应用的核心变化三、问题一页面驱动 vs 意图驱动举个例子如果继续用传统架构四、问题二业务逻辑分散在页面中AI 需要“跨页面能力”正确的做法应该是五、问题三流程是固定的而 AI 是动态的AI 应用的特点传统架构的问题六、问题四缺乏“能力抽象”如果没有能力抽象正确架构应该是七、问题五UI 与逻辑强耦合AI 场景的问题八、问题六缺少统一调度中心九、本质问题总结十、那应该怎么改1 去页面中心化2 服务能力化3 引入 Tool 层4 增加 Agent 层总结引言很多开发者在接入 AI 时第一反应通常是“在原有 App 里加一个 AI 功能就好了。”于是你会看到这样的实现新增一个 AI 页面 ↓ 调用大模型接口 ↓ 展示结果一开始这种方式看起来完全没问题。但随着功能变多很快就会出现AI 逻辑到处散落业务服务难以复用页面越来越重代码越来越难维护这时候你才会意识到一个本质问题不是你写错了而是传统 App 架构本身就不适合 AI 应用。一、传统 App 的核心设计思想传统 App 的设计本质是以页面UI为中心典型结构Page → ViewModel → Service → Repository → Network所有逻辑都是围绕页面触发 → 请求数据 → 展示结果例如asynconClick(){constdataawaitthis.userService.getUserInfo()this.userdata}特点非常明显页面是入口用户操作驱动流程每个页面对应一个业务这种模式在过去非常成功。二、AI 应用的核心变化AI 应用的核心不再是页面而是用户意图流程变成用户输入一句话 ↓ 系统理解意图 ↓ 自动调用多个服务 ↓ 组合结果返回例如“帮我安排一个周末旅行”背后可能发生AI → 解析时间 AI → 查询天气 AI → 推荐景点 AI → 生成行程注意一个关键点用户没有进入任何页面。三、问题一页面驱动 vs 意图驱动传统架构页面 功能入口AI 架构意图 功能入口这两者是冲突的。举个例子传统方式搜索页面 → 调用搜索接口 订单页面 → 调用订单接口AI 方式用户一句话 “帮我查一下订单”系统需要AI 判断 → 调用 OrderService问题来了Service 不再由页面驱动而是由 AI 调用如果继续用传统架构你可能会写出这样的代码if(intentorder){returnthis.orderPage.getOrder()}问题Service 被页面绑死逻辑混乱复用性极差四、问题二业务逻辑分散在页面中传统 App 很多逻辑写在页面或 ViewModel 中asyncloadData(){constuserawaitapi.getUser()constorderawaitapi.getOrder(user.id)this.datamerge(user,order)}这种写法的问题在 AI 场景下会被放大。AI 需要“跨页面能力”例如查询用户 查询订单 推荐商品但这些逻辑分散在UserPage OrderPage RecommendPageAI 无法复用。正确的做法应该是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:booleanfalseasyncfetch(){this.loadingtruethis.dataawaitapi.getData()this.loadingfalse}AI 场景的问题AI 调用逻辑时 不需要 UI但你的代码必须依赖 UI这会导致逻辑无法复用测试困难架构混乱八、问题六缺少统一调度中心传统 App每个页面自己管逻辑AI App需要一个统一调度中心也就是AI Service / Agent示例exportclassAgent{asyncrun(input:string){constintentawaitthis.parse(input)returnawaitthis.dispatch(intent)}}九、本质问题总结传统 App 架构的问题本质可以总结为一句话它是“页面驱动”的而 AI 应用是“意图驱动”的。对比一下维度传统 AppAI App入口页面意图流程固定动态调用方式UI 触发AI 调度结构页面分散能力集中复用低高十、那应该怎么改简单来说1 去页面中心化Page → Service 错误 AI → Service 正确2 服务能力化把所有功能拆成独立 Service3 引入 Tool 层AI → Tool → Service4 增加 Agent 层Agent 调度中心总结很多开发者在做 AI 功能时会遇到各种“诡异问题”代码越来越乱AI 功能难扩展服务无法复用但这些问题的根源其实只有一个你还在用“传统 App 架构”做“AI 应用”。AI 应用不是App AI而是AI App这意味着AI 不只是一个功能而是整个系统的核心。