企业官网建设流程全解析

1. 项目概述：当AI成为你的游戏开发合伙人

如果你是一名独立游戏开发者，或者对用Godot引擎做点小玩意儿感兴趣，那你肯定体会过那种感觉：一个绝妙的点子在你脑海里盘旋，但一想到要从零开始搭场景、写脚本、画素材，那股热情瞬间就被繁琐的细节浇灭了一半。我们总希望有个全能的搭档，能理解我们的想法，并把它们变成可运行的游戏原型。现在，这个搭档可能真的来了，它不是一个人，而是一套名为Godogen的自动化流水线。

简单来说，Godogen是一套为Claude Code和Codex这类高级AI编码助手设计的“技能”（Skills）集合。它的核心工作流程非常直观：你负责描述想法，AI负责实现一切。你告诉它“我想要一个2D平台跳跃游戏，主角是个会发射泡泡的小机器人，场景是废弃的工厂”，接下来，Godogen就会驱动AI完成从架构设计、代码编写、素材生成到最终测试的整个闭环。它不只是生成几段代码片段，而是产出一个完整的、结构清晰的Godot 4项目，包含组织好的场景、可读的脚本、导入的资产，甚至能自动运行游戏，截图检查有没有贴图错误或者物理穿模，发现问题后再让AI去修复。这相当于把一位不知疲倦、全栈通吃的开发伙伴，封装进了一套脚本和配置里。

我最初接触这个项目时，最吸引我的不是“AI生成游戏”这个噱头，而是它背后体现的工程化思想。它没有试图用一个“超级提示词”去魔法般地变出游戏，而是把游戏开发这个复杂任务，拆解成了设计、资产、代码、质检等多个可被AI可靠执行的标准化步骤，并通过“视觉质量检查”这个环节形成了反馈闭环。这比单纯让AI写代码要可靠得多，因为代码能编译通过，不代表游戏在屏幕上看起来是对的。Godogen让AI能“看到”自己创造的东西，并根据实际运行效果进行迭代，这极大地提升了产出的可用性和稳定性。

2. 核心架构与设计哲学拆解

2.1 双引擎支持：Claude Code 与 Codex 的并行世界

Godogen项目结构的一个鲜明特点是，它同时为两个主流的AI编码平台——Anthropic的Claude Code和OpenAI的Codex（通常通过Cursor等IDE集成）——提供了并行的实现。在源码仓库中，你会看到claude/和codex/两个目录。这并非简单的代码复制，而是针对不同AI助手的行为特性和接口规范进行的定制化适配。

为什么需要两种实现？因为Claude Code和Codex虽然都能写代码，但它们与开发者交互的模式、上下文管理方式以及对“技能”（Skills）的定义和支持程度存在差异。Claude Code有更结构化的技能系统和项目感知能力；而Codex（或基于它的智能体）可能更依赖于特定的提示工程和文件操作约定。Godogen的作者通过抽象出共同的核心流程（如资产生成、Godot项目操作、视觉QA），再为每个平台封装具体的交互指令和文件布局，确保了无论你使用哪个AI伙伴，都能获得一致的、高质量的生成体验。这种设计非常务实，它承认了当前AI工具生态的多样性，并以适配而非强求统一的方式，扩大了项目的适用范围。

发布机制解析：Godogen本身不是一个游戏，而是一个“生成器的源代码”。你需要通过提供的publish.sh脚本，将对应平台的技能发布到一个全新的游戏项目目录中。例如，./claude/publish.sh ~/my-game这个命令，会在~/my-game目录下创建符合Claude Code规范的技能文件（如CLAUDE.md和.claude/skills/目录）。这个目标目录就是你未来与AI协同工作的“画布”。这种将生成器与产出物分离的设计非常清晰，你可以随时更新Godogen的技能库，然后重新发布到一个新项目或覆盖旧项目，而不会污染你的游戏源码。

2.2 全链路自动化流水线：从描述到可运行项目

Godogen的流水线设计是其灵魂所在，它模拟了一个精简但完整的游戏开发周期。理解这个流程，你就能明白它如何将模糊的自然语言描述转化为具体的数字产物。

1. 架构设计与规划：AI首先解析你的需求描述，将其转化为一个具体的Godot项目架构。这包括决定需要哪些场景（如MainMenu,World,Player）、场景之间如何关联、需要哪些类型的脚本（CharacterBody2D,Area2D等）以及资源如何组织（assets/sprites/,assets/sounds/）。这一步相当于AI在动手写代码前，先画了一张详细的蓝图。

