Qwen Validation Debugger 提示应用结构

chunk_id
doc_version
source_url
source_file
source_sha256
doc_type
symbol
section_path
heading
content
code_blocks
language_tags
godot_version_tags
api_symbols
token_count
metadata

mapping_id
source_api
target_api
change_type
godot_from
godot_to
confidence
evidence_chunk_ids
match_terms
notes
negative_patterns

prototype_id
label
task_type
input_pattern
expected_finding
recommended_action
evidence_mapping_ids
evidence_chunk_ids
severity
validator_rules

你是 Godot 代码测试项目分类器。

判断下面的 TEST_ITEM 是否可以在 Godot 3 和 Godot 4 中使用相同的语法/相同的代码块进行测试，还是需要分别为 Godot 3 和 Godot 4 编写代码。

判断标准：
- 如果是使用相同的 GDScript 语法和相同的 API 调用，在 Godot 3/4 中都能自然解释的项目，则为 “common”。
- 类名、函数名、签名、节点名、调用方式等在不同版本中有意义的差异的 API/语法，则为 “separate”。
- 若不明确则归为 “separate”。更安全地生成更多测试更好。
- 必须仅输出一个 JSON 对象。

JSON 格式：
{
  "syntax_scope": "common 或 separate",
  "label": "简短的中文标签",
  "reason": "为什么这样判断的一两句话",
  "godot3_focus": "生成 Godot 3 代码时的关注点",
  "godot4_focus": "生成 Godot 4 代码时的关注点"
}

TEST_ITEM:
${itemTitle}

你是用于 Godot 测试的代码块生成器。

${versionInstruction}

要求：
- 不是整个项目，而是按函数或小代码块编写。
- 仅编写与测试项目直接相关的代码。
- 代码中必须显式包含用于版本判断的 API/语法。
- 回答必须仅输出一个 JSON 对象。
- 不要使用 Markdown 代码块标记。

JSON 格式：
{
  "godot_version": "${targetVersion}",
  "syntax_scope": "${syntaxScope}",
  "source_code": "GDScript 代码块",
  "notes": "代码中需要确认的关键点"
}

TEST_ITEM:
${itemTitle}

你是用于 Godot RAG 测试的 JSONL 生成器。

目标:
${slotCase.goal}

目标表:
${table.label}

表用途:
${table.purpose}

字段列表:
${table.schema.map((field) => `- ${field}`).join('\n')}

对直接匹配判断重要的字段:
${table.directFields.map((field) => `- ${field}`).join('\n')}

生成规则:
- 必须仅输出一个 JSON 对象。
- 不使用 Markdown 代码块。
- ${slotCase.generationRule}
- docs_chunks 是说明依据匹配，api_mapping 和 label_prototypes 是迁移源依据匹配。
- 已经以 Godot 4 目标形式应用的代码或通用语法不是 api_mapping/label_prototypes 中的 “需要转换” 依据。
- negative_patterns 和 reject_when_seen_in_code 是拒绝条件。此字段中的字符串应解释为 “否” 依据，而不是 “是” 依据。
- 不要只匹配宽泛的主题词，而是根据实际字符串/API 调用使相关/无关区分开来。
- 不要随意增加表用途之外的字段。
- source_url、source_file、*_id 值请自然地编写用于测试。

测试项目:
${itemTitle}

代码版本:
${versionLabel}

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode}

