AI 时代，ArkUI 的设计模式会改变吗？

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

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

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

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

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

📣 公众号"Swift社区"，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

💬 微信端添加好友"fzhanfei"，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。

📅 最新动态：2025 年 3 月 17 日

快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

文章目录

- 引言
- [AI 并不会取代架构](#AI 并不会取代架构)
- [ArkUI 的组件粒度可能会变小](#ArkUI 的组件粒度可能会变小)
- 状态管理可能会更加集中
- 业务逻辑会越来越独立
- [Prompt 可能会成为"新的设计文档"](#Prompt 可能会成为“新的设计文档”)
- [ArkUI 的设计模式可能会更简单](#ArkUI 的设计模式可能会更简单)
- [AI 可能会改变开发方式](#AI 可能会改变开发方式)
- 总结

引言

过去几十年，软件架构一直在围绕一个核心问题演进：

如何管理复杂性。

因此我们才会看到各种经典设计模式：

复制代码

MVC
MVP
MVVM
Clean Architecture
Redux
Flux

这些模式本质上都是在解决同一件事：

复制代码

UI
状态
业务逻辑
数据

之间的关系，而在 HarmonyOS 的 ArkUI 中，这些问题也同样存在。很多开发者在做中大型项目时，也会逐渐引入：

复制代码

Store
ViewModel
Service
Repository

这样的分层结构，但随着 AI 编程工具越来越成熟，一个新的问题开始出现：

AI 时代，ArkUI 的设计模式会不会发生变化？

答案其实是：

很可能会。

但变化的方向，可能和很多人想的不一样。

AI 并不会取代架构

很多人第一次接触 AI 编程工具时，都会有一种感觉：

"AI 能写代码，那是不是架构也不重要了？"

但实际开发一段时间之后，大多数团队都会发现，AI 擅长的是：

复制代码

写函数
生成组件
补全代码
解释逻辑

但 AI 非常依赖上下文结构，换句话说：

架构越清晰，AI 写代码越好。

例如在一个结构清晰的 ArkUI 项目里：

复制代码

Page
  ↓
ViewModel
  ↓
Service

如果你让 AI 写一个新功能，它通常可以很快补齐：

复制代码

UI
状态
数据请求
逻辑处理

但如果项目结构是这样的：

复制代码

Page
  ↓
所有逻辑
  ↓
所有状态
  ↓
所有接口

AI 反而很容易生成：

复制代码

重复逻辑
错误依赖
混乱代码

所以 AI 的出现，其实强化了一件事：

架构依然非常重要。

ArkUI 的组件粒度可能会变小

AI 时代，一个明显的变化是：

组件会越来越小。

原因很简单，过去开发者写组件时，会考虑一个问题：

复制代码

组件太多
维护成本高
代码不好管理

但如果 AI 可以快速生成组件，那么这个成本就会下降。于是 UI 结构可能会变成：

复制代码

Page
  ↓
Section
  ↓
Card
  ↓
Item

甚至更细：

复制代码

Avatar
UserName
TimeLabel
ActionButton

换句话说：

ArkUI 的组件化会变得更彻底。

这种趋势其实已经在很多前端框架中出现，AI 会进一步加速它。

状态管理可能会更加集中

另一个变化是 状态管理方式，很多 ArkUI 项目现在的状态结构是：

复制代码

Page State
Component State
Global State

但 AI 写代码时，很容易出现一个问题：

复制代码

重复状态
数据不同步
逻辑分散

因此未来的趋势可能是：

状态更加集中。

例如：

复制代码

Store

统一管理状态：

复制代码

UserStore
CartStore
OrderStore

ArkUI 页面只负责：

复制代码

读取状态
触发行为

这种模式其实和：

复制代码

Redux
MobX
Vue Store

非常类似，AI 工具通常 更擅长这种结构化架构。

业务逻辑会越来越独立

AI 时代另一个重要变化是：

业务逻辑和 UI 会更加解耦。

原因其实很现实，很多团队已经发现，如果业务逻辑写在 UI 组件里：

复制代码

AI 很难理解代码
复用性很差
测试困难

于是越来越多项目开始使用：

复制代码

UseCase
Service
Domain

这样的结构，例如：

复制代码

Page
  ↓
UserViewModel
  ↓
GetUserProfileUseCase
  ↓
UserRepository

这样做的好处是：

复制代码

逻辑可复用
代码可测试
AI 容易理解

在 AI 辅助开发的时代，这种 清晰的职责分离会变得更加重要。

Prompt 可能会成为"新的设计文档"

AI 开发还有一个很有意思的变化：

Prompt 本身会变成一种设计文档。

例如：

复制代码

实现一个 ArkUI 页面：

- 展示用户信息
- 使用 UserStore 管理状态
- 数据来自 UserService
- 组件拆分为 Avatar / Name / InfoCard

AI 就可以生成完整结构，也就是说：

复制代码

Prompt
        ↓
架构结构
        ↓
代码实现

未来很多团队的开发流程可能会变成：

复制代码

架构设计
↓
Prompt设计
↓
AI生成代码
↓
开发者优化

在这个流程里：

设计能力反而变得更重要。

ArkUI 的设计模式可能会更简单

一个很有意思的趋势是：AI 时代的架构，可能 不会越来越复杂。反而可能会变成：

更简单、更清晰。

因为 AI 在处理代码时：

复制代码

简单结构
比复杂模式
更稳定

所以未来 ArkUI 项目常见结构可能是：

复制代码

Page
  ↓
Store
  ↓
Service

三层结构就能解决大部分问题，很多过去复杂的模式，例如：

复制代码

MVP
Presenter
Interactor

可能会逐渐减少。

AI 可能会改变开发方式

最后一个变化其实不是技术，而是 开发方式。过去开发者写 UI 通常是：

复制代码

设计 → 写代码 → 调试 → 修改

但在 AI 工具的帮助下，流程可能变成：

复制代码

描述界面
↓
AI生成UI
↓
开发者调整

例如：

复制代码

生成一个 ArkUI 页面：

- 顶部用户信息
- 中间订单列表
- 底部操作按钮

AI 就可以生成基础 UI，开发者只需要：

复制代码

调整逻辑
优化交互
完善状态

这种开发模式其实会大幅提高 UI 开发效率。

总结

AI 时代，ArkUI 的设计模式确实可能会发生一些变化，但并不是很多人想象的那样：

AI 取代架构。

真正的变化其实是：

复制代码

组件更细
状态更集中
逻辑更独立
结构更简单

AI 会帮助开发者写代码，但它同样需要：

复制代码

清晰的架构
明确的职责
稳定的结构

所以未来 ArkUI 项目最重要的能力，可能不是：

复制代码

写代码

而是：

设计一个 AI 也能理解的架构。

当架构清晰之后，AI 才能真正成为开发者的"第二个工程师"。