1. 这不是一次普通上架，而是一场面向新生态的实战压力测试

“个人开发者上架鸿蒙 AI 应用：12 条整改打回，再撞三座大山”——这个标题一出来，我立刻放下手头三个在跑的自动化脚本，把手机调成免打扰模式，泡了杯浓茶，打开 DevEco Studio 和 HarmonyOS 官方文档，重新翻了一遍 2024 年 Q2 更新的所有上架规范。这不是危言耸听的标题党，而是某位真实存在的独立开发者（我们暂称他为 A 同学）在 37 天内完成从模型轻量化、能力封装、隐私合规改造到最终过审全过程后，写下的第一手复盘笔记。他做的是一款基于端侧 Whisper 微调模型的离线语音转写工具，核心功能是：不联网、不传声、不存录音、纯本地运行，支持中英混合实时转写+时间戳标记+导出 Markdown。关键词很明确： 鸿蒙原生应用、AI 能力端侧部署、个人开发者、上架审核、HarmonyOS NEXT、隐私合规、模型轻量化、AppGallery 审核机制 。

为什么这件事值得深挖？因为过去半年，我陆续接触过 11 位尝试将 AI 功能集成进鸿蒙原生应用的个人开发者，其中 9 位卡在「首次提交」环节，平均被打回 8.6 次；剩下 2 位虽已上架，但均主动下架了 AI 核心模块——不是技术做不出来，而是根本通不过审核逻辑闭环。这背后暴露的，不是某个开发者的代码问题，而是整个鸿蒙 AI 应用生态在「能力表达」与「规则认知」之间存在显著断层。官方文档写的是“支持 AI 能力”，但没写清楚“支持哪类 AI 能力、以什么形态支持、边界在哪里”。开发者按 Android 思维封装一个 .so 模型文件扔进去，结果审核系统直接判定为“未声明敏感权限+未提供模型可解释性说明+未隔离训练数据残留风险”，三条红线全中。所以这篇内容，不教你怎么写一行 AI 代码，而是带你穿透 AppGallery 审核后台那套隐性逻辑——它不看你模型多准，只看你是否让系统“看得懂、管得住、信得过”。

适合谁看？如果你是正在用 ArkTS 写鸿蒙应用、想加个语音识别/图像理解/文本摘要功能的个人开发者，或者你刚跑通了一个 Llama-3-8B 的 TinyML 版本，正琢磨怎么塞进 .hap 包里，又或者你被“HarmonyOS NEXT 不支持安卓子系统”吓退，怀疑端侧 AI 是否还有戏——那你就是这篇内容最该读的人。它不承诺“包过审”，但能让你少走 23 天无效返工，避开 90% 的典型雷区。接下来所有内容，全部来自真实打回记录、审核驳回原文截图（已脱敏）、DevEco Studio 日志分析、以及我和三位通过审核的开发者闭门复盘的逐条对照。没有理论空谈，只有每一条整改意见背后的“审核员视角”和“开发者应对动作”。

2. 12 条整改意见拆解：不是 bug，是生态语言不通

A 同学首轮提交被退回 12 条意见，我们逐条还原原始表述、审核依据、技术本质、以及他最终如何修改。注意：这些意见全部来自 AppGallery 官方审核后台，非模拟、非推测，且每一条都对应 HarmonyOS 官方《应用上架审核指南》2024.05 版本中的具体条款编号（已隐去，但可查证）。我们不做归类，就按实际打回顺序展开，因为顺序本身就有信息量——前 3 条是“硬门槛”，第 4–7 条是“逻辑链断裂”，最后 5 条是“体验可信度缺失”。

2.1 第 1 条：未声明“设备传感器使用目的”，且语音采集行为未在首次启动时显式弹窗告知用户

提示：这是 12 条中唯一一条带星号（*）的强制项，意味着不改必拒，无协商余地。

原始驳回原文：“应用在未获得用户明示授权前提下，调用麦克风硬件资源执行语音识别任务，违反《HarmonyOS 应用权限管理规范》第 3.2.1 条‘敏感权限必须一事一议、即时告知、单独授权’。”

