Qwen Godot 代码 JSONL 依据匹配测试检查清单

编写日期：2026年 6月 28日

目的

使用 Qwen 生成 50 个 Godot 3 代码块，并以与昨天进行的 JSONL 依据匹配测试相同的方式，检查 是/否 判定是否正确。

本次测试并不是要判断模型是否了解 Godot 知识。它是一个在同时提供 SOURCE_CODE 和 JSONL 时，判断 JSONL 中是否存在与实际代码块直接对应的字符串/API/模式依据的测试。

也就是说，相关的 JSONL 应该返回 是，不相关的 JSONL 应该被判定为 否 并被丢弃。

测试方式

对每个代码块至少附加两种 JSONL 进行测试。不过由于 Godot 3 与 Godot 4 之间可能存在语法完全相同的公共语法，所有功能并不都视作仅适用于 Godot 3 的语法。

JSONL
Qwen direct-evidence validator prompt
SOURCE_CODE chunk

实际验证请求是将 JSONL + 提示 + chunk 一起提交时，检查 Qwen 是否仅返回 是 或 否。

对于公共语法，使用同一个代码 chunk 进行测试。此时正确的 JSONL 是包含该代码/函数说明或模式的 JSONL，错误的 JSONL 是包含完全不同函数或系统说明的 JSONL。期望响应为 是 的情况和 否 的情况并不是因为代码不同而区分，而是取决于 JSONL 中是否直接有依据。

重复生成循环

整体目标是对 50 项功能进行全部测试。不过今天仅手动确认 5 项，之后在累计结果中先分析 是/否 的响应模式，以此简化。

今日目标: 5个  
总目标: 50/50

在填满5个之后，不强行增加新项目数量，先观察公共语法/版本差异/各表的 false positive 和 false negative 情况。

测试在重复以下流程的同时生成数据。

1. 给 Qwen 一个要测试的 Godot 功能。  
2. 首先标明该功能是 Godot 3/4 的通用语法，还是 Godot 3 的特有语法，或是 Godot 4 的特有语法。  
3. 如果是通用语法，则创建一个相同的代码块。  
4. 如果是通用语法，生成一个针对该代码/函数的正确 JSONL，以及一个针对完全不同函数的错误 JSONL。  
5. 如果不是通用语法，则分别为 Godot 4 和 Godot 3 创建专用的 JSONL 进行测试。  
6. 所有 JSONL 都要符合目标表的列要求。  
7. 在验证提示中放入 JSONL + SOURCE_CODE 代码块，并检查 “是”/“否”。  
8. 记录预期响应与实际响应是否一致。

核心不是代码生成质量，而是 JSONL 依据匹配判定是否稳定。因此正确的 JSONL 应该返回 是，错误的 JSONL 应该返回 否。

公共语法注意事项

在 Godot 3 和 Godot 4 中保持相同形式的语法不应视为版本分类测试。例如 _ready()、_process(delta)、基本变量赋值、print() 等在两侧都可能使用的代码。

这种情况下应如下处理。

因此在记录表中必须标明是否为公共语法。以后查看结果时，可区分是因为迁移依据而强行判定的公共语法，还是将有版本差异的语法误当作公共语法处理。

标准重新定义备忘

在测试第 4 条和第 5 条时发现难以给出确定判定。尤其是依据是基于 Godot 3 还是 Godot 4 生成 JSONL，会导致相同代码块的响应不同，而这种差异本身就成为模式分析的对象。

因此目前不对好/坏作出确定，而是先记录原始响应，如下所示。

响应顺序基本按照 docs_chunks 相关, docs_chunks 无关, api_mapping 相关, api_mapping 无关, label_prototypes 相关, label_prototypes 无关 来判断。

第 4 条虽然之前像整理好的项目那样记录，但在 Godot 3 检查中出现了 否, 否, 是, 否, 是, 否 的流程，因此在确定判定时被排除。本文档从现在起作为观察记录，关注“在什么标准下哪些响应会波动”，而不是“有多少是正确的”。

生成请求示例

下面是测试第一个功能 _ready() 函数初始化及视口大小设置时的请求示例。

