飞翔的十号做一个 AI 鸿蒙 App，最让我意外的不是 ArkTS 语法，也不是大模型接口的接入过程，而是做着做着我发现，过去这些年积累的 App 开发逻辑，有一大半用不上了。“逻辑变了”这四个字不是标题党，而是我把产品结构、交互方式、数据流全部推翻重来之后，真正体会到的一件事。这篇文章会把立项、设计、开发到踩坑的完整过程记录下来，重点说说那些让我觉得“再也回不去”的转变。如果你正准备做鸿蒙端 AI 应用，或者想把现有产品用 AI 重做一遍，这篇的内容应该对你有实际参考价值。
1. 立项那天，我差点用老套路做新东西
1.1 为什么选择“鸿蒙+AI”这个组合
先解释一下为什么非要选鸿蒙。我的判断很朴素：鸿蒙是目前少有的还在高速增长的操作系统，设备覆盖手机、平板、车机、智能家居，而 AI 要真正落到生活场景里，恰恰需要这样的多设备触点。你让用户单独下载一个 AI 应用，他大概率懒得装，但是 AI 能力如果能在手表上给你推送一句话、在车机上帮你规划路线，这种体验是传统单设备应用给不了的。另一方面，鸿蒙的开发范式也和过去不完全一样，ArkTS 的声明式写法、分布式数据管理、原子化服务这些概念，本身就适合承载以“任务”为单位的产品形态，而不是简单的页面堆叠。
选择 AI 的原因也很简单。过去 App 的能力边界是功能列表，用户要自己学、自己找；现在有了大模型，App 可以去理解用户的真实意图，代替用户完成一个个任务。鸿蒙的分布式能力和 AI 的多模态理解，某种程度上是天然互补的。所以我当时的定位很明确：做一个以 AI 为核心的鸿蒙 App，不是给旧应用加一个 AI 功能，而是让 AI 当主角。后来回头看，这个定位给我带来的麻烦和收获几乎一样多。
1.2 最初的方案：还是熟悉的“页面+按钮+接口”
刚立项那几天，我的第一版方案非常“传统”：首页放几个入口，智能问答、路线规划、攻略生成，每个入口对应一个页面，页面里放按钮和输入框，用户点了之后去调云端大模型接口，把返回结果渲染出来。技术上没有任何难点，ArkTS 写页面、封装 HTTP 请求、处理 JSON 返回，和我以前做过的所有 App 没什么两样。为了显得专业，我还画了完整的信息架构图：一级页面、二级页面、返回路径、空状态、加载占位符，一切看起来很严谨，甚至可以直接进入开发。
但这个方案我只花了一天就做出了 Demo，功能完全能跑。问题恰恰出在“能跑”上面——功能能跑，不代表产品逻辑是对的，更不代表用户愿意用第二次。Demo 跑通之后我拿给几个朋友试用，大部分人点了几下就退出了，只有一个朋友多问了一句“你这个智能问答，和我在浏览器里打开 AI 网页有什么区别？我为什么要装一个 App？”这句话直接把我问住了。
1.3 被用户的一句话打醒
朋友的问题让我反思了很久。如果 AI 只是一个聊天入口，用户确实完全不需要一个 App——网页、小程序、系统助手都能做到。App 的价值必须在于：它能替用户完成端到端的任务。用户说自己想去杭州玩两天，App 应该直接给出包含行程、天气、酒店建议、预约链接的完整方案，而不是只生成一段文字让他自己去搜。也就是说，用户要的不是一个“AI 按钮”，而是一份“AI 结果”。
这个认知直接推翻了我原来的全部设计。我开始意识到，做 AI 鸿蒙 App，不是在做“有 AI 功能的 App”，而是要做“AI 原生的 App”。后面所有逻辑上的调整，都是从这个点拉开的。产品经理视角的东西我原本不想写太多，但这次经历让我深刻明白：技术选型、架构设计、交互方案，全都是被这个产品定位牵着走的。定位先变了，后面的一切才跟着变。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。