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 去补全意图到路径之间的那段距离，这才是这次改造最让我觉得值得的地方。
