Lösungen für das Problem des oberflächlichen Denkens bei Claude Opus 5

Übersicht

Sofort nach dem Wechsel von Claude Code zu Opus 5 fiel mir eine plötzliche Zunahme von prosa-lastigen Antworten und eine Tendenz zu "oberflächlichem Denken" (Unfähigkeit, strukturiert zu denken) auf.

Bei der Untersuchung stellte sich heraus, dass es nicht daran lag, dass das Modell schlecht oder die Regeln kaputt waren; vielmehr hat sich der interne System-Prompt, der Opus 5 in der Claude 5 Generation bereitgestellt wird, erheblich geändert, und Legacy-Regeln wurden nicht mit dieser neuen Prämisse geschrieben.

Dieser Artikel dokumentiert den Prozess der Ursachenisolierung und der Überarbeitung von Regeln, damit sie zum neuen System-Prompt passen. Er richtet sich an Claude Code-Nutzer, die das Gefühl haben, dass die Wirksamkeit von CLAUDE.md oder ihren Regeln seit dem Upgrade auf die neue Modellgeneration nachgelassen hat.

Das Problem

Mit derselben Sitzung und denselben Regeln traten unmittelbar nach dem Wechsel des Modells zu Opus 5 folgende Probleme auf:

• Situationserklärungen wurden zu flachem, langem Prosa-Text ohne Überschriften oder Abschnitte.
• Ursachenerklärungen blieben auf einer einzigen Ebene stehen (Aufzählung von Symptomen parallel, ohne nach dem "Warum" zu graben).
• Bei der Vorschlag mehrerer Optionen wurden keine Bewertungskriterien angegeben.
• In einem Durchgang etablierte Kategorien oder Nummerierungen wurden im nächsten in andere Strukturen umgestellt.
• Das Modell übersprang die Reaktion auf meine Eingabe und sprang sofort zur Tool-Ausführung (Aufgaben) über.

Das Frustrierende war, dass es selbst bei der Aufforderung "tiefer zu denken" sporadische Antworten lieferte, während es in einem oberflächlichen Denkzustand verharrte. Wiederholte Korrekturen fruchteten nicht, was zu Argumenten statt produktiver Diskussion führte.

Es war nicht nur eine Frage der Qualität einer einzelnen Antwort; der Prozess der Überlegung durch Dialog selbst war zusammengebrochen.

Wichtige Hinweise

Dies geschah nicht mit anderen Modellen, die dieselben Regeln verwendeten (Details zu diesem Unterschied finden Sie im Anhang). Wenn die Regeln selbst nachgelassen hätten, hätte das Problem bei allen Modellen auftreten müssen. Da sich nur das Modell änderte, begann ich mit der Untersuchung unter der Annahme, dass sich die "Umgebung, die die Regeln annehmen" geändert hatte.

Ursache: Änderungen am System-Prompt für Opus 5

In der Claude 5 Generation von Claude Code wurde der interne System-Prompt im Vergleich zu früheren Generationen um etwa 80 % reduziert. Durch die Messung des tatsächlich an Opus 5 gelieferten Prompts (durch Deaktivieren der Output-Style-Injektionen und Aufforderung des Modells, seinen eigenen Prompt zu zitieren; Claude Code v2.1 Serie, Juli 2026) ergab sich folgende Struktur:

