AI游戏开发实战：三平台打包发布与项目复盘全流程

从灰色方块到可玩网页：最后一课做了什么

在AI游戏开发系列的第13课中，一个名为“仪器骑士”的像素游戏从编辑器里的灰色方块，完成了到公开可玩版本的跨越。这节课的核心任务是把游戏正式发布出去：导出Windows、macOS、Web三个平台版本，上传到itch.io，并通过AI协作完成一次项目复盘，把经验沉淀为下个项目可复用的资产。

发布不是简单点一下导出按钮。作者把整个过程拆成了十一个步骤，每一步都有明确的验收标准。这种工程化的做法，恰恰是业余项目最容易缺失的部分。

导出三平台：母版、预设与三个平台的坑

Godot的导出机制可以理解为三个概念：pck文件是“饭菜”，包含场景、脚本、图片和音频；导出预设是“装盒规格”，每个平台一份配方，保存在项目根目录的export_presets.cfg中，需要提交到git；导出母版是“饭盒”，每个平台一份精简运行时，版本号必须和编辑器完全一致，否则会直接导出失败。

三个平台各有需要注意的地方。Windows导出的exe没有签名，首次运行可能触发SmartScreen提示，需要引导玩家点击“更多信息”再“仍要运行”。macOS必须填写Bundle Identifier，且没有签名和公证的应用会被Gatekeeper拦截，本期采用built-in adhoc临时签名，并在商店页写清楚放行方法——双击一次被拦截后，进入系统设置的隐私与安全性，点击“仍要打开”。作者特别强调，不要教玩家用命令关闭Gatekeeper，那会降低整台电脑的安全性。Web版必须使用Compatibility渲染器，关闭Thread Support，视口设为1280x720。

对于小型像素游戏，Web版是最重要的分发形态——玩家点开就能玩，不需要下载、解压、放行安全提示，愿意尝试的人会多得多。桌面版作为补充，其中Windows可以勾选嵌入pck，打成单个exe便于分发。

导出母版（export templates） 是 Godot 为每个目标平台预编译的精简运行时，它本身不包含用户项目内容，只负责启动并加载 pck。Godot 编辑器版本与导出母版版本必须严格一致（如 4.3 编辑器配 4.3 母版），否则导出会直接报错。首次导出时若本机未安装母版，编辑器会提示从模板管理器下载。

pck 文件 是 Godot 的资源包格式，等同于把项目里的场景、脚本、贴图、音频打包成一个容器。桌面平台可以选择将 pck 嵌入可执行文件（单文件分发），也可以外置；Web 平台则必须外置并由 HTML 加载。导出预设保存在项目根目录的 export_presets.cfg，记录每个平台的包名、图标、渲染器、视口等配方，纳入 git 后团队和 CI 才能复现同样的构建。

Gatekeeper 是 macOS 的安全机制：从网络下载的未签名或未公证应用，首次打开会被系统拦截并提示“无法验证开发者”。代码签名用开发者证书证明应用来源；公证（notarization） 则是把应用提交给 Apple 自动扫描，通过后系统才会放行。两者都需要付费的 Apple Developer 账号。adhoc 签名是不依赖证书的本地临时签名，只能绕过部分检查，无法通过 Gatekeeper 的完整验证，因此仍需引导玩家手动放行。

SmartScreen 是 Windows 的类似机制：对没有信誉积累的 exe，首次运行会弹出“Windows 已保护你的电脑”，用户需点“更多信息”→“仍要运行”。正规消除方式是购买代码签名证书并积累下载信誉，小项目通常选择写清楚引导步骤。

发布前冻结与打包翻车现场

发布前必须做两件事：确认最新验收报告结论不是不通过，关闭所有必须修复的问题，跑一次全量测试且退出码为0；然后进入功能冻结，只允许修bug，新想法写进备份文档留给1.1.0。

翻车现场很有代表性：右键把Web文件夹整个压缩上传到itch.io，页面上只显示一个文件列表，游戏跑不起来——因为index.html不在ZIP根目录，多套了一层文件夹。修正办法是让AI写一个打包脚本，读取项目设置里的版本号，把三个平台分别打成带版本号的ZIP，Web包必须检查index.html在根目录，检查不到就报错退出。这个坑一旦用脚本固化，以后每次发布都不会再踩。

