提审不是点一下 Upload

上一篇：统计和平台功能怎样不污染业务

一个游戏能够安装、能够运行，并不代表它已经可以提交审核。发布工具里的 Upload 很醒目，也最像一个终点：选中安装包，等进度条走完，看到上传成功。但它实际只完成了传输，把某个版本送进平台的处理队列。

《Kibble Street TD》准备第一个提交版本时，我们把这件事拆开检查，结果发现真正的工作分布在安装包、商店资料、审核说明、隐私声明、内购项目和截图之间。任何一处仍是旧内容、占位内容或没有建立对应关系，上传成功都不能替它变成完整。

一个版本其实有两份交付物

第一份是玩家最终安装的包。它包含版本号、构建号、签名、权限、隐私文件、第三方能力和实际运行逻辑。第二份是平台与审核人员看到的记录，包括名称、介绍、各语言文案、截图、内购资料、隐私问卷、审核说明和发布方式。

这两份交付物不能各自“看起来没问题”，而要描述同一个产品。游戏里没有账号系统，审核说明就不能留下测试账号；商品已经全部改为消耗型内购，资料里就不能再出现订阅和恢复订阅的路径；广告只有在用户同意流程完成后才初始化，隐私说明也必须反映同一套行为。

审核材料不是包装文案，而是当前版本的外部合同。代码改变了产品行为，合同就要跟着改变。

Upload 只是发布状态中的一格

当前构建流程把移动工程生成、归档、安装包导出和可选上传分成独立步骤。归档阶段会核对版本、构建号、展示名称和调试符号；上传成功后的结论也很克制：等待平台处理，然后出现在内测分发中。

这里至少有六个不能混用的状态：构建完成、归档导出、上传完成、平台处理完成、已经提交审核、已经发布。上传完成不能证明平台处理通过，更不能证明截图、内购和隐私资料已经齐全；内测可见也不等于已经进入审核队列。

因此项目把上传、内购同步、随版本提审、提交审核和自动发布保留为不同开关，当前默认不自动触发。它多了几次明确操作，却避免一次命令在资料尚未复核时改变多个远端状态。

审核说明要能让陌生人独立完成测试

审核人员不会参与开发过程，也不应该靠猜测寻找功能。当前说明明确写出：游戏没有应用内账号，进度保存在本地；排行榜登录是可选能力，使用审核人员自己的 Apple ID；商店中的付费项目均为消耗型，不存在订阅和恢复订阅按钮；未完成交易会在再次启动时恢复处理；广告在用户同意后才启动，也不申请跟踪权限。

它还给出从首次启动、选择阵营、进入战斗、打开商店、测试内购与激励广告，到在设置页查看隐私和条款的路径。这样的说明不是功能列表，而是一份最短测试手册。只要其中一句与当前界面不一致，就会把本来可以验证的功能变成审核疑点。

隐私不是交一份文件就结束

当前安装包使用的隐私清单能够通过格式检查，构建配置也要求它必须被打进主应用；文件缺失时直接停止生成，而不是悄悄继续。清单声明不进行跟踪，并列出产品交互、崩溃、设备标识、购买记录和游戏内容等数据类别，以及应用实际会用到的系统接口理由。

但这仍只覆盖一部分。真正需要对齐的是四处：第三方能力与代码的实际行为、安装包中的隐私清单、商店后台的隐私问卷，以及审核说明中的测试方式。前两项本轮可以从本地工程验证；后台问卷是否仍与当前版本一致，必须重新读取远端记录，不能拿一份旧的同步状态代替。

文件数量不能代表本地化已经完成

发布资料目前有 33 份语言文件，核心字段都不是空值，链接也使用安全地址。只看目录结构，它很像已经完成了大范围本地化；逐字段比较后，情况完全不同。

除英文基准外，只有 10 份语言文件拥有独立的介绍与版本说明，另外 22 份非英语文件仍直接复用英文。它们在技术上不是空文件，却还不能被描述成 32 种语言都已完成翻译。

这类问题很适合让 AI 批量比较：找出空字段、重复文案、超长内容和异常链接，再把需要人工判断的部分压缩成一张清单。人要决定首发真正支持哪些语言、哪些市场可以接受英文回退，以及翻译是否准确保留玩法和商业化含义。

截图的内核是一条可追溯映射

商店展示图和内购审核图都来自游戏画面，但它们承担不同任务。商店展示图面向玩家，说明产品的主要体验，并按设备、语言和展示顺序进入对应槽位；内购审核图面向审核人员，要证明具体商品从哪里进入、售卖什么，以及它与审核路径中的哪一步对应。

正确流程从候选版本开始：在真实运行环境中取得画面，先按用途分类，再检查尺寸、透明通道、文字和可见内容；随后把展示图绑定到设备与语言，把内购图绑定到具体商品和测试路径。上传之后还要读取平台记录，确认正确图片出现在正确槽位，而不是只看传输请求有没有成功。

这条映射比图片文件本身更重要。只要界面、商品内容、语言文案或候选版本发生变化，就要回到源头重新检查受影响的槽位。磁盘上有一张图，只能证明素材存在；候选版本、图片、槽位和远端结果能够互相追溯，才证明这份截图资料真正完成。

提审条件的内核是证据闭环

提审不是收集出一堆“看起来齐全”的文件，而是让所有材料围绕同一个候选版本形成闭环。第一道门确认安装包身份，包括版本、构建号、签名、权限和隐私清单；第二道门确认商店合同，包括介绍、本地化、截图、内购与审核说明；第三道门执行本地校验，排除超长字段、缺失引用、错误格式和占位内容。

第四道门是平台回读。它要确认候选构建已经处理完成，资料进入了预期版本，截图落在正确槽位，内购处于可随版本审核的状态。第五道门才是真机审核路径：从全新安装开始，按审核说明完成首次启动、核心玩法、支付、广告同意流程和法律链接检查。

五道门使用同一个版本身份和同一轮资料修订。任何一项失败，都回到对应源头修正并重新验证，不能用手工跳过、旧截图或上一次同步状态补齐结论。全部证据成立后，再由人明确授权提交审核；这才是“可提审”的实际含义。

人和 AI 分别负责什么

AI 适合维护这张证据矩阵：比较商品标识，统计语言文案重复率，检查图片尺寸和透明通道，验证字段长度与引用关系，并把安装包、商店资料和审核说明之间的冲突列出来。它还能逐门执行可自动化检查，避免团队把“上传成功”误写成“提审完成”。

人负责最终的产品承诺：选择首发语言与地区，重写不丢失含义的短说明，确认隐私答案与第三方能力一致，判断审核人员需要哪些上下文，并决定何时允许工具真正改变平台状态。

如果你想开始

先选定一个候选版本并冻结范围。建立一张证据表，依次记录安装包身份、商店合同、本地校验、平台回读和真机审核路径；每一项都写明输入、预期结果和实际证据。前一项没有通过，就不要进入下一项。五道门全部闭合后，再执行提交审核。