2026-06-28 回顾

今天把用 Qwen 将 Markdown 收集为 JSONL 的工作暂停，思考以后把这些 JSONL 导入数据库后，如何检索并取出。

我们之前做的 AST 调试程序会从 Godot 项目中提取代码块。基于这些块，需要制定策略来检索存入数据库的 docs_chunks、api_mapping、label_prototypes JSONL。于是把搜索策略从 A 到 F 进行划分并文档化，当前采用了 F 策略。

目前仍在将 Markdown 收集为 JSONL，尚未把它们真正写入数据库并用检索器进行测试。因此今天先制作了 50 条检查清单，向 Qwen 请求生成任意的 Godot 代码。并为该代码生成了匹配的任意 JSONL 与不匹配的任意 JSONL，随后将 jsonl + prompt + chunk 一起投给 Qwen，观察其判定。即使只做了约 5 条，也立刻感受到这项工作比想象中更费力。

50 项测试计划与现实

原本打算今天测试全部 50 项 Godot 功能。

但实际操作时，理想与现实大相径庭。首先在 Godot 3 中列出 50 项可能以函数或小代码块形式频繁出现的功能，并整理成文档。随后准备了 jsonl + prompt + chunk 同时投递时，Qwen 能否以 “是” 或 “否” 正确进行依据匹配的提示模板。

起初觉得逐个制作并验证即可。结果发现，要测试一个功能，需要准备大量的 JSONL。

必须查看 docs_chunks、api_mapping、label_prototypes 三张表，并为每张表分别制作相关的 JSONL 与完全不相关的 JSONL。还要区分 Godot 3 与 Godot 4 中语法相同的情况，以及不同版本之间的差异。

如果是通用语法，只需以同一段代码为基准，向三张表分别放入成功的 JSONL 与失败的 JSONL 进行验证。若不是通用语法，则需要同时制作 Godot 3 代码和 Godot 4 代码。并且要把基于 Godot 3 的 JSONL 放入 Godot 3 代码中、放入 Godot 4 代码中、再把基于 Godot 4 的 JSONL 放入相反的代码中进行比较。

最终今天只测试了约 5 项。虽然远少于最初计划，但倒是觉得在这个程度停下来也许是件好事。如果在全部 50 项上手工推进，等到发现基准模糊时，后果可能会更糟。

通用语法与版本基准

今天测试时最深的体会是，单纯把 Godot 3 与 Godot 4 划分为两类并不容易。

有些功能在 Godot 3 与 Godot 4 中的语法几乎相同。这种情况下，仅凭一段代码强行判断是 Godot 3 专用还是 Godot 4 专用反而不合理。若是通用语法，就应视为通用语法，检查同一段代码对应的 docs_chunks、api_mapping、label_prototypes 中相关 JSONL 与无关 JSONL 是否被正确区分。

相反，存在版本差异的功能则更复杂。基于 Godot 3 的 JSONL 在 Godot 4 代码中也可能得到 “是”，而基于 Godot 4 的 JSONL 在 Godot 3 代码中也可能因某些字段而得到 “是”。尤其是 migration 相关的 JSONL 同时包含 source 与 target，单纯的字符串匹配容易导致结果摇摆不定。

因此以后需要将 “JSONL 是基于哪个版本生成的” 与 “检查的代码是哪个版本” 分别记录。即使是相同的 “是”，也要区分是通用语法下自然的 “是”，还是因 source/target 字符串混杂而产生的模糊 “是”。

需要记录 F1-score 形式

如果仅用 “成功” 或 “失败” 来记录测试结果，后期很难观察模式。

今天的想法不是立即计算 F1-score，而是像后期查看 precision、recall 那样，保留原始判定结果。例如记录本应得到 “是” 但得到 “否”，或本应得到 “否” 但得到 “是”，以及在通用语法下双向出现 “是” 是否合理，或是 migration JSONL 导致的模糊 “是”。

这样累积下来，后期可以更清晰地判断是提示词有问题、JSONL 生成基准有问题，还是表字段设计有问题。相反，如果像现在这样手工随意记录，后期追溯为何得到某个响应会非常困难。

即使只做了 5 项，也已经看到不少模糊点。因此从第 6 项起，应该先调整记录方式和提示策略，而不是继续原来的测试策略。

手工测试的局限

手动复制提示词、粘贴代码块、逐个放入 JSONL、再记录 Qwen 的响应，这种方式效率极低。

前几项手工操作确实有助于确定基准。实际操作中发现，即使是单个功能，也需要大量的 JSONL；需要区分通用语法与版本专属语法；“是”和 “否” 的含义会随情境变化。

但把这种方式套用到全部 50 项显然不现实。手工输入容易出错，后期比较结果也困难。

因此我开始考虑构建调试工具：在同一界面输入代码块、表类型、JSONL 生成基准版本、检查代码版本、期望响应、实际响应，Qwen 调用结果自动记录。如果能像之前在网页上查看 AST 与 Retriever 流程那样，在 GUI 或调试页面上循环进行 JSONL 匹配测试，将会大大提升效率。

Qwen 聊天机器人测试数据生成的思考

今天思考的是如何用 Qwen 聊天机器人生成任意测试数据。

我想制作的是一种可以动摇验证方式的小型 Demo 数据集。例如向 Qwen 询问生成一段 Godot 3 代码块、一段 Godot 4 代码块，以及符合 docs_chunks、api_mapping、label_prototypes 格式的相关 JSONL 与无关 JSONL。

问题在于，如果直接让聊天机器人 “生成正确的 JSONL 与错误的 JSONL”，结果可能会混得太自然。尤其是通用语法、Godot 3 专用、Godot 4 专用、以及 migration 的 source 与 target 是否同时出现，都会影响 “是” 与 “否”。因此在生成任意数据时，也必须同时写明基准版本、检查代码版本、表类型、期望响应。

今天的体会是，需要更精细地制定 Qwen 生成任意测试数据的方式与提示词。只有这样，才能在测试中判断 Qwen 是仅凭自身知识随意拼接，还是仅依据 JSONL 中的直接字符串依据进行判定。

今日的结论

今天并不是一个测试大量内容的日子，而是确认了检索器搜索策略和基于 Qwen 聊天机器人的 JSONL 匹配实验比想象中更费工的日子。

我起初以为可以完成全部 50 项测试。但实际上只做 5 项就已经出现了足够多的问题。虽然 Godot 3 与 Godot 4 完全分叉的情况也会出现，但也有共同语法，而且像 migration JSONL 那样 source 与 target 同时出现导致判定不稳定的情况也存在。

因此现在需要的不是盲目增加测试数量，而是建立能够正确记录测试结果的结构。需要记录 JSONL 生成基准版本、检查代码版本、表格类型、期望响应、实际响应、模糊原因。只有这样，即使完成了 50 项，也能不是单纯的感想，而是以模式进行观察。

今天本来想随意生成数据进行测试，但最终发现需要使用 Qwen 聊天机器人生成测试数据的方式、提示策略，以及自动调用的调试工具的必要性。明天之后，从第 6 次测试开始稍微调整基准，先找出减少手动重复流程的方法。