GODOT4_TARGET_CODE:
${targetCode}` : `SOURCE_CODE:
${sourceCode}`}

- 在 docs_chunks 中，只有当 JSONL 直接说明 SOURCE_CODE 的核心行为时，才允许 “是”。
- 核心行为不仅是简单的 API 名称，还包括代码计算了什么、应用于哪些对象、最终产生什么状态/结果。
- 即使出现相同的 API 或相同的方法，只要 JSONL 说明的是不同的目的、不同的目标对象、不同的结果，则仅是检索候选而非直接依据，因此为 “否”。
- 如果 JSONL 只提供相同 API 的一般说明，而未说明 SOURCE_CODE 的具体资源、分支、循环、状态变化，则不是直接说明依据，因此为 “否”。
- 根据 SOURCE_CODE 是重复执行、单次执行、状态转换还是资源替换的流程，如果 JSONL 的流程不同，则为 “否”。
- 在同一文件或同一游戏流程中一起出现的功能可以相互成为检索候选。即使如此，只有当 SOURCE_CODE 的最终目的、目标、结果与 JSONL 所说明的最终目的、目标、结果相同时，才为 “是”。
- 即使 api_symbols 或标题中出现了 SOURCE_CODE 的部分调用名称，只要 content/code_blocks 说明的是不同的工作流程，也不是直接说明依据。
- 仅仅符合生命周期函数、公共类型、一般属性名等在多个代码中重复出现的外围线索，并不是直接依据。
- 如果 JSONL 的 code_blocks 说明的是与 SOURCE_CODE 不同的示例代码，即使部分 API 相同，也为 “否”。
- 不要凭自己的知识将意义相似的其他 API 或相似的使用案例推断为等同。JSONL 必须直接呈现当前 SOURCE_CODE 的目的/目标/结果。
- 如果 JSONL_GENERATED_FROM_CODE_VERSION 与 VERIFY_TARGET_CODE_VERSION 不同，需先确认 JSONL 是否说明了当前待验证版本的代码行为。
- 即使版本不同，只要明确说明了公共 API/公共行为，也可能为 “是”，但如果 JSONL 的 code_blocks/api_symbols 与当前 SOURCE_CODE 的实际语法/API 调用不符，即使看起来是相同功能，也为 “否”。

api_mapping和 label_prototypes的提问不是“JSONL和代码是否有一点关联”，而是“是否应该根据此 JSONL 更改当前 SOURCE_CODE”。
- 首先根据 JSONL 判定当前 SOURCE_CODE 属于“更改前代码、已更改后代码、无关代码、无需转换代码”中的哪一类。  
- “是”仅在当前 SOURCE_CODE 为更改前代码且需要立即应用 JSONL 所述转换时才允许。  
- 3→4 合并 JSONL 是基于同时查看 Godot 3 更改前代码和 Godot 4 更改后代码而得出的依据。验证时需区分当前 SOURCE_CODE 是更改前代码还是更改后代码。  
- 如果当前 SOURCE_CODE 已是 Godot 4 target 形式，即使 JSONL 看起来与迁移说明相关，也视为“已应用”，答案为“否”。  
- label_prototypes 的“需要转换”判断仅在当前 SOURCE_CODE 实际包含更改前的使用方式、参数构成、调用模式时才为“是”。  
- 与当前 SOURCE_CODE 无关的转换 JSONL，即使验证对象是 Godot 3 代码，只要不适用于当前代码，也返回“否”。  
- source/before/required 系列内容视为更改前代码依据，target/after/recommended 系列内容视为更改后形式，negative/reject 系列内容视为如果在当前代码中应用该转换则不应出现的条件。  
- 即使函数名相同，只有当调用参数、返回值处理、继承节点、周边代码结构等 JSONL 所述的更改前模式直接保留在 SOURCE_CODE 中时，才算“是”。  
- source_api 与 target_api 可能共享相同名称，或 match_terms 中同时出现 source/target 术语。这种情况下，仅函数名或宽泛的 match_terms 匹配并不构成“是”。  
- 同一文件或同一游戏流程中共同出现的功能可以相互成为搜索候选，但如果当前 SOURCE_CODE 中没有直接保留的更改前模式，仍然返回“否”。  
- 若 JSONL_GENERATED_FROM_CODE_VERSION 与 VERIFY_TARGET_CODE_VERSION 不同，需先区分当前 SOURCE_CODE 是 JSONL 的更改前代码还是已更改后代码。  
- 若 JSONL_GENERATED_FROM_CODE_VERSION 不是迁移而是单一版本槽，则仅当当前验证目标代码中直接存在 source/before/required 模式时才为“是”。  
- 若当前 SOURCE_CODE 与 JSONL 的 target/after/recommended 形式相同或更为新颖，则视为已应用代码，答案为“否”。  
- 若验证目标版本为 Godot 4 或 common，而 SOURCE_CODE 已是 target/after 形式，即使 JSONL 是正确的迁移知识，也对当前代码返回“否”。  
- 当 change_type 为 signature_stable、no_change、common 等表示无需转换时，答案为“否”。  
- 即使在 Godot 4 代码或通用语法代码中附带迁移 JSONL，只要不需要额外转换，也返回“否”。

- 在判定之前，用一句话概括 SOURCE_CODE 的核心操作，并用一句话概括 JSONL 所描述的核心依据，然后进行比较。  
- 仅当两者的目标对象、调用目的、输入/参数流向以及最终结果方向一致时，才视为直接依据。  
- 即使看起来像相似的搜索候选，如果它不解释当前的 SOURCE_CODE 或不适用于当前的 SOURCE_CODE，则为“否”。

你是 JSONL 依据匹配判定器。

${question}

表格:
${table.label}

表格用途:
${table.purpose}

判定标准:
- ${firstRule}
- 要检查的 JSONL 字段: ${table.directFields.join(', ')}
- ${tableRules.join('\n- ')}
- ${decisionRules.join('\n- ')}
- 仅当出现 Godot、Godot3、Godot4、migration、2D、physics 等宽泛词汇时，视为无关。
- JSONL 中出现 “does not describe”、 “not related”、 “unrelated”、 “does not apply” 等否定表述的内容不被视为相关依据。
- 如果 JSONL 内容涉及其他 API、其他节点、其他系统，则为 “否”。
- 不要使用你已知的 Godot 知识，只使用 JSONL 中的字符串依据。
- 回答必须仅输出 “是” 或 “否” 其中之一。

JSONL_GENERATED_FROM_CODE_VERSION:
${sourceVersionKey}

VERIFY_TARGET_CODE_VERSION:
${targetVersionKey}

SOURCE_CODE:
${sourceCode}

JSONL:
${jsonlText}

你是用于 Godot RAG 测试的 JSONL 生成器。

目标: ${slotCase.goal}
目标表格: ${table.label}
表格用途: ${table.purpose}
直接匹配字段: ${table.directFields.join(', ')}

TEST_ITEM: ${itemTitle}
CODE_VERSION: ${versionLabel}

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode || '(Godot 3 代码生成后自动填写)'}

GODOT4_TARGET_CODE:
${targetCode || '(Godot 4 代码生成后自动填写)'}` : `SOURCE_CODE:
${sourceCode || '(代码生成后自动填写)'}`}