idea_world_labDEV JOURNAL
Mittwoch, 17. Juni 2026

17. Juni 2026

  • Godot 4 Coding‑Modell‑Richtung wird nicht mehr als einfaches Q&A‑Lernen, sondern aus der Sicht des SWE‑Agent‑Trajektorien‑Lernens neu strukturiert

    • Es wird angenommen, dass allein kleine Instruction‑Q&A‑Aufgaben Anfragen wie „Erstelle eine Karte“ auf Projektebene nicht bewältigen können
    • Tatsächliche Coding‑Agenten benötigen eine Trajektorie, die Repository‑Durchsuchung, Auswahl relevanter Dateien, Code‑Änderungen, Test‑/Verifikation und Patch‑Erstellung umfasst
    • Als relevante Stichwörter werden Long-context repository-level software engineering agent training und SWE-agent trajectory training festgehalten
    • Als Referenzbeispiele werden SWE‑Agent‑Trajektorien, SWE‑smith, SWE‑Gym, CoderForge‑Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot‑dodo, wallstoneai‑Datensatz aufgeführt

  • Der gesamte Roadmap für die Entwicklung von Godot LLM wird in Bild‑ und Dokumentform festgehalten

    • Der Gesamtfluss wird in den Schritten Daten → 1. RAG‑Chatbot → SFT → DPO → SWE‑Agent strukturiert
    • Von Vorbereitung Stufe 0 bis kontinuierlicher Verbesserung Stufe 6 wird unterschieden; dabei werden Daten‑Erfassung/‑Strukturierung, 1. RAG‑Chatbot, Daten‑Labeling, Modell‑Training, SWE‑Agent‑Entwicklung sowie Betrieb/‑Retraining dokumentiert
    • Der Kern besteht darin, zuerst den 1. RAG‑Chatbot zum Godot‑Dokumentations‑Experten zu machen, diesen Chatbot zur Kennzeichnung/Verarbeitung von GitHub‑Daten zu nutzen und anschließend das Modell‑Training sowie den SWE‑Agent auszubauen

  • Die auf dem Godot RAG‑Detektor basierende Daten‑Generierungsstruktur wird als Notiz ergänzt

    • Die endgültige Label‑Entscheidung wird nicht dem LLM überlassen, sondern das System‑Pipeline bestimmt Label und Validierung
    • Das LLM übernimmt nur unterstützende Generierungsaufgaben wie geänderten Code, Erklärungen, SFT‑Fragen/‑Antworten, schlechte DPO‑Antworten, Patch‑Entwürfe usw.
    • Der Ablauf wird anhand von API‑Mapping‑DB, offizieller Dokumentations‑Vektor‑DB und Label‑Prototype‑DB beschrieben: Symbol‑Extraktion → Suche → Label‑Scoring → JSONL‑Zusammenstellung/‑Validierung
    • Die zu erzeugenden Datensätze werden in acht Kategorien eingeteilt: Versionsklassifikation, API‑Mapping, Migrations‑Fix, Instruction‑SFT, DPO‑Präferenz, Repository‑Explorer, Patch‑Generierung, Metadaten‑Verifikation

  • Der MVP‑Entwicklungsfluss vom Godot RAG‑Detektor zum Qwen 3.6‑Coding‑Modell wird separat notiert

    • Der Ablauf von der Vorbereitung des Originaldokuments godot_docs_full.zip über das erste Chunking mit chunk_docs.py, Godot‑spezifische Nachbearbeitung bis zum Aufbau einer lokalen Such‑Infrastruktur wird dokumentiert
    • Durch Kombination von Vector‑DB, Keyword‑Index, Reranker, API‑Mapping‑DB und Label‑Prototype‑DB wird ein System geschaffen, das die Labels selbst bestimmt
    • Nach Strukturierung der GitHub‑Daten wird der RAG‑Detektor ausgeführt; das LLM übernimmt nur noch unterstützende Rollen wie geänderten Code, Erklärungen oder QA‑Beispiele
    • Im ersten Qwen 3.6‑SFT‑Durchlauf liegt der Fokus auf Godot 4‑Denken, Grundausgabe von GDScript und Ablehnung von Godot 3‑APIs; anschließend folgt die Erweiterung zu DPO und SWE

  • Zur Lösung des Problems mit der GitHub‑Grass‑Anzeige werden Git‑Author/Email‑Einstellungen festgehalten

    • Die globale Git‑Konfiguration wird zu yyeongjin <appsky1888@gmail.com> geändert
    • Es wurde festgestellt, dass in der bestehenden main‑Historie die Author‑/Committer‑E‑Mails gemischt waren (lokaler Host, Naver‑E‑Mail, GitHub‑noreply usw.)

  • main-Verlauf's author/committer zu yyeongjin <appsky1888@gmail.com> vereinheitlichen und auf Remote anwenden

    • Den Zustand vor dem Umschreiben im lokalen Backup-Branch backup/before-author-email-rewrite-2026-06-17 speichern

  • Dokumentation