表面看是权限问题，实则直指鸿蒙对“AI 行为”的全新定义逻辑：在鸿蒙体系里， AI 功能不是软件功能，而是硬件驱动行为的延伸 。你调用麦克风，不是为了“录音”，而是为了“触发 AI 推理管道”。因此，系统要求你不能只写一句“需要录音权限”，而必须在弹窗文案中精确说明“本应用将使用您的麦克风，实时采集语音流，交由本地部署的语音转写模型进行处理，所有数据仅在本设备内存中完成计算，不会上传至任何服务器”。A 同学最初写的弹窗是：“开启语音输入功能？[允许][拒绝]”，这在 Android 上完全合规，但在鸿蒙审核员眼里，等于没说——你没告诉用户“谁在用、怎么用、用完即焚”。

他最终修改方案：

• 弹窗标题改为：“启用本地语音转写（无需联网）”
• 正文分三行：
  • 第一行（加粗）：“本功能全程离线运行，所有语音数据仅在您设备内存中处理”
  • 第二行：“模型已内置在应用中，不访问网络、不上传音频、不存储录音”
  • 第三行（小字）：“如需关闭，请进入设置 > 隐私 > 权限管理 > 本应用 > 麦克风”

关键点在于： 把技术事实翻译成用户可感知的安全承诺，并与系统级权限管理形成双向映射 。审核员看到这个弹窗，会立刻在后台比对你的 config.json 中 module 下的 reqPermissions 字段是否包含 "ohos.permission.MICROPHONE" ，同时检查 resources/base/element/string.json 里是否有完全一致的文案字符串——二者必须字节级匹配，差一个标点都不行。

2.2 第 2 条：未提供模型文件完整性校验机制，存在被篡改风险

注意：这条打回出现在第 2 位，说明审核系统在静态扫描阶段就已介入，而非运行时检测。

原始驳回原文：“应用 assets 目录下存在未签名的 .bin 模型文件（model_quantized.bin），无法验证其来源及完整性，违反《HarmonyOS 应用安全加固规范》第 4.7 条‘所有第三方或自研模型文件必须通过应用签名密钥进行哈希绑定并提供校验入口’。”

这里暴露出一个巨大认知差：很多开发者以为，只要模型文件放在 assets 目录，打包进 .hap ，就算“嵌入应用”。但鸿蒙的审核逻辑是—— 模型是独立可执行资产，必须像 APK 里的 so 库一样具备防篡改能力 。 .bin 文件没有签名，意味着攻击者可在安装后替换该文件，注入恶意推理逻辑。A 同学的模型是用 ONNX Runtime for HarmonyOS 编译的量化版 Whisper，输出为纯二进制，确实没做任何校验。

他最终采用的方案是双校验：

• 编译期绑定 ：在 DevEco Studio 构建脚本中加入自定义 task，用应用签名密钥对 model_quantized.bin 计算 SHA256，生成 model_quantized.bin.sha256 文件，一同打入 assets ；
• 运行时校验 ：在 ArkTS 主页面 onPageShow() 生命周期中，调用 @ohos.fileio 读取模型文件，再用 @ohos.security.huks 模块调用 verify API，用预置的公钥验证签名（公钥已硬编码在代码中，且与签名密钥配对）。

代码片段（精简）：

// utils/modelValidator.ts
import fileio from '@ohos.fileio';
import huks from '@ohos.security.huks';

const MODEL_PATH = 'resources/base/assets/model_quantized.bin';
const SHA256_PATH = 'resources/base/assets/model_quantized.bin.sha256';

async function validateModelIntegrity(): Promise<boolean> {
  try {
    const modelData = await fileio.readText(MODEL_PATH);
    const sha256Data = await fileio.readText(SHA256_PATH);
    // 使用 Huks verify 接口校验（此处省略密钥初始化细节）
    return await huks.verify({
      srcData: modelData,
      signature: sha256Data,
      options: { digest: huks.HuksDigest.DIGEST_SHA256 }
    });
  } catch (err) {
    console.error('Model integrity check failed:', err);
    return false;
  }
}

这个操作看似繁琐，但解决了根本问题：审核员在后台扫描时，会自动提取 assets 下所有 .bin 文件及其同名 .sha256 文件，用内置公钥验证哈希值。一旦通过，该模型即被标记为“可信资产”，后续所有 AI 调用行为才被允许。

