Opus 4.7 scheint deine Prompts kaputt gemacht zu haben. Hat es nicht. Du hast nur die 2 wichtigen Umschreibungen übersehen.

Jedes Mal, wenn ein neues LLM erscheint, lese ich das Changelog. (Ich bin der Typ, der das Handbuch für einen neuen Rasentrimmer liest. 🤓) So habe ich bemerkt, dass mit der Opus 4.7-Panik etwas nicht stimmte.

TLDR. Falls du gerade auf 4.7 upgegradet hast, werden zwei Muster in deinen aktuellen Prompts tatsächlich kaputtgehen. Ich zeige dir, was ich in meiner Prod gefixt habe und wie du es auf dein Setup anpasst. Alles andere, was dir über "alle Prompts überprüfen" erzählt wird, ist Rauschen aus denselben vier Bullet Points.

Die Anthropic-Doku sagt eine Zeile, die niemand weitergibt: Prompts, die für 4.6 geschrieben wurden, laufen sehr gut auf 4.7 out of the box. Dieselbe Doku sagt auch explizit, wo sie es nicht tun. An zwei spezifischen Stellen. Nicht sechzehn. Nicht acht. Ich werde sie benennen, erklären warum 4.7 sie triggert, und dir zeigen, wie du deine CLAUDE.md und System-Prompts in zwei Zeilen patchst.

Ich lese Handbücher. Deshalb wusste ich, dass der Tweet falsch war.

16. April. Opus 4.7 droppt. Innerhalb von zwei Stunden ist mein Feed voller üblicher Verdächtiger: "Alles hat sich geändert", "Du musst alle deine Prompts überprüfen", "Das neue Modell ist ein anderes Biest". Nach drei Stunden landen die ersten Migration Guides. Eine Flut davon in dieser Woche. Alle kopieren dieselben vier Bullet Points aus der Anthropic-Doku, umformuliert für die Haussprache.

Während das passierte, war ich auf der Doku-Seite. Nicht auf Twitter. (Gib zu, du hast auch zuerst Twitter gecheckt.)

Drei Seiten sind wichtig: der Migration Guide, die "What's New"-Seite und die Prompting Best Practices-Seite. Lies sie in dieser Reihenfolge. Die erste sagt dir, was sich im Verhalten geändert hat. Die zweite gibt dir das echte Changelog, Tokenizer inklusive. Die dritte versteckt die Zeile, die 90% der Panik zunichtemacht. Ein Satz, vergraben in den Prompting Best Practices, der im Grunde sagt: 4.7 performt gut out of the box bei bestehenden 4.6-Prompts.

Das ist nicht "manche Prompts sind okay". Das ist nicht "du musst vielleicht nicht umschreiben, wenn du Glück hast". Das ist der Hersteller des Modells, der dir sagt: die Standard-Annahme ist, dass deine alten Prompts funktionieren. Die Migration Guides, die du liest, sind aus der gegenteiligen Annahme geschrieben. Und die Lücke zwischen diesen beiden Positionen ist, wo all die schlechten Ratschläge leben.

Also wird die Frage zur richtigen. Nicht "was schreibe ich um?". Die richtige ist: wo genau hört 4.7 auf, sich wie 4.6 zu verhalten, und warum? Die Doku beantwortet das. An zwei Stellen.

Der Mechanismus: 4.6 hat dich gedeckt

4.6 war kein dummer Textgenerator. Es war ein kooperativer. Wenn du einen Prompt geschrieben hast, der technisch unvollständig war, hat 4.6 stillschweigend die Lücken für dich gefüllt. Zwei Arten von Lücken, spezifisch.

Erste Art: implizite Tool-Calls. Du hast "prüfe die Projektstruktur vor Änderungsvorschlägen" in deine CLAUDE.md geschrieben. 4.6 würde einen Glob- oder Read-Call vor der Antwort einbauen, obwohl deine Anweisung das technisch nicht verlangte. Das Wort "prüfe" könnte "tatsächlich ein Tool aufrufen" oder "mental betrachten" bedeuten. 4.6 wählte die erste Lesart. Meistens.

