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

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

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

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

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

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

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

引言

一开始，我只是想做一件很简单的事：

在鸿蒙 App 里接入一个 AI 功能。

比如：

• 做一个智能搜索
• 加一个 AI 助手
• 支持自然语言操作

听起来很普通，对吧？

但当我真的把一个 AI 鸿蒙 App 从 0 做到能用之后，我发现一件很不对劲的事：

不是我在给 App 加 AI，而是 AI 在重写整个 App 的逻辑。

而且这种变化，不是 UI 层面的，而是：

架构级别的变化

一、最开始，我只是加了一个“AI 页面”

最初的实现很典型：

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

代码大概是这样：

@Entry
@Component
struct AIPage {

  @State input: string = ""
  @State reply: string = ""

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

}

当时我以为：

“这不就完成了吗？”

但很快问题就来了。

二、AI 开始“绕过页面”

用户开始提一些请求：

帮我查一下订单
帮我推荐几个商品
帮我看看今天有什么安排

这些需求本来应该对应：

订单页
商品页
日程页

但现在：用户根本没有进入这些页面，AI 直接返回了结果。

这时候我第一次意识到：

页面，不再是唯一入口了。

三、Service 层突然变成核心

以前我的代码结构是：

Page → Service → API

但现在变成：

AI → Service
Page → Service

也就是说：Service 被两个入口调用：

• UI
• AI

问题马上暴露出来：

1 有些 Service 写在页面里

// Page 内部逻辑
async loadOrders() {
  return await api.get("/orders")
}

AI 根本调不了。

2 有些逻辑和 UI 强绑定

this.loading = true
this.orders = await api.get()
this.loading = false

AI 也用不了，于是我不得不重构：

把所有业务逻辑从页面里“抽出来”。

四、我开始把能力“服务化”

我做的第一步是：

拆 Service

例如：

export class OrderService {

  async getOrders(userId: string) {
    return await api.get("/orders")
  }

}

然后 UI 和 AI 都调用：

await orderService.getOrders(userId)

这一刻变化很明显：

App 不再是页面集合，而是能力集合。

五、我又加了一层：Tool

很快我发现一个新问题，AI 并不知道该调用哪个 Service。

于是我加了一层：

Tool

例如：

export class OrderTool {

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

}

AI 只需要：

调用 Tool

而不用关心底层实现，这时候架构变成：

AI → Tool → Service

六、我不得不引入“Agent”

再往后，问题又来了。用户输入开始变复杂：

帮我查订单，并推荐相关商品

这已经不是一个 Service 能完成的任务，我需要：

多个步骤
多个能力
组合执行

于是我引入了：

Agent

示例：

export class Agent {

  async run(input: string) {

    const intent = await this.parse(input)

    if (intent === "order_and_recommend") {

      const orders = await orderTool.execute()
      const goods = await recommendTool.execute()

      return { orders, goods }
    }

  }

}

这时候我才彻底意识到：

AI 不只是调用接口，而是在“编排系统能力”。

七、UI 的地位明显下降了

以前：

UI = 核心

现在：

AI = 核心
UI = 展示

很多操作变成：

用户一句话
↓
AI 完成
↓
UI 展示结果

甚至很多时候：UI 根本不参与流程

八、数据流也变了

传统数据流：

UI → Service → Data → UI

现在变成：

用户输入
↓
AI
↓
Service
↓
Data
↓
UI（展示）

变化很关键：

数据流不再由 UI 触发，而是由 AI 触发。

九、最大的变化，其实是“思维方式”

做完这个项目后，我最大的感受不是代码变了，而是：

思维方式彻底变了。

以前我在想：

这个页面怎么设计？
这个按钮放哪？
这个流程怎么走？

现在我在想：

用户会说什么？
系统怎么理解？
能力怎么组合？
任务怎么完成？

十、本质总结

如果用一句话总结这次变化：

我不再是在做“页面应用”，而是在做“能力系统”。

对比一下：

维度	传统 App	AI App
入口	页面	意图
核心	UI	Agent
逻辑	固定流程	动态任务
结构	页面集合	能力系统

结语

一开始我只是想：

给鸿蒙 App 加一个 AI 功能

但最后我得到的是：

一个完全不同的应用架构。

如果你现在也在做 AI 鸿蒙 App，我给你一个建议：

不要把 AI 当成功能，而要当成系统入口来设计。

否则你很快就会遇到：

• 架构混乱
• 代码失控
• AI 能力无法扩展