从 0 到鸿蒙签名包:我用 CodeX 跑通了一次小游戏上线链路
这两天,我用 CodeX 从零开发了一款轻量解谜小游戏。一开始,我以为这只是一次很普通的 AI 编程实验:想一个玩法,让 CodeX 帮我写代码,生成 H5 游戏,然后再封装成鸿蒙应用。剩下的 50%,才是真正把一个作品从“自己电脑里能玩”,推到“可以作为应用提交平台”的关键。玩法设计、H5 实现、HarmonyOS 封装、正式签名、应用市场资料、隐私政策、截图素材、审核问题修复。最后形成了一个可重新上传的 Release 签名包。普通人用 CodeX 开发小游戏,到底能做到哪一步?
一、最开始,我只是想验证一件事
AI 能不能帮你把一个东西推进到“接近真实上线”的状态。一个能点、能动、能展示的小游戏,用 AI 辅助,确实可以很快做出来。
二、《镜潮织星》的玩法:先做一个小而完整的核心机制
它不是那种复杂的大型游戏,而是一款轻量解谜小游戏。游戏目标也不是简单连通路线,而是让“日星”和“月星”沿着轨道同步归航。这样一来,玩法就从普通的“铺路解谜”,变成了“双线协调解谜”。这类玩法适合用 AI 快速开发,因为它有三个特点:这次版本里,我把它做成了 8 个渐进关卡,适配手机和平板两种设备形态,并且完全不依赖联网。你的复盘材料也记录了这款游戏的核心机制、8 个渐进关卡、2 种设备形态和 0 联网依赖。不要一上来就要开放世界、排行榜、社交系统、皮肤商城。做到这些,已经比 90% 停留在想法阶段的人更进一步了。
三、技术路线:先 H5,再封装鸿蒙
这次我没有直接从原生鸿蒙 ArkUI 开始重写游戏逻辑。先用 H5 做游戏主体,再用鸿蒙 Web 容器承载。鸿蒙侧用 ArkTS Web 容器加载本地 rawfile 资源。如果后面要发到网页、Astrocade、小游戏平台,H5 版本都还能继续利用。你的复盘材料里也把这条路线写得很清楚:H5 游戏由 index.html / CSS / Canvas JS 组成,资源放进 entry/src/main/resources/rawfile,再通过 ArkTS Web 容器加载,最终形成 phone / tablet / release package。因为你的第一目标不是把架构做得多完美,而是先验证:如果这些都没验证,直接投入大量时间做原生重构,很容易变成无效开发。
四、真正的麻烦,是从“打包上线”开始的
mirror-tide-1.0.0-signed.app上架不要传 HAP,而是使用正式签名后的 .app。华为官方发布文档也提到,HarmonyOS 应用/元服务开发完成后,需要打包成 App Pack,也就是 .app 文件,用于上架到 AppGallery Connect。但真正面向市场提交时,后台认的是发布流程里的正式包。我的复盘材料里也记录了这次的最终校验项:releaseType 为 Release、Beta1 无残留、SHA256 已记录、版本号 1.0.0。应用市场不是看你的游戏“能不能玩”,而是先看你的包“合不合规”。
五、上架资料不是附属工作,而是产品的一部分
华为 AppGallery Connect 也有专门的隐私声明配置文档,隐私政策、用户协议等材料并不是可有可无的装饰,而是应用发布准备中的正式环节。截图、图标、隐私政策、用户协议,要从开发阶段就开始准备。
六、这次最真实的坑:技术能上传,不等于商业能上线
这次开发过程中,我遇到的真正问题,不是游戏逻辑有多复杂。DevEco SDK 元数据里出现 Beta 标记。大陆游戏分类可能涉及版号、ISBN、软著或授权材料。如果选择中国大陆游戏分类,就不能只从技术角度判断“我能不能上传”。国家新闻出版署官网有专门的游戏审批结果和国产网络游戏作品审批事项页面,游戏名称、出版单位、运营机构、批复文号、出版物号等都是公开审批信息中的关键字段。技术上已经形成可重新上传的 Release 签名包,但商业发布还要看地区、分类和材料要求。尤其是个人开发者,不要为了“快点上线”,随便改分类、绕规则、伪造材料。如果目标是快速验证,可以优先评估允许的非大陆地区。如果必须大陆上线,就要提前评估版号周期、材料成本和代理成本。
七、CodeX 真正有价值的地方,不是替你写几行代码
这次用 CodeX 开发,我最大的感受不是“AI 写代码好快”。
八、下一款小游戏,我会从第一天就按上线标准开发
这次《镜潮织星》跑完之后,我总结出一个很重要的 SOP。游戏能跑只是 50%,能合规签名、能被市场接受、能被审核理解,才是可上线版本。
九、写在最后:普通人做 AI 产品,别只停留在“生成”
这次用 CodeX 开发《镜潮织星》,给我最大的提醒是:所以我现在更愿意把 AI 编程工具看成一个“加速器”。我能不能用 AI,连续做出更多真正能上线、能验证、能增长的产品。