

子玥酱 (掘金 / 知乎 / CSDN / 简书 同名)
大家好,我是 子玥酱,一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂,目前在某国企负责前端软件研发相关工作,主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验,日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案,
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向: 前端 / 跨端 / 小程序 / 移动端工程化 内容平台: 掘金、知乎、CSDN、简书 创作特点: 实战导向、源码拆解、少空谈多落地 **文章状态:**长期稳定更新,大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用",而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍,希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端,或准备长期走前端这条路
📚 关注我,第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源 (工程化 / 框架 / 跨端 / 面试 / 架构)
💡 一起把技术学"明白",也用"到位"
持续写作,持续进阶。
愿我们都能在代码和生活里,走得更稳一点 🌱
文章目录
-
- 引言
- [一、最开始,我只是加了一个"AI 页面"](#一、最开始,我只是加了一个“AI 页面”)
- [二、AI 开始"绕过页面"](#二、AI 开始“绕过页面”)
- [三、Service 层突然变成核心](#三、Service 层突然变成核心)
-
- [1 有些 Service 写在页面里](#1 有些 Service 写在页面里)
- [2 有些逻辑和 UI 强绑定](#2 有些逻辑和 UI 强绑定)
- 四、我开始把能力"服务化"
- 五、我又加了一层:Tool
- 六、我不得不引入"Agent"
- [七、UI 的地位明显下降了](#七、UI 的地位明显下降了)
- 八、数据流也变了
- 九、最大的变化,其实是"思维方式"
- 十、本质总结
- 结语
引言
一开始,我只是想做一件很简单的事:
在鸿蒙 App 里接入一个 AI 功能。
比如:
- 做一个智能搜索
- 加一个 AI 助手
- 支持自然语言操作
听起来很普通,对吧?
但当我真的把一个 AI 鸿蒙 App 从 0 做到能用之后,我发现一件很不对劲的事:
不是我在给 App 加 AI,而是 AI 在重写整个 App 的逻辑。
而且这种变化,不是 UI 层面的,而是:
架构级别的变化
一、最开始,我只是加了一个"AI 页面"
最初的实现很典型:
首页
↓
新增一个 AI 页面
↓
调用大模型接口
↓
展示结果
代码大概是这样:
ts
@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 写在页面里
ts
// Page 内部逻辑
async loadOrders() {
return await api.get("/orders")
}
AI 根本调不了。
2 有些逻辑和 UI 强绑定
ts
this.loading = true
this.orders = await api.get()
this.loading = false
AI 也用不了,于是我不得不重构:
把所有业务逻辑从页面里"抽出来"。
四、我开始把能力"服务化"
我做的第一步是:
拆 Service
例如:
ts
export class OrderService {
async getOrders(userId: string) {
return await api.get("/orders")
}
}
然后 UI 和 AI 都调用:
ts
await orderService.getOrders(userId)
这一刻变化很明显:
App 不再是页面集合,而是能力集合。
五、我又加了一层:Tool
很快我发现一个新问题,AI 并不知道该调用哪个 Service。
于是我加了一层:
Tool
例如:
ts
export class OrderTool {
async execute(params) {
return await orderService.getOrders(params.userId)
}
}
AI 只需要:
调用 Tool
而不用关心底层实现,这时候架构变成:
AI → Tool → Service
六、我不得不引入"Agent"
再往后,问题又来了。用户输入开始变复杂:
帮我查订单,并推荐相关商品
这已经不是一个 Service 能完成的任务,我需要:
多个步骤
多个能力
组合执行
于是我引入了:
Agent
示例:
ts
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 能力无法扩展