第一次提交版本前的最后检查

上一篇：提审不是点一下 Upload

一个项目接近第一次提交时，最容易出现的错觉是：支付测过，广告看过，安装包也导出过，商店资料已经准备，剩下的只是把这些结果汇总起来。

问题恰恰出在“测过”两个字上。支付可能测在昨天的版本，截图来自更早的界面，归档使用的是另一组构建号，审核说明又描述了今天才调整的流程。每一项单独都是真的，拼在一起却未必能证明即将提交的那个版本。

所以《Kibble Street TD》的最后检查只有一个核心问题：能否证明设备上运行的、商店里描述的、审核人员将要测试的，确实是同一个候选版本？本文整理的是这套验收方法，不代表提交动作已经发生。

先冻结候选版本，再开始验收

候选版本不是一个随口说出的“最新版”，而是一组不可混用的身份信息：确定的功能范围、版本号与构建号、签名归档、导出的安装包、配套商店资料，以及这一轮测试产生的证据。它们共同组成一次提交的最小边界。

冻结之后仍然可以修问题，但不能假装旧证据自动跟着修复。只要运行逻辑或安装包发生变化，归档、安装、真机主路径、支付和广告等下游证据就要重新建立；如果只改了截图或审核说明，也至少要重做受影响的资料校验和平台回读。

项目此前已经跑通过签名归档与安装包导出，归档中也能找到调试符号、权限和隐私清单。这只能证明构建链路曾经成立。因为之后代码和资料仍有变化，那份产物就不能直接冒充当前候选版本。最后检查的第一条规则因此很简单：旧结果可以证明能力，不能证明本次交付。

一张验收表要覆盖六个层面

最后检查如果只是按部门列任务，很容易得到“程序完成、素材完成、商店完成”这样的模糊结论。更有效的方式，是按风险从内到外拆成六层，并让每一层都写清预期结果、实际证据、负责人和状态。

第一层是范围：首发包含什么、明确不包含什么，临时测试开关是否关闭。第二层是安装包身份：版本、构建号、签名、权限、隐私清单和调试符号是否属于同一次归档。第三层是真机运行：全新安装、已有存档、重启恢复和核心玩法能否连续完成。

第四层是商业化与同意流程：支付交易能否恢复且不重复发奖，激励广告是否只在奖励真正成立后发放，广告能力是否晚于用户同意。第五层是商店合同：名称、文案、截图、内购、隐私答案与审核路径是否描述同一套产品行为，并在上传后从平台重新读取。第六层是风险决策：哪些问题必须阻断，哪些限制可以明确接受，哪些指标只能上线后观察。

这六层不是六份互不相关的报告。它们必须共享同一个候选版本身份，否则“全部通过”只是把不同版本的绿色结果拼在了一起。

安装包要沿着产物链逐层验明身份

从工程到设备，中间至少经过源文件范围、签名归档、导出安装包和实际安装四个产物。每一步都在增加新的变量，因此不能只在最后看一眼应用是否能打开。

源文件阶段要锁定范围与版本；归档阶段要核对签名、权限、隐私清单和调试符号；导出后要记录安装包指纹并检查包内关键文件；安装到设备后，还要读取实际版本并完成启动路径。这样出现问题时，才能判断它来自源文件、归档设置、导出过程，还是设备运行环境。

归档成功只能证明归档成功，导出成功也只能证明生成了可安装产物。它们不能替代真机行为、平台处理结果或审核状态。反过来，如果归档后又改了一行业务逻辑，那么旧安装包上的所有真机结论也不再属于新的候选版本。

真机测试要按陌生审核人员的路径走

开发者长期使用的设备通常保留着存档、登录状态和曾经同意过的权限，它最容易绕过首次启动问题。最后验收至少要覆盖三种状态：全新安装、带旧存档升级、完全退出后重新启动。