2.3 第 3 条：未声明模型训练数据来源及偏见控制措施

这是鸿蒙区别于其他平台的标志性条款，也是个人开发者最容易忽略的“软性红线”。

原始驳回原文：“应用未在隐私政策及应用描述中说明语音转写模型所用训练数据的来源、构成比例、是否包含未成年人语音、是否进行性别/方言/口音偏差测试，违反《HarmonyOS AI 应用伦理指南》第 2.4 条‘所有面向公众的 AI 功能必须提供可验证的数据治理声明’。”

很多人第一反应是：“我用的是开源 Whisper 模型，又不是自己爬的数据！” 但审核逻辑是： 你选择了这个模型，就继承了它的数据责任 。Whisper 的训练数据包含大量 Common Voice、LibriSpeech，其中 LibriSpeech 明确标注“仅限成年朗读者”，Common Voice 则有未成年人贡献。鸿蒙要求你必须向用户坦白这一点，并说明你做了什么来降低风险。

A 同学的应对不是去改模型，而是重构“声明层”：

• 在应用内新增「AI 说明」页面（路径：设置 > 关于 > AI 技术说明），包含三部分：
  • 数据来源声明 ：“本模型基于 OpenAI Whisper v3.1.2 开源权重微调，原始训练数据来自 Common Voice（v16.0，含 12–17 岁青少年语音样本）及 LibriSpeech（clean-100，成年朗读者）”；
  • 偏差控制措施 ：“已针对中文场景进行方言适配训练（覆盖粤语、川普、东北话），并在测试集上对 5 种常见口音进行 WER 对比，误差率差异 < 2.3%”；
  • 用户可控开关 ：“如您不希望使用 AI 转写功能，可完全禁用，不影响其他文本输入功能”。

最关键的是，这份声明必须同步更新到 AppGallery 后台的应用描述页（非应用内页面），且文字需与应用内完全一致。审核员会人工比对两处文案，一处不符即打回。这本质上是在强制开发者建立“AI 透明度契约”，不是技术问题，而是产品信任基建。

2.4 第 4–7 条：逻辑链断裂——从“能跑”到“可信”的四道坎

这四条意见集中暴露了一个核心矛盾：开发者关注“功能实现”，审核关注“行为可溯”。A 同学的模型在本地跑得飞快，但审核系统看不到“推理过程是否受控”。我们逐条拆解：

第 4 条：未提供推理过程日志开关及日志脱敏策略
驳回点：所有 AI 推理调用必须支持运行时日志输出，且日志中禁止出现原始音频波形、未脱敏文本片段、内存地址等敏感信息。A 同学最初只开了 debug 日志，里面直接打印了 inputTensor.data 的前 100 字节——这在审核员看来，等于把用户刚说的半句话明文贴在日志里。解决方案：在 config.json 中新增 customConfig 字段，定义 aiLogLevel: "none" | "summary" | "debug" ，默认为 summary ； summary 模式下只记录“开始推理”“耗时 XXms”“输出 token 数”，绝不碰原始数据。

第 5 条：未声明模型最大输入长度及截断策略
驳回点：模型若支持长语音，必须明确告知用户“单次最多处理 60 秒语音，超长部分将被静音截断，不缓存、不拼接”。A 同学没声明，系统默认认为他可能偷偷缓存。他在 resources/base/element/string.json 新增字段 "ai_max_duration": "60" ，并在 UI 上显示为“最长支持 60 秒连续语音”。

第 6 条：未实现推理失败降级机制
驳回点：当模型因内存不足、芯片不支持等原因推理失败时，必须提供确定性降级方案（如返回固定提示语“当前设备暂不支持该功能”，而非崩溃或黑屏）。A 同学原来用 try/catch 捕获异常后直接 console.error ，这不算降级。他改成了：捕获 ModelLoadError 或 InferenceError 后，自动切换到纯文本输入框，并显示 Toast：“已为您切换至键盘输入模式”。

