今日速览

• 手工导出是不可持续的：Steam 上架至少要有 Windows 包，做 Steam Deck 要 Linux 包，测试/宣传还要 Web 包——每次改完代码都手动导三遍，等于给自己上刑。
• Godot 天生支持命令行导出：godot --headless --export-release "预设名" 输出路径，这就是所有自动化的地基。
• godot-ci 是现成轮子：一个 Docker 镜像（barichello/godot-ci:<版本>）里预装了 Godot 与导出模板，配 GitHub Actions 十几行就能跑。
• 核心难点只有两个：导出模板（export templates）的路径，以及导出预设（export_presets.cfg）必须提交进仓库。
• 自动化后你得到的是「可复现的构建」：每个版本都有对应产物与版本号，出问题能回溯，而不是「忘记上次怎么打出来的」。

核心学习内容

1. 一切从无头导出命令开始

Godot 4 的导出完全可以脱离编辑器，在命令行里跑：

godot --headless --export-release "Windows Desktop" build/windows/MyGame.exe
godot --headless --export-release "Linux/X11"      build/linux/MyGame.x86_64
godot --headless --export-release "Web"            build/web/index.html

--headless 不加窗口、跑完即退；引号里的 “Windows Desktop” 必须和 export_presets.cfg 里预设的名称一字不差。要记住三件事：

• 导出模板要与引擎版本完全一致，否则会报 No export template found。
• export_presets.cfg 要提交进 Git（它不在 .gitignore 里），CI 才能知道怎么导。
• 第一次导出会生成 .godot/ 导入缓存，CI 里没有缓存会慢但能跑，后面可以缓存它加速。

先在本地把这三条命令跑通，再去接 CI——顺序反了会很难排错。

2. godot-ci：把环境问题一次性打包走

自建 CI 导出最烦的是「装 Godot + 装模板」。godot-ci 用 Docker 解决：镜像里已经放好了引擎和模板，你只需要在 job 里把它们「挪到」CI 用户的家目录。

一个最小可用的 Windows 导出 workflow：

name: Export
on: [push]
env:
  GODOT_VERSION: 4.3
jobs:
  export-windows:
    runs-on: ubuntu-24.04
    container:
      image: barichello/godot-ci:4.3
    steps:
      - uses: actions/checkout@v4
        with: { lfs: true }
      - name: Setup
        run: |
          mkdir -vp ~/.local/share/godot/export_templates/
          mv /root/.local/share/godot/export_templates/${GODOT_VERSION}.stable \
             ~/.local/share/godot/export_templates/${GODOT_VERSION}.stable
      - name: Export
        run: |
          mkdir -vp build/windows
          godot --headless --verbose --export-release "Windows Desktop" \
                "$(readlink -f build)/windows/MyGame.exe"
      - uses: actions/upload-artifact@v4
        with:
          name: windows-build
          path: build/windows

要点：镜像 tag 的版本要和 GODOT_VERSION 对应；用 C#（mono）项目要换成 barichello/godot-ci:mono-4.3，并把模板目录后缀改成 .stable.mono。Linux 和 Web 只要复制这个 job、改预设名和输出路径即可。

3. 构建产物怎么衔接 Steam

CI 出的 build/windows 就是「可上传到 Steam 的内容」：里面是 MyGame.exe 加一堆 .pck/.dll。真正的上架流程是：

1. CI 产出 artifact → 下载解压；
2. 用 Steamworks SDK 的 steamcmd 执行 +login <账号> +run_app_build ../scripts/app_build_<appid>.vdf；
3. SteamPipe 自动 diff 文件、上传变更——比手动传整个包快得多。

把版本号写进 project.godot 或一个 version.txt，让 CI 用它命名 artifact（如 MyGame-v0.3.1-win），你的每一次构建就都可追溯了。

🎯 DeepSeek 提示词

提示词 1：生成 GitHub Actions 导出工作流

适用场景：第一次给 Godot 项目接 CI，不想照抄视频逐行改。

