我做了快三年鸿蒙应用从API 8一路跟到API 12最常被同行问的一句话是AI都这么强了Agent能把活直接干了App里那套底部导航、侧边栏、面包屑是不是该退休了尤其是HarmonyOS NEXT开始接入系统级AI能力之后产品经理在评审会上最爱提一个需求——把导航藏起来让用户“直接说就行”。这篇文章我想认真聊聊这个话题。先给结论传统导航结构不会死但它的地盘正在被AI一点点蚕食。到底砍到什么程度、保留哪些结构、鸿蒙生态下怎么做决策我会从用户行为、系统能力、实际案例三个角度拆开讲。适合正在做鸿蒙原生应用、或者准备把存量App迁移到HarmonyOS NEXT的开发者、产品经理看。1. 传统导航到底在解决什么问题理解它才有资格说“不要”在讨论“AI是不是要干掉导航”之前得先把传统导航的底层逻辑说清楚。导航不是设计风格不是交互趋势它是信息架构的具象化。你砍掉导航栏之前得先搞清楚那根栏到底在替你扛什么活。1.1 导航设计的本质是补偿人的认知局限传统导航结构——底部Tab、侧边栏、列表页、面包屑——本质上都是给用户“指路”的。为什么需要指路因为用户的短期记忆容量极其有限心理学上经典的研究表明人在做决策时能同时记住的选项大约只有7个左右。当一款App的功能数量超过这个阈值用户就必然依赖外部化的结构来理解“我在哪”“我能去哪”。我用一个生活类比说明如果你家只有三间房进门不需要地图但如果你家是一栋三十层的写字楼大厅里就必须有楼层索引和指示牌。App的导航栏就是那套楼层索引。它的存在不是为了好看而是为了把复杂的功能空间压缩成用户能理解的二维地图。传统导航通常分为三个层级全局导航告诉用户整个App有哪些区域、局部导航告诉用户当前区域内有哪些内容、上下文导航告诉用户当前页面内部如何跳转。打个比方全局导航相当于城市主干道局部导航相当于街区路牌上下文导航相当于导航软件里“前方500米右转”的实时语音。这三层结构配合起来用户才能不迷路。1.2 传统导航承担的四个核心价值我做了很多次用户调研和可用性测试之后总结出传统导航至少承担四个不可替代的职责第一是可发现性。用户需要知道“你这个App里有什么”。很多功能用户不是不需要而是不知道你有。没有导航结构用户只能靠猜有了导航用户扫一眼就知道这个产品的功能边界。第二是空间感知。用户需要知道自己现在处在App的什么位置。比如在电商App里用户需要清晰感知“我是在首页还是在分类页还是在购物车”失去位置感用户会焦虑会怀疑自己是不是点错了。第三是任务切换。用户的使用路径往往不是直线的经常需要在多个任务之间来回切换。比如用户逛着社区突然想回首页搜索再回来看消息通知。底部导航支持这种高频任务间的“穿梭”这是线性对话流很难替代的。第四是品牌认知与信任。导航结构本身也是一种品牌表达。用户进入一个界面熟悉的布局能提供安全感。这一点常被技术思维主导的人忽略但它在用户留存上影响很大。1.3 AI改变的是路径不是地图所以我的一个核心判断是AI Agent很强它改变的是“从A点到B点的走法”——以前需要用户一屏一屏自己翻过去现在可以一句话直达。但用户的“目的地”本身以及“他是否知道该去哪里”这仍然需要地图来解决。关键在于AI只能解决“用户明确知道自己要什么”的那部分需求。但当用户打开情感社区、内容资讯、电商种草这类产品时大量用户行为本身就是漫无目的的我来逛逛我看有什么新鲜的我随便翻翻。这种“探索型需求”AI是没法替代的——你没法对着AI说“随便给我点好玩的”然后还享受到那种一屏一屏划过去的“逛”的感觉。所以我的结论很明确传统导航不会消失但它必须进化。它承担的职责会从“引导用户找到功能”逐步转向“给用户提供一个稳定的空间结构让AI的高效直达有落点”。2. 鸿蒙生态下的导航逻辑卡片、意图框架和分布式能力改变了什么脱离了鸿蒙生态单聊“AI能不能取代导航”是没有意义的。鸿蒙真正特殊的地方在于它从系统层面提供了一套“绕过App导航结构”的能力组合。这套能力组合我在华为的开发者文档里翻了很久再加上自己在真机上的实测总结成一句话鸿蒙把“入口”这件事从App内部拆出去了。2.1 鸿蒙的三板斧元服务、服务卡片和意图框架鸿蒙给用户提供了三条不经由App内部导航就能触达功能的路径元服务。这是一种无需安装、即点即用的轻量服务形态。用户不需要下载完整的App也不需要打开App并层层导航直接在桌面、负一屏、小艺建议里点一下就能用。这相当于把App里的某个子功能“拆下来”贴到了系统桌面上。服务卡片。鸿蒙的服务卡片可以直接显示信息并支持交互。用户不需要进入App在桌面就能看到天气、快递进度、播放器控制。相当于App里最常用的几个操作区域被“投影”到了系统桌面。意图框架。这是鸿蒙在API 10之后逐步开放的系统级推荐能力。系统会学习用户的使用习惯在合适的时机推荐合适的服务。比如你每天早上八点会查地铁乘车码到了时间系统自动把乘车码服务推到负一屏、小艺建议卡片。这套机制的核心是“系统提前帮你把导航做了”。2.2 卡片和意图框架的实际能力边界它能替代哪类导航我在真机上反复测试过这三个能力也跟华为的FAE交流过。我的结论是它们替代的是App内部的“功能级导航”而不是“空间级导航”。什么叫功能级导航就是“用户明确知道要去用哪个功能”只是需要一个入口。比如打开地铁码、打开付款码、播放音乐——这些是单一高频动作服务卡片和意图框架能完美覆盖。我的App做了一个快递查询功能接入服务卡片之后用户查快递的日均操作步骤从“解锁手机—打开App—点首页Tab—点查询入口—输入单号”五步降到了“解锁手机—看桌面卡片”两步这确实很猛。但它们做不了“空间级导航”。什么叫空间级导航就是用户需要理解“我目前处在一个什么服务里周围还有什么其他服务”。地铁码直接弹出没问题但用户如果想知道“这个交通服务App里还有什么功能”卡片就给不了了。还有一个关于意图框架的现实局限它只有在用户行为足够规律、需求足够稳定时才有效。也就是说它基于的是“过去的行为预测”对“用户突然产生的新需求、新探索场景”是反应不过来的。用户第一次想通过App找附近的餐厅系统不可能在他还没进行过类似操作前就把餐厅列表推给他。2.3 分布式能力导航跟随设备变形态鸿蒙的分布式能力还带来一个其他系统没有的变量——应用可以跨设备流转。用户在手机上看到一半的内容可以流转到平板、车机上继续使用。这意味着导航结构不再是单个屏幕的静态布局而是要跟随设备形态自动切换。我在车机版本的适配中做过一次实际验证手机端的底部五Tab结构流转到车机上如果还保留驾驶场景下用户根本没精力去点。所以车机版本砍掉了几乎全部传统导航主要以语音交互大卡片为主。但我们保留了“首页”这个最基础的结构节点目的是让用户始终知道自己还能回到哪里。这里要特别提醒一点跨设备导航的连续性非常容易被忽视。用户在手机上通过底部导航进入了“消息通知”页流转到平板上之后如果平板没有消息通知这个入口用户会瞬间懵掉。所以做分布式适配时导航结构可以变但功能层级必须保持一致否则用户流转一次就迷路一次。3. 哪些产品可以大胆砍导航哪些砍了必死一套可落地的判定框架这是我在内部培训、公开分享中反复使用的分析框架。做产品设计的人最怕的不是选错方案而是“所有人都在跟风”。AI一来人人都想学那些完全对话化的激进产品结果就是自己产品的高频功能上去了低频功能被埋没了用户开始狂点“客服反馈”问“你们那个XX功能去哪了”。3.1 适合激进改造的三种产品类型从我实际接触的几十款应用里看能在大幅削减传统导航后依然活得好的产品逃不出这三类第一类是单功能工具型。功能就三五个用户打开就是为了干一件事。比如手电筒、水平仪、扫码工具、词典查询、单位换算这类工具用户目标明确、操作时间短、离开速度快。对这种应用来说传统导航本来就是累赘AI对话式入口不仅能替代导航还能提升效率。第二类是强任务闭环型。用户进App是奔着一个明确任务来的任务路径清晰、步骤化明显。比如打车软件用户的核心动作就三件事叫车、看司机位置、支付。点餐软件也类似选餐、下单、等餐。这类产品中AI Agent能非常高效地完成“用户表达需求—系统解析需求—直接进入目标动作”的闭环导航栏的角色退化为一个“服务状态展示区”而不是寻找功能的入口区。第三类是AI优先型新产物。这类产品一出生就把“对话”作为主界面导航结构天然就是辅助的。用户打开就是聊天框所有功能都通过自然语言触达。这类产品里还保留的少量导航主要服务于账号、设置、历史记录这类“元信息”而不是“功能”。3.2 砍了必死的三类产品反过来以下三类产品谁砍导航谁出事第一类是内容消费型平台。资讯、短视频、社区、电商类产品。用户核心体验在于“浏览”过程中发现的快乐。你有没有想过为什么抖音到现在还是上下滑动这个“一维导航”结构因为浏览路径本身就是产品体验的一部分。如果全变成语音指令“帮我看下有什么好看的”用户的娱乐行为就变成了任务行为——这种产品体验是反人性的。第二类是专业工具型软件。开发工具、设计工具、数据分析后台、设置管理面板。这些产品功能高度复杂、层级很深用户往往需要同时掌握多个功能区域且操作需要反复切换上下文。以IDE为例编辑器、文件树、控制台、搜索面板缺一个都会产生很大的使用障碍。这类产品的“导航”已经不是一种设计选择了而是工作台结构本身。强行改成对话式会让原本几十秒就能完成的精确定位操作变成一场与AI的“猜谜游戏”。第三类是超级App。功能横跨多个大领域用户群巨大且身份多元。这类产品里导航承担的核心职责已经从“效率”变成了“身份确认”——用户在特定场景下知道自己正在使用哪个角色、哪套工具。如果把导航砍了用户面对一个只有一个对话框的微信是没法同时管理聊天、支付、小程序、视频号的。3.3 业务自检表五个维度打分我给自己团队定了一套简易判定表这里分享给大家做设计决策前花十分钟过一遍基本不会走偏判定维度高分解读更适合保留导航低分解读可削减导航功能数量超过10个独立功能域少于5个核心功能任务复杂性涉及多层级操作与上下文切换单路径线性操作用户停留时长超过5分钟/次高频回流低于2分钟/次即用即走随机探索需求用户常自助漫游发现内容用户目标固定、路径明确多角色场景支持工作/生活/学习等多身份面向单一角色这五个维度里只要前三项中的任意两项落在“高分”区间我都建议保留完整的传统导航框架。反之如果功能少、任务简单、停留时间短那就可以大胆地让AI对话替你做入口。4. 鸿蒙上保留导航的正确姿势把AI嵌进结构里如果你的项目跑完上面的判定表结论是要保留传统导航那恭喜你接下来这个问题你需要认真研究鸿蒙上的导航跟安卓和iOS上的导航设计有什么不同怎么让AI能力在传统导航里“接力”而不是“抢班”4.1 鸿蒙底部导航的实现基础Tabs组件与自定义TabBar老规矩先给一套可运行的最小实现。HarmonyOS NEXT的ArkTS里底部导航最常见的方式是用Tabs组件加TabContent每个Tab对应一个内容区。这是最基础的写法Entry Component struct MainView { State currentIndex: number 0 private controller: TabsController new TabsController() build() { Tabs({ barPosition: BarPosition.End, controller: this.controller }) { TabContent() { HomePage() } .tabBar(this.buildTabBar(0, 首页, resource:///media/home.png)) TabContent() { DiscoveryPage() } .tabBar(this.buildTabBar(1, 发现, resource:///media/discover.png)) TabContent() { MessagePage() } .tabBar(this.buildTabBar(2, 消息, resource:///media/message.png)) TabContent() { MinePage() } .tabBar(this.buildTabBar(3, 我的, resource:///media/mine.png)) } .onChange((index: number) { this.currentIndex index }) } Builder buildTabBar(index: number, title: string, icon: string) { Column() { Image(icon) .width(24) .height(24) Text(title) .fontSize(12) .fontColor(this.currentIndex index ? #FF3C3C : #999999) } } }这里有个容易被新手踩的坑TabContent的tabBar如果直接传字符串就丢失了自定义样式的能力但如果你用Builder手写tabBar就必须处理一个“选中态刷新”的问题。上面的写法里我通过this.currentIndex的变化来动态改变文字颜色这个方案是可行的但要注意Builder内部依赖State变化触发的重新渲染如果你把构建参数传成一个普通对象刷新会失效。如果你对交互动效要求更高还可以在自定义tabBar里加一个小的过渡动画。我实测下来的经验是鸿蒙的隐式动画配合Tabs切换手感已经接近原生动画时长控制在150ms左右比较合适太快了没反馈感太慢了影响重度用户的操作节奏。4.2 把AI能力嵌进导航而不是替代导航保留导航不意味着对AI无动于衷。我建议做三件事让AI能力在传统导航框架里发挥价值第一增加一个全局AI搜索入口位置放在全局层。这个入口要保证用户在App的任何页面都能找到。我的经验是做成底部Tab中间的“AI助手”键或者顶部的搜索胶囊都可以。它的职责不是替代导航而是提供一条“捷径”。用户的路径从“找功能—翻列表—层层进入”缩短为“唤起AI—说需求—直达结果”但导航结构仍然完整。第二基于用户行为做Tab的智能排序。鸿蒙侧有端侧AI能力可以低延迟地完成行为学习。比如用户连续七天打开App都先看“消息”那就自动把消息Tab挪到第一位并给一个小小的视觉提示“已为你调整顺序”。需要注意的是不要做剧烈的自动布局变化用户对位置突变非常敏感一次只动一个位置而且要给用户手动固定的能力。第三AI预测与页面预加载。结合意图框架系统可以判断用户下一步大概率跳往哪里提前把目标页面的数据预加载好。举例来说用户每天早上会在App里看运营数据报表AI学习到该规律后用户在启动App的瞬间报表页就已经加载完毕。用户点进Tab时体感是“秒开”。这不是替代导航而是让导航“无感加速”这恰恰是传统导航活得久的关键。4.3 我要分享一个反面案例为了“AI感”砍掉导航后的惨痛教训我们团队在去年做过一次激进改造——为了配合AI概念把一款工具型App的底部四个Tab砍成一个“智能助手”Tab里面是对话界面所有功能都靠AI触达。结果上线两周数据惨不忍睹功能和页面的日均PV下降了57%客服端涌入了上千条“XX功能去哪了”的问询。复盘后我们发现问题不是AI能力不够而是AI无法解决“用户不知道自己要说啥”的问题。用户用“智能助手”里的对话去说“我想看订单记录”AI勉强能懂但让用户说“我想用你们刚上线那个新功能”用户根本不知道功能名称他只能靠导航里看到的菜单名称去描述。导航本质上是在帮用户学习“产品的语言”。没有导航用户连给AI下指令的能力都不完整。那之后我们的策略是保留完整传统导航AI作为“叠加态”存在。用户可以在导航里正常找功能也可以在AI入口里直接说需求两条路径并行。改动后又跑了一个月核心数据恢复到了改造前水平高频用户的平均任务时长反而下降了约三成——因为那部分高频用户很快就学会了用AI直达但低频用户仍然靠导航兜底。5. 不同设备上的导航生存空间车机、手表、平板各有各的活法鸿蒙的一个独特性在于多设备覆盖。讨论导航结构时不把设备形态考量进去是不完整的。我在手机、平板、手表、车机上都做过鸿蒙应用的适配可以直接给结论设备越小、使用场景越专注传统导航死的越快设备越大、使用场景越开放传统导航活得越稳。5.1 四类设备的导航形态对比手表端屏幕就那么大底部导航基本只能放一个主页面其他功能全部下沉到语音和卡片里。我们在手表上做App时甚至直接就不做导航栏用一个主功能页加一个系统卡片就完成了全部交互。车机端核心场景是驾驶交互优先级永远是“不分心”。所以语音是绝对主导菜单是辅助。传统导航只保留一个“首页”作为安全底座让用户可以在任何迷路时一键回主界面。折叠屏/平板端屏幕空间宽松但场景更接近办公和深度阅读底部导航让位给侧边导航更合适。鸿蒙的侧边导航通常用Navigation组件实现支持收起展开比底部导航更有优势。手机端仍是导航结构的主战场。但未来的方向我认为是底部导航数量会减少——从普遍的四到五个Tab收敛到三到四个让出位置给AI入口。我整理了每个设备上导航结构的推荐配置表设备类型推荐导航形态保留的核心原则手机底部三四Tab 全局AI入口高频全域可达平板/折叠屏侧边导航 分栏内容区并行多任务信息密度优先车机语音主导 首页底座分心最小化路径最短化手表单主页面 服务卡片一屏一任务极简交付这里的核心规律是导航结构的复杂度应该与设备的“注意力预算”成反比。用户在电脑前有充足的注意力可以探索在手表上只有扫一眼的注意力因此导航必须被压缩到极致。5.2 分布式流转下的导航连续性问题鸿蒙支持跨端流转这带来了一个其他平台上几乎不用考虑的难题导航结构随设备切换后用户的任务上下文能不能连续我举一个自己踩过的坑。我们App在手机端有传统的四Tab导航流转到车机后因为车机砍掉了导航用户被自动带到了车机首页。结果用户在手机上正在填一个表单流转到车机上后直接跳到首页用户瞬间不知道自己在哪、刚才填的东西还能不能继续。后来我们的解决方案是流转时强制携带“页面栈信息”目标设备接续后先恢复原页面再根据设备形态判断是否需要展示导航。这个逻辑不多但能给用户一种“虽然地图换了但我还在原地”的安定感。我强烈建议所有做鸿蒙多设备适配的团队上线前专门做一轮“流转状态下的导航迷失测试”手机开着一个二级页面流转到平板、车机上看看用户能不能在三秒内说出“我现在在哪、能去哪、刚才做到哪一步了”。这三句话答不上来就是导航连续性没做好。6. 我对“AI时代鸿蒙App导航结构”的最终判断这篇文章里我一直没有给一个非黑即白的答案。现在让我把判断说得再直接一点。AI时代的鸿蒙应用传统导航结构不会消失但会完成一次角色转换从“唯一的路径提供者”变成“稳定的结构底座AI直达的辅助通道”。未来最主流的App形态大概率不是全对话式的激进改造也不是现在这种没有任何智能的传统布局而是两层结构的混合体——底层是清晰的层级导航保证可发现性和安全感上层是智能入口提供一句话直达的高效通道。在鸿蒙生态中系统级的卡片、元服务、意图框架、分布式流转已经在系统性承接“入口”的职责。App作为开发者要把精力放在两件事上一是打磨底层信息架构让导航本身更清晰、更稳定二是让AI能力无缝叠加在这个架构之上让用户既能“看着地图走”也能“让AI带你飞”。从我的实际操作体会来说判断一个App需要保留多少导航最可靠的方法不是看技术趋势、不是看友商怎么做而是回去看自己的用户行为数据如果用户习惯在首页四处探索导航就得留着如果用户每次进来都是同一两条路径走到底那就大胆把导航砍掉、把AI入口做大。数据不会撒谎用户用脚投票的速度比你想象中快得多。我团队接下来的规划是把App里的AI能力进一步下沉到每个Tab页内部而不是单独做一个AI入口Tab。让用户在浏览内容的过程中随时可以呼出AI完成信息提取、对比、摘要——让智能像水一样渗透在传统导航的毛细血管里而不是站在导航旁边当一个大喇叭。这条路我还在摸索中以后有阶段性成果了再回来跟大家汇报。