做了一个 AI 鸿蒙 App,我发现逻辑变了


子玥酱 (掘金 / 知乎 / CSDN / 简书 同名)

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

我持续输出和沉淀前端领域的实战经验,日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案,

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端,或准备长期走前端这条路

📚 关注我,第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 (工程化 / 框架 / 跨端 / 面试 / 架构)

💡 一起把技术学"明白",也用"到位"

持续写作,持续进阶。

愿我们都能在代码和生活里,走得更稳一点 🌱

文章目录

引言

一开始,我只是想做一件很简单的事:

在鸿蒙 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 能力无法扩展
相关推荐
小陈工2 小时前
ModelEngine智能体开发实战:知识库自动生成与多Agent协作
大数据·网络·数据库·人工智能·python·django·异步
李李李li2 小时前
cudnn下载链接
人工智能·windows
小陈工2 小时前
2026年3月23日技术资讯洞察:AI Agent失控,Claude Code引领AI编程新趋势
开发语言·数据库·人工智能·后端·python·性能优化·ai编程
信也科技布道师2 小时前
信也AI赋能慢SQL治理的探索与实践
数据库·人工智能·sql
何伯特2 小时前
LLaVA与BLIP2深度对比:两种视觉-语言融合范式的全面解析
人工智能·深度学习
枫叶丹42 小时前
【HarmonyOS 6.0】Network Kit 深度解析:TLS 认证全面支持国密证书
开发语言·网络安全·华为·harmonyos
ar01232 小时前
可视化特点在AR远程协助方面的重要意义
人工智能·ar
AnalogElectronic4 小时前
人工智能初级工程师认证复习纲要(高频重点标记)
人工智能
前端不太难4 小时前
AI 原生架构:鸿蒙App的下一代形态
人工智能·架构·harmonyos