JSONL 格式及每个 JSONL 的用途已在单独文档中分离。

• Qwen 测试用 JSONL 架构与用途

_ready() 函数初始化以及与视口大小设置相匹配的 godot3 块，一个，godot4 块一个，提供给我。

但请先标明此功能在 godot3 和 godot4 中是否为公共语法。
如果是公共语法，请标明可以使用同一段代码进行测试。

另外，请提供符合 docs_chunks JSONL 格式的正确 JSONL 示例，以及不正确的 JSONL 示例。

此示例基于 docs_chunks。api_mapping、label_prototypes 也以相同方式生成符合各自 JSONL 格式和用途的正确 JSONL 和错误 JSONL，并使用相同的验证提示检查 是/否。

验证输入如下所示。

JSONL:
<正确或错误的 JSONL 单行>

PROMPT:
<direct-evidence validator prompt>

SOURCE_CODE:
<Godot 3 代码块，Godot 4 代码块，或通用语法代码块>

提示会像下面这样，在 SOURCE_CODE 与 JSONL 之间发送一种判断直接说明依据或转换依据的感觉。

你是 JSONL 依据匹配判定器。

针对下面的 SOURCE_CODE，判断下面的 JSONL 是否直接包含说明依据或转换依据。

判定标准：
- 只有当 JSONL 模式中的某一项与 SOURCE_CODE 中的实际字符串或 API 调用完全匹配时，才算 “是”。
- 仅仅因为出现 Godot、Godot3、Godot4、migration、2D、physics 等宽泛词汇并不构成关联。
- 如果 JSONL 涉及其他 API、其他节点或其他系统，则为 “否”。  
- 不要使用你对 Godot 的任何已知知识，只依据 JSONL 中的字符串依据进行判断。  
- 回答必须仅输出 “是” 或 “否” 其中之一。

判定矩阵

观察检查清单

在每个表格的 50 条样本测试结束后检查以下项目。

测试记录表格

复制下表并填写测试结果。

表格记录

docs_chunks

检查官方文档说明型依据是否与代码块直接对应。

