压缩包收到了，作者也发来了运行视频。看起来已经完成，为什么还要自己再测一遍？
因为视频证明的是某套环境下出现过某个效果，你需要确认的是它能否在约定的环境里按需求使用。验收不是再挑一次喜欢不喜欢，而是把当初说好的内容逐项核对。Mod 客栈定制页把最终验收放在结算之前，使用这类流程时尤其不要把它当作普通的“已收到”按钮。
配图：Mod 客栈公开定制页的委托流程说明。截图时间为 2026 年 10 月 2 日，不是实际交付案例。
先清点文件，不急着往游戏里覆盖
看看交付中是否包含约定的安装包、说明、依赖版本和其他文件。需要源文件的项目，再检查是否真的包含可编辑工程，而不是只有一个最终导出文件。
安装说明至少应让你知道：适用游戏版本、前置工具、安装位置、启用方式和已知限制。遇到无法确认来源的程序或异常权限要求，先请作者解释，不要为了赶测试直接关闭防护。
测试前备份存档和必要配置。优先使用单独的测试存档或隔离配置，别在唯一的长期存档上试未知变更。涉及在线功能时，先确认游戏规则与服务器许可，不能把自己的正式账号当作风险测试工具。
先复现约定环境，再测自己的组合
作者按一个明确版本和前置清单交付，你却在一套长期叠加的整合环境里测试，出错后会很难定位。
先按约定环境安装，确认核心功能。再检查事先要求兼容的其他 Mod。临时添加的新组合可以记录问题，但不能不加区分地当作原交付缺陷。
如果安装说明本身不完整，也应记录缺了哪一步，请作者补齐，而不是双方反复猜“是不是你装错了”。
用当初的使用场景走一遍
外观类可以检查指定视角、约定动作、材质和相关装备组合。功能类则按需求测试触发、关闭、重新加载和设置保存。性能要求应按约定设备与场景检查，不要临时增加另一套判断标准。
可以留一张简单记录表：
| 检查内容 | 结果 | 证据或说明 |
|---|---|---|
| 按说明完成安装 | 通过／待修正 | 缺失步骤或报错信息 |
| 核心效果与约定一致 | 通过／待修正 | 截图、视频时间点 |
| 指定兼容项正常 | 通过／待修正 | 涉及的版本和操作 |
| 重启、读档等约定场景 | 通过／待修正 | 是否能稳定复现 |
| 交付文件齐全 | 通过／待补齐 | 缺少的文件名称 |
卸载或恢复也应遵循该 Mod 的说明。会改变存档数据的内容，可能不能通过直接删除文件安全移除，这一点应在交付前说明。
报问题时，让作者能看见同一件事
“不能用”很难排查。改成“在这些版本下，完成这三步后出现这个错误，预期应该发生什么”，再附必要日志片段，会更有效。
日志和截图中若有用户名、文件路径或令牌等敏感信息，应先做必要遮蔽。尽量一次汇总同一轮发现的问题，修正后注明测试的是哪个新包，避免双方说的不是同一版。
所有约定项确认后，再完成最终验收，并留好包、说明和记录。做到这里，你确认的就不再是“文件到了”，而是“约定的东西确实能用了”。
