AI被贬名的原因是因为许多人在没有任何方向的情况下开始项目，然后得到半成品的废话，这使得真正使用AI制作的瑰宝难以被看到.
AI工具让游戏开发比以往任何时候都更易于上手，尤其是对于那些没有丰富编程、美术或游戏开发经验的人。但使用AI并不自动让游戏开发变得容易。你仍然需要计划、方向以及一定的纪律。
下面是我认为在使用AI构建游戏时能产生巨大影响的几条建议。

1. 在开始构建之前先规划你的游戏。
我知道你很想直接跳进游戏引擎，开始向AI发送指令来生成内容，但请先退一步。
你正在做什么类型的游戏？核心游戏循环是什么？玩家实际会做什么？目标是什么？关键机制定是什么？一个简单的创意大纲、核心机制以及前几个里程碑比没有方向地直接开始更好。

2. 保留项目笔记本。认真。
这是你在使用AI工作时能做的最被低估的事情之一。
保留一个笔记本或项目文档，记录以下内容：
- 你最初的游戏概念和愿景。
- 计划的功能和机制。
- 你做出的决定以及 WHY（原因）。
- 你的文件夹结构、脚本以及不同系统的连接方式。
- 你遇到的错误以及你如何解决它们。
- 目前运行正常的内容、不正常的内容以及接下来需要做的事情。
AI可以帮助你构建事物，但你需要可靠的项目方向记录。这在你需要在多次对话中工作或在不同AI工具之间切换时尤为重要。不要依赖AI记住一切。

3. 将可玩性置于视觉之上。
这点很重要！
不要在确认游戏是否好玩之前花三天时间完善草地纹理、角色设计、光照或 UI。
先使用基本形状、占位精灵、简易环境以及如果需要的话丑陋的原型。
玩家能移动吗？机制运行正常吗？核心游戏循环是否 enjoyable（令人愉快）？游戏是否感觉响应迅速？
先把这些做好。以后再让一切变美。一个美丽但不可玩的游戏仍然是问题。

4. 逐个构建小功能。
避免向AI发送一个巨大的提示让它一次性构建整个游戏。请求越复杂，出现故障时更难确定哪里出了问题。
相反，将项目拆分为可管理的任务。例如：
- 首先，让玩家移动功能正常。
- 然后添加与物体的交互。
- 接下来，添加库存功能。
- 然后引入保存和加载。
在继续之前测试每个功能。小而运行正常的系统比一个庞大的 AI 生成代码集更易于维护。

5. 不要盲目信任 AI 生成的代码。
AI 可能生成看起来很可信的代码，但其中可能包含错误、做出错误假设，或破坏已经正常工作的部分。
频繁运行游戏。阅读错误信息。测试边缘情况。在接受你不理解的更改之前，让 AI 解释脚本的作用。
你不需要是编程专家，但应逐步学习足够的知识以理解你正在构建的系统。

6. 向 AI 提供清晰的上下文。
与其只说“帮我做一个库存系统”，不如说明你的游戏引擎、编程语言、现有系统、期望的行为以及任何约束。
例如：“我使用 Godot 4 和 GDScript。玩家已经有交互系统。请创建一个能够与之集成的库存系统，而无需重写现有的移动或交互脚本。”
你提供的相关上下文越多，越不容易得到不适合你项目的解决方案。

7. 使用版本控制和备份。
在进行重大更改之前，创建备份或将当前工作版本提交到 Git。
AI 可能会意外覆盖正常代码、重新组织文件或在修复其他问题时引入错误。
拥有已知良好的版本意味着你可以恢复，而不是重新开始。

8. 在完成基础之前不要不断添加新功能。
很容易陷入不断添加新点子的陷阱。你一开始做一款种植游戏，然后加入钓鱼、烹饪、制作、宠物、关系、多人游戏以及庞大的开放世界。
此时，你有 50 个未完成的系统，而且没有任何系统感觉完整。
先让一个小可玩版本运行起来。在扩展之前，先完成游戏的一个小片段。

9. 将 AI 视为协作者，而非判断的替代。
AI 是工具。你仍然是游戏设计师。
你决定什么让你的游戏独特，哪些建议符合你的愿景，什么需要改进，以及什么应该被移除。
不要因为 AI 能快速生成内容就让它决定所有设计。

10. 测试实际游戏，而非仅测试代码是否运行。
脚本可以运行而没有错误，但游戏仍然可能感觉很糟糕。
像玩家一样通过你的游戏。尝试不寻常的输入、重复操作、探索机制的极限，并寻找令人困惑的交互。
如果可能，让其他人在不了解具体实现的情况下尝试。
目标不是仅让代码运行，而是创造人们会享受的体验。

我的最大收获： AI 让创建事物更容易，但它并不消除对规划、测试和良好项目管理的需求。
从小处着手。保持项目有条理。先让其可玩，再让其美观。并且记录你在做什么，以免失去对自己的愿景的把握。