2026-06-01 回顾 | idea_world

今天的工作

今天直接运行了 Godot 项目，查看了地图生成结果，并在此过程中再次测试了 AI 编码工具在实际游戏开发工作中的适配程度。

另外，我为个人私密仓库单独定制了网页搜索 MCP。与其直接使用默认的 web-search-mcp，不如根据我想要的搜索流程和输出进行调整。这是一次尝试，因为在处理设计、Godot、最新文档等不断变化的信息时，搜索工具几乎是必不可少的。

Qwen Code、Codex、OpenCode 都进行了测试。

先说结论，全部都没有达到预期的稳定性。Qwen Code 的重复回答出现得太频繁。它会反复制定相同的计划、寻找相同的文件、再次相信失败的路径。除非按照文档进行设置并调优，否则即使换模型，这种循环问题也难以轻易改善。

Codex 和 OpenCode 相比 Qwen Code 在工具调用本身上有一定优势，但它们对 Godot 工作的上下文理解不深，图像解析也不够好。回答中途会中断，或者自行制定计划却无法正确执行，还出现了召唤子代理进行“研究”，却去查询文件系统的奇怪流程。

如果不是 Qwen Code，web-search MCP 的集成感觉也不太顺畅，令人感到无从下手。相反，即使使用 Qwen Code，MCP 仍然存在重复和状态解释的问题。

其他模型倾向于提出基于旧版代码模式的建议，而不是针对最新的 Godot 版本。因此，我尝试使用了 Hugging Face 上的 bekoozkan/godot-gemma-4-e4b-it-GGUF 模型。

本以为它会对 Godot 有更好的理解，但实际效果有限。模型参数太小，无法很好地理解长上下文。

尤其在需要检查图像的任务中，问题更为突出。要判断地图是否显示异常、哪些地方不自然，需要直接观看实际画面，但模型无法稳定地解析图像。游戏开发不仅仅是代码正确，还要画面自然，这一点上 AI 工具表现得相当不稳。

Godot 是模型相对不熟悉的领域。最新的语法、场景结构、编辑器行为、资源路径、运行结果的检查都需要关联，但很多模型仅凭代码片段就用旧知识作答。

今天的实际工作就是运行 Godot，确认地图显示异常的问题。但在此过程中，我不断调试工具设置、MCP 连接、模型切换、沙盒问题、图像解析问题。实际上，花在处理工具上的时间比真正开发游戏的时间还长。

说实话，我觉得这个方向并不太适合我。

我本期待通过合理组合 AI 工具来提升开发效率，结果却经常遇到工具丢失状态、重复操作、找错文件、无法识别图像、只推荐旧代码等问题。我的目标是制作游戏，却一直在调试工具的局限。

不过也收获了一些东西。网页搜索 MCP 是必需的，Qwen Code 需要严格按照文档进行调优，Godot 工作必须配合实际运行画面的验证。与其把全部计划和执行交给 LLM，不如让人或脚本负责验证循环，LLM 只提供草案和辅助判断，这更为现实。

从明天起，我打算直接进行微调。仅仅使用通用模型或公开的 Godot 专用模型，无法满足我所需的 Godot 版本、工作方式和画面验证流程。需要自行收集示例和失败案例，构建符合自己工作方式的数据集。