网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

如果你的鸿蒙“ System”的架构升级之后，你会进入一个新的阶段：

结构清晰了
逻辑解耦了
系统可扩展了

但很快，你会遇到一个新的瓶颈：

系统“能跑”，但不“聪明”

比如：

推荐是写死规则
流程是固定路径
用户行为只是被动响应

这时候很多人会开始“往 UI 里加 AI”：

加个聊天框
接个大模型 API
做个智能助手

看起来很“AI 化”，但本质上：

AI 只是一个外挂功能，而不是系统的一部分

所以这一篇我们要解决一个更关键的问题：

System + AI：如何让 AI 成为“架构的一等公民”？

一、传统 AI 接入方式的问题

先看一个常见写法：

async askAI(prompt: string) {
  const res = await aiAPI(prompt)
  this.message = res
}

问题在哪？

AI 在 UI 层
AI 不参与系统决策
AI 不影响核心流程

换句话说：

AI = 一个“高级接口调用”

这会导致：

无法复用
无法组合
无法控制

二、一个关键认知升级

你必须接受一个事实：

AI 不是工具函数，而是“决策系统”

这意味着：

AI 不应该写在 UI
AI 应该进入 System

架构升级为：

Store（状态）
System（规则 + AI）
Engine（调度）
UI（展示）

变化点只有一个：

System 从“确定性规则”，升级为“规则 + 智能决策”

三、AI 应该放在哪一层？

答案很明确：

System 层

因为 System 本质是：

定义“状态如何变化”

而 AI 擅长的是：

决定“应该怎么变化”

两者天然契合。

四、第一步：把 AI 封装成“能力模块”

不要在 System 里直接写：

fetch("LLM API")

正确方式：

// ai/DecisionModel.ts
export class DecisionModel {

  async decide(input: string): Promise<string> {
    return await aiAPI(input)
  }

}

这一层的意义：

屏蔽模型细节
统一接口
方便替换（本地模型 / 云模型）

五、第二步：让 AI 进入 System

示例：推荐系统

// system/RecommendSystem.ts
export class RecommendSystem {

  model = new DecisionModel()

  async recommend(store: AppStore) {

    const prompt = `
      用户历史：${store.history}
      当前行为：${store.currentAction}
      请推荐内容
    `

    const result = await this.model.decide(prompt)

    store.recommendList = parse(result)

  }

}

关键变化：

AI 不再是 UI 工具
而是 System 的一部分

六、第三步：AI 不直接操作 Store

一个非常重要的原则：

错误 AI 不能直接改 Store
正确 AI 只“给建议”，System 决定是否执行

错误写法

store.balance -= 100 // AI 说要扣钱

问题：

不可控
不可预测
有风险

正确写法

const decision = await model.decide(input)

if (decision.action === "PAY") {
  paymentSystem.pay(store)
}

本质是：

AI = 决策建议，而不是执行者

七、第四步：引入“AI 调度层”

当 AI 多了之后，你会遇到一个问题：

推荐 AI
对话 AI
风控 AI

谁先执行？

谁影响谁？

引入 AI Engine

class AIEngine {

  recommend = new RecommendSystem()
  risk = new RiskSystem()

  async run(store: AppStore) {

    await this.risk.check(store)

    if (!store.isSafe) return

    await this.recommend.recommend(store)

  }

}

作用：

统一 AI 执行顺序
控制风险
避免混乱

八、第五步：让 AI “可控”

这是最关键的一步。

如果你只是接入 AI：

系统 = 不可预测

你必须增加：

1、约束

if (store.balance < 0) reject()

2、校验

if (!isValid(decision)) fallback()

3、回滚

snapshot = clone(store)
try {
  runAI()
} catch {
  store = snapshot
}

4、日志

记录 AI 决策路径

总结一句话：

AI 必须被 System“驯化”，而不是放任

九、完整架构演进

最终结构会变成：

                ┌──────────────┐
                │   Store      │
                └──────┬───────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
   RuleSystem     AISystem       RiskSystem
        │              │              │
        └──────────┬───┴───────────┘
                   │
               AI Engine
                   │
               App Engine
                   │
                   UI

十、这一套架构带来了什么？

1、从“功能 App”到“智能 App”

不再只是响应
而是主动决策

2、从“固定流程”到“动态流程”

流程由 AI 决定

3、从“用户操作”到“用户意图”

点击 → 行为
AI → 意图理解

4、从“代码驱动”到“数据驱动 + 模型驱动”

规则 + AI 共存

十一、开发者最容易踩的坑

误区 1：AI 写在 UI

结果：

不可复用
逻辑混乱

误区 2：AI 直接改 Store

结果：

系统失控

误区 3：没有约束

结果：

不可预测
无法上线

误区 4：把 AI 当“万能逻辑”

结果：

性能差
成本高
难调试

十二、一个终极认知升级

当你走到这一步，你会意识到：

你写的已经不是：

App

而是：

一个“人类 + AI 协同决策系统”

系统运行逻辑变成：

用户输入
   ↓
System（规则）
   ↓
AI（决策建议）
   ↓
System（校验 + 执行）
   ↓
Store（状态变化）
   ↓
UI（展示）

总结

下一代鸿蒙 App 架构，本质是：

System = 规则 + AI

整体结构：

Store：状态源
System：规则 + AI
AI Engine：智能调度
App Engine：流程控制
UI：展示层

如果用一句话总结：

未来的鸿蒙 App，不再只是“代码驱动”，而是“规则 + AI 共同驱动的智能系统”。