Le 28 juin, j’ai créé manuellement des morceaux de code Godot et des JSONL avec le chatbot Qwen, puis effectué des validations « oui/non » à la main
Cette méthode a permis de vérifier la faisabilité, mais à mesure que le nombre d’éléments augmente, le copier‑coller et la comparaison des résultats deviennent très lourds
En particulier, les trois tables docs_chunks, api_mapping, label_prototypes doivent toutes être testées ; si la syntaxe est commune, 6 slots sont nécessaires, sinon 12 slots, rendant la gestion manuelle rapidement très complexe
L’outil charge un échantillon de 50 éléments de test Godot, et pour chaque élément Qwen doit d’abord les étiqueter comme syntaxe commune ou séparation Godot 3/4
Si c’est une syntaxe commune, un seul code commun est généré
En cas de différence de version, les codes Godot 3 et Godot 4 sont générés séparément
Ensuite, les slots JSONL sont automatiquement constitués pour chaque table
J’ai confirmé que l’on ne peut pas simplement regrouper docs_chunks, api_mapping et label_prototypes sous un même « oui/non »
docs_chunks sert de justification de description de code, donc si le code correspond directement, la réponse est « oui »
api_mapping et label_prototypes sont des justifications de source de migration ; souvent, le code déjà appliqué à Godot 4 ou la syntaxe commune donne une réponse « non »
Ainsi, les noms de slots ont été divisés en : « justification de description », « description non pertinente », « conversion nécessaire », « déjà appliqué », « commun/inutile », « conversion non pertinente »
Le changement le plus important lors de la création de l’outil a été la séparation du « code de génération JSONL » et du « code cible de validation »
Au départ, les JSONL générés à partir de code Godot 3 étaient validés uniquement avec le code Godot 3, et ceux de Godot 4 uniquement avec le code Godot 4
En pratique, il faut aussi vérifier que le JSONL basé sur Godot 3 donne bien « non » lorsqu’il est appliqué au code Godot 4
J’ai donc ajouté des boutons séparés « validation code Godot 3 » et « validation code Godot 4 » pour chaque slot, et les résultats sont enregistrés séparément
Après la création de l’outil, la productivité de développement a nettement changé
Auparavant, je devais demander à Qwen le code et le JSONL à chaque fois, les coller dans le prompt, les valider, puis comparer mentalement la réponse attendue
Désormais, la sélection d’éléments, l’étiquetage, la génération de code, la création de JSONL, la validation croisée Godot 3/4, et la visualisation du prompt/réponse brute se font sur un seul écran
Plutôt que de produire rapidement en grande quantité, le plus important est de savoir quel critère a été utilisé et sur quel code la validation a eu lieu, évitant toute confusion
En répétant les 50 tests, l’état mental à retenir diminue, ce qui permet de repérer plus rapidement les schémas d’échec
Grâce à cet outil, on peut voir directement à l’écran quel prompt est envoyé, l’ordre d’appel de la génération/validation massive de JSONL, et comment les prompts de validation et de requête sont construits
Les réponses attendues sont fixées selon l’étiquetage et le type de slot, de sorte que le critère « oui/non » ne prête pas à confusion
Les résultats s’affichent immédiatement par slot, facilitant l’identification rapide du code et du JSONL qui ont échoué
Même si un échec provient du prompt, le prompt utilisé reste visible, simplifiant les ajustements ultérieurs
Maintenant que l’outil est partiellement réalisé, je prévois de ralentir le rythme, de ne pas forcer l’augmentation du volume, mais d’affiner progressivement les critères de validation