第 7 条：未提供模型版本及更新策略说明
驳回点：模型不是静态资产，必须说明“何时更新、如何更新、用户是否可控”。A 同学原计划 OTA 更新模型，但没写清楚。他最终在「AI 说明」页增加：“模型版本：Whisper-HM-20240521，随应用版本更新，不单独推送。您可在设置 > 关于 > 检查更新中查看模型变更日志”。

这四条合起来，构成了一条完整的“AI 行为可信链”：你能启动（第 1 条）、文件可信（第 2 条）、数据透明（第 3 条）、过程可查（第 4 条）、边界清晰（第 5 条）、失败可控（第 6 条）、演进可知（第 7 条）。缺一不可。

2.5 第 8–12 条：体验可信度缺失——让用户“信得过”的五个细节

最后五条，全是关于“用户感知”的细节。它们不致命，但集体出现，说明审核员认为你“没把 AI 当成熟产品做”。我们看 A 同学如何用最小成本补全：

第 8 条：转写结果未标注“AI 生成”水印
解决方案：在所有转写结果的 Markdown 导出文件末尾，自动追加一行： <!-- AI-generated by [App Name] v1.0.0, local inference only --> 。不是 UI 上加 logo，而是埋在数据层，确保用户分享出去时，接收方也能看到来源声明。

第 9 条：未提供“清除本次推理上下文”按钮
解决方案：在转写界面右上角增加一个垃圾桶图标，点击后清空当前 session 的所有中间缓存（包括音频 buffer、token history、attention mask），并重置模型状态。代码上用 @ohos.app.ability.UIAbility 的 onDestroy() 钩子确保进程退出时也清空。

第 10 条：未说明模型对设备温度/电量的影响
解决方案：在「AI 说明」页新增：“持续转写 10 分钟约增加设备温度 1.2°C，耗电约 3.7%，建议在通风环境下使用”。数据来自他用 @ohos.battery 和 @ohos.sensor 模块实测的 12 台不同型号真机数据，取中位数。

第 11 条：未提供“禁用 AI 加速”的手动开关
解决方案：在设置页增加开关，默认开启。关闭后，强制使用 CPU 推理（绕过 NPU），速度下降但兼容性 100%。这满足了“用户主权”原则——不是系统替你决定用什么硬件。

第 12 条：应用图标未体现 AI 属性
解决方案：在 resources/base/media/icon.png 旁，新增 icon_ai.png （带微光粒子效果的抽象脑图），并在 module.json5 的 abilities 下 metadata 字段中声明 "aiIcon": "$media:icon_ai" 。审核员会检查图标语义是否与功能一致。

这五条，表面是细节，实则是鸿蒙在构建一种新的“AI 产品范式”： AI 不是炫技插件，而是需要被设计、被声明、被尊重、被掌控的用户资产 。A 同学改完这 12 条，第二轮提交，3 天后收到“审核通过”邮件。

3. 再撞三座大山：过审之后的真实挑战

过审不等于结束，而是真正挑战的开始。A 同学在应用上线第 5 天，遭遇了三座意料之外的“大山”，每一座都比审核更难缠。它们不是来自官方规则，而是来自生态本身的不成熟、用户预期的错位、以及技术落地的物理限制。这三座山，才是个人开发者真正要扛的。

3.1 第一座大山：NPU 兼容性黑洞——同一份模型，在不同设备上表现天壤之别

A 同学的模型在 DevEco Studio 模拟器（API 12，x86_64）上跑得飞快，1 秒语音 0.3 秒出结果；在华为 Mate 50（麒麟 9000S，达芬奇 NPU）上，速度提升 4.2 倍；但在某款搭载紫光展锐 T7520 的中端机型上，NPU 推理直接报错 ERR_NPU_NOT_SUPPORTED ，被迫回退到 CPU，速度暴跌 8 倍，用户反馈“转写卡成幻灯片”。

问题根源在于： HarmonyOS NEXT 的 NPU 抽象层（HIAI NN）尚未完全统一 。麒麟芯片用达芬奇架构，海思自研驱动；高通骁龙用 Hexagon，需高通 SDK 适配；紫光展锐用自研架构，驱动由芯片厂提供，但鸿蒙系统层对其支持深度不一。A 同学最初只做了“NPU 可用则用，不可用则 CPU”，没做分级适配。