| 21 | 屏幕抖动（Screen Shake）效果实现 | 版本差异 | 相机偏移、抖动强度/时间、Tween 或随机偏移说明依据与代码块对照 | 敌人移动、相机追踪、UI 动画候选并区分 | sample-21 是检查即使出现 “相机” 词汇，也要确认是否直接说明屏幕抖动结果 | | 22 | 粒子系统创建及位置匹配 | 版本差异 | 粒子节点创建、位置同步、发射开始说明依据与代码块对照 | 普通节点创建、弹体创建、动画候选并区分 | sample-22 用于确认创建对象是否为 particle，是否包含位置匹配和 emission 流程 | | 23 | 场景切换（Scene Change）函数 | 版本差异 | 场景切换请求、SceneTree 调用、目标场景路径说明的文档候选与代码块对照 | 菜单显示、暂停、资源加载等非场景切换本身的候选并区分 | sample-23 需区分是否真正调用了更换画面/场景，还是仅仅是加载或 UI 显示说明 | | 24 | 主菜单场景加载及显示 | 版本差异 | 加载主菜单场景并在屏幕上显示的说明依据与代码块对照 | 单纯的场景切换、暂停、资源预加载候选并区分 | sample-24 用于判断是否实际显示了菜单场景，还是其他场景处理的说明 | | 25 | 游戏暂停（Pause）功能切换 | 公共语法 | pause 状态切换、get_tree().paused、根据输入的暂停/恢复说明依据与代码块对照 | 打开菜单、场景切换、游戏结束候选并区分 | sample-25 检查是否真正改变了暂停状态，还是仅仅是 UI 显示 | | 26 | 键盘输入状态检查（Input.is_key_pressed） | 版本差异 | Input.is_key_pressed 与键常量/键码说明依据与代码块对照 | action map 输入、鼠标输入、移动处理候选并区分 | sample-26 将键盘状态查询本身与整体移动逻辑分开查看 | | 27 | 鼠标位置（光标）坐标获取 | 公共语法 | viewport/global mouse position 查询说明依据与代码块对照 | 鼠标点击发射、触摸输入、光标显示候选并区分 | sample-27 用于确认代码是读取坐标而非点击事件 | | 28 | 随机数字生成函数 | 版本差异 | RNG 初始化、随机数生成、范围指定说明依据与代码块对照 | 随机位置分布、敌人生成计时器候选并区分 | sample-28 将数字生成函数本身与使用该数字的游戏逻辑分开 | | 29 | 定时生成敌人（Spawn） | 版本差异 | 基于 Timer/timeout/累计时间周期性生成敌人的说明依据与代码块对照 | 随机位置计算或敌人移动 AI 候选并区分 | sample-29 检查时间间隔和 spawn 调用是否直接作为依据 | | 30 | 已生成敌人的位置随机分布 | 公共语法 | 随机坐标范围、spawn 区域、位置分布说明依据与代码块对照 | 定时生成的计时器候选并区分 | sample-30 用于确认说明的是“放在哪里”，而非“何时生成” | | 31 | 玩家动画状态切换（Idle、Run、Jump） | 版本差异 | 根据输入/速度/状态更改动画名称的说明依据与代码块对照 | 动画播放速度或时间控制候选并区分 | sample-31 将状态切换与播放时间控制分开查看 | | 32 | 动画播放时间控制 | 公共语法 | animation speed、seek、advance、playback position 控制说明依据与代码块对照 | Idle/Run/Jump 状态切换候选并区分 | sample-32 检查是否是调节播放时间/速度，而不是选择哪段动画 | | 33 | 碰撞区域大小调整 | 版本差异 | CollisionShape2D/Shape2D 大小属性、RectangleShape2D 的 size/extents 系列说明依据与代码块对照 | 碰撞检测、伤害处理、Area2D signal 候选并区分 | sample-33 用于确认代码是调整碰撞区域的形状/大小，而非检测是否发生碰撞 | | 34 | 物理重力（Gravity）应用 | 版本差异 | 将 gravity 与 delta 累加到 velocity 并通过 move 函数应用的说明依据与代码块对照 | 跳跃力度、着地检测、Area 重力设置候选并区分 | sample-34 将重力累加流程与跳跃/着地判定分开验证 | | 35 | 跳跃（Jump）力度应用及着地检测 | 版本差异 | is_on_floor()、跳跃速度、输入条件、着地状态说明依据与代码块对照 | 仅重力应用或动画状态切换候选并区分 | sample-35 检查跳跃输入和地面判定是否在同一移动流程中说明 | | 36 | 墙体碰撞时滑动（Slide）处理 | | | | | | 37 | 玩家方向切换（Facing Left/Right） | | | | | | 38 | 弹匣（Ammo）计数减少 | | | | | | 39 | 弹匣空时的重新装填（Reload）状态切换 | | | | | | 40 | UI 按钮点击事件绑定 | | | | | | 41 | 设置（Settings）菜单打开/关闭切换 | | | | | | 42 | 语言（Language）更改时文本更新 | | | | | | 43 | 保存数据（Save Game）JSON 序列化 | | | | | | 44 | 加载数据（Load Game）JSON 反序列化 | | | | | | 45 | 文件读写错误处理 | | | | | | 46 | 网络连接状态检查 | | | | | | 47 | 通过远程函数（RPC）调用进行同步 | | | | | | 48 | 场景资源动态加载 | | | | | | 49 | 内存释放及资源卸载 | | | | | | 50 | 调试日志输出（print 或 print_debug） | | | | |

api_mapping

检查关于从 Godot 3 到 Godot 4 名称、类、函数、符号如何变化的依据是否直接与代码块匹配。

