大家好，我是 SiKi老师。如果桌面上有“最终版”“最终版2”和“真的最终版”，收到试玩反馈时，第一件事可能变成猜对方打开了哪个包。我建议给每份交付包一个不重复的标识，再用记录把它和源码、构建设置、测试结果联系起来。
这篇是小项目交付记录方法，不依赖特定引擎，也不讲自动构建脚本。文件名和编号都是假想例子，没有实际打包或运行结果。写好名字只能帮助追溯，不能证明包能正常启动。
包标识回答“你拿到的是哪一份”
先为同一个项目约定一种简单命名形式，例如“项目简称_平台_日期_序号”。假想文件名 RunnerPractice_Win_20260921_01.zip 中，序号用于区分当天的多次交付。这个格式是整理建议，不是 Windows、Unity 或其他工具的强制规则。
只要交付内容变化，就给它新的包标识。不要用新文件覆盖旧文件后，继续告诉试玩者“还是上次那个链接里的版本”。保存旧包是否合适取决于资源和保留策略，但至少应保留旧标识与对应记录，避免反馈失去参照。
公开名称里不用加入电脑用户名、私人目录或账号信息。项目简称如果会暴露未公开内容，也要换成适合分享的名称。命名应帮助协作，而不是复制本机环境信息。
一个包配一条构建记录
文件名不适合装下所有细节。我会用一张表记录完整信息，包标识只负责把几份记录连在一起。
| 包标识 | 和交付文件、包内说明一致的编号 |
| 源码位置 | 可恢复的工程版本或提交标识 |
| 构建环境 | 引擎及必要工具的实际版本 |
| 构建范围 | 平台、入口场景和会影响结果的设置 |
| 本次变化 | 相对上一包改了什么，不写笼统“优化” |
| 测试记录 | 测了哪些路径；通过、失败或未测 |
| 已知限制 | 未支持或未验证的条件 |
| 交付文件位置 | 可定位到实际文件的位置，不公开私人凭据 |
没有版本控制的小练习，也应至少保留可恢复的工程副本，并建立对应关系。如果当前副本已经继续修改，不确定是否就是打包时的内容，就写“源码对应待核验”，不要为了表格完整抄一个最新日期。
源码标记和试玩包标识不是一回事
Git 官方书说明，标签可以标记仓库历史中的特定位置，常用于标记发布点。Pro Git：Tagging
这能帮助记录源码版本，但我的交付建议仍是给实际包保留单独标识。相同源码可能选择不同平台或构建设置；如果构建时还有未记录的本地改动，仅写一个提交编号也不足以说明全部输入。
因此，表里的源码标记不能代替构建范围、未记录改动和产物记录。本文没有给出 Git 建标签、改标签或推送命令，也没有验证可复现构建；如果项目需要证明同样输入得到一致产物，要另做相应测试和记录。
让试玩者能找到编号
先在压缩包名称与包内说明中使用同一个编号。项目如果已经有版本信息界面，可以核对其显示是否匹配；尚未实现就如实注明，不宣称界面已经具备该功能。
收到反馈时，先问对应包标识，再看现象。对方只记得“昨天下载的”，可以让其查看文件名或说明，但不能因为日期相近就替其填成最新编号。确认不了的反馈保留为版本未知，不和已确认版本的数据混在一起。
同一包也可能在不同设备上表现不同。编号解决的是交付对象，环境字段解决的是运行条件，两者都需要记录。把不同平台的文件取同一个无区分名称，会让这层关系更难读。
修复以后，保留旧问题的参照
假设某条反馈指出菜单关闭后不能操作，修复后重新交付新包，应在记录里写清“针对哪条问题修改”，然后记录新包上的复查结果。不要因为提交了修改，就直接把问题状态改成已经验证解决。
可以同时记录旧包出现的条件、新包复查的条件，以及仍未检查的部分。这里说的是记录结构；没有运行的路径必须标为未测，不能用打勾代替执行。
我也建议交付前打开一次准备分享的目录，确认说明里的编号、文件名称和这次记录一致。这只能检查命名一致性；程序是否能启动、资源是否齐全、功能是否符合预期，仍需要单独验收。
从下一次交付开始使用
不必先给所有旧文件补一个看似精确的历史编号。对于无法确认来源的旧包，保留“对应版本未知”，从下一次实际构建开始认真记录，会比猜测历史更可靠。
你的试玩反馈现在能对应到具体包吗？如果不能，先在文件名或说明里补哪个标识，能让下一次沟通少猜一步？