Zweite Art: impliziter Scope und Ausnahmen. Du hast "warne den Kunden einmal pro Conversation über Lieferverzögerungen" geschrieben. 4.6 verstand "einmal, aber wieder aufgreifen, wenn eine wirklich neue Bestellung in der Session auftaucht". Du hast "niemals Ausrufezeichen verwenden" geschrieben. 4.6 wendete es auf generierten Prosatext an, aber nicht auf Code-Blöcke oder zitierte Review-Inhalte, weil Interpunktion aus wörtlichen Reviews zu entfernen absurd wäre. Wer editiert eine Fünf-Sterne-Kundenbewertung? 4.6 hat die Grenze selbst abgeleitet.

4.7 macht beides nicht. Es liest deine Anweisung wörtlich. Wenn du nicht "du MUSST das Tool aufrufen" gesagt hast, liest es "prüfe" als "betrachte". Wenn du "einmal pro Conversation" ohne Ausnahmenliste geschrieben hast, wendet es "einmal" an und macht weiter, neue Bestellung hin oder her.

Anthropic dokumentiert das im Migration Guide ohne Beschönigung: das Modell wird eine Regel nicht stillschweigend von einem Fall auf einen ähnlichen erweitern, und es wird nicht bei Anfragen raten, die du nicht tatsächlich gestellt hast. Das ist die Änderung. Das ist die gesamte Änderung. Der Rest (schnelleres Reasoning, weniger Standard-Tool-Calls, direkterer Ton) fließt alles aus dieser einen Haltungsänderung.

Was bedeutet, dass deine Prompts nicht kaputtgegangen sind. Sie waren schon immer unvollständig. 4.6 hat die Löcher im laufenden Betrieb gepatcht, und 4.7 hört auf zu patchen.

Andere Write-ups bestätigen den Mechanismus aus verschiedenen Winkeln. Ein Deep-Dive bemerkt, dass schwache Prompts, die von 4.6 übertüncht wurden, jetzt als sichtbare Lücken auftauchen. Dieselbe Schlussfolgerung, anderes Framing. Der nützliche Teil ist, dass es genau zwei Stellen gibt, wo die Lücken wichtig genug sind zum Umschreiben.

Rewrite #1: Tool-Calls, die Vorschläge waren

Öffne jetzt deine CLAUDE.md. Ich warte.

Scanne sie nach Verben, die actionable klingen, aber nicht bindend sind. "Prüfe". "Betrachte". "Schaue dir an". "Überprüfe". Jedes davon ist aus 4.7s Sicht ein Vorschlag. Wenn die Aktion load-bearing ist, also der nächste Schritt tatsächlich vom Tool-Output abhängt, hast du gerade einen stillen Fehlermodus eingeführt.

Konkretes Beispiel aus meiner eigenen CLAUDE.md, bereinigt damit es generisch lesbar ist. Ich hatte eine Regel, die sagte "vor Code-Änderungsvorschlägen die aktuelle Projektstruktur prüfen". Auf 4.6 produzierte das jedes Mal einen Glob-Call. Claude listete Dateien auf, sah was da war, schlug dann Änderungen vor, die im echten Zustand begründet waren. Auf 4.7, dieselbe Regel, derselbe Prompt, kein Glob. Claude schlug Änderungen aus dem Gedächtnis vor. Manchmal richtig. Manchmal komplett out of sync mit dem Repo, weil der Session-Kontext veraltet war und das Verb "prüfe" keinen Tool-Call erzwang.

Kein Bug. Literalismus. "Prüfe" kann "Tool aufrufen" oder "darüber nachdenken" bedeuten. 4.7 defaultet zu "darüber nachdenken". Der Fix braucht zwei Zeilen.

Ersetze die weiche Anweisung mit einer harten. Anstatt:

Vor Änderungsvorschlägen die aktuelle Projektstruktur prüfen.

Schreibe:

Vor jedem Code-Vorschlag MUSST du Glob aufrufen, um die aktuelle Projektstruktur zu listen. 
Verlasse dich nicht auf vorherigen Session-Kontext für die Dateistruktur.

