Godot 源码分析评分化架构
编写日期：2026年 6月 25日
目的
利用 Godot 官方文档 RAG 将 GitHub 源码按项目单元进行分类，并整理后续 SFT/DPO 数据生成的流程。
本次整理的核心是将 docs_chunks、api_mapping、label_prototypes 都作为同一官方文档 Markdown → JSONL 分类的对象。根据文档性质，将说明块放入 docs_chunks，函数名/类名/符号名的变更放入 api_mapping，函数使用方式/参数构成/调用模式的整体变更放入 label_prototypes。
当前结论
在初始官方文档收集阶段需要准备的核心表格如下三张。
| 表格 | 作用 |
|---|---|
docs_chunks |
官方文档说明正文、教程、class reference 块的存储对象 |
api_mapping |
保存 Godot 3 → Godot 4 中函数名、类名、符号名如何变化的对象 |
label_prototypes |
保存函数使用方式、参数构成、调用模式整体变更时该如何编写的对象 |
| 项目 | 整理 |
|---|---|
| 既有混乱 | 起初把三个表格当作拥有不同工作流的东西来考虑。 |
| 新边界 | 三个表格都是在将官方文档 Markdown 分类为 JSONL 时使用的存储对象。 |
| 当前优先级 | 按原计划保留三张表格，并根据文档性质将其分类存储为一个或多个 JSONL。 |
最终分析单元
输入为 GitHub 项目或本地项目目录。
分析器遍历文件系统，按 AST 或代码片段单元拆分 Godot 相关文件。
初始对象：
| 文件 | 用途 |
|---|---|
.gd |
GDScript AST/行/函数单元分析 |
.tscn, .tres |
场景/资源中的 class、script、node type 线索提取 |
project.godot |
项目版本、特性、渲染器、autoload 等项目线索提取 |
| README/文档 | 项目说明和 Godot 版本提示辅助 |
按需 LLM 调用流程
LLM 并非始终保持开启，而是根据需要的 AST/代码片段按需调用。
每个 AST 片段会连同以下依据一起传递给 LLM。
AST/代码块
+ 所需官方文档 JSONL 搜索结果
+ 输出 JSONL 模式
+ 项目/文件 标识 信息LLM 响应模式和 score DB 保存列尚未确定。当前文档仅记录在什么流程中搜索哪些表，以及其结果如何用于文件系统分类。
代码说明生成数据流
在代码说明生成中，docs_chunks 是核心依据。
流程：
用户输入“这是什么意思？”以及源代码。
AST 解析器将代码划分为代码片段。
检索器在
docs_chunks中搜索相关的官方文档。Qwen 3.6 验证提示、代码片段和检索依据是否相互关联。
丢弃不相关的检索结果。
将相关的依据和代码片段重新传递给 Qwen 3.6，生成说明 JSONL。
验证器对响应进行验证。
将验证后的结果保存到 score DB。
根据 score DB 的结果对文件系统进行分类。
Godot 3 -> Godot 4 函数名转换流程
在迁移过程中，api_mapping 是核心依据。
流程：
- 用户输入 “这需要转换吗？” 和源代码。
- AST Parser 提取 Godot API 候选符号。
- Retriever 在
api_mapping中搜索 source API、target API、change type。 - Qwen 3.6 验证搜索结果是否实际与该代码片段相关。
- 废弃不相关的映射。
- 仅使用相关的映射生成 Godot 3 -> 4 迁移 JSONL。
- Validator 验证转换响应。
- 将验证后的结果存入 score DB。
- 根据 score DB 的结果对文件系统进行分类。
Godot 3 -> Godot 4 使用模式转换流程
在使用模式转换中，label_prototypes 是核心依据。
流程：
- 用户输入 “这需要转换吗？” 和源代码。
- AST 解析器提取函数调用、参数构成、调用模式候选项。
- 检索器在
label_prototypes中搜索使用方式/参数/调用模式转换的依据。 - Qwen 3.6 验证搜索结果是否实际与该代码片段相关。
- 将不相关的原型废弃。
- 仅使用相关的原型生成 Godot 3 → 4 使用模式转换的 JSONL。
- 验证器对转换响应进行校验。
- 将验证后的结果存入 score DB。
- 根据 score DB 的结果对文件系统进行分类。
Score DB
AST 片段的 Retriever 搜索结果、LLM 验证结果、Validator 通过结果最终会保存到 score DB 中。
score DB 并不是保存学习数据原本，而是用于文件系统分类的判断结果存储。记录在源码分析过程中产生的 Retriever、LLM、Validator 结果。
docs_chunks搜索结果：在代码说明请求中验证官方文档依据是否与实际代码相关的结果api_mapping搜索结果：验证 Godot 3 → Godot 4 函数名/符号转换依据是否与实际代码相关的结果label_prototypes搜索结果：验证函数使用方式、参数构成、调用模式转换依据是否与实际代码相关的结果
score DB 的列、汇总方式、分类标签尚未确定。本文档中仅固定 score DB 为“收集分类前判断结果的存储库”这一角色。
最终文件系统分类：
project source
-> AST/code chunks
-> official docs JSONL retrieval
-> on-demand LLM verification
-> score DB
-> classified filesystemSFT和DPO生成
SFT和DPO的详细设计尚未确定。目前确定的是score DB本身不是学习数据源。首先对文件系统进行分类，之后将基于已分类的文件系统制作用于设计SFT和DPO的来源。
Git 上传安全标准
在本次文档中，网页 UI、本地转换脚本、AST 分析脚本、API 密钥、JSONL 输出物、测试源代码均不上传。
允许上传：
- 架构文档
- 流程图图片
- 可公开的回顾/路线图文本
禁止上传：
- Streamlit Web 应用代码
- Markdown -> JSONL 转换实验脚本
- Retriever/AST 分析实验脚本
- API key, endpoint,
.env - 收集的完整 Markdown 原始 zip
- AST/code chunk 分析结果
- JSONL 中间产出物
- 用于测试克隆的外部 Godot 项目源码