导言

PA 开发与打包实践 · 02 进阶篇
从单工程多配置，到候选验收、版本固定与断点恢复，记录多产品、多渠道交付中的工程做法。

连续做过几批 PA 项目后，我越来越在意一个问题：当同一套玩法需要同时适配多个产品、渠道和语言时，怎样保证每一份成品都来自正确的源码，并且经过了对应的验证？

单个版本可以靠人工记忆推进。规模扩大以后，素材版本、产品身份、渠道配置、候选验收和正式发布之间的关系，就需要明确记录下来。

我们的一次历史交付包含两款产品，最终生成了 824 个文件。这是那个批次的实际规模，并不是所有项目的固定目标。它带来的直观感受是：当成品达到几百份，靠逐个改配置、手工挑文件的方式，很难稳定地完成交付。

这篇文章结合现有项目，整理我们如何组织开发与打包流程。文中的顺序是团队实践，具体渠道格式、体积限制和工具命令，仍然需要以项目采用的规范为准。

阅读导航

• 01 · 用配置组织差异
• 02 · 把输入检查放在构建之前
• 03 · 跑通体验并验证变更边界
• 04 · 让候选包覆盖风险
• 05 · 分开记录不同层次的验证
• 06 · 让测试结果绑定实际文件
• 07 · 安排发布顺序
• 08 · 人工接力与依赖推进
• 09 · 从中断处恢复流水线

01–用配置组织差异

我们采用单工程、多配置输出的方式。主要玩法由一套源码维护，产品、渠道、国家和语言等差异通过配置表达。

为了便于理解，可以把工程职责分成几部分：

这种划分让修改的影响范围更容易判断。

修复拖拽逻辑时，重点检查共用玩法；更换产品图标时，重点检查产品配置和资源；调整渠道接入时，则检查对应平台的行为。

实际工程未必完全按这张表拆目录，但职责应该尽量清楚。否则，一个看起来只是换 Logo 的任务，也可能意外影响其他产品的按钮或跳转。

配置化也不意味着可以任意组合。哪些国家与语言需要交付，哪些产品支持哪些渠道，都应该来自本次明确的范围。构建矩阵需要校验，不能默认把所有维度做一次笛卡尔积。

02–把输入检查放在构建之前

过去遇到问题时，很容易直接进入工程：先拉代码、恢复依赖、导入素材，最后才发现产品资料不完整。

现在，我们把素材和产品信息检查放在前面。

检查对象包括本批需要的资源、批准来源、文件完整性、产品身份和渠道语言范围。更换主题的任务，还要核对布局及相关视觉资源；仅替换图标和 Logo 的任务，则围绕其实际变化检查。

这样安排的价值，是让错误尽可能出现在成本较低的阶段。

缺一张批准的结束页图片，应该在准备阶段暴露。如果等到正式构建后再发现，后面已经完成的视觉检查、候选测试和文件记录都可能需要更新。

同时，构建来源也要固定下来。我们记录业务源码、模板、依赖和规范的版本。公共参考库可以共享，但各工程的依赖安装目录、编辑器缓存和构建产物保持独立，避免并行任务相互影响。

输入稳定，后续验证才有明确的对象。
素材检查解决“用什么”，版本记录解决“从哪里来”，任务范围解决“要生成哪些内容”。

03–跑通体验并验证变更边界

打包流程再完善，也无法替代玩法本身的正确性。

在实现时，我们会先确认从启动、首次操作、过程反馈到结束页面的完整路径。随后检查容易被改动影响的部分，比如输入是否重复响应、动画期间能否误触、重新开始后状态是否重置，以及音频是否按预期播放。

更换主题时，还需要验证素材接入后的真实布局。设计图中的位置正确，不代表实际运行中的缩放、遮挡和点击区域也正确。

生产内容与测试工具也要保持边界。用于模拟平台、观察事件或快速跳过流程的能力，可以帮助开发，但不能未经隔离就进入正式成品。

这类问题未必会让本地试玩立即报错，却会影响最终产物的可信度。因此，运行检查和源码检查需要同时存在。

04–让候选包覆盖风险

如果正式范围很大，每次改动都先跑一轮全量构建，会产生明显的时间和存储成本。

我们当前的默认策略，是每款产品先准备少量代表性候选，通常共一到两份，再根据变化和风险判断是否需要扩大范围。这是本项目的执行策略，不是通用的充分测试标准。

候选选择需要有理由。

每一次抽样都应该说明：选择了什么，验证了什么，还有哪些差异没有覆盖。

