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

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

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

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

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

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

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

引言

过去二十年，移动 App 的信息架构几乎没有本质变化：

• 首页 → 列表 → 详情
• Tab 导航 → 二级页面 → 功能入口
• 搜索框永远在右上角

无论你用的是 iOS、Android，还是如今的鸿蒙，大多数 App 仍然遵循“页面驱动”的设计逻辑。

但 AI 出现后，一个根本问题开始浮现：

当用户不再通过“点页面”获取信息，那 App 还需要那么多页面吗？

这不是 UI 变化，这是信息架构级别的重构。

传统 App 的信息架构，本质是什么

先别急着谈 AI，我们先看旧世界，传统 App 的核心是三件事：

页面层级

通过层层跳转组织信息：

• 首页承载入口
• 列表承载筛选
• 详情承载内容

本质是：

用“空间结构”组织信息。

典型页面跳转结构（ArkTS）：

router.pushUrl({ url: 'pages/List' })

// List → Detail
router.pushUrl({
  url: 'pages/Detail',
  params: { id: itemId }
})

这正是“空间层级驱动信息”的最直接体现。

功能入口

用户必须知道：

• 去哪里点
• 点什么按钮
• 下一步在哪

也就是说：

用户要先理解产品结构，才能完成任务。

入口按钮式交互：

Button('查看订单')
  .onClick(() => {
    router.pushUrl({ url: 'pages/order/List' })
  })

这里的核心不是“能力”，而是入口位置。

搜索是补救机制

当用户找不到入口时：

• 才会用搜索
• 还要自己组织关键词

所以传统搜索体验永远不完美。

传统关键词搜索实现：

search(keyword: string) {
  return this.list.filter(item => item.title.includes(keyword))
}

问题在于：

系统并不理解语义，只是在做字符串匹配。

AI 出现后，第一个被打碎的是什么

不是页面，不是按钮，而是——

“入口”这个概念本身。

当用户可以直接说：

• “帮我把这周的待办整理一下”
• “找出最便宜的航班”
• “把这篇文章总结成三点”

用户其实在表达：

我不关心页面在哪， 我只关心结果。

AI 意图直达任务：

async function handleIntent(intent: string) {
  if (intent.includes('待办')) {
    return openTodoAndSort()
  }

  if (intent.includes('最便宜航班')) {
    return searchFlight({ sortBy: 'price' })
  }
}

这里已经：

没有“入口查找”这一步。

鸿蒙环境下，这种变化更剧烈

很多人没意识到一点：

AI + 全场景系统 = 架构级爆炸。

1. 鸿蒙不是单设备 App

传统移动 App：

一块屏幕解决所有事。

但鸿蒙是：

• 手机
• 平板
• PC
• 车机
• IoT

当用户说一句话：

“把会议资料打开。”

系统必须决定：

• 在哪台设备展示
• 用什么交互形式
• 是否跨设备协同

这已经不是 UI 问题，而是信息调度问题。

分布式数据同步示例：

import distributedData from '@ohos.data.distributedData'

await kvStore.put('meeting_doc', docId)

另一设备读取：

let id = await kvStore.get('meeting_doc')
openDocument(id)

用户完全不需要关心：

在哪个设备、哪个页面。

2. 分布式能力让“页面”失去中心地位

在多设备流转场景里：

• 用户不会记得哪个页面
• 也不会记得哪个设备

用户只记得：

我要完成一件事。

于是信息架构从：页面中心 → 任务中心

任务驱动模型：

interface Task {
  name: string
  execute(): Promise<void>
}

AI 重构信息架构的三层变化

第一层：从“页面导航”到“任务直达”

旧模型：

用户 → 找入口 → 点页面 → 找功能 → 完成任务

AI 模型：

用户 → 说需求 → 系统直接完成

变化本质：

交互从“浏览式”变为“执行式”。

await ai.execute('继续阅读昨天的章节')

第二层：从“信息层级”到“语义网络”

传统架构依赖：

• 分类
• 层级
• 标签

但 AI 更擅长的是：

理解语义关系。

这意味着：

• 信息不再按页面组织
• 而按“语义连接”组织

你可以理解为：

App 内部开始变成一个小型知识图谱。

type KnowledgeNode = {
  id: string
  tags: string[]
  relations: string[]
}

第三层：从“功能集合”到“能力集合”

旧 App：

• 有多少页面
• 就有多少功能

AI App：

• 页面只是外壳
• 真正核心是能力接口

例如：

• 搜索能力
• 推荐能力
• 生成能力
• 规划能力

未来的 App 更像：

一个可调用的能力容器。

export interface AIAbility {
  name: string
  run(params: object): Promise<any>
}

对鸿蒙开发者意味着什么

1. 页面设计的重要性在下降

不是说 UI 不重要，而是：

UI 不再是唯一入口。

未来一定会出现：

• 70% 操作由 AI 直接完成
• 用户很少完整浏览页面

@Entry
@Component
struct DirectTaskPage {
  aboutToAppear() {
    ai.restoreLastTask()
  }
}

2. 信息建模变成核心竞争力

过去比拼：

• 动效
• 布局
• 视觉

未来比拼：

数据结构 + 语义结构。

谁的信息模型更清晰，谁的 AI 就更聪明。

class SemanticIndex {
  map: Map<string, KnowledgeNode>
}

3. App 边界开始模糊

当系统级 AI 能：

• 跨应用调度
• 自动组合能力

那么问题来了：

用户还需要打开具体 App 吗？

await systemAI.compose([
  '打开文档',
  '总结要点',
  '发送给同事'
])

这会带来一次巨大的生态重排。

未来三年的一个关键判断

可以给你一个非常明确的趋势：

不会 AI 化的 App， 会逐渐退化成“工具型壳”。

而真正有价值的应用，将具备三点：

• 可被 AI 调用
• 拥有结构化知识
• 能跨设备完成任务

这三点，刚好与鸿蒙的系统方向完全重合。

export type FutureApp = {
  abilities: AIAbility[]
  knowledgeGraph: KnowledgeNode[]
  distributedTasks: Task[]
}

总结

很多人以为：

AI 只是给 App 加一个聊天框。

但真正的变化是：

AI 正在重写 App 的信息架构底层逻辑。

当入口消失、页面弱化、语义成为核心，我们熟悉的移动应用形态，很可能在未来几年里彻底改变。

而鸿蒙，恰好站在这场变化的正中央。