2. 资产生成与集成：这是最体现“多模态”能力的环节。Godogen并不绑定单一的AI绘画模型，而是根据资产类型智能调度：

   • 角色与精确参考图：倾向于使用Google的Gemini模型，因为它可能在遵循复杂描述和保持细节一致性上表现更好。
   • 纹理与简单物体：使用xAI的Grok模型来生成。
   • 3D模型：对于需要3D资产的游戏，它会将2D概念图通过Tripo3D API转换为3D模型。
   • 动画精灵：利用Grok的视频生成功能，生成短动画序列，再通过工具（如ffmpeg）检测循环点并导出为精灵图（Sprite Sheet）。背景移除等后期处理则使用专门的模型（如BiRefNet）完成。 生成后的资产会被自动放入项目对应的assets/目录，并在Godot的.import文件中配置好导入选项。

3. 代码生成与编译：所有游戏逻辑代码均使用C#编写（基于.NET 9）。AI会按照架构设计，逐个创建场景文件（.tscn）和对应的C#脚本文件（.cs）。生成一段代码后，流水线可能会调用dotnet build进行快速编译检查，确保语法基本正确，而不是等到最后才发现成堆的错误。

4. 视觉质量保证闭环：这是Godogen区别于其他代码生成工具的关键创新。它不会在生成代码后就宣布完成，而是会：

   • 启动Godot引擎，加载刚刚生成的项目。
   • 运行游戏并自动控制（例如，让角色移动一段距离，触发一些事件）。
   • 捕获屏幕截图或录屏。
   • 将截图反馈给多模态AI进行审查。AI会像测试员一样检查画面：“角色纹理加载了吗？有没有漂浮在空中的物体（Z-fighting）？碰撞体看起来对吗？”
   • 如果发现问题，AI会根据视觉反馈的描述，回头去修改代码或重新生成资产，然后再次进入这个循环，直到输出一个“看起来正确”的游戏。

这个“描述-生成-运行-审查-修复”的闭环，极大地提升了生成结果的可靠性和完成度。它让AI的创作过程具备了“感知”能力，而不仅仅是符号推理。

2.3 技术栈选型背后的考量

为什么是Godot 4？Godot引擎以其轻量、开源、场景树设计清晰而备受独立开发者喜爱。Godot 4版本带来了渲染器、物理引擎和脚本语言的巨大升级，性能和生产效率都显著提高。更重要的是，它的项目文件（.tscn）是纯文本格式，场景结构易于被AI理解和生成，这比解析复杂的二进制格式要友好得多。同时，Godot命令行工具完善，便于流水线进行自动化启动、运行和截图。

为什么坚定选择C#，而非GDScript？项目文档中专门有一篇gdscript-vs-csharp.md来阐述这个问题，这本身就是一个重要的经验点。对于AI生成代码的场景，C#相比GDScript有几大优势：

• 静态类型与工具链支持：C#是强类型语言，配合.NET的编译器，能在生成阶段就捕获大量的类型错误，比运行时才报错的GDScript更可靠。dotnet build可以作为一个快速的验证步骤集成到流水线中。
• 更广泛的知识库：像Claude、Codex这样的模型，在C#这种通用语言上的训练数据量远大于Godot专属的GDScript。这意味着AI写出符合习惯、功能正确的C#代码的概率更高。
• 项目结构标准化：C#项目有标准的.csproj文件管理依赖和构建，这为AI提供了明确的项目上下文，减少了在文件引用和配置上的歧义。 当然，这并不意味着GDScript不好，而是针对“全自动生成”这一特定目标，C#带来的可验证性和可靠性收益更大。

云服务API的选型与组合：Godogen在资产生成环节采用了“多模型混用”的策略，这很聪明。它根据子任务的特点选择最合适的模型：Gemini可能更擅长理解复杂描述生成精准图像；Grok可能在创意性纹理和视频生成上性价比高；Tripo3D专攻2D转3D。这种“最佳工具做最佳事”的思路，比依赖单一全能模型通常能获得更好、更稳定的结果。不过，这也意味着你需要管理多个API密钥，并承担相应的费用。

3. 环境搭建与实操入门指南

3.1 系统与软件 prerequisites 详解