| 22 | 粒子系统创建及位置匹配 | 版本差异 | Particles2D/GPUParticles2D、emitting、position/global_position 相关更改依据是否直接出现在代码中 | 与弹体创建或普通节点创建的映射区分 | sample-22 将粒子系统专用 API 变化与普通生成逻辑分开查看 | | 23 | 场景切换（Scene Change）函数 | 版本差异 | change_scene、change_scene_to_file、change_scene_to_packed 系列更改依据是否直接出现在当前代码中 | 与普通 load()/preload() 或主菜单显示的映射区分 | sample-23 检查 Godot 3 的场景切换调用与 Godot 4 的替代调用是否按实际代码版本匹配 | | 24 | 主菜单场景加载及显示 | 版本差异 | 场景加载、实例化、菜单场景显示相关更改依据是否在当前代码中必需 | 与普通场景切换或资源 preload 的映射区分 | sample-24 用于判断主菜单显示目的与场景 API 更改依据是否混合 | | 25 | 游戏暂停（Pause）功能切换 | 通用语法 | pause mode / process mode、树暂停相关更改依据是否真的在当前代码中需要 | 与菜单 UI 或游戏结束的映射区分 | sample-25 检查通用暂停切换代码的迁移映射是否过度附加 | | 26 | 键盘输入状态检查 (Input.is_key_pressed) | 版本差异 | 键常量、scancode/keycode、Input.is_key_pressed 相关更改依据是否直接匹配代码 | 与 action map 移动处理或鼠标输入的映射区分 | sample-26 将键状态查询 API 变化与使用该输入的游戏逻辑分开查看 | | 27 | 获取鼠标位置（光标）坐标 | 通用语法 | mouse position 查询 API 是否需要版本间更改依据 | 与点击生成弹体或触摸输入的映射区分 | sample-27 检查坐标读取代码中是否附加了不必要的转换依据 | | 28 | 随机数字生成函数 | 版本差异 | randomize、RandomNumberGenerator、range 函数更改依据是否直接出现在代码中 | 与随机生成位置或生成计时器的映射区分 | sample-28 将随机数 API 本身的更改与随机数使用目的分离查看 | | 29 | 定时生成敌人（Spawn） | 版本差异 | Timer 信号、timeout 连接、yield/await 系列更改依据是否直接出现在当前代码中 | 与敌人位置随机分布或敌人 AI 移动的映射区分 | sample-29 同时检查周期执行结构与生成目标逻辑 |

| 30 | 生成敌人的位置随机分布 | 公共语法 | random range、viewport size、spawn area 计算是否需要实际 API 更改依据 | 基于 Timer 的周期生成映射与之区分 | sample-30 检查仅有位置计算的代码是否未附加生成周期映射 | | 31 | 玩家动画状态切换（Idle、Run、Jump） | 版本差异 | AnimatedSprite/AnimatedSprite2D、AnimationPlayer 状态切换相关更改依据是否与代码直接匹配 | playback speed/seek/time 控制映射与之区分 | sample-31 将动画节点名称更改与状态切换模式分离查看 | | 32 | 动画播放时间控制 | 公共语法 | playback speed、seek、current position 相关更改依据在当前代码中是否必要 | Idle/Run/Jump 状态选择映射与之区分 | sample-32 区分播放时间调节 API 与状态切换 API | | 33 | 碰撞区域大小调整 | 版本差异 | CollisionShape2D、RectangleShape2D、shape size/extents 更改依据在当前代码中是否直接必要 | collision signal、physics layer、damage 映射与之区分 | sample-33 检查不是碰撞判定 API，而是 shape 大小调整 API 的变化是否与实际代码相符 | | 34 | 物理重力（Gravity）应用 | 版本差异 | CharacterBody2D/KinematicBody2D、velocity、move_and_slide 系列更改依据在当前代码中是否直接必要 | jump impulse、floor check、Area2D gravity 映射与之区分 | sample-34 确认在物理帧中重力是否累计并映射到移动 | | 35 | 跳跃（Jump）力度应用及着陆检测 | 版本差异 | is_on_floor()、jump velocity、Input action、move_and_slide 相关更改依据是否与代码直接匹配 | 仅 gravity 移动、动画状态、墙体碰撞映射与之区分 | sample-35 检查跳跃启动条件与着陆判定是否共同构成所需映射 | | 36 | 墙体碰撞时滑动（Slide）处理 | | | | | | 37 | 玩家方向切换（Facing Left/Right） | | | | | | 38 | 弹药（Ammo）计数减少 | | | | | | 39 | 弹药耗尽时的换弹（Reload）状态切换 | | | | | | 40 | UI 按钮点击事件关联 | | | | | | 41 | 设置（Settings）菜单打开/关闭切换 | | | | | | 42 | 语言（Language）更改时文本更新 | | | | | | 43 | 保存数据（Save Game）JSON 序列化 | | | | | | 44 | 加载数据（Load Game）JSON 反序列化 | | | | | | 45 | 文件读写错误处理 | | | | |

