Die Idee

Ein Prompt besteht aus der Anweisung und dem relevanten Kontext, die du einem KI-Modell gibst. Bei einer Coding-Aufgabe benennt „Repariere den Parser“ zwar ein Ziel. Es sagt aber nicht, wie weit das Modell gehen darf, wann es pausieren soll oder welcher Nachweis die Arbeit abschließt.

Diese fehlenden Angaben sind wichtig, wenn ein Tool ein Repository untersuchen oder verändern kann. Mit dem Umfang legst du den erlaubten Arbeitsbereich fest. Mit Abschlusskriterien benennst du das Ergebnis, das vor dem Abschluss vorliegen muss. Lege außerdem eine Regel für Rückfragen fest: Bei welchen Entscheidungen brauchst du deine Zustimmung?

Einfach gesagt: Sage dem Modell nicht nur, was es ändern soll, sondern auch, wo es aufhören und wie es die funktionierende Änderung nachweisen soll.

Dieses Prompting-Muster ist für Entwickler-Tools allgemein nützlich. Für Claude Sonnet 5.5 ist es besonders relevant. Anthropic dokumentiert, dass das Modell bei längeren agentischen Coding-Aufgaben mit niedrigem oder mittlerem Effort früher stoppen und nachfragen kann. Höherer Effort oder offene Aufgaben können dagegen zu ungefragten Ergänzungen führen. Die Anleitung empfiehlt, ausdrücklich festzulegen, wann weitergearbeitet und wann gestoppt werden soll, und keine ungefragten Features, Tests, Dateien, Dokumentation oder Refactorings hinzuzufügen. Quelle

Eine Effort-Einstellung ist eine Modellsteuerung, die die Verarbeitungstiefe beeinflusst. Für Sonnet 5.5 beschreibt Anthropic Effort als Steuerung der Verarbeitungstiefe und weist darauf hin, dass derselbe Wert nicht dieselbe Menge an Verarbeitung wie bei Sonnet 5 erzeugt. Betrachte eine übernommene Einstellung deshalb als etwas, das du erneut testen musst, nicht als festes Etikett. Quelle

Ein System-Prompt ist eine Anweisung, die eine Anwendung auf Systemebene bereitstellt. Dort passen stabile Teamregeln hin, etwa nur vor notwendigen oder riskanten Schritten nachzufragen. Dein Aufgaben-Prompt enthält dann das aufgabenspezifische Ziel und die Grenzen.

Ein kleines Beispiel

Beispiel — hypothetische Aufgabe: Du möchtest ein KI-Coding-Tool einen Parser-Fehler beheben lassen, durch den ein gültiges Datumsformat abgelehnt wird.

Eine vage Anfrage lautet: „Repariere den Datumsparser und stelle sicher, dass er funktioniert.“ Das Tool muss raten, ob es verwandte Module ändern, eine neue Test-Suite hinzufügen, Dokumentation umschreiben oder angrenzenden Code aufräumen darf.

Eine klar begrenzte Anfrage lautet:

Ändere nur den Datumsparser, damit er YYYY/MM/DD akzeptiert. Ändere weder Aufrufer noch öffentliche APIs. Frage vor jeder riskanten oder notwendigen Entscheidung außerhalb dieser Datei. Ergänze keine Features, Dateien, Dokumentation, Tests oder Refactorings, außer sie sind für diesen Fix erforderlich. Führe die vorhandenen Parser-Tests aus und berichte Befehl und Ergebnis. Stoppe, nachdem du die geänderte Datei und das Testergebnis genannt hast.

Die Anfrage hat vier Teile:

  1. Ziel: Ein Format akzeptieren.
  2. Umfang: Nur der Datumsparser; keine Änderungen an Aufrufern oder APIs.
  3. Entscheidungsregel: Vor Arbeit außerhalb dieser Grenze nachfragen.
  4. Nachweis: Vorhandene Parser-Tests ausführen und das Ergebnis berichten.

Der letzte Teil ist die Verifikation: eine echte Prüfung, die testet, ob die gewünschte Änderung funktioniert. Anthropic empfiehlt, vor der Meldung, eine Codeänderung sei abgeschlossen, eine passende echte Prüfung auszuführen, etwa Tests, Type-Checking, einen Build oder den geänderten Befehl. Quelle

Probier es aus

Nimm eine kleine Aufgabe aus deiner aktuellen Arbeit. Wandle sie in fünf Minuten in eine klar begrenzte Anfrage um.

Schreibe zuerst einen Satz zur gewünschten Änderung. Ergänze dann eine explizite Grenze: Welche Dateien, Module oder öffentlichen Schnittstellen dürfen sich nicht ändern? Füge danach eine Rückfrage-Regel hinzu, zum Beispiel: „Frage vor einer Änderung an einer Abhängigkeit.“ Benenne schließlich einen Befehl oder Check, der ausgeführt werden soll, und lege fest, was der Abschlussbericht enthalten muss.

Nutze diese Vorlage:

Ändere . Verändere nur . Mache nicht . Frage vor . Prüfe mit . Berichte und stoppe dann.

Beginne mit einer Aufgabe, die du leicht prüfen kannst. Vergleiche den entstandenen Diff mit der von dir formulierten Grenze. Wenn das Tool mehr geändert hat als verlangt, formuliere die Grenze beim nächsten Mal konkreter.

Darauf solltest du achten

Ein präziser Prompt ist keine Garantie für Korrektheit. Prüfe den Diff, bewerte die Begründung für riskante Änderungen und kontrolliere die tatsächliche Ausgabe von Tests, Type-Checking oder Builds.

Gehe nicht davon aus, dass ein Effort-Wert zwischen Modellen oder Versionen übertragbar ist. Anthropic rät ausdrücklich dazu, Effort-Einstellungen für Sonnet 5.5 neu zu bewerten, statt Einstellungen von Sonnet 5 unverändert zu übernehmen. Quelle

Nutze außerdem modellbezogene Hinweise vor allgemeinem Rat. Anthropic empfiehlt in seiner allgemeinen Anleitung, zuerst die modellbezogene Prompting-Dokumentation zu verwenden und danach klare Anweisungen, Beispiele, strukturierte Abschnitte und ein passendes Tool-Design einzusetzen. Quelle