1. 老 App 的“信息迷宫”传统信息架构的三个硬伤先说结论信息架构不是因为用了鸿蒙才存在的问题它本来就是我们日常开发中一直在将就的问题。我做移动端架构这些年最怕听到一句话“这个功能埋得有点深用户找不到。”每一次收到这种反馈常规动作就是改菜单层级、把入口往首页挪、给按钮换一个更显眼的颜色。但说白了传统 App 的信息架构是一棵静态的树用户必须被动适应这棵树的分叉方式适应不了就是迷路迷路了就只能反复点击或者放弃离开。鸿蒙App 刚出现的时候不少人以为换一套 UI 框架、把页面从原来的代码迁移过来就够了。但真正到多设备协同、原子化服务铺开之后传统信息架构的僵硬就暴露得更明显了。这里我先把三个最常见的病根拆开讲后面你才会明白 AI 为什么能对症下药。1.1 树状目录越做越深用户越走越晕绝大多数传统 App 的信息架构本质上就是一个深树顶部导航、一级分类、二级分类、筛选项、详情页。每往下多一层用户流失就会翻一截。信息架构领域有个粗糙但实用的经验值多一个层级任务完成率可能要打对折。尤其在手机屏幕上用户没有耐心也没有视觉线索去记忆上一级在哪里。我之前接手过一款功能特别全的工具类应用光设置和各种工具入口就有三百多个。为了“看起来整齐”团队给首页设计了三层菜单加一个“更多”结果用户找“如何清理缓存”花了四十多秒还有人反馈“找不到就卸载了”。可用性测试里最典型的一幕是用户凭直觉点进一个分类发现里面没有想找的东西后退两步之后直接僵住他已经搞不清楚刚才是在哪个层级进来的。传统解决思路是加“猜你喜欢”“最近使用”但这只是在一个静态层级上贴了一块创可贴。推荐位越多用户越需要扫视和过滤信息架构本身还是那个迷宫。1.2 搜索只能拼关键词语义理解等于零树状导航失效之后搜索框被当成救命稻草。但传统搜索的匹配逻辑非常脆弱用户搜“跑步鞋”商品标的是“sneaker”匹配不到用户搜“怎么关通知”帮助文档里写的是“关闭消息提醒”也匹配不到。关键词搜索本质是在做字符串比对不是理解你在问什么。更尴尬的是用户经常用一段完整的话去搜索比如“晚上睡觉总觉得吵想开勿扰模式”。传统搜索引擎会把句子拆成“晚上”“睡觉”“吵”“勿扰”然后返回一堆既包含这些词、又完全不相关的结果。用户试两次找不到就会认为这个 App 根本不好用。在鸿蒙这样的多设备场景里这个问题还会被放大。手表上的搜索框根本没有键盘输入条件用户靠语音提问经常带着口语的冗余和模糊。如果底层还是关键词匹配那“把亮度调低点”和“屏幕太刺眼”就完全是两个世界的东西。1.3 页面千篇一律信息没有优先级传统信息架构还有一个隐蔽的问题它完全不看上下文。同一个首页凌晨两点的用户和早上九点的用户看到的内容一模一样新安装用户和老用户看到的功能顺序一模一样在办公室里和在户外走得满头大汗的用户面前还是那一套固定卡片。因为页面是静态的所以设计者只能提前把“最重要的功能”排在前面但这个“重要”是针对平均用户定义的。实际使用中每个用户的优先级不一样、每个时刻的优先级也不一样。用户被迫自己在一堆固定信息里找自己当前需要的那一条信息架构呈现的是一维的毫无差别的信息流。这种静态结构在单一设备上已经够累了放到鸿蒙的分布式环境里就更不合理同一套信息架构如何在手机、平板、手表、车机上同时成立难道每个屏幕都显示一样的菜单深度传统 IA 无法回答这个问题因为它从一开始就没考虑过“信息应该围绕用户动态流动”这件事。2. 鸿蒙生态给 AI 改造铺好的路原子化服务与分布式软总线在我讲具体怎么用 AI 之前先说说为什么鸿蒙这个平台特别适合做信息架构改造。这不是因为我多喜欢这个生态而是因为它的两个基础特性恰好补足了传统 App 在结构上的短板。2.1 原子化服务信息架构的最小单元从“页面”变成“服务”传统 App 的最小信息单元是“页面”页面之间是路由关系。所以信息架构本质上就是页面拓扑图从哪个页面进、跳到哪个页面、回退到哪一层。鸿蒙里的原子化服务把最小单元变成了“服务”用户可以直接触发某个功能不一定非要先进 App 再往下钻。这个变化很关键。页面强调的是“位置”服务强调的是“能力”。一个“查快递”原子服务它可以从语音助手的推荐里直接拉起来也可以从桌面卡片点开还可以在另一个设备的协同卡片上继续显示。它不依赖你在哪个菜单层级它是独立存在的。AI 非常适合做“服务编排者”。因为 AI 的输入是用户意图输出是调用某个服务有了原子化服务之后这个调用路径就可以不经过传统导航树。比如用户说“帮我看看明天天气再顺手订个明早的闹钟”意图识别模型可以把这拆成两个服务查询天气服务、设置闹钟服务。传统信息架构里这需要用户先找到天气模块再退出再进闹钟模块。而现在 AI 只需要调度两个服务并且让它们共享一个上下文中间不需要任何菜单中转。2.2 分布式场景同一个意图多个设备自动接力鸿蒙的分布式软总线让设备之间可以互相发现、共享数据和能力。这意味着用户在手机上处理一半的任务可以无缝转到平板上继续在车机上卡住的流程到家之后由智能家居设备接上。传统信息架构在单设备内可以靠页面跳转完成跨设备就变成了一座座孤岛。分布式场景下的信息架构重点不再是屏幕上的菜单长什么样而是用户当前在哪个设备、处于什么场景、他的任务应该如何被迁移。AI 在这里的价值是承接连续性用户问“我刚才那个文档草稿在哪”AI 能确认来源设备、调取文档服务、在当前设备上打开而不是让用户先回忆“我是用哪个设备存的、存到哪个目录了”。所以我说鸿蒙给 AI 改造铺好了路原子化服务提供了可调用的最小粒度假对象分布式软总线让 AI 的调度可以跨设备生效。传统信息架构是“页面从哪进”AI 信息架构是“用户想干什么该由谁来干”。3. 我用 AI 重构检索与导航的完整思路在具体改造某款鸿蒙工具类 App 的时候我没有一上来就推倒所有页面重做。那样风险太高团队也没办法向业务方交代。我的做法是先选两个最影响体验的环节做改造检索和导航。这两个环节正是传统 IA 最僵硬的地方而且用户感知最强改完能立刻看到效果。3.1 语义检索替换关键词搜索用户的自然语言就是查询条件第一件事是把搜索从关键词匹配升级成语义检索。实现路径并不复杂核心是三段式流水线先把所有功能项、帮助文档、服务卡片的内容做向量化存进向量索引用户输入查询时同样向量化然后做相似度召回最后用一个轻量级排序模型把召回结果重新排序只保留最相关的几个。举一个实际例子。功能库里有这样一条设置勿扰模式的说明原始文档写的是“如何开启免打扰”。用户直接用自然语言输入“睡觉时别响”关键词搜索绝对查不到“免打扰”这个词。但在语义检索里“睡觉时别响”和“免打扰”的向量距离非常近召回结果里就能正确返回这项功能。类似场景还覆盖了同义词、口语化表达、甚至中英文混搭。为了控制延迟我没有把向量化计算全部放在云端。在端侧用小模型做实时向量化把功能索引的向量表预置到本地。查询时用近似最近邻检索ANN快速召回候选集再让云端大模型做重排序兜底这样大部分查询在端侧就能返回不需要每次问问题都等待网络。这里有一个容易被忽视的关键点召回结果不等于最终展示结果。传统搜索把召回结果按某种分数直接呈现给用户经常出现“看起来相关但完全不是用户要的东西”的悬浮窗。我加了一个过滤层专门剔除实体不匹配的结果。比如用户搜“充电”召回里同时有“充电口在哪里”和“关闭充电声”过滤层确认当前用户想看的是“功能位置类”信息就把后者压到更靠后的位置。3.2 意图识别驱动的动态导航菜单不再是画死的语义检索解决了“搜索框”问题但树状目录的根子还在。我的做法是把导航也从静态配置改成动态装配先识别用户当前意图再根据意图生成最短路线的功能入口。具体来说我在用户发起操作之前加了一个轻量级意图识别模型。它输入的是用户当前场景页面停留、语音指令、历史行为、时间地点输出的是意图标签和实体参数。这个标签不直接映射到页面而是映射到服务动作。比如“用户查询‘怎么设闹钟’”会打成“alarm_setup”然后导航配置层查到对应的服务是“设置闹钟”直接弹出或跳转。导航配置我做成了一份结构化映射表AI 输出的意图标签只是其中一个字段并不负责直接决定跳转目标。这样做的原因是模型会犯错但人工可以直接改配置表来兜底。比如下面这段简化 JSON{ intent: alarm_setup, confidence: 0.86, action: navigate_to_service, service: smart_alarm, params: { source: voice, device: phone } }当置信度高于 0.8 时系统自动导航到服务置信度在 0.6 到 0.8 之间时系统不直接跳转而是在当前页弹出一个悬浮建议卡让用户确认“你是不是想设置闹钟”置信度低于 0.6 时就退回传统导航界面不让 AI 瞎指挥。这个置信度分档设计非常关键它既保持了智能感又给了用户纠错的机会。动态导航和传统菜单不是互斥的。我的经验是让 AI 先生成路径但如果用户反复在某个页面上找不到目标入口传统菜单会保留在二级层级作为兜底。你可以把它理解成“AI 优先铺路导航树永远在底下接着”。4. 内容层动态折叠AI 怎么让页面自己“变短”检索和导航改造之后还有一个层面的问题没有解决内容页面本身的呈现方式。传统页面上无论什么用户、什么时刻、什么设备内容都是一股脑全铺开。AI 改造到这一步我开始动内容层目标是让页面学会“动态折叠”——根据用户语境自动展开需要的内容自动收起当前不太重要的内容。4.1 信息标签化给每条内容打上可计算的“语义指纹”要做动态折叠前提是页面上每一块信息都能被 AI 理解。我建了一套标签体系把功能按钮、帮助文字、卡片数据都打上结构化元数据类似给每条信息盖一个可计算的“语义指纹”。这里举个例子一个设置了“电动车充电状态”的卡片标签可能是[device, charging, status]一个“查看历史充电记录”的按钮标签可能是[device, charging, history]。当 AI 判断用户当前关注“设备状态”时它就会优先展开充电进度相关卡片把历史记录入口折叠到次级操作区当用户明确搜索“历史记录”时它又立刻把历史列表提上来。标签体系不是越多越好太细反而会让模型无所适从。我建议优先做三个维度功能类别、操作频率、上下文敏感度。功能类别决定它属于哪一簇操作频率决定它在普通状态下的默认位置上下文敏感度决定它是否容易被动态唤起。这个架构很像给一本书做目录但每一条目录旁边多了一堆索引标签让搜索引擎能根据不同的切口快速找到内容。4.2 场景化聚合同一个用户在不同状态下看到不同的信息密度有了标签之后页面的动态性就能落地了。我的实现逻辑是不直接让 AI 重写界面而是在原有布局层之上加了一个“展示密度控制器”由它对页面模块做排序、显隐和折叠。控制器接收意图识别结果、用户画像和设备类型输出一个页面装配方案。举个例子晚间十一点用户在手机上打开智能家居控制页。传统页面会把灯光、窗帘、安防、能耗等模块全部平铺。经过 AI 动态聚合之后页面优先展示睡眠相关场景——灯光调整、空调睡眠模式、勿扰模式能耗统计和历史记录这些低频内容被折叠到二级入口页面高度缩减了一倍以上。这种动态折叠不是简单地把内容藏起来而是改变信息密度。在平板这样的大屏设备上AI 反而可以增加密度把更多模块放上来利用多栏布局让用户一眼看到更多可行操作在手表这样的小屏设备上则只保留最核心的一到两个功能卡片其余全部收进菜单。它和传统“千人千面”推荐有一个核心差别推荐结构依赖的是用户历史画像而场景化聚合依赖的是当前意图和当前上下文。同样是前一次买过跑步鞋用户今天搜的是维修保养页面就该把维修入口提上来而不是继续推跑步鞋。AI 的目标不是“让你多逛一会儿”而是“让你尽快到达你想做的事”。5. 实测改造中的坑与取舍数据延迟、误判和调试任何智能化改造都不可能一路顺畅我也一样。看到效果的同时遇到了一堆在文档里写不到的现实问题。这一节我把最有代表性的几个坑展开聊聊都是直接踩过的。5.1 意图识别“用力过猛”的教训第一次上线意图识别时我犯了一个典型错误模型把用户的一句抱怨理解成了强烈意图。当时有用户反馈“这个设置也太难找了吧”系统直接判定“用户想关闭设置页面”弹出了一个退出确认弹窗用户当场就懵了。后来翻日志才发现模型把“难找”和“离开”绑定得太近置信度还给了 0.7 以上。这件事让我学到一个原则意图识别要先做否定过滤。不是所有带有情绪的文本都需要触发某个功能跳转负面情绪往往意味着用户需要帮助而不是真的想退出。我在模型前面加了一个情绪抑制层当文本包含“太麻烦”“找不到”“怎么还不显示”这类表达时系统不直接导航改为展示关联帮助卡片让用户选择是否继续。另外一个修正策略是“候选确认”。凡是置信度处于中段区间的结果一律先给建议卡片而不是直接跳转。虽然多了一次点击但大幅减少了误触带来的迷失感。用户被 AI 带错方向一次他的信任感损失远超一次主动确认的成本。5.2 个性化过度投放导致的信息茧房动态导航跑了一段时间后新的问题又出现了信息茧房。因为 AI 会根据历史使用频率调整展示优先级低频但真实存在的功能会被越压越深。有个用户想要开发票但这个功能他半年才用一次结果在动态导航里怎么翻都找不到最后只能靠传统搜索硬搜。个性化排序的悖论就在这用户过去没做过的事不代表未来不会做低频功能恰恰是最需要的是保障稳定的入口。我的修正方案是把个性化分成两层显式搜索时不参与个性化过滤用户明确输入关键词时全局匹配优先级最高浏览式导航时才做个性化调整。同时给每个模块设置最小展示概率保证再冷门的功能也有机会出现在页面里而不是完全被算法屏蔽。回想起来这个问题本质上是“效率优先”和“可预期性”之间的矛盾。AI 可以做动态推荐但必须保留用户可预期的传统路径。全自动的个性化导航会让用户在每次打开页面时都面临一个“移动的沙盒”这种不确定性比多找两步更让人焦虑。5.3 可观测性设计没有日志AI 导航就是一个黑盒传统页面跳转有完整的路由日志出问题能快速定位从哪个页面进的、点击了哪个按钮、跳到哪里。AI 导航出现问题时可观测性却非常薄弱。如果不提前埋点你根本不知道用户在看到什么推荐、为什么选择了它、又为什么放弃了它。我在改造中额外加了两类日志。一类是“决策日志”记录意图识别模型的输出标签、置信度、候选列表、最终动作。另一类是“纠正日志”记录用户在 AI 建议之后是否主动点击了其他入口或者是否撤销了一个导航。这两类日志合在一起基本能还原每一个用户会话从“他问了什么”到“AI 给了什么”再到“他最终接受了什么”。有一个调试案例我们反复收到用户投诉说“语音设置闹钟不能用”但用户明明成功打开过设置闹钟服务。后来通过日志回放发现模型确认了意图却导错了服务参数导致打开的是一个固定闹钟界面而不是语音输入的闹钟界面。这种问题没有日志根本不可能定位。AI 改造不是加一个模型那么简单可观测性必须同步建设否则上线之后你就是在盲飞。6. 对技术团队的四条实在建议最后这部分算是给正在准备做类似改造的团队一点经验汇总。没有放之四海皆准的方案但下面这几条是我认为值得记住的。6.1 别一次推到重来先用旁路模式验证AI 导航的改造风险最高的阶段是刚上线那一下。我强烈建议先做旁路模式AI 在后台运行只记录预测结果但不实际改变界面对用户不可见。等到积累一周的真实数据和用户对照行为再评估“如果让 AI 接管导航用户任务完成率会不会提高”。旁路模式的好处是你有机会用真实数据检验模型而不必承担导航出错影响用户的风险。我当时跑了两周旁路发现模型在三个高频场景上预测准确率超过九成才敢逐步放开导航权。这个过程很像换心脏之前先做体外循环一定要把旧机制保住等到新机制证明自己稳定之后再慢慢接管。6.2 给用户留一个“非智能模式”的逃生通道不管 AI 做得多么顺滑总有一部分用户会觉得被算法牵着走。我在设计中特意加了一个“经典模式”开关切换后所有动态导航、个性化排序全部关闭恢复最传统的菜单结构。这个开关大部分时候很少有人用但它的存在本身就很有价值它让用户知道你不是在剥夺他的控制权。从心理学角度看对 AI 的不信任有时候不是因为准确率而是因为失去掌控感。一个显式逃生通道能显著降低这种不信任。即便用户最终不切过去他也知道有退路愿意多试试智能推荐。6.3 衡量指标要从点击率变成任务完成率传统信息架构好不好团队通常看点击率、页面停留时长、跳出率。这些指标对 AI 导航并不适用。AI 最该优化的其实是“任务完成率”和“平均任务落地时长”。如果一个用户一进来就能直达他要的页面点击率可能反而下降——因为他不需要再四处逛这不是坏事而是好事。我在改造后的报表里把“从搜索到目标功能的转化率”“从意图出现到任务完成的平均步骤数”作为一级指标点击率只作为参考。几乎每一版迭代看着任务完成率上升用户投诉下降我才确认改造方向是对的。6.4 信息架构师的技能清单要扩展传统信息架构师主要画页面流程图、写功能目录、做导航原型。有了 AI 之后这个岗位需要懂一点模型评估知道意图标签怎么定义会构建标准测试集来判断导航是否击中目标。这并不意味着架构师要去调模型而是要能提出类似“用户问这句话的时候系统应该怎么反应”的问题并把答案固化成配置和测试用例。信息架构从一次性设计变成了持续迭代的体系。每一次模型更新架构师都要跟着做一轮回归测试比较新旧模型在测试集上的表现抽查误判样本确认低频功能入口没有被折叠掉。我们团队现在每次发版之前会专门跑一遍“核心路径回归”确保 AI 再怎么调整用户最常用的几个功能永远不会变难找。信息架构不会消失它只是从“画在原型图上”变成了“跑在模型推理里”。对做鸿蒙App 的人来说最大的变化不是界面多了一个语音助手或者推荐位而是整个产品的信息分发逻辑变了——用户不再需要知道你的菜单长什么样他只需要知道自己要什么。让 AI 去补全意图到路径之间的那段距离这才是这次改造最让我觉得值得的地方。