全新安装从同意流程和阵营选择开始，进入首页后完成一场战斗与结算，再进入商店测试支付和激励广告，最后检查设置中的隐私与条款入口。已有存档要验证版本升级后仍能进入正确关卡，货币、道具和已处理交易没有重复。重新启动则要确认存档恢复、未完成交易恢复和页面路由仍然正确。

这条路径故意按“陌生人第一次拿到游戏”的顺序执行。审核说明也应该使用同一顺序，让没有开发背景的人不依赖内部知识就能找到功能。如果说明里的一步无法在候选版本上照做，应该修改产品或说明，而不是临时向审核人员补充一段只有团队看得懂的解释。

成功路径通过，仍然不够

支付最危险的情况不是购买按钮完全失效，而是已经扣款、发奖或保存，却在下一步中断。《Kibble Street TD》的支付链路先处理经过验证的交易，再保存发奖结果，最后结束交易；同一交易再次到达时要识别为重复，发奖失败或结束失败时要保留可恢复路径。自动检查可以覆盖幂等、保存失败、结束失败和未完成交易恢复，但真实商店环境仍要在本次候选版本上验证。

激励广告同样不能把“广告关闭”当成“奖励成立”。只有收到明确的奖励事件，业务层才允许发放内容；无填充、网络失败、用户提前关闭或回调异常都必须保持未发奖状态。广告初始化还要服从同意结果，用户不具备请求广告的条件时，广告能力不能抢先启动。

自动化适合反复验证这些状态机，但它不能替人判断系统弹窗、支付面板、广告画面和返回路径在真实设备上是否可理解。最后验收必须同时保留机器检查与真机记录，不能用其中一类替代另一类。

已知风险必须进入决策

最后检查不是把所有问题都写成“已解决”，而是给每个问题一个可执行的归属。

阻断项会破坏候选版本身份、核心玩法、支付恢复、隐私承诺或审核路径，结论只能是修复、重建、重测。可接受风险是不影响关键路径的明确限制，但必须写出影响范围、接受人和后续处理时间。上线后观察项则是当前没有真实数据就无法回答的问题，例如广告填充、转化、设备性能分布和玩家流失位置。

AI 可以发现矛盾、整理证据和提示缺口，却不能替项目负责人接受风险。一次真正的风险接受必须留下谁作出决定、依据是什么、何时重新检查；否则它只是被换了名字的遗漏。

Go 或 No-Go，最后只能有一个结论

允许提交的条件应该同时成立：候选版本已经冻结；自动校验没有阻断项；归档、安装包和设备版本能够互相对应；真机审核路径通过；支付、广告与恢复路径在当前候选版本上完成验证；平台回读确认正确构建和资料进入正确位置；最后由人明确授权提交。

其中任何一项为红色，结论就是 No-Go。修复后从受影响的源头重新生成证据，而不是在验收表里手工改成绿色。全部成立时，结论才是 Go，并且授权的是“提交审核”这一项具体动作，不自动扩展为发布或后续版本操作。

人和 AI 分别负责什么

AI 负责执行可重复检查：比较版本身份，核对配置与资料引用，验证图片规格，检查支付和广告状态机，汇总每个证据属于哪个候选版本，并在输入变化时标记失效范围。

人负责真实设备操作、体验判断、隐私与商业承诺、风险接受和最终授权。AI 可以把几十项检查压缩成一张清晰的决策表，但“这个版本现在是否值得提交”仍然是人的产品责任。

如果你想开始

不要先复制一份很长的通用发布清单。先写下唯一候选版本的身份，再建立六行验收表：范围、安装包、真机、支付与广告、商店合同、风险。每行只保留四列：预期结果、实际证据、负责人、状态。凡是不能指向当前候选版本的旧截图、旧安装包和口头结论，先移出验收表。

前 18 篇到这里走到了第一个可提交版本的边界。接下来的内容不提前编排结果；等审核反馈、真实用户数据或下一次迭代实际发生，再从第 19 篇继续记录。