你是一位 Godot 4 + GitHub Actions 的 DevOps 工程师。

任务：为我的 Godot 4.3 项目生成一份 .github/workflows/export.yml，实现
push 时自动导出 Windows、Linux、Web 三个平台并上传为 artifact。

已知条件：
- 项目 project.godot 在仓库根目录
- 使用 barichello/godot-ci 镜像
- 三个导出预设名称分别为："Windows Desktop" / "Linux/X11" / "Web"
- 游戏名 MyGame

输出要求：
1. 完整可直接提交的 YAML，含 on、env、三个 job
2. 每个 job 都要有 Checkout（lfs: true）、Setup（移动 export_templates）、
   Export（--headless --export-release）、upload-artifact 四步
3. 用注释标出我可能要根据自己项目修改的地方（版本号、预设名、输出路径）
4. 最后附一段「常见报错 → 原因 → 修法」的表格

约束：不要用已废弃的 action 版本；不要省略 setup 步骤；YAML 缩进必须正确。

提示词 2：无头导出报错诊断

适用场景：godot --headless --export-release 在本地或 CI 里报错，看不懂日志。

你是 Godot 4 导出系统专家，擅长根据报错定位根因。

我会给你：报错原文 + 我执行的完整命令 + 导出预设名 + Godot 版本 + 运行环境（本地/CI）。
你要输出：
1. 【根因】一句话说明为什么失败（按可能性从高到低列 1-3 个）
2. 【验证】一条能立即确认该猜想的命令或检查项
3. 【修法】具体到文件的修改步骤
4. 【预防】怎么避免下次再犯

重点检查这些高频原因：导出模板版本不匹配、预设名拼写不一致、
export_presets.cfg 未提交、headless 下缺少依赖库、输出目录不存在、路径未用绝对路径。
如果信息不足以下结论，先反问我最多 3 个问题，不要瞎猜。

我的报错信息如下：
"""
（在此粘贴报错）
"""

提示词 3：构建版本号与 SteamPipe 上传脚本

适用场景：CI 已经能出包，想把「版本命名 + steamcmd 上传」也自动化。

你是一位游戏发布自动化工程师。

任务：帮我设计一套「构建版本号管理 + SteamPipe 上传」的方案，产出一个 shell 脚本。

要求：
1. 版本号来自仓库根的 version.txt（形如 0.3.1），构建产物命名为
   MyGame-v{版本}-{平台}.zip
2. 脚本 build_and_upload.sh 做三件事：读版本号 → 打包 build/ 下各平台目录 →
   调用 steamcmd 用 app_build_{APPID}.vdf 上传到 Steam
3. steamcmd 账号密码从环境变量 STEAM_USER / STEAM_PASS 读取，禁止硬编码
4. 输出：完整脚本 + app_build_*.vdf 模板 + README 说明每条命令的作用
5. 明确标出哪些步骤只在 CI 跑、哪些可以本地跑

约束：脚本要 set -euo pipefail；路径全部用变量；每一步打印日志；
如果 APPID 未设置就直接报错退出，不要静默失败。

学习心得

今天补的是整条链路里最不”性感”、但决定你能不能持续做下去的一环。用 DeepSeek 做游戏，真正的瓶颈从来不是「写不出代码」——而是写完之后怎么稳定、可重复地把它变成能交到玩家手里的东西。手工导出三平台这种重复劳动，正好是 AI 最擅长帮你写脚本替代的：把「我要一个自动导出流水线」拆成「先本地跑通三行命令 → 再包成 Actions job → 再接 steamcmd」三步，每一步都能丢给 DeepSeek 生成并让它解释。流程自动化之后，你每天唯一要做的动作就只剩 git push。

明日关注

• 在本地把 --headless --export-release 三条命令跑通，确认预设名与版本号
• 把 .github/workflows/export.yml 提交，看第一次 Actions 是否跑绿
• 了解 steamcmd 与 app_build VDF 的字段含义，为真正上传 Steam 做准备

本文由自动化学习流水线每日生成，坚持即学即记。