2026-07-03 回顾

今天的工作

今天简单地打开了 YouTube 24 小时直播，同时进行收集，尝试了翻译测试，并在 6 月 30 日制作的验证工具上点击进行验证。

Markdown -> JSONL Converter 那边，官方文档的 JSONL 转换收集量从 737 条提升到 850 条。今天也没有大幅度新增实现，而是利用 RunPod 可以保持开启的时间进行收集，同时在此期间逐步检查验证和翻译流程。

翻译方面正在单独实验使用 NVIDIA 免费模型 API 的流水线。通过 GitHub workflow secrets 已经看到一定程度的成功，并确认了生成日文/中文 README 的界面。虽然还不能说完全引入，但文档越多，自动翻译流程的需求就越强烈。

制作验证工具的价值

今天最深刻的体会是，6 月 30 日制作的验证工具真的非常有用。实际上如果没有那个工具，差点出大事。

以前的做法是让 Qwen 分别生成代码和 JSONL，然后再把它们粘贴到提示中，靠脑子比较预期响应。现在只需点击条目，生成代码和 JSONL，分别对 Godot 3 代码和 Godot 4 代码进行验证，甚至可以在同一屏幕上看到原始提示和原始响应。虽然仍有繁琐，但至少可以不遗漏地看到哪里出错。

今天在 50 条测试条目中点到第 10 条进行确认。过程中发现 LLM 产生错误答案的情况确实存在。

• 第 1 条因为 docs_chunks 候选与相同的 _ready() 或 viewport 系列线索相似，实际是不同代码说明，却返回了 “是”。
• 第 3、4、7 条在已经把基于 Godot 3 的迁移 JSONL 粘贴到 Godot 4 代码中时，仍然返回了 “是”。
• 第 8 条因为 docs_chunks 处理相同的追踪/移动主题或相似的 API，虽然与当前 SOURCE_CODE 的实际行为不同，却被判定为 “是”。
• 第 6、9、10 条则全部符合预期，通过了验证，说明改进方向并非全错。

这些问题并非单个 JSONL 异常导致，而是当以后通过混合搜索出现相似候选时，Qwen 是否会直接把它当作依据，还是仅视为搜索候选而过滤。于是需要对验证提示进行细化，使其更准确判断当前代码与 JSONL 候选的关系，而不是简单阻断特定 token。

感想

今天并没有进行特别炫目的实现。自动收集、手动点击验证、查看 JSONL 与验证结果，花的时间比想象中要慢。不过感觉做了点事，还是很满足。

验证比想象中要耗时。即使看似只检查一个代码和一个 JSONL，docs_chunks、api_mapping、label_prototypes 的属性各不相同，Godot 3 与 Godot 4 的代码也不同。即使只做十条，也会出现相当多的案例。

不过只要像今天这样事先捕捉错误点，后续在实际数据库搜索和 Retriever 验证流程中就能减少因意外导致的崩溃。以后在测试时仍希望持续捕捉可以提前发现的问题。

如果要改进，除了坚持使用 RunPod，也可以考虑同时使用免费 API。只要 NVIDIA 免费模型 API 或其他免费端点能够稳定地用于翻译、辅助验证、文档同步等任务，就有可能降低对 RunPod 的依赖。