做了一个 AI 鸿蒙 App，我发现逻辑变了
子玥酱（掘金 / 知乎 / ZEEKLOG / 简书 同名）
大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、ZEEKLOG、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
引言
一开始，我只是想做一件很简单的事：
在鸿蒙 App 里接入一个 AI 功能。
比如：
- 做一个智能搜索
- 加一个 AI 助手
- 支持自然语言操作
听起来很普通，对吧？
但当我真的把一个 AI 鸿蒙 App 从 0 做到能用之后，我发现一件很不对劲的事：
不是我在给 App 加 AI，而是 AI 在重写整个 App 的逻辑。
而且这种变化，不是 UI 层面的，而是：
架构级别的变化 一、最开始，我只是加了一个“AI 页面”
最初的实现很典型：
首页 ↓ 新增一个 AI 页面 ↓ 调用大模型接口 ↓ 展示结果 代码大概是这样：
@Entry@Component struct AIPage {@State input:string=""@State reply:string=""asyncsend(){this.reply =await aiService.chat(this.input)}}当时我以为：
“这不就完成了吗？”
但很快问题就来了。
二、AI 开始“绕过页面”
用户开始提一些请求：
帮我查一下订单 帮我推荐几个商品 帮我看看今天有什么安排 这些需求本来应该对应：
订单页 商品页 日程页 但现在：用户根本没有进入这些页面，AI 直接返回了结果。
这时候我第一次意识到：
页面，不再是唯一入口了。
三、Service 层突然变成核心
以前我的代码结构是：
Page → Service → API 但现在变成：
AI → Service Page → Service 也就是说：Service 被两个入口调用：
- UI
- AI
问题马上暴露出来：
1 有些 Service 写在页面里
// Page 内部逻辑asyncloadOrders(){returnawait api.get("/orders")}AI 根本调不了。
2 有些逻辑和 UI 强绑定
this.loading =truethis.orders =await api.get()this.loading =falseAI 也用不了，于是我不得不重构：
把所有业务逻辑从页面里“抽出来”。
四、我开始把能力“服务化”
我做的第一步是：
拆 Service 例如：
exportclassOrderService{asyncgetOrders(userId:string){returnawait api.get("/orders")}}然后 UI 和 AI 都调用：
await orderService.getOrders(userId)这一刻变化很明显：
App 不再是页面集合，而是能力集合。
五、我又加了一层：Tool
很快我发现一个新问题，AI 并不知道该调用哪个 Service。
于是我加了一层：
Tool 例如：
exportclassOrderTool{asyncexecute(params){returnawait orderService.getOrders(params.userId)}}AI 只需要：
调用 Tool 而不用关心底层实现，这时候架构变成：
AI → Tool → Service 六、我不得不引入“Agent”
再往后，问题又来了。用户输入开始变复杂：
帮我查订单，并推荐相关商品 这已经不是一个 Service 能完成的任务，我需要：
多个步骤 多个能力 组合执行 于是我引入了：
Agent 示例：
exportclassAgent{asyncrun(input:string){const intent =awaitthis.parse(input)if(intent ==="order_and_recommend"){const orders =await orderTool.execute()const goods =await recommendTool.execute()return{ orders, goods }}}}这时候我才彻底意识到：
AI 不只是调用接口，而是在“编排系统能力”。
七、UI 的地位明显下降了
以前：
UI = 核心 现在：
AI = 核心 UI = 展示 很多操作变成：
用户一句话 ↓ AI 完成 ↓ UI 展示结果 甚至很多时候：UI 根本不参与流程
八、数据流也变了
传统数据流：
UI → Service → Data → UI 现在变成：
用户输入 ↓ AI ↓ Service ↓ Data ↓ UI（展示） 变化很关键：
数据流不再由 UI 触发，而是由 AI 触发。
九、最大的变化，其实是“思维方式”
做完这个项目后，我最大的感受不是代码变了，而是：
思维方式彻底变了。
以前我在想：
这个页面怎么设计？ 这个按钮放哪？ 这个流程怎么走？ 现在我在想：
用户会说什么？ 系统怎么理解？ 能力怎么组合？ 任务怎么完成？ 十、本质总结
如果用一句话总结这次变化：
我不再是在做“页面应用”，而是在做“能力系统”。
对比一下：
| 维度 | 传统 App | AI App |
|---|---|---|
| 入口 | 页面 | 意图 |
| 核心 | UI | Agent |
| 逻辑 | 固定流程 | 动态任务 |
| 结构 | 页面集合 | 能力系统 |
结语
一开始我只是想：
给鸿蒙 App 加一个 AI 功能
但最后我得到的是：
一个完全不同的应用架构。
如果你现在也在做 AI 鸿蒙 App，我给你一个建议：
不要把 AI 当成功能，而要当成系统入口来设计。
否则你很快就会遇到：
- 架构混乱
- 代码失控
- AI 能力无法扩展