2026年6月17日星期三2026 年 6 月 17 日
- 将 Godot 4 编码模型方向从单纯的 Q&A 学习重新整理为 SWE‑agent 轨迹学习的视角
- 认为仅靠小规模的 instruction Q&A 难以处理 “帮我做个地图” 之类的项目级请求
- 实际的编码代理需要包括仓库浏览、相关文件选择、代码修改、测试/验证、生成补丁等完整轨迹
- 用关键词记录
Long-context repository-level software engineering agent training、SWE-agent trajectory training
- 参考案例包括 SWE‑agent trajectories、SWE‑smith、SWE‑Gym、CoderForge‑Preview、ACC、RepoBench/CrossCodeEval/RepoCoder、aiXcoder CoLT、godot‑dodo、wallstoneai 数据集
- 用图片和文档记录 Godot LLM 开发整体路线图
- 将整体流程划分为
数据 -> 1 阶段 RAG 聊天机器人 -> SFT -> DPO -> SWE Agent 四个阶段
- 从 Stage 0 准备阶段到 Stage 6 持续改进，分别记录数据收集/结构化、1 阶段 RAG 聊天机器人、数据标注、模型训练、SWE Agent 开发、运营/再训练的流程
- 核心是先把 1 阶段 RAG 聊天机器人打造为 Godot 文档专家，再利用该机器人对 GitHub 数据进行标注/加工，随后进行模型训练并扩展到 SWE Agent
- 将基于 Godot RAG 判别器的数据生成结构以备忘录形式补充
- 不让 LLM 决定最终标签，而是让系统管道负责标签和验证的决定
- 让 LLM 只承担生成辅助角色，如修改代码、说明、SFT 问答、DPO 差评、补丁草案等
- 基于 API 映射 DB、官方文档向量 DB、标签原型 DB，记录符号抽取、检索、标签打分、JSONL 组装/验证的完整流程
- 将生成目标数据集归纳为 version classification、api mapping、migration fix、instruction SFT、DPO preference、repo explorer、patch generation、metadata verification 共 8 类
- 将 Godot RAG 判别器到 Qwen 3.6 编码模型的 MVP 开发流程单独记为备忘录
- 从准备
godot_docs_full.zip 原始文档、基于 chunk_docs.py 的首次分块、Godot 专用后处理、搭建本地检索基础设施的全过程记录
- 通过组合 Vector DB、Keyword Index、Reranker、API Mapping DB、Label Prototype DB，实现标签由系统决定的结构
- 将 GitHub 数据结构化后运行 RAG 判别器，LLM 仅承担修改代码/说明/QA 示例等生成辅助角色，明确职责划分
- 在首次 Qwen 3.6 SFT 中以 Godot 4 为主、输出 GDScript 基础、拒绝 Godot 3 API 为目标，随后通过 DPO 与 SWE 扩展的流程记录
- 为解决 GitHub 草稿（GitHub grass）显示问题，整理 Git 作者/邮箱设置
- 将全局 Git 配置改为
yyeongjin <appsky1888@gmail.com>
- 发现原
main 历史的 author/committer 邮箱混杂了本地主机邮箱、Naver 邮箱、GitHub noreply 等问题
- 将
main 历史的 author/committer 统一为 yyeongjin <appsky1888@gmail.com> 并推送到远程
- 重写前的状态保存在本地备份分支
backup/before-author-email-rewrite-2026-06-17 中
- 记录文档