Drei Unterschiede. "MUSST" statt weiches Verb. Benanntes Tool statt generische Aktion. Explizite Negation des Fallback-Verhaltens, was das Schlupfloch schließt.

Das gilt überall, wo ein Tool-Call load-bearing ist. Dein Agent trifft eine Partner-API bevor er entscheidet? Benenne den API-Call. Dein Support-Bot liest den täglichen Distributor-CSV-Feed? Benenne den File-Read. Dein WooCommerce-Assistent fragt User-Records ab vor der Antwort? Benenne das Database-Tool. Jedes Mal, wenn die Daten aus einem Live-Call kommen müssen, muss der Call im Text des Prompts nicht-optional sein, nicht im Kopf der Person, die ihn geschrieben hat.

Caveat, das es wert ist hier zu verteilen, nicht am Ende: dieser Fix ist nur wichtig, wenn der Tool-Call load-bearing ist. Wenn es dir egal ist, ob Claude das Tool aufruft oder aus dem Kontext rät, lass es in Ruhe. Manche Checks sind wirklich optional. Mach das zu einer bewussten Entscheidung, nicht zu einer blinden.

Breiteres Prinzip: Tool called schlägt reasoning inferred. Wenn du tiefer gehen willst, habe ich warum CLIs MCP für load-bearing Tool-Calls schlagen vor ein paar Monaten geschrieben. Das Argument gilt unter 4.7 noch härter.

Zwei Zeilen. Erster Fix erledigt.

Rewrite #2: Der, den alle genau falsch verstehen

Hier ist ein konkreter Break aus meiner Prod, letzte Woche.

Ich betreibe einen Produktbeschreibungs-Generator. Alte Regel, seit Monaten sauber am Laufen: "niemals Ausrufezeichen verwenden". Auf 4.6 galt das für den generierten Prosatext, und offensichtlich nicht für die zitierten Kundenbewertungen, die unter jedem Produkt eingebettet waren. Denn wer editiert eine Fünf-Sterne-Bewertung? Das Modell wusste es. Die Grenze war implizit aber real.

Upgrade auf 4.7. Dieselbe Regel. Nächster Batch von Produktseiten, meine zitierten Review-Blöcke verlieren Ausrufezeichen. Kundenzitate, die ursprünglich "Bestes Angebot diesen Sommer!!!" sagten, lesen sich jetzt "Bestes Angebot diesen Sommer". Plattgemacht. Was ein kleines Qualitätsproblem für Produktseiten ist, und ein echtes Problem, wenn du wörtliche Reviews aus rechtlichen oder Vertrauensgründen laufen lässt. Die Quelle stimmt nicht mehr mit dem Zitat überein.

Nicht das Modell wird "schlechter". Das Modell ist genau das, worum ich gebeten habe. Ich schrieb "niemals Ausrufezeichen verwenden". 4.7 las das als "niemals, nirgendwo, Punkt". Fein in der Absicht, kaputt im Output.

Fix: schreibe den Scope.

Niemals Ausrufezeichen irgendwo im generierten Produktprosatext verwenden. 
Diese Regel gilt nicht innerhalb zitierter Kundenbewertungen, die 
wörtlich aus externen Quellen gezogen werden.

Vier Zeilen statt einer. Null Mehrdeutigkeit. Das NIEMALS wurde stärker, nicht schwächer. Was ich getan habe, war aufzuhören, das Modell die Grenze für mich ziehen zu lassen.

Dieselbe Pipeline. Andere Regel. Diese war teurer, bevor ich sie erwischte.

"Versandrichtlinien einmal pro Conversation bestätigen." Auf 4.6 verstand das Modell "einmal unter normalem Ablauf, aber rebestätigen, wenn eine neue Bestellung eingeführt wird, oder wenn der Kunde mitten in der Session von national zu international wechselt". Die implizite Ausnahme war immer da. Nie geschrieben. Immer abgeleitet.

Auf 4.7: einmal. Punkt. Fünfzehn Nachrichten später bringt der Kunde eine komplett neue Bestellung in ein anderes Land auf. Keine Rebestätigung der Richtlinie. Weil die Anweisung "einmal" sagte und das Modell "einmal" machte.

