游戏外包开发的验收是整个流程中最关键的“守门”环节。验收不严，不仅会导致游戏上线后出现大量 Bug 或性能问题，还可能在支付尾款后发现源文件无法二次开发。
以下是针对不同外包类型制定的专业验收指南：
- 美术资产验收
美术验收的核心在于“视觉对标”与“工程规范”。
视觉审核： 角色比例、色彩表现是否符合原画或 Benchmark（标杆）。
技术指标审核：
面数/顶点数： 是否超过约定的阈值。
贴图规范： 尺寸是否为 2 的幂次方，贴图通道（如 Alpha 通道）是否正确。
骨骼与动画： 检查是否有拉伸、穿模，动画循环是否平滑，命名是否符合引擎规范。
工程可用性： 资源导入 Unity/UE 引擎后，材质球是否丢失，Shader 表现是否一致。
- 程序与功能验收
程序验收应关注逻辑的完整性和代码的健康度。
功能测试（黑盒测试）： 根据需求文档（PRD）逐项检查功能是否实现。
边界条件测试： 弱网环境、内存溢出、断电断网等极端情况下的表现。
代码质量评审（白盒测试）：
可读性： 注释是否清晰，变量命名是否规范。
解耦性： 模块之间是否过度耦合（防止后期动一发而动全身）。
无后门： 检查是否残留有乙方的私有服务器地址或硬编码的账号。
性能压力测试： 在目标机型上运行，检查 FPS、内存（Pry/Heap）、CPU 发热情况。
- 交付物完整性检查
在支付尾款前，必须确认以下资料已完整交付：
- 验收测试流程
建议遵循“分阶段、多环境”的验收逻辑：
Demo/Alpha 验收： 验证核心玩法和底层架构是否跑通。
Beta 验收： 验证内容完整性，进行大规模 Bug 扫描。
灰度/内测验收： 在真实网络环境下验证稳定性和数据准确性。
最终验收 (Final Sign-off)： 乙方修复所有 P0/P1 级别的 Bug 后，双方签署《验收合格单》。
- 常见坑点与对策
“黑盒交付”： 乙方只给编译好的包（APK/IPA），不给源码。
对策： 合同中必须写明“源码交付是结款的前提”，并由甲方技术人员亲自编译成功。
“资源冗余”： 交付的资源包含大量未使用的废料，导致包体过大。
对策： 要求乙方提供资源使用报告，清理无用引用的 Asset。
“文档缺失”： 代码能跑，但没有任何注释或技术文档。
对策： 将文档作为里程碑（Milestone）的一部分，文档不合格视为该阶段未完成。
- 建议
如果您现在手里已经拿到了一批外包产出，您可以尝试按照以下方式操作：
要求乙方在您的私有 Git 仓库（如 GitLab/Gitee）上提交代码，而不是通过压缩包发送。
在您的目标真机上跑一遍性能分析（Profiler），看看是否有未说明的内存泄露。
