子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多团队在接入 AI 时，都会有一个共同的预期：

“只是加一个功能，不需要动原有架构。”

于是常见的做法是：

新增一个 AI 页面
↓
接入大模型接口
↓
返回结果展示

前期看起来一切正常，甚至还挺“顺利”。但只要项目稍微往前走一点，很快就会出现一系列问题：

• AI 能力无法复用
• 业务逻辑开始变乱
• 页面越来越重
• 代码耦合越来越高

最后很多团队都会走到同一个结论：

必须重构。

这不是技术能力问题，而是：

AI 的引入，改变了 App 的底层架构逻辑。

一、问题从哪里开始失控

最开始，AI 通常只是这样接入：

async send() {
  this.reply = await aiService.chat(this.input)
}

看起来很干净，但当需求变成：

帮我查订单
帮我推荐商品
帮我生成总结

你就不得不：

AI → 调用业务逻辑

于是代码开始变成：

if (intent === "order") {
  return await api.get("/orders")
}

问题开始出现： AI 开始直接操作业务层。

二、传统架构的第一个崩点：入口被替换

传统鸿蒙 App：

入口 = 页面

AI 应用：

入口 = 意图

例如：

“查订单”

以前：

用户进入订单页 → 点击按钮

现在：

AI 直接调用 OrderService

这会导致一个严重问题：

原本围绕“页面设计”的架构，失去中心。

三、第二个崩点：业务逻辑不再属于页面

很多项目里，业务逻辑写在：

Page
ViewModel

例如：

async loadOrders() {
  this.orders = await api.get("/orders")
}

AI 想复用： 完全不行。

你不得不做一件事：

把所有逻辑从页面里拆出来

例如：

export class OrderService {

  async getOrders(userId: string) {
    return await 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

示例：

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

4 引入 Agent 层

export class Agent {

  async run(input: string) {
    const intent = await this.parse(input)
    return await this.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 不是功能，而是入口。

一旦入口变了，架构就一定要变。