| 46 | 网络连接状态检查 | | | | | | 47 | 通过远程函数(RPC)调用进行同步 | | | | | | 48 | 场景资源动态加载 | | | | | | 49 | 内存释放及资源卸载 | | | | | | 50 | 调试日志输出（print 或 print_debug） | | | | |

label_prototypes

不是仅仅更改名称，而是函数的使用方式、参数构成、调用模式整体改变的示例依据是否与代码块直接匹配，需要确认。

| 23 | 场景切换（Scene Change）函数 | 版本差异 | 检查是否在当前代码中直接存在接受场景路径并通过 SceneTree 切换的调用模式 | 与单纯资源加载、打开菜单、暂停原型区分 | sample-23 用于确认场景切换的输入路径、调用目标以及切换结果是否由原型说明 | | 24 | 主菜单场景加载与显示 | 版本差异 | 检查是否在当前代码中直接存在加载并显示菜单场景的调用模式 | 与单纯资源加载、场景切换、暂停菜单原型区分 | sample-24 用于确认原型是否说明“显示主菜单”这一结果 | | 25 | 游戏暂停（Pause）功能切换 | 公共语法 | 检查是否在当前代码中直接存在翻转 pause 状态并绑定相关 UI/输入处理的模式 | 与打开设置菜单或游戏结束原型区分 | sample-25 用于确认 pause 标志的改变与画面显示是否应视为同一流程 | | 26 | 键盘输入状态检查 (Input.is_key_pressed) | 版本差异 | 检查是否在当前代码中直接存在轮询键盘输入状态的模式 | 与动作强度、移动向量、鼠标输入原型区分 | sample-26 用于将输入查询与基于该输入执行的行为分离记录 | | 27 | 获取鼠标位置（光标）坐标 | 公共语法 | 检查是否在当前代码中直接存在读取光标坐标并用于变量或位置计算的模式 | 与鼠标点击事件或子弹生成原型区分 | sample-27 用于确认仅查询鼠标位置本身是否为核心 | | 28 | 随机数字生成函数 | 版本差异 | 检查是否在当前代码中直接存在随机数生成/范围指定的调用模式 | 与生成位置分布、掉落表、计时器生成原型区分 | sample-28 用于将 random API 调用与 random 结果的使用场景分离观察 | | 29 | 按特定时间间隔生成敌人（Spawn） | 版本差异 | 检查是否在当前代码中直接存在按固定时间调用 spawn 函数的模式 | 与随机位置计算或敌人追踪 AI 原型区分 | sample-29 用于确认时间条件、计时器、spawn 调用顺序是否正确 | | 30 | 已生成敌人的位置随机分布 | 公共语法 | 检查是否在当前代码中直接存在将生成的敌人位置放置在随机范围内的模式 | 与按固定时间生成的 spawn 循环原型区分 | sample-30 用于将分布/坐标计算与生成周期分离 | | 31 | 玩家动画状态切换（Idle、Run、Jump） | 版本差异 | 检查是否在当前代码中直接存在根据状态值或速度更改 animation name 的模式 | 与播放速度、seek、帧/时间控制原型区分 | sample-31 用于确认切换到哪种状态是核心 | | 32 | 动画播放时间控制 | 公共语法 | 检查是否在当前代码中直接存在控制播放速度、seek、当前播放位置的模式 | 与 Idle/Run/Jump 状态切换原型区分 | sample-32 用于确认核心是播放时间控制而非动画选择 | | 33 | 碰撞区域大小调整 | 版本差异 | 检查是否在当前代码中直接存在读取或修改碰撞 shape 大小值的模式 | 与碰撞事件处理或伤害应用原型区分 | sample-33 用于将 shape 大小修改与碰撞结果处理分离记录 | | 34 | 物理重力（Gravity）应用 | 版本差异 | 检查是否在当前代码中直接存在基于 delta 将重力累加到 velocity 并在移动调用中体现的模式 | 与跳跃输入、着陆检测、生成/计时器原型区分 | sample-34 用于确认在物理移动循环中重力累加是核心 | | 35 | 跳跃（Jump）力度应用及着陆检测 | 版本差异 | 检查是否在当前代码中直接存在在地面时施加跳跃力度并随后检测着陆的模式 | 与仅有重力累加的移动原型或动画状态切换原型区分 | sample-35 用于确认跳跃条件、垂直速度改变、地面判定是否被统一为一条流程 | | 36 | 墙体碰撞时滑动（Slide）处理 | | | | | | 37 | 玩家方向切换（Facing Left/Right） | | | | | | 38 | 弹药（Ammo）计数减少 | | | | | | 39 | 弹药耗尽时的换弹（Reload）状态切换 | | | | | | 40 | UI 按钮点击事件绑定 | | | | | | 41 | 设置（Settings）菜单打开/关闭切换 | | | | | | 42 | 语言（Language）更改时文本更新 | | | | | | 43 | 保存数据（Save Game）JSON 序列化 | | | | | | 44 | 加载数据（Load Game）JSON 反序列化 | | | | | | 45 | 文件读写错误处理 | | | | | | 46 | 网络连接状态检查 | | | | | | 47 | 通过远程函数（RPC）调用进行同步 | | | | | | 48 | 场景资源动态加载 | | | | | | 49 | 内存释放及资源卸载 | | | | | | 50 | 调试日志输出（print 或 print_debug） | | | | |