要让Godogen跑起来，你需要准备一个“工作车间”。官方推荐Ubuntu、Debian或macOS，理论上Windows的WSL2环境也应该可以，但可能需要处理一些额外的路径或依赖问题。

核心软件清单：

1. Godot 4 (.NET版本)：这是硬性要求。你必须从Godot官网下载标有“.NET”的版本（通常是Windows下的Godot_v4.x.x-stable_mono_win64.exe.zip，Linux/macOS类似）。下载后，不仅是要安装，务必将其所在目录添加到系统的PATH环境变量中。这样后续的脚本才能在命令行中直接调用godot或godot4命令。验证方法：打开终端，输入godot --version或godot4 --version，应该能正确输出版本信息。
2. Python 3 与 pip：现代Linux和macOS通常自带Python3。确保python3 --version和pip3 --version命令可用。建议使用虚拟环境（venv）来管理依赖，避免污染系统Python库。
3. 系统级依赖包：这些是支撑自动化流程的“螺丝刀”。
   • vulkan-tools：包含vkcube等工具，用于验证Vulkan渲染（Godot 4默认渲染器）是否正常工作，尤其在无图形界面的服务器上很重要。
   • xvfb：一个“虚拟帧缓冲区”。简单说，它可以在没有实际显示器的环境下模拟一个屏幕，让Godot这种图形程序能够运行起来。这是让整个流水线在服务器或后台运行的关键。
   • ffmpeg：视频处理瑞士军刀。用于处理Grok生成的视频，比如截取帧、制作循环、转换格式以生成精灵动画。
   • imagemagick：图像处理命令行工具集。用于批量调整生成图片的尺寸、格式转换、合成等后期处理。 在Ubuntu/Debian上，你可以用sudo apt-get install vulkan-tools xvfb ffmpeg imagemagick一键安装。macOS用户可以通过Homebrew安装：brew install vulkan-tools xorg-xvfb ffmpeg imagemagick。

3.2 API密钥配置：安全与管理的实践

Godogen需要调用多个外部AI服务，因此API密钥的管理是第一步，也是安全关键的一步。

最佳实践：使用环境变量绝对不要将API密钥硬编码在脚本或代码里。Godogen的设计就是通过读取环境变量来获取密钥。

# 在终端中临时设置（仅当前会话有效） export GOOGLE_API_KEY="your_google_ai_studio_key_here" export XAI_API_KEY="your_xai_grok_key_here" export TRIPO3D_API_KEY="your_tripo3d_key_here" # 为了永久生效，通常将上述 export 命令添加到你的 shell 配置文件 # 例如 ~/.bashrc, ~/.zshrc, 或 ~/.profile 中。 # 添加后执行 source ~/.bashrc 使其生效。

如何获取这些密钥？

• GOOGLE_API_KEY：访问 Google AI Studio ，创建一个API密钥。注意配额和费用。
• XAI_API_KEY：需要在 xAI 开发者控制台 注册并创建API密钥。
• TRIPO3D_API_KEY：前往 Tripo3D AI 平台 获取。

注意：使用这些商业API通常会产生费用。强烈建议在初次使用时，先为每个服务设置用量提醒或预算上限，并在Godogen的测试中从小型、简单的资产生成开始，以了解成本结构。

3.3 发布技能到你的游戏项目

环境准备好后，你就可以“武装”你的AI助手了。首先，克隆Godogen的源代码仓库：

git clone https://github.com/htdt/godogen.git cd godogen

接下来，根据你主要使用的AI编码助手，选择对应的版本发布技能。

为 Claude Code 发布：

# 假设你想在 /home/yourname/dev 目录下创建名为 my_first_ai_game 的项目 ./claude/publish.sh /home/yourname/dev/my_first_ai_game

这个命令会：

1. 在目标路径创建目录（如果不存在）。
2. 将claude/目录下的技能定义、提示词模板等必要文件，按照Claude Code能识别的结构，复制到目标项目的.claude/skills/目录下。
3. 生成一个CLAUDE.md文件，这可能是给Claude Code的主引导文档。

为 Codex (如Cursor智能体) 发布：

./codex/publish.sh /home/yourname/dev/my_first_ai_game

同理，它会创建.agents/skills/目录和AGENTS.md文件。

重要参数--force：如果你在同一个目标目录再次运行发布命令，它会提示你目录非空。如果你想用最新版本的技能覆盖旧版本（比如你更新了Godogen源码后），就需要加上--force标志：

