AI 一接入，鸿蒙 App 为什么必须重构？
子玥酱（掘金 / 知乎 / ZEEKLOG / 简书 同名）
大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、ZEEKLOG、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
引言
很多团队在接入 AI 时，都会有一个共同的预期：
“只是加一个功能，不需要动原有架构。”
于是常见的做法是：
新增一个 AI 页面 ↓ 接入大模型接口 ↓ 返回结果展示 前期看起来一切正常，甚至还挺“顺利”。但只要项目稍微往前走一点，很快就会出现一系列问题：
- AI 能力无法复用
- 业务逻辑开始变乱
- 页面越来越重
- 代码耦合越来越高
最后很多团队都会走到同一个结论：
必须重构。
这不是技术能力问题，而是：
AI 的引入，改变了 App 的底层架构逻辑。
一、问题从哪里开始失控
最开始，AI 通常只是这样接入：
asyncsend(){this.reply =await aiService.chat(this.input)}看起来很干净，但当需求变成：
帮我查订单 帮我推荐商品 帮我生成总结 你就不得不：
AI → 调用业务逻辑 于是代码开始变成：
if(intent ==="order"){returnawait api.get("/orders")}问题开始出现： AI 开始直接操作业务层。
二、传统架构的第一个崩点：入口被替换
传统鸿蒙 App：
入口 = 页面 AI 应用：
入口 = 意图 例如：
“查订单” 以前：
用户进入订单页 → 点击按钮 现在：
AI 直接调用 OrderService 这会导致一个严重问题：
原本围绕“页面设计”的架构，失去中心。
三、第二个崩点：业务逻辑不再属于页面
很多项目里，业务逻辑写在：
Page ViewModel 例如：
asyncloadOrders(){this.orders =await api.get("/orders")}AI 想复用： 完全不行。
你不得不做一件事：
把所有逻辑从页面里拆出来 例如：
exportclassOrderService{asyncgetOrders(userId:string){returnawait api.get("/orders")}}这一步，其实已经是：
架构级重构。
四、第三个崩点：流程变成动态的
传统 App：
流程 = 写死 例如：
点击 → 请求 → 展示 AI 应用：
流程 = 运行时决定 例如：
“帮我安排出差” 可能变成：
查航班 → 查酒店 → 安排行程 问题在于：传统代码无法表达“动态流程”
if(...){stepA()}else{stepB()}这种写法完全不够用。
五、第四个崩点：能力无法复用
传统 App：
页面 = 功能 例如：
OrderPage SearchPage ProfilePage 但 AI 需要的是：
能力 例如：
查询订单 搜索商品 获取用户信息 如果没有拆分：AI 根本无法组合能力。
六、第五个崩点：数据流彻底混乱
传统数据流：
UI → Service → Data → UI AI 接入后：
UI → Service AI → Service 如果没有设计，会变成：
多个入口同时改数据 结果：
- 状态错乱
- UI 不更新
- Bug 难以复现
七、为什么“必须重构”
到这里，其实已经很清楚了，AI 带来的变化，不是：
多一个功能 而是：
改变了系统入口 改变了调用方式 改变了流程结构 换句话说：
AI 改变的是“系统结构”，而不是“功能层”。
八、正确的重构方向
如果你准备做 AI 鸿蒙 App，建议直接重构这几件事：
1 去页面中心化
Page → Service 错误 AI → Service 正确 2 拆分 Service
所有业务逻辑必须独立：
UserService OrderService SearchService 3 引入 Tool 层
AI → Tool → Service 示例：
exportclassOrderTool{asyncexecute(params){returnawait orderService.getOrders(params.userId)}}4 引入 Agent 层
exportclassAgent{asyncrun(input:string){const intent =awaitthis.parse(input)returnawaitthis.dispatch(intent)}}5 重构数据流
统一为：
AI / UI → Service → Data → State → UI 九、一个重构前后对比
重构前
Page ├─ 请求 API ├─ 处理逻辑 └─ 更新 UI 重构后
Agent ├─ Tool │ ├─ Service │ │ └─ Repository UI：
只负责展示 十、本质
如果用一句话总结：
AI 接入后，App 的“控制权”从 UI 转移到了 AI。
对比：
| 维度 | 传统 App | AI App |
|---|---|---|
| 控制中心 | UI | Agent |
| 入口 | 页面 | 意图 |
| 流程 | 固定 | 动态 |
| 结构 | 页面驱动 | 能力驱动 |
总结
很多团队在接入 AI 时都会经历一个阶段：
一开始只是加功能，最后不得不重构架构。
这其实不是“踩坑”，而是一个必然过程。因为：
你在用旧架构，承载一个全新的应用形态。
如果你正在做鸿蒙 AI App，可以记住一句话：
AI 不是功能，而是入口。
一旦入口变了，架构就一定要变。