版本号、更新日志与商店文案的AI协作

版本号分三位：主版本、次版本、修订号。开发中用0.x，验收版是0.9，首个公开版本为1.0.0。只修bug则修订号加1，新增内容且兼容则次版本加1，存档格式变化等不兼容改动则主版本加1，改了哪一位，右边的位归零。

更新日志让AI从git log中只取v0.9.0之后的提交，写成Keep a Changelog风格，要求用玩家能懂的话、不出现函数名和文件路径、忽略测试和重构类内部提交、每条不超过30字、同类小修复合并，文末附150字以内的开发日志草稿。验收标准是每一条都能在git log里找到依据，拿不准的标注待确认。

商店文案同样交给AI起草，但约束写得非常硬：不夸大、不写“史诗级”“3A品质”、不和其他游戏比较、不提别的游戏名、特色必须是游戏里真实存在的内容。AI交回来之后要逐条对照游戏核实，AI披露段要和Credits文档一致，操作说明要和输入映射一致。

语义化版本（SemVer） 的约定是 主版本.次版本.修订号：不兼容的改动升主版本，向下兼容的新功能升次版本，向下兼容的修复升修订号，且任一位递增时其右侧位归零。文章中的 0.x 开发版、0.9 验收版、1.0.0 首个公开版正是这一约定的实践。

Keep a Changelog 是一个更新日志书写规范，主张日志面向人而非机器，按 Added、Changed、Fixed、Removed 等类别分组，并关联版本号与日期。要求“用玩家能懂的话、不出现函数名和文件路径”，本质是让 changelog 服务于玩家而非开发者。

git log 是版本库的提交历史记录，每次 commit 带有哈希、作者、时间和说明。让 AI 只取某个 tag（如 v0.9.0）之后的提交，可以限定范围、避免把早期内部提交混入玩家可见的日志。

复盘的正确姿势：产出三份可喂给AI的资产

作者对复盘有一个犀利的判断：最容易写成“收获很大，AI很好用，下次继续努力”的感想，可等下次开工，这里面没有一句能直接用。复盘的产物应该是三份文件——项目宪法（每次对话自动生效的规则）、提示词库（复制就能用）、常见坑清单（写提示词前查一遍）。

AI协作复盘表按环节列，从立项、美术与手感一直到测试验收和打包发布，每一行写用的AI、估计节省的时间、返工次数、返工原因和下次怎么做。作者强调，节省时间和返工次数这两列必须由本人填写，AI不知道真实耗时，数字要基于记忆或记录，不能让AI编。

沉淀的例子很具体：像素素材反复返工三次，沉淀成宪法里的一条规则并写明来源；AI改断言那次，沉淀成提示词库里的“修bug先写失败测试”；ZIP多套一层，沉淀成坑清单里一句能直接放进约束的话。最关键的约束是项目无关化——320x180这类数值写成占位符或标注“横板项目专用”，因为下一个项目是俯视类。

值得记住的坑与课程验收

除了打包和Gatekeeper，还有两个新坑：网页版画面比例不对，是视口不是320x180的整数倍，itch上设1280x720即可；网页版没有声音，是因为浏览器要求玩家先交互才能播放音频，保留点击开始、不勾自动启动就能解决。复盘本身也有坑：项目宪法越写越长，AI反而不遵守，每条规则都写来源、控制在150行以内、定期删减。

本课验收清单包括：预设提交到git、图标启动画面和版本号设好、三个发布包的Web根目录有index.html、正式版调试桥关闭、别的电脑跑通桌面版、更新日志和版本标签、itch.io页面公开、复盘和三份资产完成。

这节课真正传递的信号是：发布一个游戏只是起点，把发布流程脚本化、把复盘沉淀成可复用的规则资产，才是让下一个项目更快更好的关键。作者最后提到，同一个Copilot一会儿当策划、一会儿当程序、一会儿当测试，上下文会越来越乱——下一课将把复盘资产升级成一支AI团队。