./claude/publish.sh /home/yourname/dev/my_first_ai_game --force

使用--force前务必确认，因为它会清空目标目录下的现有内容。一个安全的做法是，始终为不同的游戏创意使用不同的项目目录。

发布完成后，你的my_first_ai_game目录就变成了一个“待激活”的AI游戏项目。接下来，你需要用Claude Code或Codex打开这个目录。AI助手会读取.claude/skills/或.agents/skills/中的技能，这时你就可以开始用自然语言描述你的游戏设想了。

4. 核心技能深度解析与调优

4.1 资产生成流水线的内部运作

Godogen的资产生成不是简单地调用一个“生成游戏图片”的API，而是一个精心编排的管道，针对不同类型的游戏资产，选择最优的工具链。

2D精灵与纹理生成： 当AI判断需要一张角色立绘或背景纹理时，它会构造一个详细的提示词，其中不仅包含你的描述（“一个穿着蒸汽朋克护目镜的猫工匠”），还会附加Godogen预设的风格化指令和技术约束。例如，会要求输出特定尺寸（如512x512像素）、透明背景（PNG格式）、以及适合游戏美术的特定风格（可能是像素风、低多边形或手绘风）。生成后的图片会通过imagemagick进行自动化处理，如统一缩放至Godot中常用的2的幂次方尺寸（128, 256, 512...），以优化内存和渲染性能。

从静态到动态：动画精灵生成： 这是非常酷的一个环节。对于需要跑、跳、攻击等动画的角色，Godogen的流程是：

1. 视频生成：利用xAI Grok的视频生成能力，输入类似“一只猫从左走到右，循环行走”的提示，生成一段短视频（例如2-3秒）。
2. 循环检测与帧提取：使用ffmpeg分析视频，通过算法检测出最适合作为循环点的起止帧。然后，将这一个循环周期内的所有帧提取出来。
3. 精灵图合成：将提取出的所有帧，按照Godot引擎所需的格式，横向或纵向排列，合成一张大的“精灵图”（Sprite Sheet），并同时生成一个定义每帧位置和大小的配套数据文件（如.tres或通过脚本定义）。
4. 背景移除与优化：对每一帧或合成后的精灵图，使用像BiRefNet这样的专用图像分割模型进行高精度的背景移除（抠图），确保角色能与游戏背景完美融合。

3D模型生成的工作流： 对于3D项目，流程有所不同：

1. 概念图生成：首先用Gemini或Grok生成角色的多视角概念图（正视图、侧视图、45度角视图等）。
2. 3D重建：将这些多视角图片上传至Tripo3D的API。Tripo3D会基于多视图几何原理，重建出一个初步的3D网格模型。
3. 格式转换与导入：生成的3D模型（可能是.obj或.glb格式）会被下载，并通过Godot的导入系统或命令行工具自动导入到项目中，转换为Godot内部的.mesh资源。

实操心得：资产生成的提示词工程：虽然Godogen内置了技能，但最终生成资产的质量极大程度上依赖于你最初的描述。我的经验是，描述要具体，并加入风格参考。不要说“一个战士”，而要说“一个身穿北欧风格镶钉皮甲、手持双手战斧、面容沧桑的维京战士，风格类似《战神》但更卡通化一些，等距视角，游戏精灵风格”。提供明确的风格、视角、用途关键词，能显著提升AI输出结果的可用性。

4.2 代码生成与架构构建策略

AI在Godot项目中写代码，并非天马行空。Godogen的技能引导AI遵循一套基于最佳实践的Godot C#开发模式。

场景驱动的架构：AI会倾向于采用Godot推荐的结构化方式。例如，为一个简单的玩家角色，它会：

1. 创建一个Player场景，根节点是一个CharacterBody2D（用于2D物理移动）或CharacterBody3D。
2. 为这个根节点添加子节点，比如Sprite2D（用于显示）、CollisionShape2D（用于碰撞）、Camera2D（用于镜头跟随）。
3. 为CharacterBody2D节点附加一个同名的C#脚本（Player.cs）。
4. 在脚本中，会生成标准的生命周期方法，如_Ready(),_Process()，并实现基于物理的移动逻辑。代码会包含基本的注释，变量命名也力求清晰。