Fix: benenne die Ausnahmen.

Versandrichtlinien einmal pro Conversation unter normalem Ablauf bestätigen. 
Rebestätigen wann immer: (a) eine neue Bestellung eingeführt wird, (b) das 
Ziel sich ändert (national zu international oder umgekehrt), 
(c) der Kunde explizit wieder nach Versandbedingungen fragt.

Jetzt ist der Scope explizit und die Ausnahmen sind gelistet. Keine Ableitung erforderlich.

Und hier wird der Ratschlag, mit dem du gefüttert wirst, genau falsch herum. Jeder Migration Guide in deinem Feed sagt dir "lockere deine NIEMALS-Regeln jetzt, wo 4.7 Anweisungen besser befolgt". Das ist das Gegenteil von dem, was du tun willst.

Deine NIEMALS-Regeln sind in Ordnung. Sie wurden nur schärfer. Was kaputtging, sind die Regeln, die darauf angewiesen waren, dass das Modell den Scope oder die Ausnahmen ableitet, die du nicht aufgeschrieben hast. Deine Absolute machen ihren Job. Das Problem sind deine "einmal", deine "immer", deine "normalerweise". Das sind die Regeln, die sich auf 4.6s stille Kooperation stützten.

Wenn du das vollständige Framework für das Schreiben von Prompts willst, die sich nicht auf Modell-Kooperation stützen, habe ich alles davon in den Prompt Contracts-Ansatz gesteckt, den ich nach sechs Monaten genau dieser Desaster gebaut habe. 4.7 macht dieses Framework relevanter, nicht weniger.

Deine NIEMALS-Regeln wurden schärfer. Deine "einmal"- und "immer"-Regeln wurden dumm. Fixe die letzteren, rühre die ersteren nicht an.

Was bleibt, und die Regel zum Merken

Jetzt die guten Nachrichten. Der Großteil deines Prompts bewegt sich nicht.

Die harten Verbote verbessern sich unter 4.7. Keine Gedankenstriche, keine Tabellen, keine verbotenen Opener, keine leeren Formeln: alles läuft straffer, nicht lockerer, weil das Modell aufhört, sie als Style-Vorschläge zu behandeln und anfängt, sie als Regeln zu behandeln. Der direkte Ton, den du früher mit expliziten Anweisungen gepacht hast, alignt mit 4.7s Standard-Voice. Deine langen System-Prompts halten weiterhin über den Kontext. Dein Markdown rendert genau gleich. Deine Tool-Definitionen, deine Personas, deine Output-Format-Specs, deine Content-Regeln: 90% eines gut geschriebenen 4.6-Prompts bleiben intakt.

Die Rewrite-Oberfläche ist schmal. Zwei Fragen, in Reihenfolge.

Erstens, wo hängt mein Prompt von einem Tool-Call ab, den ich nicht explizit verlangt habe? Finde die. Mache den Call mandatory. Benenne das Tool. Schließe den Fallback.

Zweitens, wo hängt mein Prompt davon ab, dass das Modell den Scope oder die Ausnahmen errät? Finde die. Schreibe den Scope. Liste die Ausnahmen.

Das war's. Nicht siebzehn Checkpoints. Zwei Fragen.

Karen aus der Buchhaltung würde siebzehn Checkpoints lieben, weil sie eine Tabelle machen könnte. Du brauchst keine Tabelle. Du musst deine Prompts nach weichen Verben und nach Regeln mit impliziten Grenzen greppen. Zehn Minuten grep. Eine Stunde Umschreiben. Fertig.

Erinnerst du dich an RTFM? 😬 (Entspann dich, ich bin für dich da.)

Quellen

• Claude API Migration Guide: die Verhaltensänderungen, von Anthropic ohne Spin erklärt.
• What's new in Claude Opus 4.7: das vollständige Changelog, Tokenizer inklusive.
• Prompting Best Practices: die Zeile über 4.6-Prompts, die auf 4.7 out of the box laufen, steht da drin.

(*) Das Cover ist AI-generiert. Meine eigenen Illustrationsfähigkeiten erreichten ihren Höhepunkt in der dritten Klasse.