今天第一篇在讲 AI 美术，这一篇回到「地基」——工程化。很多独立开发者栽跟头不是因为不会写代码，而是项目做到一半目录乱成麻、.godot/ 被提交进仓库、.tscn 冲突一合并就崩。这类问题不解决，DeepSeek 帮你写再多代码也只是往烂地基上加砖。今天就把 Godot 官方的工程组织与版本控制建议一次讲透。
今日速览
- Godot 不限制目录结构，所以「怎么放」全靠自觉：官方推荐把资源尽量贴近使用它的场景，项目变大才好维护。
- 命名规范是硬性防坑：文件夹与文件用
snake_case（C# 脚本除外，用 PascalCase），节点名用PascalCase。 - 大小写是隐形地雷：导出后的 PCK 虚拟文件系统大小写敏感，Windows 上能跑的路径，导出后可能直接读不到。
- 版本控制要忽略
.godot/和*.translation：编辑器能一键生成.gitignore/.gitattributes，别手写漏项。 - 大素材交给 Git LFS，而且必须在第一次提交前配好：已经提交过再用 LFS 会非常痛苦。
核心学习内容
1. 目录结构：贴着场景放资源
Godot 是「场景驱动」的，几乎所有资源都内嵌在场景里，所以文件系统本身很干净。官方推荐的思路不是「按类型建一堆全局文件夹」，而是让资源跟着用它的东西走。官方给的一个例子长这样：
/project.godot
/characters/player/player.tscn
/characters/player/player.png
/characters/enemies/goblin/goblin.tscn
/characters/enemies/goblin/goblin.png
/levels/riverdale/riverdale.tscn
/models/town/house/house.glb规则很朴素：一个角色/一个关卡，就是一个文件夹，图和场景放一起；只有真正全局共用的东西（UI 主题、音效库、字体）才单独开一层。官方还建议第三方插件统一放顶层 addons/，方便一眼区分「哪些不是自己写的」。另外，不想让 Godot 导入某个文件夹（比如一堆参考文档），在里面放一个空的 .gdignore 文件即可——它会让该目录从 FileSystem 面板消失、也不再占用导入时间。
2. 命名与「大小写陷阱」
官方风格指南只有两条，但每条都在防坑：
- 文件和文件夹用
snake_case（如player_controller.gd、main_menu.tscn）。原因不只是好看——Windows/macOS 默认大小写不敏感，Linux 敏感，Godot 导出的 PCK 也大小写敏感。你本地Player.png和代码里写的player.png在 Windows 上「碰巧」能跑，导出后就是找不到文件。统一小写能一次性消灭这类 bug。 - 节点名用
PascalCase（PlayerBody、Hurtbox），跟 Godot 内置节点（CharacterBody2D）的命名保持一致，代码里$PlayerBody读起来也顺。
C# 项目是唯一例外：脚本按类名用 PascalCase（PlayerController.cs），其余仍守 snake_case。
3. 版本控制：忽略清单 + LFS，一个都不能少
Godot 4.1 之后，编辑器会自动生成 export_presets.cfg 等敏感/生成文件，但仍有两样必须排除在 Git 之外：
.godot/：编辑器缓存（导入结果、临时数据），提交它会让仓库疯狂膨胀、天天冲突。*.translation：从 CSV 生成的二进制翻译文件，属于构建产物，不入库。
最省事的做法是别手写 .gitignore——在项目管理器新建项目时选 Git，或菜单 项目 > 版本控制 > 生成版本控制元数据，Godot 会自动生成 .gitignore 和 .gitattributes，后者还会强制 LF 换行（这样 Windows 上就不必再改 core.autocrlf）。
大素材（纹理、音频、模型）用 Git LFS 管理。官方特别强调：LFS 一定要在第一次提交之前配好（git lfs install，再在 .gitattributes 里声明要跟踪的扩展名，如 *.png、*.wav、*.glb）。如果已经提交过二进制文件才想起 LFS，就得用 git lfs migrate 清理历史，费时费力还容易出错。
🎯 DeepSeek 提示词（可直接复制）
提示词 1：让 DeepSeek 设计项目目录与场景组织方案
适用场景：刚立项，或已有的项目已经乱到不敢动，想让 AI 出一套「可持续」的结构。
你是资深的 Godot 4 项目架构师，熟悉 Godot 官方的 Project organization 最佳实践。
【我的项目】
（粘贴：游戏类型、2D/3D、大概有哪些系统，例如「2D 像素横版动作，有玩家、3 种敌人、Boss、若干关卡、UI、音效」）
【任务】
产出一份完整的项目目录结构方案，要求：
1. 以「贴近场景放资源」为原则：一个角色/关卡/系统一个文件夹，图和场景放一起。
2. 全局共用资源（UI 主题、音效库、字体、自动加载脚本）单独分层。
3. 第三方插件统一放 addons/。
4. 用代码块画出目录树，并在每个目录后用一句话注释「放什么、为什么这么分」。
【约束】
- 所有文件和文件夹名必须用 snake_case，节点名用 PascalCase，并解释这条规则的由来。
- 明确指出哪些目录将来要放进 .gitignore 或 .gdignore。
- 最后给一条「迁移建议」：如果项目已经乱了，按什么顺序整理最安全。提示词 2：生成正确的 .gitignore 与 .gitattributes
适用场景：准备把项目推上 GitHub/GitLab，怕手写忽略规则漏项。
你是精通 Godot 4 + Git 的工程化专家。请为我的 Godot 4.3 项目生成版本控制配置文件。
【项目情况】
（如：2D 游戏，仓库私有，素材约 500MB，团队 2 人，Windows + macOS 混合开发）
【任务】
1. 生成 .gitignore：必须忽略 Godot 4.1+ 的 `.godot/` 与 `*.translation`，并忽略常见编辑器/系统垃圾文件（.DS_Store、Thumbs.db 等）。每一项后加简短注释。
2. 生成 .gitattributes：强制 LF 换行；并用 Git LFS 跟踪大二进制素材（.png / .wav / .ogg / .glb / .ttf 等）。
3. 给出配套的初始化命令（git lfs install 等），并说明执行顺序。
【约束】
- 注释里必须提醒：LFS 必须在「第一次提交二进制文件之前」配好，否则要 git lfs migrate 清历史。
- 不要包含任何过时（Godot 3.x / 4.0）的忽略项。
- 输出两个独立代码块，方便我直接另存为文件。提示词 3：审查工程结构 / 排查 .tscn 合并冲突
适用场景：项目变乱想体检，或合并分支时
.tscn/.tres冲突不知道怎么办。
你是 Godot 项目的工程化审查员。
【任务可选二选一，按我贴的内容判断】
A. 结构审查：我会贴一份项目目录树（或 git status 输出），请指出——
- 违反 snake_case / PascalCase 命名的文件与节点；
- 可能引发大小写导出 bug 的路径；
- 应该加 .gdignore / .gitignore 却没加的目录；
- 资源组织是否「贴近场景」，给出具体整改步骤。
B. 冲突诊断：我会贴一段 Git 冲突标记（<<<<<<< 等）包裹的 .tscn 或 .tres 内容，请——
- 解释冲突的根源（是节点属性、外部资源 uid，还是子节点顺序）；
- 给出「保留哪一侧 / 如何手工合并」的具体建议；
- 提示如何用 Godot 重新保存场景来修复 uid 不一致。
【约束】
- 不要直接重写整个文件，先给判断和最小改动方案。
- 遇到无法确定的地方，明确告诉我要检查哪个文件，而不是猜测。
- 最后附 3 条预防这类问题的长期习惯。学习心得
今天两篇一对比特别有意思：第一篇讲「怎么把 AI 的产出变成能进引擎的素材」，这一篇讲「怎么让一堆素材不至于把项目压垮」。它们指向同一件事——独立开发者真正的护城河不是写了多少代码，而是工程的可持续性。目录贴着场景放、命名统一小写、.godot/ 不入库、大文件走 LFS——这些规则单看都是小事，但每一条都在替你省下未来某个深夜的 debug。更重要的是：规矩定得越早，DeepSeek 协作越稳。当你的项目结构清晰、命名有规律，AI 才能准确猜到你说的 player_controller.gd 到底在哪、该长什么样;地基越干净，AI 帮你盖楼就越快。所谓「用 AI 从零做一款 Steam 游戏」，第一步不是写玩法，而是先把这个地基铺平。
明日关注
- 用提示词 1 给当前项目出一份目录结构方案，先只调整「新文件该放哪」，别急着大搬迁。
- 在下一次提交前跑一遍提示词 2，把
.gitignore/.gitattributes（含 LFS）配好并git lfs install。 - 做一次「大小写审计」：把全项目文件名/路径统一成小写 snake_case，验证导出后资源不漏。
本文由自动化学习流水线每日生成，坚持即学即记。
评论