代码组织与可读性：生成的代码会注意避免“上帝脚本”。不同的功能会被划分到不同的脚本中。例如，UI逻辑放在UI场景的脚本里，敌人的AI放在敌人场景的脚本里。公共的常量或工具函数可能会被放在一个Global或Utils静态类中。这种组织方式使得生成的项目不至于一团乱麻，后续人工介入调整也成为可能。

编译验证集成：在生成关键脚本后，流水线可能会自动执行dotnet build来编译整个C#项目。这能快速发现语法错误、缺少的引用或类型不匹配等基础问题。如果编译失败，错误信息会被反馈给AI，AI会尝试理解错误并修正代码。这个快速的反馈循环是保证代码基础质量的重要防线。

4.3 视觉质量保证：让AI“看见”并修复错误

这是Godogen最值得称道的部分，它解决了AI生成内容“纸上谈兵”的问题。

自动化游戏启动与截图：

1. 流水线通过Godot的命令行接口，以--headless（无头模式）或配合xvfb在虚拟显示中启动游戏。
2. 它可能会向游戏发送模拟输入（通过Godot的Input类或OS级模拟），让角色移动、触发事件，使游戏状态发生变化。
3. 在关键节点，通过Godot的get_viewport().get_texture().get_image()等功能或外部截图工具，捕获游戏窗口的画面。

多模态审查： 捕获的截图被送入具备视觉识别能力的多模态AI（如GPT-4V、Claude 3.5 Sonnet等）。AI会被要求以QA测试员的身份审查图片，问题清单是预设好的：

• 渲染问题：有没有模型闪烁（Z-fighting）？纹理是否缺失（显示为紫色或白色）？光照看起来是否异常？
• 逻辑问题：角色是否站在了应该掉下去的地方（碰撞体错误）？UI元素的位置对吗？动画播放是否流畅？
• 内容一致性问题：生成的游戏画面，是否符合最初描述的设定？（例如，你要的是“雪地”，画面里却是草地）。

闭环修复： 如果AI审查出问题，它会生成一份问题报告，例如：“玩家角色的纹理未能加载，显示为默认的粉色占位图。可能原因是纹理文件路径错误或导入失败。” 然后，这个报告会作为新的上下文，驱动AI重新执行资产集成或代码修改的步骤。例如，AI可能会去检查.import文件，重新导入纹理，或者修正脚本中引用纹理的Texture2D路径。

这个过程可能会迭代数次，直到AI认为视觉上“没有问题”或达到迭代上限。这极大地提升了生成原型的可用性，你拿到的不再是一堆可能跑不起来的代码和图片，而是一个至少能启动、看起来像那么回事的“可玩原型”。

5. 高级部署与持续优化

5.1 服务器端部署与远程协作

一次完整的Godogen生成流程，涉及多次AI API调用、Godot渲染和图像处理，耗时可能长达数小时。在本地电脑上运行会完全占用你的机器，因此部署到云端服务器是一个明智的选择，尤其是拥有GPU的服务器可以加速Godot的渲染和截图过程。

服务器环境准备：

1. 选择一台云服务器（如AWS EC2 G系列、Google Cloud GPU实例、或性价比高的VPS），安装Ubuntu等Linux发行版。
2. 按照3.1节的说明，在服务器上安装所有Prerequisites（Godot、Python、系统包等）。
3. 同样通过环境变量配置好所有API密钥。

保持会话持久化： 由于生成时间长，你需要防止SSH连接断开导致进程终止。使用tmux或screen会话来托管进程：

# 使用 tmux tmux new -s godogen-session # 在tmux会话中，激活你的Python虚拟环境，导航到项目目录，然后启动AI助手（如Claude Code的远程模式）或运行相关脚本。 # 按下 Ctrl+b，然后按 d，可以脱离会话。 # 重新连接：tmux attach -t godogen-session

进度推送与远程监控： 在服务器上枯燥地等待几小时是不可接受的。Godogen作者推荐了 tg-push 工具。这是一个通过Telegram Bot API发送消息和文件的脚本。你可以将其集成到流水线中，让AI在完成关键里程碑（如“资产生成完毕”、“首次编译成功”、“视觉QA通过”）时，向你的Telegram发送一条通知，甚至附上最新的游戏截图或录屏。这样，你就可以在手机上随时掌握生成进度，并在出现卡顿时及时介入。