他最终的破局方案是“三级推理路由”：

• Level 1（最优） ：检测到麒麟/骁龙高端 NPU，加载 model_npu_hiai.bin ，用 @ohos.npu 模块调用；
• Level 2（次优） ：检测到中端 NPU（如 T7520、天玑 810），加载 model_npu_lite.bin （专为低算力 NPU 优化的 4-bit 量化版），用 @ohos.npu 的 LiteSession 接口；
• Level 3（保底） ：NPU 不可用或 Level 2 失败，加载 model_cpu_f32.bin （FP32 精度，CPU 优化版），用 @ohos.ai 模块的 cpuInference 接口。

关键实现是动态检测：

import npu from '@ohos.npu';

async function getNpuCapability(): Promise<'high' | 'mid' | 'none'> {
  try {
    const info = await npu.getDeviceCapability();
    if (info.vendor === 'HISILICON' && info.version >= '2.0') return 'high';
    if (info.vendor === 'UNISOC' && info.version === '1.2') return 'mid'; // T7520 固定版本号
    return 'none';
  } catch (err) {
    return 'none';
  }
}

他为此多写了 370 行设备适配代码，但换来的是：上线后 7 天内，用户投诉“卡顿”从 23% 降至 1.8%。这提醒所有开发者： 端侧 AI 不是“写一次，跑所有”，而是“为每一块芯片写一次” 。

3.2 第二座大山：用户教育成本远超预期——90% 的差评源于“不知道它能干什么”

应用上线首周，A 同学收到 127 条用户评价，其中 89 条是：“说半天没反应”“转写不准”“和讯飞比差太远”。他一头雾水，直到亲自录了 100 条用户操作视频（经用户同意），才发现真相： 83% 的用户根本没点开那个小小的“麦克风”图标，而是对着手机屏幕说话，或者把手机放桌上，指望它自动监听 。

鸿蒙的语音采集，必须由用户主动触发（ startRecording() ），且要求麦克风正对声源 30cm 内。但用户潜意识里，把这当成了“智能音箱”，期待“随时待命”。A 同学最初的 UI，只有一个底部浮动按钮，没有任何引导。

他紧急迭代了 V1.1.0，核心是“零学习成本引导”：

• 首次启动 ：全屏蒙层，箭头指向麦克风按钮，文字：“点这里，开始说话（请靠近麦克风）”；
• 长按麦克风 ：触发震动反馈 + 文字气泡：“正在监听… 请保持 30cm 内”；
• 转写中 ：UI 顶部显示实时波形动画（非真实音频，而是模拟的振幅变化），让用户“看见声音”；
• 失败时 ：不显示“错误”，而是显示：“没听清，试试再说一遍？（环境安静些，离话筒近点）”。

他还把 FAQ 做进了应用：在设置页新增「使用技巧」，用 3 张卡片说明：“1. 最佳距离：20–40cm；2. 避免背景音乐；3. 中文请用普通话，英文请用美式发音”。上线后一周，差评率从 70% 直降到 12%。这印证了一个残酷事实： 在 AI 产品里，UI/UX 不是加分项，而是生存线。技术再强，用户不会用，等于零 。

3.3 第三座大山：模型更新的“静默陷阱”——用户不升级，你就永远困在旧版本

A 同学的 V1.0.0 模型在上线第 10 天，被发现对“数字串”（如电话号码、身份证号）识别率偏低。他迅速优化了微调数据集，发布了 V1.1.0，模型精度提升 37%。但两周后，后台数据显示：仍有 68% 的活跃用户停留在 V1.0.0。他们不是不想升，而是根本不知道有新版本——鸿蒙的 OTA 更新不像安卓那样强提醒，尤其对个人开发者应用，系统默认“静默更新”。

更麻烦的是，V1.1.0 的模型文件比 V1.0.0 大 1.2MB，部分低端机用户安装失败，报错 INSTALL_FAILED_INSUFFICIENT_STORAGE ，但他们看不到具体原因，只觉得“更新不了”。

A 同学的破局是“双通道更新”：

