KI sicher für die FiveM-Serverentwicklung nutzen

KI kann bei einer FiveM-Ressource helfen, wenn du ihre Ausgabe als ungeprüften Entwurf behandelst: Definiere eine kleine Aufgabe, stelle die aktuellen Cfx.re- oder Framework-Schnittstellenvorgaben bereit, prüfe jede geänderte Zeile und teste die Ressource vor der Bereitstellung auf einem Entwicklungsserver. KI kann deinen privaten Framework-Fork, dein Datenbankschema, Lizenzen, den Serverstatus oder das Produktionsergebnis nicht überprüfen, wenn du diese Nachweise nicht bereitstellst.

Wähle eine Aufgabe, die überprüft werden kann

Gute Aufgaben haben eine enge Eingabe und ein testbares Ergebnis: Erkläre einen Fehler, füge eine Validierung für ein Ereignis hinzu, konvertiere ein veraltetes Manifest, schreibe einen fokussierten Test oder vergleiche eine Implementierung mit einer offiziellen Schnittstelle. „Baue meinen vollständigen Server“ verbirgt zu viele Annahmen über Ressourcen, Startreihenfolge, Framework-Versionen und Datenbesitz.

1. Gib die genaue Ressource, Laufzeit und Framework-Version an.
2. Beschreibe das aktuelle und das erwartete Verhalten.
3. Füge den kleinsten relevanten Code und den genauen Fehler hinzu, nicht das gesamte private Repository.
4. Verlinke die primäre Dokumentation, der die Antwort folgen muss.
5. Bitte um einen minimalen Diff, Annahmen und einen Rollback-Schritt.

Stütze die Antwort auf aktuelle FiveM-Schnittstellenvorgaben

Für Lua-Ressourcen beginne mit der offiziellen CfxLua-Laufzeitdokumentation und Ressourcenmanifestreferenz. FiveM verwendet CfxLua, das auf Lua 5.4 basiert; neue Ressourcen verwenden fxmanifest.lua, und der alte __resource.lua Pfad sollte nicht als aktueller Standard dargestellt werden.

Framework-Aufrufe müssen aus der offiziellen Version stammen, die du ausführst. ESX, QBCore und QBOX sind nicht austauschbar, und eine Kompatibilitätsbrücke macht nicht jede API identisch. Wenn die Dokumentation und die generierte Antwort nicht übereinstimmen, stoppe und überprüfe die installierte Quelle oder die Typen.

Behandle Clients als nicht vertrauenswürdig

Ein KI-Assistent kann ein Netzwerkereignis erzeugen, das Geld-, Artikel-, Rollen- oder Koordinatenwerte vom Client akzeptiert. Das ist unsicher. Der offizielle Cfx.re-Leitfaden zur Sicherheit von Events erklärt, dass Clients vernetzte Ereignisse auslösen können und dass autoritative Werte serverseitig validiert werden müssen. Überprüfe Berechtigungen, Status, Inventar, Position und Ratenbegrenzungen auf dem Server, bevor du geschützte Daten änderst.

Überprüfe den Diff, bevor du ihn ausführst

• Umfang: nur angeforderte Dateien und Verhalten geändert.
• APIs: Jede native Funktion, jeder Export, jedes Ereignis und jeder Konfigurationsschlüssel existiert in der relevanten primären Quelle.
• Vertrauensgrenze: Serverseitige Entscheidungen basieren nicht auf einer vom Client bereitgestellten Berechtigung oder Menge.
• Leistung: Schleifen geben die Ausführung zwischendurch an den Scheduler ab und führen nicht in jedem Frame Datenbank- oder Netzwerkoperationen aus.
• Daten: SQL ist parametrisiert und Schemaänderungen nutzen den Migrationspfad des Projekts.
• Betrieb: Logs enthalten keine Geheimnisse oder unnötigen Spieler-Identifikatoren.
• Lizenz: Generierter oder kopierter Code führt keinen Code oder keine Medien ein, für deren Verwendung du keine Berechtigung hast.

Teste jeweils eine Ebene

1. Sichere die Ressource und die Konfiguration, dann verwende einen separaten Entwicklungsserver.
2. Führe Syntax-, Typ- und Projekttests aus, die bereits existieren.
3. Verwende refresh und ensure resource-name nur über die Serverkonsole und nur für die vorgesehene Ressource. Die aktuellen Befehle sind hier dokumentiert: Cfx.re Server-Befehlsreferenz.
4. Überprüfe die Serverkonsole und die F8-Clientkonsole auf Fehler.
5. Teste Erfolg, ungültige Eingaben, fehlende Berechtigungen, wiederholte Anfragen und die Nichtverfügbarkeit einer Abhängigkeit.
6. Starte den Server einmal neu, um die Startreihenfolge und den persistenten Zustand zu überprüfen.

Nutze KI zur Überprüfung, nicht als Beweis

KI kann kleine Diffs erklären, Fehlerfälle aufzählen oder offizielle Schnittstellenvorgaben in eine Checkliste übertragen. Sie belegt jedoch nicht, dass eine Ressource getestet, ein Benchmark verbessert oder ein Sicherheitsproblem behoben wurde. Halte die Befehle und beobachteten Ergebnisse fest, die solche Aussagen stützen. Beschreibe ein nicht reproduzierbares Ergebnis als Vorschlag statt als verifiziertes Resultat.