2026-06-02 回顾
今天的工作
今天为了改进 Godot 项目的 gongju 地图，重新实验了 Qwen 系列模型。前提是模型难以直接稳定地解析资产图片，于是先让 Codex 查看图片，并用英文在 assets/ASSET_LABELS.md 中整理了资产路径、像素尺寸、用途、是否重复、注意事项。
本文档是一个辅助索引，帮助 Qwen 在编写 Godot 代码时即使不直接解析 PNG 也能知道该使用哪些资产。实际上，地图代码中出现了将错误风格的瓦片当作自然对象使用，或把房子放在实际建筑资产上而是使用 grass sheet 的任意坐标的问题，这类问题如果有资产标签就能更容易发现。
Qwen2.5 Coder 实验
尝试使用 bekoozkan/godot-qwen2.5-coder-7b-instruct-bnb-4bit 作为 Godot 工作的辅助模型。
一开始用 llama.cpp 运行，但 Qwen Code 的 tool calling 没有正常连接。模型没有真正调用工具，而是直接输出 <function=glob> 之类的文本，未能进行文件列表查询或代码修改。后来确认需要使用 vLLM 运行。
不过即使运行方式改变，按当前标准，Qwen2.5 Coder 仍未达到能够把握整个项目上下文并稳定修改代码的水平。vLLM 与 llama.cpp 的响应表现不同，但结论是两者都不足以信任其实际代码修改。
但这并不意味着只能有限度地使用 Qwen。相反，这是一例通过失败案例确认需要让 Qwen 成为编码工具应学习什么的案例。现在需要的不是放弃模型，而是根据 tool calling、读取 Godot 项目上下文、利用资产标签、基于执行结果的再修改流程，对训练数据和运行环境进行相应的对齐。
额外发现的工具
查阅了一个可以让本地模型运行与运维更简便的参考项目 club-3090。
此外，为了后续模型适配或微调实验，也把 LLaMA-Factory 作为候选。
要把 Qwen 用作编码工具，最终需要收集在 Godot 工作中实际失败的案例和成功的模式进行微调。没有足够的失败案例就更换模型或仅附加学习工具，容易导致同样的试错循环。因此，今后要把这些失败案例保留为训练数据候选。
MCP 与研究
通过 Qwen 的 web-search-mcp 找到了 Reddit MCP 候选，并添加了 reddit-mcp-buddy。
Godot、本地模型、Qwen Code 等工具仅凭官方文档往往难以解决所有问题，可能需要 Reddit 或社区案例。但把 MCP 接入与实际提升开发判断是两码事。仍需持续验证将搜索结果转化为代码修改的能力。
困难点
今天说实话精神状态相当低落。
即使更换模型、改变服务器运行方式、接入 MCP、甚至制作资产说明，Qwen 仍未能读完整个项目并进行修复。尤其是工具调用未被真正执行而是以文本形式输出，让人感到失望。表面上看像是编码代理，但实际上既不能读取文件，也不能进行修改。
最终只能稍作休息。如果继续强行推进，只会重复同样的失望，而不是更好地看到问题。
今日判断
Qwen2.5 Coder 目前还不是可以承担整个 Godot 项目的代理。目标并非局限使用 Qwen，而是让它真正成为编码代理。
因此，今天的失败不是缩小使用范围的依据，而是作为微调和运行环境对齐的参考。
- 让 Codex 负责图像解析、文件浏览、实际修改、验证。
- 将 Codex 生成的资产标签、实际修改 diff、运行错误、再修改过程作为 Qwen 的训练数据候选。
- 通过 tool calling 与工作流程让 Qwen 能读取整个项目上下文并直接修改 Godot 代码。
- 若 tool calling 在运行环境中失效，立即判定为失败，并优先搭建基于 vLLM 的真实工具调用配置。
- 使用 LLaMA-Factory 对 Godot 工作模式和失败案例进行微调尝试。
下一步标准
- 再次测试 Qwen 时，首先确认基于 vLLM 的 tool calling 是否真实工作。
- 若工具调用仅以文本输出，则该会话直接判定为失败。
- Godot 工作必须检查运行结果，不能仅凭模型说明完成。
- 资产使用以
assets/ASSET_LABELS.md为准，避免混用不同风格的瓦片集。 - 用 LLaMA-Factory 准备基于 Godot 失败案例的微调。
- 最终目标是把 Qwen 打造成能够实际进行代码修改的编码工具。