AI 时代，鸿蒙 App 还需要传统导航结构吗？

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

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

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

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

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

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

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

文章目录

• 引言
• 传统导航结构的本质
  • 1、 解决“信息分区”问题
  • 2、解决“路径可预期”问题
  • 3、解决“功能发现”问题
• AI 出现后，导航被削弱的三个原因
  • 第一，任务直达替代层级查找
  • 第二，语义搜索替代功能浏览
  • 第三，系统级调度弱化 App 边界
• 那么，导航会消失吗？
• 第一种转型：从“主入口”变为“兜底机制”
• 第二种转型：从“功能分类”变为“能力分类”
• 第三种转型：从“固定结构”变为“动态结构”
• 鸿蒙环境下的特殊变量
  • 多设备下，导航本身可能消失
  • 分布式流转弱化页面概念
• AI 时代的导航设计原则
  • 1、导航必须可被 AI 替代
  • 2、导航不应承载业务逻辑
  • 3、导航结构必须支持动态生成
• 一个更激进的判断
• 总结

引言

过去十几年，移动 App 的导航结构几乎是“行业共识”：

• 底部 Tab
• 顶部导航栏
• 二级页面返回
• 三级页面层层深入

无论是 iOS、Android，还是如今的鸿蒙，我们都默认一个前提：

用户必须通过“导航结构”理解产品。

导航，是信息组织方式。
导航，是功能分配方式。
导航，甚至是产品战略的体现。

但当 AI 成为系统级能力后，一个问题开始变得尖锐：

如果用户不再依赖页面跳转完成任务，那传统导航结构还必要吗？

这不是“要不要保留 Tab”的问题。这是：

App 是否仍然以“页面”为中心。

传统导航结构的本质

我们先拆解传统导航到底在解决什么。

1、 解决“信息分区”问题

典型底部导航结构：

Tabs(){TabContent(){HomePage()}.tabBar('首页')TabContent(){OrderPage()}.tabBar('订单')TabContent(){ProfilePage()}.tabBar('我的')}

本质是：

用空间分区管理功能。

不同 Tab 代表不同功能域。

2、解决“路径可预期”问题

页面跳转结构：

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

这种结构让用户形成心理模型：

• 我从哪里来
• 我现在在哪
• 我要怎么回去

导航保证了“路径可解释性”。

3、解决“功能发现”问题

当用户不知道功能在哪时：

• 通过浏览 Tab
• 通过查看菜单
• 通过层级展开

导航承担的是：

功能曝光机制。

AI 出现后，导航被削弱的三个原因

AI 的出现，不是让导航消失。而是让它不再是唯一入口。

第一，任务直达替代层级查找

用户过去的行为：

打开 App → 找到订单 Tab → 点历史 → 查记录

现在可能变成：

“帮我查上个月的订单。”

const intent =await ai.parse('查上个月的订单')if(intent.type ==='QUERY_ORDER'){ orderService.query(intent.timeRange)}

这里已经绕过：

• 首页
• Tab
• 列表页

导航路径被“意图解析”替代。

第二，语义搜索替代功能浏览

传统搜索是：

search(keyword:string){returnthis.orders.filter(o => o.title.includes(keyword))}

AI 搜索是：

const result =await ai.semanticSearch({ query:'去年最贵的一笔消费'})

用户不再浏览分类，而是直接表达语义。

第三，系统级调度弱化 App 边界

在鸿蒙环境下，AI 不仅存在于 App 内。当用户说：

“把昨天的会议记录发给老板。”

系统可能完成：

1. 打开文档
2. 提取会议记录
3. 总结重点
4. 打开发送界面

await systemAI.compose(['查找会议记录','总结重点','发送联系人'])

这里：

用户甚至没有进入具体导航路径。

那么，导航会消失吗？

不会，但会发生三种转型。

第一种转型：从“主入口”变为“兜底机制”

导航将不再是主流程，而是：

当 AI 理解失败时的 fallback。

例如：

try{await ai.execute(intent)}catch{ router.pushUrl({ url:'pages/manual/Search'})}

导航变成安全网。

第二种转型：从“功能分类”变为“能力分类”

传统 Tab 是：

• 首页
• 订单
• 我的

未来可能变成：

• 任务中心
• 历史上下文
• 能力库

示例：

Tabs(){TabContent(){TaskCenterPage()}.tabBar('任务')TabContent(){ContextPage()}.tabBar('上下文')TabContent(){AbilityPage()}.tabBar('能力')}

页面从“功能集合”，转向“能力集合”。

第三种转型：从“固定结构”变为“动态结构”

AI 可以根据用户行为生成个性化导航。

const personalizedTabs =await ai.generateNavigation(userProfile)

再渲染：

Tabs(){ForEach(personalizedTabs, tab =>{TabContent(){DynamicPage(tab.id)}.tabBar(tab.name)})}

导航不再是写死的，而是：

数据驱动生成。

鸿蒙环境下的特殊变量

鸿蒙不是单屏系统，当设备包括：

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

导航结构的意义更复杂。

多设备下，导航本身可能消失

用户在车机上说：

“继续播放我昨天看的内容。”

系统直接恢复状态：

ai.restoreLastSession()

没有页面跳转，没有 Tab 选择。这是：

状态恢复型交互。

分布式流转弱化页面概念

import distributedData from'@ohos.data.distributedData'await kvStore.put('current_task', taskId)

另一设备读取：

let task =await kvStore.get('current_task')resumeTask(task)

用户感知的是任务流转，不是页面跳转。

AI 时代的导航设计原则

如果总结成三条：

1、导航必须可被 AI 替代

任何必须通过点击才能完成的核心功能，未来都会被 AI 覆盖。

2、导航不应承载业务逻辑

导航只负责“视图切换”，业务必须抽象为能力接口：

exportinterfaceAbility{ name:stringexecute(params: object):Promise<any>}

3、导航结构必须支持动态生成

固定结构，会限制 AI 扩展能力。

一个更激进的判断

未来三年，我们会看到三类鸿蒙 App：

1. 传统导航型（功能驱动）
2. 混合型（AI + 页面共存）
3. AI 原生型（任务驱动）

第三类应用中：

• 页面是渲染层
• 导航是备用层
• 能力才是核心层

总结

AI 时代，鸿蒙 App 还需要传统导航结构吗？答案是：

需要，但不再是中心。

导航不会消失，但它会从：

结构核心

退化为：

体验补充。

真正的核心，将从“页面组织能力”，转向：

• 语义理解能力
• 任务编排能力
• 分布式执行能力

当用户不再“点页面”，而是“表达意图”，我们熟悉的导航结构，将成为历史阶段的产物。而鸿蒙，正在为这种转型提供最适合的土壤。