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

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

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

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

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

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

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

引言

随着大模型能力逐渐普及，越来越多应用开始接入 AI 功能。
但很多开发者在真正做 AI 应用时，很快会遇到一个问题：

传统 App 架构，并不适合 AI 应用。

过去我们设计 App，通常围绕 页面 + 业务逻辑展开。但 AI 应用的核心不再只是页面，而是：

AI 能力
任务理解
服务调用

这意味着应用架构需要发生变化。

一、传统 App 架构是什么样

大多数鸿蒙应用的架构类似这样：

Page
 ↓
Service
 ↓
Repository
 ↓
Network

职责很清晰：

Page        UI 展示
Service     业务逻辑
Repository  数据管理
Network     网络请求

例如：

用户点击按钮
     ↓
页面调用 Service
     ↓
Service 调用 API
     ↓
返回数据展示

这种架构适合 功能型应用，但 AI 应用的逻辑完全不同。

二、AI App 的核心流程

AI 应用通常是这样工作的：

用户输入
     ↓
AI 理解意图
     ↓
任务规划
     ↓
调用服务
     ↓
返回结果

例如，用户输入：

帮我推荐附近好吃的餐厅

系统流程可能是：

AI → 意图识别
AI → 解析位置
AI → 调用餐厅服务
AI → 返回推荐

这里 AI 其实成为 系统核心入口。

三、AI App 的核心模块

一个完整的 AI 应用通常包含几个核心模块：

AI Layer
Service Layer
Data Layer
UI Layer

结构示意：

用户输入
   ↓
AI Layer
   ↓
Service Layer
   ↓
Data Layer
   ↓
UI 展示

AI 层变成整个系统的 控制中心。

四、AI Layer（AI 层）

AI 层负责：

意图识别
任务规划
工具调用

典型模块包括：

Intent Parser
Task Planner
Tool Manager
Prompt Manager

结构示例：

ai
 ├─ ai_service
 ├─ intent_parser
 ├─ task_planner
 └─ prompt_manager

示例代码：

export class AIService {

  async chat(message: string) {
    const intent = await this.parseIntent(message)
    return await this.executeTask(intent)
  }

}

AI 层会决定 调用哪个服务。

五、Service Layer（服务层）

Service 层负责具体业务能力，例如：

用户服务
订单服务
搜索服务
推荐服务

结构：

services
 ├─ UserService
 ├─ SearchService
 └─ OrderService

示例：

export class SearchService {

  async searchRestaurant(keyword: string) {
    return await ApiClient.get("/restaurant/search")
  }

}

AI 通过 Service 调用业务能力。

六、Tool Layer（工具层）

在 AI 应用中，经常会设计 Tool（工具）系统，Tool 的作用是：

把应用能力暴露给 AI

例如：

搜索餐厅
查询天气
预订酒店

结构：

tools
 ├─ SearchRestaurantTool
 ├─ WeatherTool
 └─ BookingTool

示例：

export class WeatherTool {

  async execute(city: string) {
    return await WeatherService.getWeather(city)
  }

}

AI 可以通过工具调用服务。

七、数据层

数据层负责：

网络请求
缓存
数据库

结构：

repository
 ├─ UserRepository
 └─ ContentRepository

示例：

export class UserRepository {

  async fetchUserInfo() {
    return await HttpClient.get("/user")
  }

}

八、UI 层

AI 应用的 UI 通常更简单，UI 主要负责：

输入
展示结果
确认操作

例如：

@Entry
@Component
struct ChatPage {

  @State message: string = ""
  @State reply: string = ""

  aiService: AIService = new AIService()

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

}

UI 只是一个 交互入口。

九、完整架构示意

一个比较完整的鸿蒙 AI App 架构可能是：

entry
 ├─ pages
 │
 ├─ components
 │
 ├─ ai
 │   ├─ ai_service
 │   ├─ intent_parser
 │   ├─ task_planner
 │   └─ prompt_manager
 │
 ├─ tools
 │
 ├─ services
 │
 ├─ repository
 │
 ├─ models
 │
 └─ utils

数据流：

用户输入
   ↓
AI Service
   ↓
Intent Parser
   ↓
Task Planner
   ↓
Tool / Service
   ↓
返回结果

十、AI 应用架构的关键设计原则

设计 AI 应用架构时，有几个关键原则。

1、AI 作为入口

传统应用：

UI → Service

AI 应用：

AI → Service

2、服务能力模块化

每个能力都应该是一个 独立 Service，例如：

SearchService
PaymentService
WeatherService

3、工具化能力

AI 通过 Tool 调用系统能力。

Tool → Service

总结

随着 AI 技术的发展，应用架构正在发生变化，传统 App：

UI → Service → Network

AI App：

User Input
   ↓
AI Layer
   ↓
Tool / Service
   ↓
Data Layer

也就是说：

AI 不再只是功能，而是应用架构的核心。

对于鸿蒙应用来说，未来 AI 很可能成为：

系统能力
应用入口
任务执行者

这意味着：鸿蒙 AI App 的架构，正在从 页面驱动逐渐转向 智能驱动。