• 通道一（系统级） ：在 module.json5 中配置 "updatePolicy": "auto" ，并接入 @ohos.update 模块，当检测到新版本时，调用 checkUpdate() + downloadAndInstall() ，失败时捕获 UpdateErrorCode.DOWNLOAD_FAILED ；
• 通道二（应用内） ：在首页 Banner 位增加横幅：“新版上线！数字识别准确率↑37%，点击立即升级”，点击后跳转到 AppGallery 页面，强制用户走商店流程（商店会处理存储空间清理）。

他还做了个狠招：在 V1.1.0 中，给所有 V1.0.0 用户的首次转写结果末尾，自动添加一行小字：“检测到您使用的是旧版模型，升级后可获得更准的数字识别 → [立即升级]”。这招让 7 天内升级率从 32% 拉到 89%。

这第三座山揭示了一个本质： 端侧 AI 应用不是“发布即结束”，而是“发布即运营” 。你得像运维一个 SaaS 服务一样，盯着模型性能、用户版本分布、失败率曲线。个人开发者没有运营团队，那就得把运营逻辑写进代码里。

4. 实操避坑清单：12 条整改 + 三座大山背后的 27 个血泪教训

把上面所有内容压缩成一张可直接抄作业的避坑清单。这不是理论总结，而是 A 同学、我和另外两位过审开发者，在 37 天高强度迭代中，用真金白银（时间、流量、用户口碑）换来的 27 条硬核经验。每一条，都对应一个曾让我们熬夜到凌晨三点的具体问题。

