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

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

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

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

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

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

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

引言

很多人第一次做鸿蒙 App 架构时，核心思路其实都很简单：

页面展示数据
按钮触发逻辑
状态驱动 UI

刚开始这种结构没有问题。但随着项目越来越复杂，很快就会进入一种熟悉的状态：

状态越来越多
任务越来越乱
页面越来越重

尤其 AI 接入之后，你会发现：

一次任务
可能连续修改几十个状态

例如：

await agent.run("整理今天会议")

AI 可能：

• 更新日历
• 创建待办
• 写入笔记
• 同步消息
• 修改提醒状态

这时候，一个问题会突然爆发：

到底谁在管理任务？

到底谁在管理状态？

很多项目后期失控，本质原因就是：

Task 和 State 没有分离

最后整个系统会变成：

任务到处跑
状态到处改

于是越来越多中大型鸿蒙项目，最终都会走向一种新结构：

Task + State 双核心架构。

一、为什么传统页面架构越来越撑不住

传统 App 的核心模型：

页面
 ↓
按钮
 ↓
功能
 ↓
状态更新

问题在于：

页面承担了太多职责

例如：

• UI
• 状态
• 业务逻辑
• 网络请求
• 流程控制

最后页面会越来越像：

巨型控制器

一个典型页面

@State loading: boolean = false
@State orders: Order[] = []

async load() {
  this.loading = true

  this.orders = await api.getOrders()

  this.loading = false
}

刚开始没问题，但后面：

• AI 也会改 orders
• 分布式同步也会改 orders
• 其他页面也会改 orders

最后：

状态来源彻底失控

二、Task + State 架构真正解决的是什么

一句话总结：

Task 负责“过程”，State 负责“结果”。

Task 管什么

Task 管：

• 流程
• 调度
• 执行
• 生命周期
• 多步骤协同

State 管什么

State 管：

• 数据
• 当前状态
• UI 响应
• 状态同步
• 数据一致性

一个非常关键的认知

很多项目的问题：

Task 偷偷保存状态
State 偷偷处理流程

最后：

职责完全混乱

三、Task 为什么会成为未来鸿蒙 App 的核心

因为未来 App 的核心已经不是：

页面

而是：

用户目标

例如：

创建订单
整理会议
发送报告
同步设备

这些本质上都是：

任务

AI 更是天然 Task 化

AI 不理解：

页面

AI 理解的是：

目标

例如：

await agent.run("帮我整理今天会议")

AI 真正执行的是：

任务流

而不是：

页面跳转

四、State 为什么会成为另一半核心

因为鸿蒙本质是：

状态驱动系统

ArkUI 的核心：

@State

本质就是：

状态变化
驱动 UI

但未来，状态来源已经不只是：

用户点击

还包括：

• AI
• 分布式同步
• 多设备协同
• 后台任务
• Task 调度

于是：

State 会越来越重要

五、Task + State 的真正关系

这是整个架构最核心的一点：

Task 不持有状态。

Task 只修改 State。

错误写法

class OrderTask {

  currentOrder: Order

}

问题：

状态藏在 Task 内部

后面一定会出现：

• 状态覆盖
• 分布式异常
• 生命周期错乱

正确写法

class OrderTask {

  async run() {
    const order = await api.create()

    orderStore.set(order)
  }

}

Task：

只负责流程

State：

只负责数据

六、Task + State 双核心模型

推荐一个非常稳定的结构：

Intent
   ↓
Task
   ↓
State
   ↓
UI

每层职责

1、Intent

用户目标，例如：

创建订单
取消支付
同步会议

2、Task

任务执行，例如：

• 调用多个 Service
• 编排流程
• 调度 AI
• 分发任务

3、State

状态存储，例如：

orderStore.orders

4、 UI

状态展示，例如：

Text(orderStore.current.title)

七、为什么这种结构特别适合 AI

因为 AI 最大的问题：

不可预测。

例如：

await agent.run("整理今天任务")

AI 可能：

• 创建日程
• 修改订单
• 删除待办
• 更新消息

如果 AI 可以直接操作 UI：

整个系统一定失控

正确方式

AI：

只能操作 Task

Task：

只能修改 Store

UI：

只能监听状态

这就是边界

AI → Task → State → UI

八、为什么这种结构特别适合分布式

因为鸿蒙本质不是：

页面系统

而是：

状态同步系统

多设备协同真正同步的是什么

不是页面，而是：

任务上下文 + 状态

示例

手机：

taskCenter.run("继续会议")

PC：

meetingStore.currentMeeting

自动恢复。

分布式同步

await kvStore.put(
  "meeting_state",
  meetingStore.current
)

这里同步的不是：

页面

而是：

State

九、为什么未来鸿蒙 App 一定会走向“双核心”

因为未来系统会越来越：

弱页面化

用户越来越习惯：

直接表达目标

例如：

“帮我继续昨天会议”
“帮我总结待办”
“帮我创建订单”

这些本质都是：

Task

但最终真正驱动 UI 的：

仍然是 State

所以未来鸿蒙 App 会越来越明显地变成：

Task + State 双核心系统。

十、一个推荐的代码结构

app/
 ├── task/
 ├── store/
 ├── system/
 ├── repository/
 ├── ai/
 └── ui/

task/

负责：

流程
编排
调度

store/

负责：

状态
缓存
同步

system/

负责：

无状态能力

repository/

负责：

数据访问

ai/

负责：

AI 调度
意图解析

ui/

负责：

界面展示

十一、真正优秀的鸿蒙 AI App 都在做什么

不是：

疯狂堆页面

而是：

建立稳定的 Task + State 架构

因为未来真正重要的已经不是：

• 页面数量
• 导航层级
• Tab 结构

而是：

• Task 流
• 状态流
• AI 调度
• 分布式同步

十二、总结

如果用一句话总结：

Task + State，本质是“过程”和“结果”的彻底分离。

Task：

负责系统怎么运行

State：

负责系统当前是什么状态

只有当两者彻底解耦：

整个鸿蒙 App 才会真正稳定

很多人以为：

未来 App 的核心还是页面

但真正的变化其实是：

页面正在退居外围。

未来系统真正的核心会变成：

Task
+
State

你会越来越明显地发现：

Task 决定系统行为
State 决定系统呈现

最终很多鸿蒙 AI App 会逐渐演变成：

一个由 Task 驱动、由 State 渲染的智能系统。