我最近在把一个儿童手表音频 App 搬到鸿蒙，目标设备是华为超新星 X1 Pro。Android 版和设计稿都是现成的，首页、搜索、播放、扫码登录、收藏、历史记录，每块业务都有参考。
迁移过程基本靠 AI 打主力：读旧代码、拆任务、写页面，再用 Figma MCP 读设计稿、核对视觉效果。上手之前，我以为这是把旧代码“翻译”一遍的事，真正走下来才发现，花时间的不是翻译，是几件提前想不到的小事——儿童表的手势和系统返回怎么相处，审核对首次联网查得有多细，上架材料要提前多久准备。
这篇把整个流程和踩过的坑整理一遍。文中的提示词是按这次任务重新整理的，你用的时候换成自己的项目路径和功能范围就行。
先收藏这份官方文档
做儿童表，华为这份《智能穿戴应用开发》：儿童智能表发布注意事项建议先存下来。屏幕规格、工程配置、包管理策略、功能开发、发布注意事项，选设备、配工程、查接口、备材料，入口都在这一页。写这篇文章时，页面标注的更新时间是 2026 年 9 月 15 日。
儿童表要先申请准入才能开发，开发完还要自检、提交回执。这两步最好和开发一起排期，不然代码写完了，卡在材料和申请上。
1. 先确定设备，再让 AI 规划工程
鸿蒙手表屏幕形状和尺寸不统一，成人圆表与儿童方表的界面不能直接套用。这次超新星 X1 Pro 的官方参数是 1.82 英寸 AMOLED、480 × 408 像素。查看官方规格
工程里也要声明目标设备。我们的 module.json5 保留标准设备类型 wearable，再增加儿童表特征，并引用分发策略：
// 合入 module 字段，保留工程原有的其他配置
{
"deviceTypes"
: [
"wearable"
],
"metadata"
: [{
"name"
:
"string"
,
"value"
:
"string"
,
"resource"
:
"$profile:distributionFilter_config"
}],
"requiredDeviceFeatures"
: {
"wearable"
: [
"child"
]
}
}
resources/base/profile/distributionFilter_config.json 中配置：
{
"distributionFilter"
: {
"screenShape"
: {
"policy"
:
"include"
,
"value"
: [
"rect"
] },
"screenWindow"
: {
"policy"
:
"include"
,
"value"
: [
"480*408"
] }
}
}
这里的 rect 和 480*408 只用于筛选分发设备，不会替你完成页面布局。模拟器里的 wearablekid 是设备模板名称，也不能直接拿来替换工程的 deviceTypes。
官方文档还单独列了儿童表的开发工具与 API 要求。规划时，我把设备型号、屏幕尺寸、系统版本、SDK 和可用能力一起交给 AI 核对配置。某个设备不支持表冠，核心操作就不能只放在表冠旋转上；接口能编译，也不代表目标设备支持。
2. 让 AI 读旧工程，第一轮只做分析
旧工程里既有业务流程，也可能混着不同厂商、不同渠道的实现，第一步先把参考范围说清楚。
第一轮我让 AI 只读代码、不改代码：
请分析这个 Android 儿童手表项目，先不要修改代码。以指定的华为渠道为参考，梳理工程模块、页面入口、首页与播放流程、登录、权益、收藏和历史记录。
标注关键源码位置，整理接口调用顺序、本地存储和系统依赖。区分可参考的业务规则、需要在鸿蒙重新实现的平台能力，以及不属于首版范围的功能。
输出迁移分析文档。无法确认的地方列出问题，不要自行补全。
我要的是一份能查回源码的说明：某个登录流程来自哪个类，会员判断在哪个接口之后执行，哪些逻辑只对某个渠道生效。每条都能对回源代码。
旧项目做久了，需求文档、设计稿和线上实现可能已经对不上。碰到这种差异，我让 AI 单独列出来，确认了再往下做。
3. 迁移任务拆到能运行、能检查
我把需求、Android 源码、Figma 链接、已有的鸿蒙代码一起交给 AI，每份资料的用途说清楚：首版做哪些功能看需求，业务流程查 Android，页面样式对照 Figma。
音频部分直接参考了已有的鸿蒙播放器代码，再按儿童表的功能范围取舍。迁移计划我这样交代：
根据迁移分析制定实施计划。按功能列出 Android 参考位置、鸿蒙实现方式、平台差异、依赖条件和验收方法。
先跑通“首页真实数据 → 内容列表 → 音频播放 → 返回”的路径，再补登录、权益、收藏、历史与异常状态。
每个阶段完成后构建并运行到儿童手表模拟器，提交截图和验证结果。记录待确认项，不要把编译通过写成设备验收通过。
先跑通首页到播放这条路径，接口、跳转、播放器的问题会尽早暴露；登录、收藏再逐项补，每补一项就跑一次模拟器检查。
4. 用 Figma MCP 还原视觉，状态也要一起核
视觉还原靠 Figma MCP：读设计信息、看页面、提取资源，再到模拟器里截图对照。
播放页的设计稿里，播放、暂停、异常、不可播放、音量调节、会员标识都有对应状态；个人中心也有未登录、非会员、会员、会员过期四档。
页面动手前，先让 AI 把状态理清楚：
通过 Figma MCP 读取指定页面及相关状态，整理页面结构、资源和状态清单。结合需求与 Android 实现，确认每种状态的进入条件和交互。
先完成一个页面，运行到目标模拟器，截图与设计稿核对。复用设计资源；业务规则不明确时先标注，不要仅凭画面猜测。
页面写完，我同时开 Android 和鸿蒙两个模拟器，把首页、列表、播放器各走一遍，对着排版和操作看差异。
左是 Android 320×320 模拟器，右是鸿蒙儿童表 480×408，截图保留各自屏幕比例。播放器两端停在不同节目，对照的是按钮位置、文字排版和页面结构。
5. 一个要提前约定的交互：右滑翻页还是返回
手表里页面可以横向切，系统又有侧滑返回，两者会在边界撞上。我们希望“我的”右滑回首页，首页再右滑回桌面，二级页面则先退回上一层。
应用需要在分页边界把手势让出来。参考的另一个鸿蒙手表项目用 Swiper，第一页向右滑时，通过 onGestureRecognizerJudgeBegin 拒绝 Swiper 自己的拖动手势，把机会留给导航返回。我们项目用自定义横向拖动，规则一样。
华为的 ArcSwiper 侧滑返回示例也讲了分页边界的处理，可以对照自己用的组件查。
验收任务给得很直接：
分别验证“我的 → 首页”“首页 → 系统桌面”“二级页面 → 上一层”。从页面中的按钮和卡片区域开始滑动，检查是否误触点击。记录每条路径的实际结果。
测试时我特意滑到第一页，再向右滑一次，看能不能正常退出。
6. 审核反馈，先拆成一张清单
这次审核反馈不只是一个弹窗的问题。儿童手表应用，下面四项都得单独核对：
-
未成年人应用要提供举报功能或举报渠道。
审核意见明确指出，面向未成年人的儿童类应用不能缺少便捷、合理、有效的举报入口。只写一个普通的“联系客服”还不够，入口名称、提交路径和后续受理方式都要能对应上。相关要求可参考《审核指南》第 8.14 项：查看审核指南。
-
首次使用数据流量时，确认要出现在首页加载之前。
如果用户还没有点击播放，首页接口、封面图片或账号初始化已经开始联网，就会被认为存在偷跑流量的风险。
-
首次同意之后，后续使用数据流量不要反复弹窗。
后续可以用 Toast 提示“正在使用流量中”，不要每次播放都再次打断用户。
-
联网应用点击 ICP 备案号，要展示备案二维码。
备案入口不能只显示一串文字，点击后要能看到对应的二维码。
第 2、3 项直接影响启动顺序和播放器状态，我单独拆了一条联网许可流程。
把流量确认移到首页加载之前
审核反馈里有一条是：首次使用数据流量时，点击播放才出现确认弹窗，但页面已经加载了。
首页接口、封面图片、账号初始化，都可能在播放之前联网。整改时我们把首次蜂窝确认提前到启动初始化之前，在业务 HTTP 创建入口加一道统一许可检查。
现在的顺序是：同意隐私协议，检查网络与流量许可，必要时确认，然后加载首页、启动相关联网任务。已经同意过流量的用户，后续改成 Toast 提示，不再反复打断。
先让 AI 查启动阶段哪些地方在联网：
梳理冷启动到首页显示期间的全部联网行为，包括业务接口、账号初始化和远程图片。检查首次蜂窝确认前是否已经触发请求。
修改后验证停止、继续、再次启动、网络状态切换等路径，记录确认页出现前的请求情况和播放恢复结果。
这轮回归覆盖了首次启动确认、选择停止/取消、选择继续、退出后再次启动，以及播放中切换到蜂窝状态。确认页出现前，业务请求数为 0；点击继续后才开始加载首页和播放内容。已经同意过流量的用户，后续只显示“正在使用流量中”的 Toast；切换网络时播放先暂停，确认继续后恢复原节目。
儿童表上架，材料要提前准备
准备上架，还得回到这份儿童智能表发布注意事项。申请准入要交 App 名称、包名、版本、App ID、功能介绍这些资料；开发完成后，再提交自检回执。
自检表里我把四项审核反馈直接列成检查项：举报入口能不能找到并提交，首次确认前是否零业务请求，后续流量是不是 Toast，ICP 备案号点开有没有二维码。上架前对着清单走一遍完整路径，比盯着某个页面看有没有弹窗可靠。
