2026年6月30日星期二2026 年 6 月 30 日
- 因为世界杯赛季在看世界杯，睡眠不足，工作进度受限
localhost:8501 的 Markdown -> JSONL 转换目前已完成约 655 条- 今天重点不在大规模收集/训练，而是简化并完善验证测试调试工具
- 制定了验证测试调试工具的策略，并实现了独立的网页工具
Qwen Validation Debugger
- 执行路径为
tools/qwen-validation-debugger
- 本地运行命令为
npm run validation-debug:debug
- 默认地址为
http://127.0.0.1:8520/
- 6 月 28 日使用 Qwen 聊天机器人手动创建了 Godot 代码块和 JSONL，并进行 “是”/“否” 验证
- 这种方式可以验证可行性，但随着条目增多，复制/粘贴和结果比对工作量急剧增加
- 特别是需要同时测试
docs_chunks、api_mapping、label_prototypes 三个表格，若是通用语法需 6 个槽位，若区分版本则需 12 个槽位，手动管理变得非常复杂
- 工具示例加载了 50 条 Godot 测试条目，并让 Qwen 为每条标记是通用语法还是 Godot 3/4 区分
- 若是通用语法，则生成一段通用代码
- 若有版本差异，则分别生成 Godot 3 代码和 Godot 4 代码
- 随后自动为每个表格生成对应的 JSONL 槽位
- 再次确认不能仅用统一的 “是/否” 来处理
docs_chunks、api_mapping、label_prototypes
docs_chunks 是代码说明依据，代码直接匹配时标记为 “是”api_mapping 与 label_prototypes 是迁移源依据，已在 Godot 4 中实现的代码或通用语法往往应标记为 “否”- 因此将槽位名称细分为 “说明依据”、 “无关说明”、 “需要转换”、 “已应用”、 “通用/不必要”、 “无关转换”
- 制作工具时最大变化是将
JSONL 生成基准代码 与 验证目标代码 分离
- 最初的设计是：用 Godot 3 代码生成的 JSONL 只在 Godot 3 代码上验证，Godot 4 代码生成的 JSONL 只在 Godot 4 代码上验证
- 实际上需要检查将基于 Godot 3 的 JSONL 放入 Godot 4 代码时是否应返回 “否”
- 因此为每个槽位分别添加了 “Godot 3 代码验证” 与 “Godot 4 代码验证” 按钮，并分别保存结果
- 完成工具后开发效率显著提升
- 之前每次都要向 Qwen 请求代码和 JSONL，随后手动粘贴到提示中验证，并在脑中比对预期响应
- 现在可以在同一界面完成条目选择、标记、代码生成、JSONL 生成、Godot 3/4 交叉验证以及 raw prompt/response 查看
- 与其快速大量产出，不如明确生成依据和验证代码，避免混淆，这一点收益最大
- 在重复 50 条测试条目时，减少了记忆负担，使得更快发现失败模式
- 通过该工具可以直观看到使用了哪些提示发送请求、JSONL 批量生成/验证的调用顺序、验证提示和请求提示本身的构成
- 根据标记和槽位属性预设 “是”/“否” 基准，避免混淆
- 响应结果即时显示在对应槽位，快速定位是哪段代码和哪条 JSONL 组合导致失败
- 即使因提示导致失败，使用的提示仍保留在界面上，便于后续修改
- 工具已基本完成，后续计划放慢节奏，侧重慢慢完善验证标准，而不是强行增加数量
- 记录文档: Qwen Validation Debugger 策略与实现记录
- 回顾: docs/retrospectives/2026-06-30.md