序号	问题领域	血泪教训	实操建议
1	权限声明	“录音权限”四个字不够，必须说明“谁用、怎么用、用完即焚”	弹窗文案必须包含三要素：① 功能名（本地语音转写）② 数据路径（仅在设备内存）③ 不做什么（不上传、不存储、不联网）。字数控制在 80 字内，与 config.json 严格一致。
2	模型安全	模型文件没签名 = 黑箱，审核直接拒	所有 .bin / .onnx 模型必须配对 .sha256 文件，且校验逻辑必须在 onPageShow() 中执行，失败则禁用 AI 功能并 Toast 提示。
3	数据伦理	不提训练数据 = 隐瞒，不是“我不知道”，而是“我不愿说”	在应用内和 AppGallery 后台，必须同步声明：① 开源模型名称及版本 ② 主要训练数据集及年龄范围 ③ 已做的偏差测试类型（方言/性别/口音）及误差率。拒绝模糊表述如“大量公开数据”。
4	日志管理	Debug 日志打原始 tensor = 泄露用户语音	日志等级必须可配置（none/summary/debug），summary 模式下只记录耗时、token 数、状态码；debug 模式需用户手动开启，且自动脱敏所有输入输出。
5	输入边界	不声明最大时长 = 系统默认你可能缓存	在 string.json 中定义 ai_max_duration ，并在 UI 显著位置展示（如按钮旁加“≤60s”角标）。超时时必须静音截断，不拼接、不缓存。
6	失败降级	try/catch 后 console.error ≠ 降级	必须提供用户可见的确定性降级：① 自动切换到备用输入方式（键盘）② 显示友好提示语（非错误码）③ 记录失败原因到本地统计（用于后续优化）。
7	模型版本	不说更新策略 = 用户无法预期变化	在「关于」页必须写明：① 当前模型版本号（含日期）② 更新方式（随应用更新）③ 变更日志入口（链接到 GitHub Release 或内嵌网页）。
8	AI 水印	不标注 AI 生成 = 欺骗用户	所有 AI 输出内容（文本、Markdown、JSON），必须在数据层嵌入不可见水印，格式为 <!-- AI-generated by [App Name] vX.X.X --> 。
9	上下文管理	不提供清除按钮 = 用户担心隐私	必须在 UI 提供一键清除当前 session 所有缓存的按钮，点击后重置模型状态、清空内存 buffer、销毁临时文件。
10	设备影响	不说明温/电影响 = 用户误判为故障	在「AI 说明」页，用实测数据写明：① 持续使用 10 分钟的温升（°C）② 耗电百分比 ③ 建议使用环境（如“建议通风”）。数据必须来自至少 5 台不同芯片机型的实测。
11	硬件控制	不提供禁用开关 = 剥夺用户选择权	设置页必须有“禁用 AI 加速”开关，默认开启。关闭后，强制走 CPU 推理，并在 UI 显示“CPU 模式”状态标签。
12	图标语义	图标无 AI 元素 = 功能不直观	必须提供 icon_ai.png ，风格需体现智能（如脑图、光效、抽象电路），并在 module.json5 中声明。审核员会人工比对图标与功能一致性。
13	NPU 适配	一份模型打天下 = 在中低端机上必然失败	必须实现三级路由：① 高端 NPU（麒麟/骁龙旗舰）→ full 模型 ② 中端 NPU（T7520/天玑 810）→ lite 模型 ③ 无 NPU → CPU 模型。检测逻辑必须覆盖芯片厂商+版本号。
14	用户引导	UI 无引导 = 83% 用户不会用	首次启动必须全屏引导，长按有震动+气泡提示，转写中显示模拟波形，失败时给可操作建议（非错误码）。
15	模型精度	只测普通话 = 对数字/方言/口音束手无策	测试集必须包含：① 5 种主流方言（粤/川/闽/吴/东北）② 3 类数字串（电话/身份证/银行卡）③ 2 种口音（港普/台普）。WER（词错误率）差异需 < 3%。
16	存储空间	模型变大不处理 = 低端机安装失败率飙升	模型文件超过 5MB 时，必须在安装前调用 @ohos.fileio.getFreeStorageSize() 检查剩余空间，不足则 Toast 提示“需至少 XX MB 空间”，并引导用户清理。
17	内存管理	不释放模型 = 多次转写后 OOM 崩溃	每次推理完成后，必须调用 model.destroy() 销毁实例；在 onPageHide() 和 onDestroy() 生命周期中，强制销毁所有模型引用，防止内存泄漏。
18	网络兜底	完全离线 = 用户遇到问题无求助渠道	即使 100% 离线，也必须在设置页提供「在线帮助」入口，链接到你的知识库（如 Notion 页面），内容需覆盖：① 常见问题 ② 设备兼容列表 ③ 模型原理简述。
19	语言包	只做中文 = 错失海外用户	如果模型支持英文，UI 必须同步支持 en-US 语言包，且在 resources/base/element/string.json 中，所有 AI 相关文案（弹窗、提示、说明）都需有英文翻译。审核员会切换系统语言测试。
20	热更新	模型热更 = 违反鸿蒙安全沙箱	绝对禁止通过网络下载模型文件并动态加载。所有模型必须打包进 .hap ，更新只能通过应用版本升级。热更会被系统拦截，且审核直接拒。
21	权限最小化	申请多余权限 = 触发隐私质疑	只申请必需权限： MICROPHONE 。禁用 STORAGE （不存录音）、 LOCATION （不依赖位置）、 CONTACTS （不读通讯录）。即使你的模型理论上能用，也不申请。
22	耗电优化	不监控耗电 = 用户吐槽“太费电”	在 @ohos.power 模块中监听 POWER_STATE_CHANGED 事件，当设备进入低电量模式（<15%）时，自动降低模型推理频率（如从实时转写降为每 2 秒采样一次），并 Toast 提示“已为您省电优化”。
23	真机覆盖	只测模拟器 = 上线即翻车	必须用真机测试：① 至少 3 款麒麟芯片（Mate 50/P60/畅享）② 至少 2 款高通芯片（Pura 70/Mate X5）③ 至少 1 款紫光展锐（畅享 70）。模拟器无法反映 NPU 真实性能。
24	审核沟通	被打回不问 = 永远不知道审核员在想什么	每次被打回，必须在 AppGallery 后台“联系审核员”入口提交工单，问题描述必须包含：① 应用包名 ② 提交版本号 ③ 具体哪一条意见 ④ 你已做的修改（附代码片段或截图）。我们 70% 的二次过审，靠的是精准提问。
25	版本回滚	不留旧版备份 = 用户投诉无法降级	每次发布新版本前，必须在本地存档旧版 .hap 文件，并在 GitHub Release 中同步上传。当用户反馈新版本问题时，能快速提供降级包。
26	用户反馈闭环	不看差评 = 问题永远在重复