做 AI 鸿蒙 App 后，我重构了应用逻辑

还有些逻辑直接和界面状态绑在一起，比如 loading、列表渲染、空态处理，这类代码对 AI 没什么用，反而会把业务层拖得很脏。最后只能老老实实拆：把能复用的能力从页面里抽出来。

把能力拆成 Service

我先做的是 Service 化。

export class OrderService {
  async getOrders(userId: string) {
    return await api.get("/orders")
  }
}

拆完之后，UI 和 AI 都只面对同一层能力：

await orderService.getOrders(userId)

这一步看起来不复杂，但很关键。App 不再只是页面拼起来的东西，而更像是一组可以被复用的能力。

再往上一层，补一个 Tool

Service 拆出来以后，新的问题来了：AI 并不知道该调哪个能力，也不该直接知道底层 API 怎么实现。于是我加了一层 Tool，把'怎么调用'这件事包起来。

export class OrderTool {
  async execute(params) {
    return await orderService.getOrders(params.userId)
  }
}

AI 只要调用 Tool 就行，不用关心下面是 Service、API 还是别的什么实现。结构变成了：

AI → Tool → Service

这层封装不花哨，但很实用。至少以后改接口、换实现，不用一层层去碰页面代码。

复杂任务逼出了 Agent

再后来，用户的输入开始变成复合任务：

帮我查订单，并推荐相关商品

这不是一个 Service 能搞定的事，要先理解意图，再拆成多个步骤，最后把不同能力拼起来。于是我加了 Agent。

export class Agent {
  async run(input: string) {
    const intent = await this.parse(input)
    if (intent === "order_and_recommend") {
      const orders = await orderTool.execute()
      const goods = await recommendTool.execute()
      return { orders, goods }
    }
  }
}

做到这里，感觉就很明显了：AI 不是单纯调接口，它是在编排系统能力。这个差别很大。

UI 的位置变了

传统 App 里，UI 是起点，也是大部分流程的中心。接入 AI 之后，UI 更像结果展示层。

用户一句话 → AI 完成 → UI 展示结果

很多操作甚至不需要用户先进入某个页面，UI 只是把 AI 的处理结果呈现出来。它没有退场，只是退到了后面。

数据流也换了一套思路

以前的数据流大多是：

UI → Service → Data → UI

现在更像：

用户输入 ↓ AI ↓ Service ↓ Data ↓ UI（展示）

区别不只是箭头方向。以前是页面驱动流程，现在更像是意图驱动流程。这个变化会直接影响你怎么拆模块、怎么定义边界、怎么做复用。

真正变的是思维方式

项目做完以后，我最大的感受不是代码多了，而是思路变了。

以前会先想：这个页面怎么设计，按钮放哪，流程怎么走。现在先想的是：用户可能会怎么说，系统怎么理解，哪些能力可以组合，任务怎么拆开。

这不是一个小修小补的变化。它会逼着你重新看待 App 的核心。

结论

如果只用一句话概括这次变化，我会说：我做的已经不再是页面应用，而是能力系统。

结语

最开始，我只是想给鸿蒙 App 加一个 AI 功能。做完之后才发现，真正被改写的是应用架构本身。

如果你现在也在做 AI 鸿蒙 App，我的建议很直接：别把 AI 当成一个额外页面，它更像系统入口。这样设计，后面扩展能力、重构逻辑、接更多工具时，才不会把自己绕进去。