系列收官篇。B19 搞定了"包本身干净"，B20 搞定了"应用内合规"，最后一步是把应用讲给应用市场和潜在用户听：物料包。我们的物料不住在聊天记录和设计师的电脑里，而是归档进仓库：

docs/release/appgallery/
├── README.md              # 物料包索引与状态
├── listing.md             # 市场文案定稿（名称/简介/详细描述/分类）
├── icons-checklist.md     # 图标核对清单
├── screenshot-script.md   # 截图脚本（每张图对应的真实 UI 路径）
├── screenshots/           # 真机截图归档
└── store-icon-1024.png    # 分层图标 1024 成品

物料进仓库的意义：和代码同源 review、同源演进，市场文案改一个字也有 diff 可查。

1. listing 的第一原则：禁止夸大未交付能力

listing.md 文件头一行加粗：与实现一致；禁止夸大未交付能力。这不是套话——定稿过程中真的抓到一批品牌指南与市场草稿和实现的漂移，每条都修了：

这张表是物料工作最有价值的部分：市场是产品承诺的放大器，实现是承诺的预算。夸大的文案不是营销技巧，是给自己签的欠条——审核打回算轻的，用户按文案找不到功能给一星才是代价。注意漂移修正不只改物料，还回写了品牌指南源文档——口径的修复要回到源头，否则下一版物料又从错的源头长出来。

详细描述里还有个成熟做法：隐私与数据段落直接复述技术事实（本地词库分析、历史存应用沙箱约 50 条无音频、Key 系统保险箱保存可清除）——B20 的结论：合规文案是技术决策的复述。市场文案、隐私政策、实现三者同源，审核问任何一处都答得上来。

2. 图标与截图：鸿蒙的规格与传统坑

分层图标。鸿蒙的应用图标不是一张平图，而是前景层 + 背景层的分层结构：系统桌面、主题引擎会按层做动效和裁剪（圆角、描边、深色底适配都是系统按层处理的）。工程内对应 AppScope/resources/base/media/ 下的前景/背景图加 layered 声明；市场上传的 1024×1024 成品同样按这个心智准备——前景主体居中留出安全区，背景层可以铺满，千万别把带圆角和阴影的"成品效果图"当源图交上去，系统再裁一次就双重圆角了。我们配 icons-checklist.md 逐项核对：尺寸、分层、无拉伸、深浅底都试过。图标是用户在市场的第一眼，但也是纯视觉活，清单化之后核对五分钟搞定。

截图。规格按 AGC 当期要求（张数下限、分辨率比例、手机/平板分端）准备，两个实操建议：一是用真机截图不用模拟器——状态栏、字体渲染、HDS 组件的细节在真机上才是用户真实看到的样子；二是注意状态栏卫生，电量、时间、通知图标在 5 张图里尽量统一，这是细节但市场截图本质是橱窗。流程上我们不写"截图 5 张"就完事，而是 screenshot-script.md——每张图对应真实的 UI 路径（首页 ST-01 点哪里进入、什么状态下能看到这个画面、要不要先配置 Key）。截图脚本的价值：换版本要重拍截图时，任何人照着脚本都能复现同一批画面；验收时也能核对"图里的功能是不是真的存在"。

3. AGC 后台：鸿蒙特有的几个表单项

物料备齐后进 AppGallery Connect 后台，有几处是鸿蒙应用特有的关注点：

• 应用类型别选错：AGC 里"HarmonyOS 应用"与"元服务（原子化服务）"是两种形态——元服务免安装、有包体和入口限制，走完全不同的分发路径。我们是标准应用，创建时选 HarmonyOS 应用；这个选择影响后续所有表单项，选错没有后悔药。

• bundleName 创建即锁定：后台创建应用时填的包名必须与 AppScope/app.json5 的 bundleName 一字不差，上架后不可改（B19 的核对清单在这兑现）。

• 上传的是 App Pack（.app）：不是 hdc 装的那个 HAP。本地 assembleApp 出包、记录 hash、后台上传；versionCode 单调递增由后台强制校验。

• 内容分级问卷：按实际内容如实填（教育类工具通常很低龄向），分级结果会显示在市场页。

• 隐私声明表单：后台要逐项声明收集哪些数据、用途、是否共享第三方。这张表必须与应用内隐私政策（B20）同源对照填写——审核会比对表单声明、隐私政策文本、应用内实际行为三处，任何一处对不上都是打回项。我们的答案之所以好填，是因为架构里数据根本不出沙箱、唯一的网络出口是用户自配 Key 的 AI 调用，表单上大片"否"。合规友好的架构，在填表时才开始分红。

4. 缺项的诚实姿势：已知问题，不是假装完成

物料包关单时有一个真实的缺口：5 张真机截图需要项目方在真机上补拍，研发侧交付不了。处理方式不是 P 图凑数、不是用模拟器图冒充，而是：

1. 缺口登记为已知问题（KI-01：截图可上架前再补）；

2. 关单条件里写明"5 张真机图为独立验收通过条件"，由项目方明示豁免后才关单；

3. 豁免事实连同日期写进任务单状态（截图经项目方 2026-07-16 明示豁免）。

缺口可以被豁免，但豁免必须显式、留痕、有授权人。 这个流程看起来繁琐，它防的是软件工程最贵的病：大家心照不宣地把未完成当成完成。

5. 门禁兜底：物料也有静态检查

物料包配了 check-p7-appgallery-assets.sh（+ 14 个 mutation）：归档文件齐全、listing 里的版本/bundle/vendor 与 app.json5 一致（B19 的同源原则延伸到文案）、禁止词扫描（示例占位、夸大表述黑名单）、截图脚本引用的 UI 路径真实存在。市场文案漂移进门禁，和代码红线同等待遇。

6. 提交流程速查

1. RC 标签管理候选（speaklab-1.0.0-rc.N），干净重建 + SHA-256 记录（B19）

2. 真机 RC 矩阵回归（静态门禁不替代真机）

3. 物料核对：listing 门禁绿、图标分层清单 PASS、截图补齐（KI-01 关闭）

4. assembleApp 出 App Pack，记录 hash；后台创建/核对应用（HarmonyOS 应用、bundleName 一致）

5. 后台填写：名称/分类（建议教育）/内容分级/隐私声明表单——与应用内隐私政策同源对照

6. versionCode 递增提交，等待审核；打回按意见改，文案类问题先改源头文档再改物料

7. 系列结语

到这里，《鸿蒙实战手记》21 篇走完了一个应用从空白工程到上架的完整链路：

• 第 1 章（B01–B03）：工程骨架、Debug/Release 物理隔离、启动装配——地基打在哪，楼就盖多高；

• 第 2 章（B04–B06）：导航壳层、语义主题、富文本——UI 的一致性来自纪律不是审美；

• 第 3 章（B07–B09）：词库加载、算法移植、持久化分层——数据是资产，按成本分层管理；

• 第 4 章（B10–B12）：ASR、权限、生命周期——系统能力的正确姿势是边界 + 隔离 + fail-closed；

• 第 5 章（B13–B15）：HTTP 调用层、Prompt 契约、Key 安全——AI 功能工程化，不确定性只留给模型文采；

• 第 6 章（B16–B18）：测试纪律、门禁、变异测试——验证手段本身也要被验证；

• 第 7 章（B19–B21）：发布卫生、最小合规、物料上架——把"完成"定义成有证据的事。

如果只能带走一句话：把每一条重要的规矩，都变成可执行、可验证、可留痕的东西——注释、脚本、门禁、契约、hash。记忆会褪色，团队会换血，但被脚本守住的规矩不会。

祝你上架顺利。