和 AI 一起做个鸿蒙 App:从写代码到提交审核
- 2026-11-01 12:16:00
一次真实的鸿蒙开发记录
代码已经跑起来了，手机却提示签名有问题；软件包终于上传成功，后台还要继续等待审核。
这段时间，我和 AI 一起做了 P5JS Studio 的鸿蒙版。过程中最让我头晕的，就是那一堆名字相似、用途不同的证书。
把开发、测试和提交审核走过一遍后，我想用这次经历讲清楚：一个鸿蒙 App 是怎样做出来的，AI 又替我们完成了哪些工作。
本文以原生鸿蒙手机应用为例。项目状态依据 2026 年 10 月 28 日 11:02 的记录：1.4 已提交，处于预审中，尚不代表最终审核通过。
01先说清楚：这个 App 给谁用？
P5JS Studio 做的事情很具体：把电脑上创作的 p5.js 作品带到手机上，随时查看、运行，做一些轻量修改，再试试倾斜、摇晃和短振动互动。
p5.js 可以简单理解为一个创意编程工具库：用代码画图形、做动画、处理交互。
这次我们先把范围定小：免费、离线、无账号，作品保存在手机本地。这样，精力可以先放在“作品好用、修改不丢”上。
AI 能帮忙拆解需求，但要做什么、哪些功能这版先不做，仍然需要人决定。
比如，“自动保存”还不够具体。我们进一步约定：停止输入后存草稿；异常退出后能恢复；恢复先进入编辑器，点保存后才更新正式作品。
有了这些具体条件，才知道功能究竟有没有做好。
图1｜人确定目标，AI 协助实现，测试结果决定能否进入下一步。
02开发工具，可以这样理解
刚开始会遇到不少新名词。先记住三个就够用：
DevEco Studio 是工作台。在这里管理工程、写代码、编译和调试。
ArkTS 是表达程序逻辑的语言。按钮按下后做什么、作品怎样保存，都要用代码描述。
ArkUI 是搭界面的组件工具。按钮、列表、输入框和页面布局，都可以由它来组织。
需要访问文件、传感器或系统分享时，还会用到 SDK 提供的接口。SDK 就像一套系统能力工具箱。
我们也没有把所有东西从头重写。作品运行能力和项目格式尽量复用，手机界面重新适配；编辑器则采用成熟的 CodeMirror 6，加上高亮、行号、字号、换行和撤销重做。
其中一部分网页技术运行在应用内部的 ArkWeb 环境里，可以理解为 App 内置的网页引擎。手机硬件能力由原生层把关，只开放需要的接口。
03那一堆证书，到底在证明什么？
手机安装一个程序，需要核对它的来源、内容和应用身份。这就涉及数字签名。
常见的“签名三件套”，可以用三个比喻记住：
私钥库 .p12：装着私人印章的保险盒。里面保存签名所需的私钥等材料，用来给软件包生成数字签名。
证书 .cer：印章的认证书。包含公钥等信息，供系统验证签名和信任关系。
Profile .p7b：这个 App 的通行证。关联应用、证书和分发用途；调试类型还会列出允许使用的测试设备。
这也是为什么：只下载一个 Profile，事情还没有做完。它需要与匹配的密钥和证书配合。
图2｜手动签名的材料流程示意。本项目正式发布采用云管理签名，工具会协助管理相关材料。
调试和发布，又是两种场景。调试签名主要用于指定测试设备；发布签名用于正式分发。两套配置要按用途匹配。
另外，签名和加密解决不同问题。签名帮助验证来源和完整性；加密用于限制内容被直接读取。选择软件包“不加密”，仍然需要正确签名。
我们还申请过用于查询后台数据的 API 凭据。它属于后台访问身份，和手机安装签名要分开管理。
04能打开，还要继续测什么？
这次开发让我印象最深的一个问题是：画布已经报错，点击却还能听到声音。
如果只检查“有没有声音”，就会漏掉问题。我们进一步检查了连续点按、错误提示、画布是否保留，以及停止和返回后的行为。
中文输入也一样。自动填进去一段中文，不能完整代替人在手机上选候选词、移动光标，再操作撤销和重做。
AI 可以读取日志、编写测试、自动操作部分界面。但声音是否正常、振动是否短促、倾斜互动是否跟手，需要我拿起手机亲自确认。
升级还多了一项要求：保留原来的作品。
我们先备份，再进行匹配应用身份的覆盖安装，最后核对数据。1.4 验收结束时，原有 7 个作品记录和 22 个素材、封面文件与升级前一致。
所以，“编译成功”“测试通过”“真机可用”，每句话都应该说清楚验证了什么。
05上传成功，距离上架还有几步？
程序完成后，通常还要在开发者中心创建应用、配置基本信息，并准备正式软件包和市场资料。账号注册与实名认证，也在这条流程中。
开发时会遇到 HAP 和 APP：HAP 是模块包；APP 是本次提交市场使用的发布包。工具会负责组织这些内容。
上架资料包括图标、真实截图、应用介绍、更新说明、隐私网址和审核备注。涉及哪些备案、版权或行业材料，要根据应用类别和当期规则核查。
离线应用，也有需要说明的数据处理。例如粘贴的代码、导入的图片、保存的草稿，以及何时读取动作数据。我们还根据早期审核反馈，补上了首次启动时的隐私阅读提示。
使用开源库，也要继续保留相应许可和版权说明。这个项目把源码及许可材料一并放进了应用，支持离线查看和导出。
图3｜本项目的主要发布路径。自检、预审、最终审核和正式上架，是不同阶段。
这次 1.4 的云端上架自检花了 19 分 49 秒，在 1 台设备上执行 22 个用例并通过。报告也提醒：没有覆盖折叠屏。
确认后，我们按授权撤销仍在排队的 1.3 待审申请，改用 1.4 的软件包和资料提交。记录中的状态是“预审中”，发布方式是“审核通过立即上架”。
上传成功 ≠ 自检通过 ≠ 审核通过 ≠ 正式上架。
06这次到底哪些事情是 AI 做的？
传统开发本来就有编译器、测试脚本和自动化工具。AI 带来的变化，是能够参与理解任务、组织工具，并在出错后继续查日志、改代码、再验证。
这次的实际分工，大致是这样：
AI 承担大量实现和检查。拆解功能、编写代码、分析错误、编写测试、调用构建与设备工具、核对文件，还起草了更新说明和审核备注。在获得授权后，也通过浏览器操作了后台、提交审核并刷新核对状态。
我负责方向、体验和重要决定。决定功能范围，完成登录等身份操作，连接和解锁手机，选择测试文件，确认声音、触觉与输入法体验，并授权版本替换及发布。此次 DevEco 正式签名和上传，由我按指导操作。
工具链和平台给出实际结果。编译器执行构建，签名系统处理可信签名，华为平台执行云测试、预审和后续审核。AI 负责调用和读取结果，不能替平台宣布通过。
因此，这次是一次贯穿开发、测试和发布的协作，不能简单归为“全自动上架”。
07AI 会做很多事，也需要核对依据
过程中还有一个小插曲：上传窗口里，一个文件创建于 10 月 15 日，另一个创建于 10 月 27 日。AI 起初仅凭文件名建议选择，我注意到了日期问题。
进一步检查才确认：创建日期较早的文件，实际已经更新成 1.4；较晚创建的重签文件，反而仍是旧版 1.3。
判断版本，最终要看包内信息；判断功能，要看实际测试；判断提交，要看后台状态。
如果你也想开始做一个鸿蒙 App，可以先把第一个目标定得很小：一个页面，一次可靠的本地保存，一次真正跑通的手机测试。
再逐步增加图片、分享或硬件互动。让每个功能带着清楚的验收条件进入下一版，开发过程会更容易掌握。
AI 降低了许多实现和操作的门槛。产品是否值得做、体验是否舒服、数据是否可靠，仍然需要开发者持续判断。
延伸阅读
华为：设计与开发鸿蒙应用
https://developer.huawei.com/consumer/cn/app/planning
华为：开发者测试服务入门
https://developer.huawei.com/consumer/cn/testing/get-started/
华为：提交你的应用
https://developer.huawei.com/consumer/cn/app/submit
文中流程图为主要步骤示意，案例记录截至 2026 年 10 月 28 日。工具入口、资质要求和审核流程，以平台当期说明为准。
