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

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

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

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

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

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

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

引言

过去的 App 信息架构，解决的是一个问题：

如何把信息摆在合适的位置，让用户“找到它”。

于是我们有了：

• 首页推荐
• Tab 分类
• 多级菜单
• 搜索入口

整个设计逻辑只有一个核心：

用户主动浏览。

但当 AI 成为系统默认能力之后，问题变了。

用户不再问：

• 这个功能在哪？
• 这个页面怎么进？
• 这个按钮怎么点？

用户开始直接说：

• “帮我找出上个月最重要的三封邮件。”
• “把昨天讨论的内容整理成待办。”
• “继续我昨天没看完的内容。”

这意味着：

信息架构不再围绕“页面”，而要围绕“意图”。

这不是交互升级，这是结构重建。

传统信息架构的底层逻辑

我们先看旧模型，传统 App 的结构，本质是：

页面层级
↓
功能入口
↓
数据展示

它依赖三个核心机制。

空间层级组织

首页 → 列表 → 详情

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

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

信息通过“页面层级”排列。

本质是：

空间结构管理信息。

用户理解产品结构

用户必须知道：

• 去哪里找
• 如何筛选
• 下一步在哪

Button('查看记录')
  .onClick(() => {
    router.pushUrl({ url: 'pages/history/List' })
  })

产品结构 = 用户路径。

搜索是补救机制

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

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

AI 原生架构的第一原则：意图优先

当 AI 能理解自然语言时，信息架构必须升级。

从：

页面驱动

变为：

意图驱动

用户输入：

“把最紧急的任务排到前面。”

系统应该直接理解并执行：

async function handleIntent(text: string) {
  const intent = await ai.parse(text)

  if (intent.type === 'SORT_TASK') {
    return taskService.sortByPriority()
  }
}

注意变化：

用户不再“进入排序页面”。 而是直接触发“能力”。

入口被抽象掉了。

AI 原生信息架构的三层重构

真正的 AI 原生架构，会发生三层变化。

第一层：从“页面树”到“能力图”

传统 App 是树结构：

Home
 ├─ Orders
 │   ├─ Detail
 ├─ Profile

AI 原生架构更像图结构：

能力节点 ←→ 数据节点 ←→ 语义关系

示例：

type AbilityNode = {
  id: string
  description: string
  execute(params: object): Promise<any>
}

页面不再是核心单位。

能力才是核心单位。

第二层：从“分类标签”到“语义索引”

传统：

• 分类
• 标签
• 关键词

AI 原生：

语义向量 + 关系网络

type SemanticNode = {
  id: string
  content: string
  embedding: number[]
  relations: string[]
}

当用户说：

“昨天那个关于预算的文件”

系统通过语义匹配，而不是标题匹配。

第三层：从“入口集合”到“任务编排”

传统流程：

用户 → 页面 → 功能 → 结果

AI 原生：

用户 → 意图 → 多能力组合 → 结果

await systemAI.compose([
  '查找会议纪要',
  '提取行动项',
  '生成任务列表'
])

信息架构开始支持：

任务链式执行。

鸿蒙环境下，变化更剧烈

鸿蒙的特殊性在于：

• 多设备
• 分布式能力
• 系统级 AI

这让 AI 原生架构不只是 App 内部升级，而是系统级重构。

多设备语义一致性

用户说：

“把资料发到车机上。”

系统需要决定：

• 解析在哪执行
• 数据在哪同步
• 展示在哪完成

await distributedKV.put('doc_id', id)

车机读取：

let docId = await distributedKV.get('doc_id')
openOnCar(docId)

页面不再是信息中心。

任务才是中心。

AI 原生架构的设计模型

可以把未来鸿蒙 App 抽象为：

export type AINativeApp = {
  abilities: AbilityNode[]
  knowledgeGraph: SemanticNode[]
  taskEngine: TaskExecutor
}

三大核心：

1. 能力集合
2. 语义知识图谱
3. 任务编排引擎

页面只是渲染层。

对开发者的三点启示

页面设计不再是最高优先级

UI 仍然重要，但不再是唯一入口。

@Entry
@Component
struct RestoreTaskPage {
  aboutToAppear() {
    ai.restoreContext()
  }
}

很多行为甚至不需要用户触发。

数据结构设计成为核心竞争力

未来的差距，不在动画。在：

你的数据是否结构化？

class KnowledgeGraph {
  nodes: Map<string, SemanticNode>
}

没有结构化数据，就没有高质量 AI。

App 边界开始模糊

当系统级 AI 可以：

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

那么：

用户是否还需要知道 App 名称？

await systemAI.compose([
  '打开文档',
  '总结要点',
  '发送到企业微信'
])

生态形态会被重写。

一个明确趋势判断

未来三年，真正成功的鸿蒙 App 会具备三点：

• 可被 AI 调用
• 拥有语义知识结构
• 支持任务级执行

不具备这三点的 App，会逐渐退化为：

被系统 AI 包装调用的“能力壳”。

总结

很多人以为：

AI 原生架构 = 聊天框 + 智能推荐。

但真正的 AI 原生信息架构，是：

能力化 + 语义化 + 任务化。

当页面不再是核心、当入口开始消失、当任务成为基本单位，我们熟悉的移动应用形态，将在鸿蒙时代被重新定义。