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 最新版本更早期的代码模式，我尝试寻找更贴近 Godot 专用的模型，使用了 Hugging Face 的 bekoozkan/godot-gemma-4-e4b-it-GGUF 模型。

本期待模型能更了解 Godot，但实际效果有限。模型参数过小，无法很好地理解长上下文。

尤其在图像确认至关重要的工作中，表现尤为令人沮丧。需要判断地图是否异常、哪些地方不自然、以及实际画面是否符合预期，但模型并未能可靠地解析图像。游戏开发不仅仅是代码正确，更在于画面是否自然，这一点上 AI 工具表现出很大波动。

Godot 对模型来说是一个相对陌生的领域。最新语法、场景结构、编辑器行为、资源路径、运行结果的确认都需要相互关联，但许多模型仅凭代码片段就以过时的知识作答。

今天的实际工作只是运行 Godot 并确认地图显示异常。但围绕这一点，我不断调整工具设置、MCP 连接、模型切换、沙盒问题、图像解析问题。实际上，花在处理工具上的时间比实际游戏开发更长。

说实话，我觉得这个领域并不适合我。

我本期待通过良好组合 AI 工具来简化开发，然而实际情况是工具会丢失自身状态、重复操作、错误查找文件、无法识别图像、只建议过时代码，我必须不断确认这些问题。我想做的是游戏，却一直在调试工具的局限。

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

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