L'IA peut vous aider avec une ressource FiveM si vous traitez sa sortie comme un brouillon non fiable : définissez une petite tâche, fournissez le contrat actuel de Cfx.re ou du framework, examinez chaque ligne modifiée et testez la ressource sur un serveur de développement avant le déploiement. Elle ne peut pas vérifier votre fork privé du framework, votre schéma de base de données, vos licences, l'état du serveur ou le résultat de production, sauf si vous fournissez ces preuves.
Ne collez pas de secrets ou de données client dans une invite. Supprimez les clés de licence, les identifiants de base de données, les webhooks, les identifiants de joueur, les données de commande et le code source privé que vous n'êtes pas autorisé à divulguer. Le code généré ne prouve pas qu'une modification est sécurisée, compatible ou prête pour la production.
Choisissez une tâche qui peut être examinée
Les bonnes tâches ont une entrée étroite et un résultat testable : expliquez une erreur, ajoutez une validation à un événement, convertissez un manifeste obsolète, écrivez un test ciblé ou comparez une implémentation avec une interface officielle. « Construire mon serveur complet » cache trop d'hypothèses sur les ressources, l'ordre de démarrage, les versions du framework et la propriété des données.
- Indiquez la version exacte de la ressource, du runtime et du framework.
- Décrivez le comportement actuel et le comportement attendu.
- Incluez le code pertinent le plus concis et l'erreur exacte, pas l'intégralité du dépôt privé.
- Liez la documentation principale que la réponse doit suivre.
- Demandez un diff minimal, des hypothèses et une étape de retour en arrière.
Ancrez la réponse dans les contrats FiveM actuels
Pour les ressources Lua, commencez par la documentation officielle du runtime CfxLua et référence du manifeste de ressource. FiveM utilise CfxLua basé sur Lua 5.4 ; les nouvelles ressources utilisent fxmanifest.lua, et l'ancien chemin __resource.lua ne doit pas être présenté comme une valeur par défaut actuelle.
Les appels de framework doivent provenir de la version officielle que vous exécutez. ESX, QBCore et QBOX ne sont pas interchangeables, et un pont de compatibilité ne rend pas toutes les API identiques. Lorsque la documentation et la réponse générée divergent, arrêtez-vous et vérifiez la source ou les types installés.
Traitez les clients comme non fiables
Un assistant IA peut produire un événement réseau qui accepte des valeurs d'argent, d'objet, de rôle ou de coordonnées du client. C'est dangereux. Le guide de sécurité des événements Cfx.re explique que les clients peuvent déclencher des événements réseau et que les valeurs faisant autorité doivent être validées côté serveur. Vérifiez les permissions, l'état, l'inventaire, la position et les limites de débit sur le serveur avant de modifier des données protégées.
Vérifiez le diff avant de l'exécuter
- Portée : seuls les fichiers demandés et le comportement ont été modifiés.
- API : chaque fonction native, export, événement et clé de configuration existe dans la source principale pertinente.
- Frontière de confiance : les décisions côté serveur ne dépendent pas d'un droit ou d'un montant fourni par le client.
- Performance : les boucles rendent la main et n’effectuent pas d’opérations de base de données ou de réseau à chaque frame.
- Données : Les requêtes SQL sont paramétrées et les modifications de schéma utilisent le chemin de migration du projet.
- Opérations : les journaux ne contiennent pas de secrets ou d'identifiants de joueur inutiles.
- Licence : le code généré ou copié n'introduit pas de code ou de média que vous n'êtes pas autorisé à utiliser.
Testez une couche à la fois
- Sauvegardez la ressource et la configuration, puis utilisez un serveur de développement séparé.
- Exécutez les tests de syntaxe, de type et de projet qui existent déjà.
- Utilisez
refreshetensure resource-namedepuis la console du serveur uniquement pour la ressource prévue. Les commandes actuelles sont documentées dans la référence des commandes serveur de Cfx.re. - Vérifiez la console du serveur et la console client F8 pour les erreurs.
- Testez la réussite, les entrées invalides, les permissions manquantes, les requêtes répétées et l’indisponibilité d’une dépendance.
- Redémarrez le serveur une fois pour prouver l'ordre de démarrage et l'état persistant.
Utilisez l'IA pour la révision, pas comme preuve.
L'IA est utile pour expliquer une petite différence, énumérer les cas d'échec ou transformer un contrat officiel en une liste de contrôle. Elle n'établit pas qu'une ressource a été testée, qu'un benchmark a été amélioré ou qu'un problème de sécurité a été corrigé. Enregistrez les commandes et les résultats observés qui étayent ces affirmations. Si le résultat ne peut pas être reproduit, décrivez-le comme une proposition plutôt qu'un résultat vérifié.