1. Identität, Rollendeklaration und Sicherheitsrichtlinie — Die einleitende Präambel.
2. Harness-Spezifikationen (# Harness) — Erläuterungen zur Ausführungsumgebung, z. B. dass die Ausgabe als Markdown angezeigt wird.
3. Umgebungsinfo und Funktionsbeschreibungen (# Session-specific guidance / # Memory / # Environment / # Context management) — CWD, Git-Status, Modell-ID, Speicher und Komprimierungsmechanismen für den Kontext.
4. Bereichsdisziplin (# Delivering work) — Keine Einengung oder Erweiterung des angeforderten Umfangs ohne Erlaubnis.
5. Korrektur-Etikette (# Corrections) — Korrekturen kurz halten, ohne Entschuldigungen oder Präambeln hinzuzufügen.

Zwei spezifische Merkmale standen in direktem Zusammenhang mit den Symptomen:

• Merkmal 1: Keine Anweisungen zum Antwortstil. Es gab keine Regeln zu Prosa vs. Struktur, Verwendung von Überschriften oder Tabellen oder Prägnanz – Formatierungsregeln, die in früheren Generationen umfangreich waren, fehlten vollständig.
• Merkmal 2: Eine "Handeln zuerst"-Autonomie-Richtlinie wurde hinzugefügt. Um das Original zu zitieren: "Wenn Sie genügend Informationen zum Handeln haben, handeln Sie." und "Wenn Sie eine Wahl abwägen, geben Sie eine Empfehlung, keine erschöpfende Übersicht."

Wenn man die Symptome durch diese beiden Merkmale erneut liest, wird alles klar. Da es keine Stilregeln gibt, kommt die rohe Ausgabetendenz des Modells – flache Prosa – zum Vorschein. Die Richtlinie "Empfehlung vor Übersicht" fördert das Weglassen von Bewertungskriterien.

Sie denken vielleicht: "Wenn die Regeln leer sind, sollten meine benutzerdefinierten Regeln doch die alleinige Autorität werden und besser funktionieren?" In Wirklichkeit geschah das Gegenteil. Dieser leere Raum ist kein Spielraum für den Benutzer; er ist an das Standardverhalten delegiert, das dem Modell während des Trainings eingeprägt wurde. Der "schlanke Prompt" geht davon aus, dass Modelle der neuen Generation verinnerlichten Verhaltensweisen folgen, ohne detaillierte Anweisungen. Anstatt von Ihren Regeln gefüllt zu werden, wird die Lücke von den vortrainierten Standardeinstellungen des Modells gefüllt. Und Opus 5s Standardeinstellung ist prägnante Prosa, die handelt, bevor sie bestätigt.

Meine alten Regeln verwendeten allgemeine Anweisungen wie "Situationen strukturell aufschlüsseln", "Bewertungskriterien zu mehreren Optionen hinzufügen" und "antworten, bevor gehandelt wird". Diese wurden geschrieben in der Annahme, dass sie zusammen mit einem stilreichen System-Prompt gelesen würden. Sie waren zwar damals ausreichend, aber sowohl in der Spezifität (Benennung des Originaltextes) als auch in der Auslieferung (Erreichen des Modells direkt vor der Aktion) zu schwach, um trainierte Standardeinstellungen zu überschreiben. Dies ist die wahre Natur der Symptome.

Anthropic selbst bezeichnet diese Reduzierung im Changelog (v2.1.154) als "lean system prompt", was einen Wandel in der Designphilosophie widerspiegelt: "Modelle der neuen Generation haben Verhaltensweisen durch Training verinnerlicht, sodass detaillierte Anweisungen Reibungen oder Widersprüche verursachen können." Detaillierte Erklärungen finden Sie unter Claude Code System Prompt um 80 % reduziert — Prompt-Design-Philosophie für die Fable 5 Generation. Für Primärquellen siehe das Claude Code Changelog und Prompting Claude Fable 5 (Offizieller Leitfaden).

Kurz gesagt, Symptome werden durch die Kombination von "Regeln × dem tatsächlich an dieses Modell gelieferten Prompt" bestimmt. Sie können die Ursache nicht finden, indem Sie nur die Regeln betrachten. Die erste Lektion war, dass ein Modell-Update auch ein System-Prompt-Update ist.

Maßnahme 1: Widersprüche identifizieren und durch Benennung des Originaltextes überschreiben

Zuerst habe ich alle Regeln mit dem neuen System-Prompt abgeglichen, um zu identifizieren, wo sie das Gegenteil aussagten. Für Regeln, die die Systemrichtlinie überschreiben sollten, habe ich sie umgeschrieben, um explizit den Originaltext zu zitieren und die Priorität zu erklären.

Um damit zu beginnen, was nicht funktioniert hat: Das Hinzufügen von Allgemeinplätzen wie "schreibe mehrere Optionen mit Bewertungskriterien" ist wirkungslos.

Wenn es neben der Systemanweisung "gib eine Empfehlung, keine erschöpfende Übersicht" steht, gibt es keinen Hinweis darauf, welche Vorrang hat. Indem man den Konflikt benennt, wird die Priorität klar.

Für Dinge, die im Prompt völlig fehlen, wie Stilregeln, funktioniert die Anweisung, um die "Lücke zu füllen", anstatt sie zu überschreiben.

Ich habe auch überarbeitet, wie Auslösebedingungen geschrieben werden. Bedingungen wie "bei wichtigen Änderungen" oder "wenn als Produktionsumgebung eingeschätzt" scheitern, sobald das Modell die Situation nicht so kategorisiert. Ich habe Auslöser in beobachtbare Fakten geändert, wie "einen Interrupt erhalten" oder "die Äußerung des Benutzers enthält eine Korrektur".

Maßnahme 2: Gewünschte Aktionen beschreiben anstatt Verbote

Alte Regeln waren eine Ansammlung von "Verboten". Verbote helfen, Verstöße zu erkennen, vermitteln aber nicht, was stattdessen zu tun ist. Wenn ein Verbot mit einer neuen Systemrichtlinie in Konflikt gerät, findet das Modell eine Gesetzeslücke: "Folge der Systemrichtlinie, während du das Verbot umgehst." Ich habe negative Einschränkungen in Beschreibungen des gewünschten Verhaltens umgewandelt.

• Vorher: "Schlage keinen Commit vor, wenn die Tests unvollständig sind."
• Nachher: "Wenn du einen Commit vorschlägst, füge die Ergebnisse der Ausführung des Produkts aus der Perspektive des Endbenutzers in den Fließtext ein."

Ich habe die umgeschriebenen Regeln anhand der folgenden Kriterien überprüft, insbesondere auf Ausdrücke, die mit dem System-Prompt kollidieren:

1. Ist die Regel in sich geschlossen? (Umfang, Beispiele und Kriterien an einem Ort)
2. Ist der Auslöser eine beobachtbare Tatsache?
3. Widerspricht sie dem internen System-Prompt?
4. Beschreibt sie das gewünschte Verhalten? (Nicht nur eine Liste von Verboten)
5. Gibt es ein einziges Kriterium für die Beurteilung? (Keine Liste von Szenarien)
6. Ist die Betonung (IMPORTANT) nur für das reserviert, was wirklich nicht wegfallen kann?
7. Ist sie als gewünschter Endzustand geschrieben? (Nicht zuerst Vorlagen oder Schritte erzwingen)
8. Kann die Einhaltung im Nachhinein festgestellt werden?

Ich habe Hervorhebungsmarkierungen (IMPORTANT) auf nur Sicherheits- und Genehmigungsstufen reduziert. Ein Dokument, in dem alles hervorgehoben wird, ist dasselbe wie ein Dokument, in dem nichts hervorgehoben wird.

Maßnahme 3: Wähle die "Ebene" für die Zustellung von Anweisungen

Es ging nicht nur um den Text. Claude Code hat mindestens vier Wege, um Anweisungen an das Modell zu liefern, und sie unterscheiden sich erheblich in ihrer Wirksamkeit.

Da die API zustandslos ist, werden Inhalte aus allen Pfaden mit jeder Anfrage (jeder Runde) an das Modell gesendet. Der Unterschied liegt darin, "wann der Inhalt finalisiert wird" und "wo er im Prompt platziert ist = wie nah er an der ausgeführten Aktion ist."

Überraschenderweise wurde output style – das laut Dokumentation "den System-Prompt ersetzt" – gemäß Sitzungsprotokollen in jeder Runde als Anhang ausgeliefert.

Ich habe zwei Arten von Anweisungen in diesem output style geschrieben: Stil (Maßnahme 1: strukturell schreiben, Kriterien hinzufügen) und Prozess (dem Benutzer antworten, bevor mit der Arbeit begonnen wird). Die Ergebnisse waren gemischt.

Während die Stilanweisungen eine Verbesserung zeigten, hörte das Prozessproblem – das Überspringen von Antworten, um mit der Arbeit zu beginnen – nicht durch output style auf. Ich habe diese Angewohnheit schließlich gestoppt, indem ich einen UserPromptSubmit-Hook verwendete, um unmittelbar nach jeder Benutzeräußerung eine einzelne Zeile einzufügen: "Schreibe eine Antwort auf diese Äußerung (Antwort oder Bestätigung und Plan) in den Fließtext, bevor du Tools ausführst."

Die Kosten betragen etwa 50 Token pro Äußerung. Selbst 100 Äußerungen kosten nur 5.000 Token, was gegen einen Kontext von 200K vernachlässigbar ist. Die allgemeine Regel, die ich gelernt habe, ist einfach: Anweisungen, die "kurz, jedes Mal, direkt vor der Aktion" geliefert werden, sind am effektivsten. Viele ineffektive Anweisungen sind inhaltlich nicht schlecht; sie sind nur im Moment der Aktion nicht griffbereit.

Ergebnisse

Hier sind die bisher bestätigten Ergebnisse:

• Ein Trend zur Rückkehr von Überschriften/Abschnitten in Situations- und Ursachenerklärungen. (Allerdings bleibt flache Ausgabe manchmal zu Beginn der Sitzung bestehen; fortlaufende Beobachtung erforderlich).
• Die Angewohnheit "ohne Antwort zu arbeiten" ließ sich nicht allein mit output style beheben, hörte aber nach der Einführung der pro-Äußerung-Injektion auf (derzeitige Beobachtung der Langzeiteffekte).

Zusammenfassung

• Ein Modell-Update ist auch ein System-Prompt-Update. Wenn sich Antworttrends plötzlich ändern, lesen Sie die Änderungen auf der Systemseite, bevor Sie weitere Regeln hinzufügen.
• Regeln, die mit Systemrichtlinien konkurrieren, müssen den Originaltext benennen und die Priorität erklären. Allgemeine Ergänzungen verlieren angesichts von Widersprüchen.
• Schreiben Sie Auslöser basierend auf Beobachtung und beschreiben Sie gewünschte Aktionen anstatt Verbote. Selbstkategorisierungs-Auslöser und Verbotslisten neigen zu Fehlern, wenn sich Modelle ändern.
• Wählen Sie die richtige Ebene für Anweisungen. Injektionen, die kurz und häufig direkt vor einer Aktion geliefert werden, waren weitaus zuverlässiger als große Regeln, die am Anfang des Kontexts platziert werden.

Referenz 1: Tatsächlich in Maßnahme 1 verwendete Regeln

Hier ist ein Auszug der Regeln, die ich verwende, um den System-Prompt zu überschreiben (passen Sie sie an Ihre Umgebung an; ich platziere sie im output style). Einige Originalphrasen (wie die Prosa-Richtlinie) existieren im Prompt für bestimmte Modelle nicht (siehe Anhang). In diesen Modellen fungieren sie als Definitionen, um die Lücke zu füllen.

1# Berichts- und Zerlegungsformat
2
3Diese Anweisung hat Vorrang vor den folgenden Beschreibungen im Claude Code System-Prompt:
4"a simple question gets a direct answer in prose, not headers and sections" /
5"Use tables only for short enumerable facts" /
6"Don't make the reader cross-reference labels or numbering you invented earlier" /
7"If you are weighing a choice, give a recommendation, not an exhaustive survey." /
8"You are operating autonomously... proceed without asking." /
9"Text you write between tool calls may not be shown to the user."
10
11## Schreibstil
12
13Wenn Sie Situationen, Ursachen erklären oder mehrere Optionen präsentieren, schreiben Sie so, dass die Struktur des Inhalts für den Leser erkennbar ist.
14Verwenden Sie Überschriften, Aufzählungspunkte oder Tabellen, je nach Inhalt. Beantworten Sie Ein-Satz-Fragen in Prosa.
15
16- Fassen Sie zuerst die Gedanken zusammen, dann strukturieren Sie am Ende. Platzieren Sie nicht zuerst eine Vorlage und füllen Sie sie aus.
17- Wenn Sie Ursachen erklären, verfolgen Sie das "Warum" mindestens zwei Ebenen tief vom beobachteten Ereignis aus und beschreiben Sie, worauf sich jede Ebene bezieht. Hören Sie nicht bei der parallelen Auflistung von Symptomen auf.
18- Wenn Sie mehrere Optionen präsentieren, schreiben Sie zuerst die Empfehlung und ihre Begründung, gefolgt von den Kriterien, die die Entscheidung beeinflussen, und der Bewertung jeder Option. Wenn Kriterien nicht identifiziert werden können, geben Sie keine Optionen an; schreiben Sie stattdessen, was untersucht werden muss, um die Kriterien zu füllen. Vergleiche von Kriterien können in Tabellen geschrieben werden.
19- Sobald Kategorien und Nummern festgelegt sind, verwenden Sie dieselben in nachfolgenden Durchgängen, während Sie dieselbe Aufgabe fortsetzen. Wenn Sie sie ändern, schreiben Sie zuerst, was geändert wurde.
20
21## Dialog und Prozess
22
23- Die Systemaussage "the user is not watching in real-time" ist ein Standard, keine Tatsache. Wenn in dieser Sitzung auch nur einmal eine Zwischenäußerung, ein Interrupt oder eine Korrektur empfangen wird, behandeln Sie den Benutzer von da an als zuschauend: Teilen Sie die Arbeit in kleine Segmente auf, beenden Sie jede Runde mit einem Bericht im Fließtext und halten Sie bei Runden, in denen eine Frage gestellt wird, an, um auf eine Antwort zu warten.
24- In dieser Umgebung wird nur der Fließtext am Ende einer Runde angezeigt. Platzieren Sie alle zu übermittelnden Informationen am Ende der Runde.
25- Fragen sind ein legitimes Mittel, wenn es Mehrdeutigkeiten, Vorgänge, die eine Genehmigung erfordern, oder unklare Ziele gibt.

Referenz 2: Warum ist dies nicht mit Fable 5 / Opus 4.7 passiert?

Während sich der Haupttext auf Opus 5 konzentrierte, hier der Grund, warum es nicht mit anderen Modellen passiert ist:

• Opus 4.7 ist einfach: Es ist von der Anwendung des "Lean Prompts" ausgeschlossen (laut Changelog), sodass es immer noch mit dem langen, Legacy-Prompt läuft, für den die Legacy-Regeln entwickelt wurden. Es bleibt mit alten Regeln synchron.
• Fable 5 war eine Überraschung. Ich nahm an, dass es denselben Prompt hätte, da es dieselbe Generation ist, aber Messungen zeigten, dass Fable 5 einen anderen Prompt erhält als Opus 5.

Hier ist ein Vergleich jedes Modells, das seinen eigenen Prompt unter identischen Bedingungen zitiert (headless mode, output style deaktiviert):

Der Abschnitt # Communicating with the user von Fable 5 enthält Normen wie "conclusion first, prioritize readability, write for the audience." Zusätzlich zu "give a recommendation, not an exhaustive survey" enthält es die Prosa-Richtlinie "a simple question gets a direct answer in prose, not headers and sections." Da der Prompt selbst diese Schreibnormen enthält, ist das Ausgabeformat weniger anfällig für Zusammenbrüche, und in meinen Beobachtungen blieb die Einhaltung der Benutzerregeln erhalten.

Zusammenfassend lässt sich sagen, dass das Problem bei Opus 5 intensiv auftrat, weil drei Faktoren zusammenkamen:

1. Es erhielt einen Prompt ohne Schreibstilregeln, wodurch rohe Ausgabetendenzen freigelegt wurden.
2. Richtlinien wie "act when info is sufficient" und "recommendation over survey" förderten sofortiges Handeln und das Weglassen von Kriterien.
3. Legacy-Regeln basierten immer noch auf dem alten, detaillierten Prompt und waren nicht darauf ausgelegt, diese neue Lücke zu füllen.