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

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

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

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

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

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

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

引言

过去几年，大模型最典型的产品形态一直是：

ChatGPT
DeepSeek
Claude
Kimi

大家习惯了：

打开聊天框
输入问题
等待回答

于是很多开发者在做鸿蒙 AI App 时，也会下意识地认为：

接入一个聊天窗口，就是 AI 应用。

但实际上：

聊天只是表现形式

真正有价值的，是：

让 AI 成为 App 内部的智能助手。

例如，在教育 App 中：

帮我规划学习路线

在电商 App 中：

帮我找到最适合我的课程

在办公 App 中：

整理今天会议纪要

在鸿蒙系统中：

帮我把手机里的文件发到平板

这时候：

AI 不再是聊天机器人

而是：

智能助手（Assistant）

这也是未来 AI Native 鸿蒙 App 的核心形态之一。

一、什么是鸿蒙 App 智能助手

一句话解释：

智能助手 = 大模型 + 业务能力。

很多人理解的大模型：

只能回答问题

实际上：

回答问题
只是最基础能力

真正的智能助手应该具备：

理解意图
拆解任务
调用能力
执行结果

例如，用户说：

帮我预约明天下午的课程

AI 不应该返回：

好的，你可以点击预约按钮

而应该：

直接完成预约

这才是真正的 Assistant。

二、智能助手和聊天机器人的区别

很多团队一开始都会做成：

聊天框
 ↓
大模型
 ↓
回复文本

结构：

User
 ↓
LLM
 ↓
Response

这种其实属于：

Chat Bot

而智能助手应该是：

User
 ↓
Intent
 ↓
Task
 ↓
Tool
 ↓
Result

例如，用户：

帮我取消订单

助手：

识别意图

↓

调用订单系统

↓

完成取消

↓

返回结果

这里：

AI 不只是回答
而是在执行

三、鸿蒙智能助手的核心架构

推荐采用：

UI
 ↓
Assistant
 ↓
Task Runtime
 ↓
Tool Runtime
 ↓
System
 ↓
Repository

这是目前比较适合鸿蒙 AI App 的结构。

第一层：UI

负责：

展示交互

例如：

TextInput()
Button("发送")

或者：

语音输入

页面永远不要直接调用：

订单系统
支付系统

而是：

Assistant

第二层：Assistant

负责：

理解用户意图

例如：

帮我购买英语课程

模型识别：

{
  "intent": "buy_course",
  "course": "英语"
}

Assistant 是整个系统的大脑。

第三层：Task Runtime

负责：

拆解任务

例如：

购买课程

可能拆分成：

查询课程
确认库存
创建订单
完成支付

示例：

await taskCenter.run(
  "BuyCourseTask"
)

第四层：Tool Runtime

负责：

调用业务能力

例如：

OrderTool
UserTool
PaymentTool

示例：

class OrderTool {

  async createOrder() {}

}

AI 永远不要直接访问数据库。

必须经过：

Tool

四、为什么 Tool 是最重要的一层

很多团队最容易犯的错误：

让 AI 直接操作业务代码

例如：

orderStore.orders = []

风险非常大，正确做法：

await orderTool.cancel(id)

优势：

权限可控
行为可追踪
日志可审计

未来所有 AI Native 鸿蒙 App，都会有：

Tool Layer

五、一个课程助手实战案例

例如，海绵教育 App。

用户：

帮我推荐适合专升本的课程

Assistant 识别：

{
  "intent":"recommend_course",
  "target":"专升本"
}

调用：

await courseTool.search(
  "专升本"
)

返回：

课程列表

然后：

自动生成推荐理由

最终：

推荐课程 + 推荐原因

返回给用户。

六、鸿蒙 ArkUI 如何接入助手

页面层非常简单。

@State question: string = ""

TextInput({
  text: this.question
})

Button("发送")
  .onClick(async () => {

    const result =
      await assistant.run(
        this.question
      )

  })

这里，页面不知道：

模型是谁
任务怎么执行
工具怎么调用

页面只负责：

输入
输出

七、Assistant 核心实现

示例：

class Assistant {

  async run(text: string) {

    const intent =
      await llm.parse(text)

    return await taskCenter.run(
      intent
    )

  }

}

流程：

用户输入
 ↓
Intent
 ↓
Task
 ↓
Result

这是最稳定的结构。

八、为什么未来会变成 Task 驱动

传统 App：

按钮驱动

例如：

点击预约

AI App：

意图驱动

例如：

帮我预约明天下午课程

这里：

用户不关心按钮

只关心：

目标

因此：

Intent
 ↓
Task

会成为未来主流架构。

九、多设备场景如何设计

鸿蒙最大的特点：

一个账号
多个设备

例如，手机：

输入需求

平板：

展示结果

PC：

继续编辑

这时候智能助手状态必须中心化。推荐：

AssistantState

结构：

class AssistantState {

  currentTask

  history

}

统一同步：

手机
平板
PC

共享同一个任务状态。

十、AI Native 鸿蒙 App 的最终形态

很多人以为，未来：

App + AI

其实更准确的说法是：

AI + App

因为未来：

AI 是入口

而：

页面只是结果展示

例如，用户：

帮我找到最适合我的课程

系统自动：

• 搜索课程
• 分析用户画像
• 推荐方案
• 创建学习计划

整个过程中：

用户甚至不用跳页面

十一、真正优秀的智能助手都具备什么

通常会有：

Intent Engine

负责：

意图识别

Task Engine

负责：

任务编排

Tool Engine

负责：

能力调用

State Engine

负责：

状态管理

Memory Engine

负责：

上下文记忆

最终形成

Assistant Runtime

这也是未来鸿蒙 AI 应用最重要的基础设施之一。

十二、本质总结

如果用一句话总结：

智能助手并不是“大模型聊天框”，而是“AI 驱动的任务执行系统”。

过去：

用户点击功能

未来：

用户表达意图

过去：

页面组织能力

未来：

Assistant 组织能力

过去：

功能驱动 App

未来：

任务驱动 App

很多开发者刚接触 AI 时，会把重点放在：

• Prompt
• 模型参数
• 聊天界面

但未来鸿蒙 App 真正的竞争力，其实不在这里。

而在于：

能否把 AI 变成应用内部的智能助手。

记住一句话：

聊天机器人回答问题，
智能助手完成任务。

当你的鸿蒙 App 开始拥有：

• Intent Engine
• Task Runtime
• Tool Runtime
• Assistant State
• Memory System

你会发现：

AI 不再是一个功能

而开始成为整个 App 的新操作系统。