2026年7月6日 追加记录

从第6条到第10条已经在2026年7月3日反映了改进流程并留下了详细观察。因此在本文件中，6~10条不留空白，而是将原有的观察内容分别对应写入 docs_chunks、api_mapping、label_prototypes 表中。

2026年7月6日，以 http://localhost:8520/#item=sample-22 为基准，追加记录了第11条到第22条。该区间逐条说明每个条目中哪些候选依据对应的 JSONL，哪些候选应当以其他代码/其他转换/其他模式出现。

2026年7月8日 追加记录

2026年7月8日，以 http://localhost:8520/#item=sample-32 为基准，继续记录了第23条之后至第32条。此区间更像是观察表，而不是最终判定表，记录 docs_chunks、api_mapping、label_prototypes 对同一代码块的不同视角解释或拒绝理由。

2026年7月13日 追加记录

2026年7月13日，以 http://localhost:8520/#item=sample-35 为基准，记录了第33条之后至第35条。该区间涉及冲突区域大小、重力、跳跃/着陆等物理移动与碰撞形态相互影响的条目，需要同时考虑代码的目的和使用位置，而不仅仅是字符串的重叠。

第5条 逆向观察

第5条虽然在今天的目标数量中，但在以 Godot 4 为基准的 JSONL 逆向检查时，结果并未以简洁的 “是/否” 对出现。因此不对其作出最终判定，而在后续阶段将其作为模式分析的对象。

响应顺序为 docs_chunks #1、docs_chunks #2、api_mapping #1、api_mapping #2、label_prototypes #1、label_prototypes #2。

该结果不应仅视为模型错误，而是提示需要检查 JSONL 中的 match_terms、required_when_seen_in_code、content 是否过于宽泛。尤其是 move_and_slide() 和 Input.is_action_pressed 这类共同出现的字符串虽可作为直接依据，但在最大速度限制或版本差异的依据上可能过于宽泛。

不一致案例记录

False Positive

记录本应为 “否” 但被判为 “是” 的案例。

False Negative

记录本应为 “是” 但被判为 “否” 的案例。

响应格式违规

记录既不是 “是” 也不是 “否”，而是给出说明、JSON、空响应或多句回答的案例。

观察摘要

在测试过程中填写以下数字和原始响应。此处不作最终判定，只观察响应在何种标准下出现波动。