AI IDE List
ブログへ戻る
目次8 セクション

Dieser Leitfaden basiert auf dem Stand von September 2026. Preise, Modelle und Oberflächenbezeichnungen können sich ändern; die Informationen sind keine Live-Daten.

Gib Agenten hilfreiche Projektvorgaben, ohne jede Eingabe zur Spezifikation zu machen.

Überprüfbare Regeln schreiben

Beginne mit Prüfkommandos, wichtigen Quellverzeichnissen und wenigen Architekturvorgaben. „Nutze die vorhandene Formularvalidierung“ ist konkreter als „Schreibe sauberen Code“. Dies sind Empfehlungen; Dateinamen und Aktivierungsregeln unterscheiden sich je Werkzeug.

Eine erste Anweisung

Passe das Beispiel an dein Repository an und speichere es über die dokumentierte Regel- oder Anweisungsfunktion.

Before editing, inspect the nearest existing implementation.
Use the package manager already configured in this repository.
Run the relevant checks for changed behavior.
Report any check you could not run and why.
Do not edit generated output directly.

Prüfen, ob eine Regel greift

Teste eine kleine Aufgabe, bei der die Regel eine sichtbare Handlung verändert. Prüfe Ausgabe und Befehle und grenze die Regel ein, falls sie bei fremden Aufgaben greift. Pflege Regeln wie Build-Anweisungen zusammen mit dem Repository.

Die erste vollständige Aufgabe: ändern, prüfen, begutachten

  1. Wählen Sie ein kleines Repository mit funktionierendem Build. Speichern Sie einen sauberen Git-Stand und den derzeit erfolgreichen Prüfkommando als Ausgangsbasis.

  2. Beschreiben Sie ein sichtbares Ergebnis, etwa ein Pflichtfeld in einem bestehenden Formular. Nennen Sie Dateien, vorhandene Validierung und unverändert zu lassendes Verhalten.

  3. Prüfen Sie vor der Bearbeitung einen kurzen Plan: betroffene Komponenten, Datenfluss und Prüfschritte. Ergänzen Sie fehlenden Kontext zuerst.

  4. Prüfen Sie Diffs in kleinen Schritten, einschließlich Abhängigkeiten, generierter Dateien, Umgebungsvariablen und Fehlerbehandlung. Testen Sie Erfolgs- und Fehlerfälle.

  5. Notieren Sie das akzeptierte Ergebnis, Prüfaufwand und Verbrauch. Wiederholen Sie dies mit einer zweiten typischen Aufgabe, bevor Sie Tarif oder Teamumstieg festlegen.

Vorlage für eine Aufgabenbeschreibung

Ziel: für Nutzer sichtbare Änderung.
Kontext: relevante Dateien und bestehende Umsetzung.
Grenzen: öffentliche API und Abhängigkeiten beibehalten.
Prüfung: Projektprüfungen und Fehlerfälle ausführen.
Abschluss: geänderte Dateien, Prüfungen und verbleibende Grenzen nennen.

Wenn das Ergebnis nicht funktioniert

Eine erfolgreiche Antwort beweist keinen funktionierenden Code. Bei falschen Dateien grenzen Sie die Aufgabe ein und nennen den Einstiegspunkt. Befehle im gleichen Terminal reproduzieren. Bei MCP Start, Zugangsdaten und Clientkonfiguration getrennt prüfen. Bei Verbrauchslimits zuerst Guthaben und Modell kontrollieren. Halten Sie Patches klein und separat rücksetzbar.

Häufige Fragen vor dem Wechsel

Bedeutet ein Abonnement unbegrenzte Agentennutzung?

Nein. Preis, enthaltene Nutzung, Modellzugriff und Mehrverbrauch sind getrennt. Unbegrenzte Vervollständigung bedeutet keine unbegrenzten Modellanfragen.

Soll ich alle MCP-Server anschließen?

Beginnen Sie mit der benötigten Integration. Prüfen Sie Start, Werkzeuge und Kontextumfang vor weiteren Verbindungen.

Wie vergleiche ich zwei Editoren?

Mit demselben Repository, derselben Aufgabe und denselben Prüfkriterien. Vergleichen Sie korrekte Änderungen, Prüfaufwand, Einrichtung und Verbrauch.

Weitere TRAE-Anleitungen

この記事を共有
XFacebookLinkedInRedditHacker News