如果两份候选无法覆盖本次关键风险，就应该调整测试范围。代表性抽样的前提，是理解变化和风险；抽样结果也不能写成全量验收结论。

05–分开记录不同层次的验证

我们逐渐把验证拆成不同层次：

这些结论需要分别成立。

例如，本地日志出现一条事件，只能说明客户端执行到了某个位置。请求成功返回，也不能单独证明后台已经完成入库。平台页面显示测试成功，则需要确认它具体覆盖了哪些检查项。

同样，本地模拟环境可以帮助定位问题，但不能替代真实平台的验收。

当某个后台确实没有可用的查询入口时，我们会记录未核验的原因，以及本任务是否允许带着这项限制继续。已知事件漏发、身份错误等真实缺陷，则需要修复。这两种情况必须分开处理。

06–让测试结果绑定实际文件

这是整条流程里很重要的一点。

“这个版本测过了”是一句不够准确的话。版本号相同的两个文件，也可能因为素材、配置或压缩参数不同而产生不同内容。

因此，我们会给候选和正式成品记录 SHA256。可以把它理解为文件内容的指纹，用来核对后续拿到的文件，是否与当时验证的文件一致。

文件指纹不能证明游戏正确，但能帮助维护证据之间的对应关系：

测试的是哪一份 → 上传的是哪一份 → 交付清单指向的是哪一份

如果修改了资源、代码、配置或压缩参数，就需要重新判断旧证据是否适用。候选文件的通过记录，不能自动覆盖重新生成的正式文件。

压缩调整尤其容易被低估。体积变小了，文字边缘、透明效果或者音频也可能改变，所以除了检查字节数，还需要检查实际观感和听感。

对于支持分组的输出，我们会先检查是否能够通过合理分组满足体积要求，再评估质量调整。具体分组上限和策略属于项目约定，需要结合工具能力使用。

07–安排发布顺序

我们当前采用的主要顺序是：

1. 固定输入： 版本、源码和相关文档定稿。
2. 验证候选： 完成最终候选构建与验收。
3. 登记就绪： 由工具登记产品就绪状态。
4. 审核源码： PR 审核与合并，核验主分支。
5. 固定发布版本： 创建新标签。
6. 生成正式成品： 执行正式本地构建。
7. 验证最终文件： 完成对应正式文件的验收。
8. 发布交付： 上传并发送通知。

把版本和相关文档放到最终候选之前，是因为部分工具会把这些输入纳入校验。验收后继续修改输入，可能让原有凭据失效。

候选通过后，也要确认就绪状态真正进入了提交和主分支。只在本地生成一份报告，而正式源码里仍然缺少登记，后面的发布工具仍然可能拒绝执行。

标签用来固定正式源码来源。标签发布后发现真实缺陷，应通过修复版本继续推进，保留原版本的可追溯性。

这里还要分清候选阶段与正式阶段：候选验收支持源码进入发布流程；正式成品从固定版本生成后，再完成对应文件的验收。正式文件尚未生成时，不可能提前拥有它的真实验收结果。

08–人工接力与依赖推进

有些平台检查需要人工完成。在我们的流程里，MTG 和 UN 的相应平台检验会交给用户，交接时提供实际文件、文件指纹、阶段、范围和检查入口。

等待反馈期间，可以继续做不依赖结果的工作，例如检查其他渠道、整理源码审查材料、准备 PR 说明和交付清单。

但“已经准备好 PR 说明”不等于“可以跳过候选门禁提交发布”，同样，“已经生成交付清单”也不等于“文件已经发布”。

把准备、执行、通过分别记录，流程才能在提高效率的同时保持清楚。

09–从中断处恢复流水线

批量任务可能因为构建耗时、人工反馈或外部服务而跨越多个工作时段。恢复任务时，如果只能依赖聊天记录，很容易重复构建或重复发送通知。

我们会保留几类记录：

尤其要注意，“运行中”不等于“失败”。恢复时应该先检查原任务是否仍在执行、产物是否已经生成，再决定是否重试。

交付也是一样：上传后需要核对文件数量与指纹，通知内容需要反映实际交付范围。消息发送成功，只能证明通知送达，无法替代对交付内容的检查。

经过这些任务，我们逐渐把“完成”的含义写得更具体：需求范围里的文件已经生成，来源可以追溯，适用的验证已经完成，实际上传内容与清单一致，剩余事项也有明确记录。

这样，后续维护者拿到某个 PA 文件时，就能够查到它从哪里来、经过哪些检查，以及下一次修改应该从哪里开始。