远程控制AI助手： 无论是Claude Code还是Codex（通过Cursor等），通常都支持某种形式的“远程控制”或“持续会话”。这意味着你可以在本地电脑上打开IDE或Web界面，连接到运行在服务器上的AI助手进程，实时查看它的思考过程、提供的代码，并在必要时进行人工指导和干预（“Steering”）。这结合了服务器的计算力和本地操作的便利性。

5.2 技能迭代与提示词优化

Godogen的技能本身也是可以进化、优化的。一次完整的生成会话结束后，你应该主动向你的AI助手寻求反馈。

进行事后分析： 向刚刚完成工作的AI（Claude Code或Codex）提出如下请求：

“请分析刚才的整个生成会话。我提供的指令（即Godogen技能）是否最优？有没有哪些地方过于冗长、显而易见，或者缺失了关键信息，甚至产生了误导？在生成过程中，有没有哪些工具输出了大量无关信息，污染了你的思考上下文？截图验证循环是否真的抓住了核心问题？有没有遇到工具本身失败的情况，以及你是如何绕过的？”

AI基于刚刚完成的实际任务，往往能给出极具建设性的反馈。例如，它可能会指出：“在生成C#脚本时，关于[Export]属性用法的指令有点模糊，导致我几次都忘了将关键参数暴露到编辑器。”“ffmpeg检测视频循环点时，有时会因为视频开头几帧是黑屏而失败，建议在提取帧之前先添加一个跳过开头N帧的指令。”

基于反馈改进技能： 拿到这些反馈后，你可以去修改Godogen源码中对应平台的技能定义文件（通常在claude/skills/或codex/skills/目录下）。这些文件本质上是结构化的提示词（Prompt）模板。你可以：

• 澄清模糊指令：让步骤描述更精确，减少AI的猜测空间。
• 添加上下文约束：例如，明确要求AI在每次生成代码后，都检查一遍核心节点的引用是否设置正确。
• 优化错误处理流程：为已知可能失败的工具调用（如某个API超时），添加备选方案或重试逻辑。
• 精简输出：要求某些工具（如dotnet build）在成功时只输出简要信息，失败时才输出详细错误，以减少上下文噪音。

修改完成后，使用publish.sh --force将新技能发布到你的游戏项目（或一个新的测试项目），然后开始新一轮的生成测试。通过这种“使用-反馈-改进”的循环，你可以让这套自动化流水线越来越贴合你的个人开发习惯和特定游戏类型的需求。

5.3 扩展可能性与未来展望

Godogen目前聚焦于Godot 4和C#，但其架构思想具有很好的可扩展性。

支持其他游戏引擎： 文档中提到了探索Bevy引擎作为替代。Bevy是一个新兴的、数据驱动的Rust游戏引擎，其ECS（实体组件系统）架构与Godot的场景树截然不同。要适配Bevy，需要重写技能中关于项目结构、代码模板和构建流程的部分。但核心的“描述-生成-资产-视觉QA”闭环依然适用。这为未来支持Unity、Unreal等引擎提供了想象空间。

自定义资产生成管道： 如果你对Stable Diffusion等开源模型更熟悉，或者有自己的素材库，你可以修改资产生成的技能部分。例如，将调用Gemini/Grok的步骤，替换为调用本地部署的Stable Diffusion WebUI API，或者改为从指定目录挑选现有素材的规则。这需要你具备一定的脚本编写能力，但Godogen的模块化设计使得这种替换成为可能。

复杂游戏逻辑的引导： 目前，Godogen擅长生成相对标准的游戏机制（移动、跳跃、碰撞、简单UI）。对于更复杂的逻辑（如技能树、任务系统、状态机），你需要提供更详细、更结构化的描述。未来，技能库可以预置一些常见复杂系统的“模板”或“设计模式”，比如“请为我实现一个基于状态机的敌人AI，包含巡逻、追击、攻击、撤退四种状态”。这需要更精细的提示词工程和可能的中间表示层。

从原型到可发布产品： Godogen生成的终究是一个原型。要将其变为可发布的游戏，还需要大量的人工打磨：平衡性调整、美术风格统一、性能优化、bug修复、内容填充等。但Godogen的价值在于，它以前所未有的速度将你的核心创意“可视化”和“可交互化”，让你能极早地验证玩法是否有趣，从而决定是否值得投入后续的深度开发。它不是一个取代开发者的工具，而是一个强大的创意加速器和原型验证伙伴。