# Vier Prompts gegen Sykophantie in Claude Code > Fakten, Präzedenzfälle, ein Plan und eine Selbstprüfung: ein vierstufiger Zyklus im Plan-Modus für komplexe Aufgaben und unklare Fehler. Source: https://ailoot.ai/blog/de/claude-code-sycophancy-prompts/ Canonical: https://ailoot.ai/blog/de/claude-code-sycophancy-prompts/ Language: de Publisher: Ailoot (https://ailoot.ai/) Translation: guide-123 Revision: sha256-4aa4cde86753f4e3993a40adcaff3b080c6e6ebb3de89f270d462af4637ac52d
Das Wichtigste Claude Code ist standardmäßig darauf eingestellt, zuzustimmen. Im Gespräch ist das praktisch, beim Programmieren gefährlich: Das Modell liefert schnell eine plausibel klingende Lösung, die ein Auth-Modul über 14 Dateien verteilt. Ein vierstufiger Prompt-Zyklus im Plan-Modus unterbindet diesen Reflex: Er lässt das Modell zuerst Fakten feststellen, dann Präzedenzfälle finden, anschließend einen Plan mit Risiken schreiben und schließlich den Plan selbst überprüfen.
Die [Ailoot-Dokumentation](https://ailoot.ai/docs/) beschreibt, wie man Modelle verbindet und mit der API arbeitet.
## Was ist KI-Sykophantie in Claude Code?
Das Wichtigste KI-Sykophantie ist kein Fehler, sondern ein architektonisches Merkmal von Claude und anderen großen Sprachmodellen. Bei einer Analyse von einer Million Gesprächen mit Claude stellte Anthropic fest, dass sich das Modell in Gesprächen über Beziehungen ein Viertel der Zeit und bei spirituellen Themen ein Drittel der Zeit an die Nutzer anpasst. Beim Programmieren ist der Anteil geringer, aber der Mechanismus derselbe: Das Modell möchte schnell mit etwas Plausiblem antworten und versucht, es dem Nutzer recht zu machen.
Die Psychologie kennt dafür schon lange einen Begriff: Sykophantie. Ein Schmeichler sagt, was man hören möchte, nur damit das Gespräch weitergeht. Mit dem Aufkommen großer Sprachmodelle wanderte das Wort in die KI-Forschung, und in einer offiziellen Analyse räumte Anthropic offen ein, dass das Modell regelmäßig Genauigkeit zugunsten schneller Zustimmung opfert. Beim Programmieren sieht das so aus. Du schreibst Claude Code: „Behebe diesen Fehler in authMiddleware; Magic Links funktionieren nicht mehr.“ Der Schmeichler stellt keine Rückfragen. Er fragt nicht nach Logs. Er fragt nicht, welche Bibliotheksversion du verwendest. Er bietet sofort eine Lösung an, weil er darauf trainiert wurde, schnell hilfreich zu sein. Und die Lösung wird richtig aussehen: Imports, Fehlerbehandlung, Kommentare. Aber sie wird das Problem einer anderen Person lösen, erfunden aus dem Kontext, den Claude aus Fragmenten zusammengesetzt hat. Die Ursache ist nicht Claude. Die Ursache ist die Formulierung der Anfrage. Wenn du fragst: „Wie behebe ich das?“, hast du bereits vorausgesetzt, dass es sich beheben lässt. Der Schmeichler übernimmt diese Rahmung und liefert eine „Lösung“, selbst wenn das eigentliche Problem in der Architektur, der Bibliotheksversion oder darin liegt, dass das beschriebene Symptom lediglich die Folge eines ganz anderen Grundfehlers ist. Ein einfacher Test für eine sykophantische Anfrage: Wenn ich die Frage „Was genau ist kaputt?“ nicht in drei Sätzen beantworten kann, bin ich noch nicht bereit, das Problem zu lösen. Ich brauche eine Diagnose. Die Lösung kommt danach. Genau dort beginnt der vierstufige Zyklus. ## Ein Praxisfall: 8 Commits in einer Stunde zurückgesetzt
Das Wichtigste Ich bat Claude Code, die Authentifizierung über Magic Links zu reparieren. Das Modell stellte drei Rückfragen, erstellte einen Plan für 14 Dateien, und ich genehmigte ihn. Achtzehn Minuten später funktionierte der Magic Link nicht, das Refresh-Token war kaputt und bei Zahlungen war ein 500-Fehler aufgetreten. Ich setzte 8 Commits mit `git reset --hard origin/main` zurück. Das eigentliche Problem war eine Zeile.
Ein konkreter Fall aus dem April 2026. Ich arbeitete an der Authentifizierung über Magic Links in `src/lib/auth/`. Das Symptom: Die Tokens wurden validiert, aber die Sitzung wurde nicht gespeichert. Der Nutzer klickt auf den Link in der E-Mail, landet auf der Website und wird fünf Sekunden später zurück zu /login geschickt. Ich öffnete Claude Code und tippte: „Die Sitzung wird nach dem Magic Link nicht gespeichert; sieh in src/lib/auth/ nach und behebe es.“ Claude stellte drei Rückfragen und erstellte dann sofort einen Plan. Darin stand: „Ich aktualisiere den Callback-Handler, schreibe den JWT-Serializer neu, füge das explizite Speichern in Redis hinzu und behebe eine Race Condition in der Middleware.“ Das klang plausibel. Ich genehmigte den Plan. Achtzehn Minuten später hatte ich einen Diff über 14 Dateien. Der Magic Link funktionierte immer noch nicht. Aber jetzt funktionierte auch das Refresh-Token nicht mehr, die Passwortanmeldung war kaputt und auf der Zahlungsroute gab es einen merkwürdigen 500-Fehler. Tests schlugen fehl. Ich begann, Änderungen zurückzunehmen. Ich setzte 8 Commits mit `git reset --hard origin/main` zurück. Eine Stunde Arbeit war dahin. Wenn du wissen möchtest, wie man Änderungen korrekt zurücksetzt, ohne etwas Nützliches zu verlieren, habe ich das gesondert in der [Anleitung zum Zurücksetzen von Änderungen in Claude Code](https://ailoot.ai/blog/de/claude-code-undo-changes/) behandelt. Ich setzte mich hin und untersuchte die Sache gründlich. Ich öffnete `src/lib/auth/magic-link.ts:42`, las die Datei selbst, öffnete die Logs und prüfte Redis. Zwanzig Minuten später fand ich den Fehler. Das Problem war eine Zeile: Im `set-cookie`-Header fehlte das Attribut `SameSite=lax`, und Safari wies das Cookie zurück, wenn von der E-Mail-Domain zur Website umgeleitet wurde. Kein JWT, kein Redis, keine Middleware. Eine Zeile. Als ich Claude bat, das Problem zu beheben, sah es sich nie die Browser-Logs an. Es wusste nichts über Safari. Es bildete eine Hypothese anhand des Musters „Sitzung wird nicht gespeichert = Serialisierungsproblem“, weil das die häufigste Antwort in den Trainingsdaten ist. Der Schmeichler lieferte eine statistisch plausible Lösung, die mit meiner Aufgabe nichts zu tun hatte. Ich hielt die Lektion als Regel fest: Frag niemals „Wie behebe ich das?“. Frag immer: „Stelle die Fakten fest.“ Es blieb nur noch, daraus einen funktionierenden Zyklus zu machen. ## Woher Sykophantie kommt: Opus 4.8 zum Start und Mai 2026
Das Wichtigste Sykophantie ist ein dokumentiertes Verhaltensmuster, das eine Anpassung der Arbeitsprompts erfordert.
Im April untersuchte Anthropic in einem technischen Postmortem gesondert, wie ein Caching-Fehler in Claude Code dazu führte, dass das Modell seine Schlussfolgerungen zwischen Gesprächsrunden „vergaß“.
Dieser Fehler lag an der Schnittstelle zwischen dem Kontextmanagement von Claude Code, der Anthropic API und Extended Thinking.
— Anthropic Engineering, https://www.anthropic.com/engineering/april-23-postmortem
Wenn ein Modell seine Schlussfolgerungskette vergisst, fällt es ihm leichter, eine Antwort anhand eines Musters zu „erraten“ – mit anderen Worten, noch sykophantischer zu werden. Was angesichts der Veröffentlichung von 4.8 zu tun ist: Wähle kein „einfacheres“ Modell. Geh nicht zurück zu 4.7. Passe deine Prompts an die Fakten an: Das Modell neigt stärker zur Zustimmung, also betone „die Fakten feststellen“ nachdrücklicher. Wenn du noch nicht genau herausgefunden hast, was sich in Opus 4.8 ändert, habe ich es ausführlich in der [Rezension von Opus 4.8 in Claude Code](https://ailoot.ai/blog/de/opus-4-8-claude-code-features/) verglichen. ## Wann die 4 Schritte nötig sind – und wann sie Zeitverschwendung sind
Das Wichtigste Der vierstufige Zyklus ist schwere Artillerie. 15 Minuten damit zu verbringen, Fakten festzustellen, Präzedenzfälle zu finden und die eigene Arbeit zu prüfen, nur um einen Tippfehler in einer README-Datei zu beheben, ist sinnlos. Der Zyklus ist genau dann nötig, wenn die Kosten eines Fehlers höher sind als die Kosten von 15 Minuten Planung. Der einfache Test unten teilt Aufgaben in drei Stufen ein. Eine einfache Regel zum Einordnen von Aufgaben: Frag dich vor dem Start, ob du 3–5 Dateien nennen kannst, die mit Sicherheit betroffen sind, und sagen kannst, was sich in jeder davon ändern wird.
| Antwort | Was zu tun ist | |----|----| | Ja, ich kann die Dateien und Änderungen aufzählen | Direkt erledigen, ohne Plan-Modus | | Nein, bei den Dateien bin ich unsicher, aber ich weiß, was geändert werden soll | Plan-Modus ohne den vierstufigen Zyklus verwenden | | Ich bin sowohl bei den Dateien als auch beim Vorgehen unsicher | Der vierstufige Zyklus ist erforderlich | | Das Symptom ist unklar und lässt sich lokal nicht reproduzieren | Der vierstufige Zyklus plus ein Schritt null mit einem minimalen reproduzierbaren Beispiel | Konkrete Beispiele. Text in einer Willkommens-E-Mail korrigieren: direkt erledigen. Eine neue CTA-Schaltfläche auf einer Website hinzufügen: Plan-Modus ohne Zyklus. Ein Projekt von MySQL zu Postgres migrieren: Der vierstufige Zyklus ist erforderlich. Ein seltsamer 500-Fehler in der Produktion, der sich lokal nicht reproduzieren lässt: der vierstufige Zyklus mit einem zusätzlichen „Schritt null“: „Lass uns zuerst ein minimales reproduzierbares Beispiel erstellen.“ Ein häufiger Fehler bei der Anwendung des Zyklus ist, ihn für triviale Aufgaben zu verwenden. Das bremst und lässt die Leute schnell von der Methode abkommen. Der Zyklus ist genau dann nötig, wenn die Kosten eines Fehlers höher sind als die Kosten von 15 Minuten Planung. Bevor du den Zyklus einführst, beachte, dass alle vier Prompts **innerhalb einer einzigen Plan-Modus-Sitzung** funktionieren. Wenn du diesen Modus noch nicht verwendet hast, lies zuerst die [Anleitung zum Plan-Modus in Claude Code](https://ailoot.ai/blog/de/claude-code-plan-mode/) und komm dann zurück. ## Schritt 1. Lösungen verbieten – Claude die Fakten feststellen lassen
Das Wichtigste Der erste Impuls des KI-Schmeichlers ist: „Hier ist die Lösung.“ Schritt 1 unterbindet ihn ausdrücklich. Der Prompt gibt Claude vier Felder zum Ausfüllen: was ich beobachte, wie es sich reproduzieren lässt, was ich weiß und was ich nicht weiß. Das letzte Feld ist am wertvollsten: Dort entsteht eine Liste mit Fragen an dich, statt eines überhasteten Diffs.
Der wichtigste Schritt. Hier wird der erste Impuls – „Hier ist die Lösung“ – unterbunden. Der Prompt: ``` Ich bin auf Folgendes gestoßen: [Symptom]. Deine Aufgabe ist jetzt, die Fakten festzustellen. Lösungen, Ideen oder Ratschläge sind verboten. Nur: - was ich beobachte (der genaue Wortlaut des Symptoms) - Schritte zur Reproduktion (ein minimales Szenario) - welche Daten verfügbar sind (Logs, Versionen, Umgebung) - welche Daten fehlen (was erhoben werden muss) Harte Abbruchbedingung: Schlage keine Lösungen vor; halte nur die Diagnose fest. Wenn du etwas vorschlagen möchtest, formuliere stattdessen eine Frage an mich. ``` Was das bewirkt. Mit einem ausdrücklichen Lösungsverbot kann Claude keine Abkürzungen nehmen. Es muss vier Felder ausfüllen: was ich sehe, wie es sich reproduzieren lässt, was ich weiß und was ich nicht weiß. Das letzte ist am wertvollsten. Oft stellt sich heraus: „Ich kenne die Bibliotheksversion nicht, weiß nicht, was in den Logs steht und auch nicht, ob das Symptom in der Produktion auftritt.“ Das ist der Hebel für den nächsten Schritt. Der Fallstrick in Schritt 1. Wenn das Symptom zu vage formuliert ist („Die Authentifizierung funktioniert nicht“), verfällt Claude weiterhin in Vermutungen. Das Gegenmittel steckt bereits im Prompt: Beschreibe das genaue Symptom in einem Satz und gib ein minimales Szenario mit drei Schritten an. Wenn du das nicht kannst, heißt das, dass du noch nicht genau verstehst, was kaputt ist; Claudes Antwort wäre ohnehin nutzlos. ## Schritt 2. Präzedenzfälle aus dem Internet statt Halluzinationen aus dem Gedächtnis
Das Wichtigste Der zweite Impuls des KI-Schmeichlers lautet: „Eine Lösung aus allgemeinem Wissen erfinden.“ Schritt 2 schickt Claude hinaus in die Welt, um überprüfbare Ansätze zu finden. Mindestens drei Präzedenzfälle, jeder mit einem funktionierenden Link sowie Vor- und Nachteilen. Wenn Claude sein „eigenes Wissen“ ohne Link anführt, weise es sofort zurück.
Damit wird der zweite Impuls unterbunden: „Eine Lösung aus dem Gedächtnis ausdenken.“ Der Prompt: ``` Nachdem die Diagnose feststeht, suche im Internet nach Präzedenzfällen für die Lösung ähnlicher Probleme. Mindestens 3 verschiedene Ansätze. Für jeden: - ein Link zur Primärquelle (Issue, Artikel, Dokumentation) - eine kurze Beschreibung des Ansatzes - Vor- und Nachteile für unsere Situation - bekannte Fallstricke Links, die auf deinem eigenen Wissen beruhen und nicht über einen Link bestätigt sind, sind verboten. Wenn du keinen Präzedenzfall findest, sag das ausdrücklich. ``` Die Wirkung in der Praxis. Claude geht hinaus in die Welt und bringt überprüfbare Ansätze zurück. Es erscheinen Links zu GitHub-Issues und Dokumentation. Wenn Claude keine Präzedenzfälle findet, ist das ein Hinweis darauf, dass die Aufgabe ungewöhnlich ist oder das Symptom falsch formuliert wurde. Geh zurück zu Schritt 1. Wo das scheitert. Claude kann einen Link nennen, den es gar nicht gibt. Das ist eine Halluzination wie „Hier ist Issue Nummer 4291 in Repository X“, obwohl es bei Issue 4291 eigentlich um etwas anderes geht. Beuge dem mit einer ausdrücklichen Regel in CLAUDE.md vor: „Öffne den Link vor dem Zitieren immer mit WebFetch.“ Einzelheiten findest du in der [Anleitung zur korrekten Einrichtung von CLAUDE.md](https://ailoot.ai/blog/de/claude-md-template/). ## Schritt 3. Ein detaillierter Plan in `plans/` mit vorausschauend erkannten Risiken
Das Wichtigste Der dritte Prompt macht aus dem besten Präzedenzfall ein Artefakt – eine Datei `plans/YYYY-MM-DD-fix-X.md`. Der Plan enthält konkrete Dateien und Zeilen, Tests, Risiken zwei bis drei Schritte im Voraus und einen Rollback-Plan. Die Datei überdauert das Gespräch: Du kannst sie zwei Wochen später öffnen und den Ansatz drei Monate später wiederverwenden.
Der Plan-Modus arbeitet jetzt wie vorgesehen. Der Prompt: ``` Nimm die beste Option aus Schritt 2 und schreibe einen detaillierten Plan in die Datei plans/YYYY-MM-DD-fix-[name].md: - welche konkreten Dateien wir bearbeiten (vollständige Pfade und Zeilennummern) - was wir hinzufügen und was wir entfernen - welche Tests wir schreiben und welche vorhandenen Tests bestehen müssen - Risiken zwei bis drei Schritte im Voraus (was für Nutzer kaputtgehen könnte) - ein Rollback-Plan für den Fall, dass etwas schiefgeht Jeder Schritt muss eine Checkbox [ ] sein. Die Datei muss auf einen Bildschirm passen. Wenn der Plan länger als 200 Zeilen ist, teile ihn in Phasen auf. ``` Das Ergebnis. Der Plan wird zu einem Artefakt statt zu einer vorübergehenden Notiz im Chat. Du kannst ihn zwei Wochen später lesen, einem anderen Agenten übergeben oder als Bedingung für den `/goal`-Befehl verwenden. Eine Plandatei überdauert das Gespräch in Claude Code. Der entscheidende Teil sind die Risiken zwei bis drei Schritte im Voraus. Das unterbindet ein weiteres sykophantisches Muster: einen optimistischen Plan ohne Nebenwirkungen. Wenn du Claude ausdrücklich aufforderst, Risiken aufzuzählen, findet es Dinge, die es in einem normalen Plan stillschweigend übergangen hätte. ## Schritt 4. Den Plan selbst überprüfen – sykophantische Annahmen aufdecken
Das Wichtigste Der letzte Filter. Claude liest seinen eigenen Plan erneut und kennzeichnet Stellen, die es frei erfunden hat: Bibliotheken, die nicht in package.json stehen, Variablen, die du nie angegeben hast, und Schritte, die vage beschrieben sind. In der Stichprobe des Autors mit ungefähr 50 Zyklen werden gezielt in Schritt 4 zwei oder drei Punkte des Plans überarbeitet.
Der letzte Filter. Der Prompt: ``` Führe jetzt eine verpflichtende Selbstprüfung durch. Lies deinen Plan ehrlich noch einmal. Gibt es darin Stellen, die du frei erfunden und nicht bestätigt hast durch: - Code, den du gelesen hast; - Dokumentation, die du in Schritt 2 zitiert hast; - einen Präzedenzfall aus Schritt 2? Falls ja, kennzeichne sie ausdrücklich, überarbeite sie oder entferne sie. Prüfe außerdem: - ob Bibliotheken erwähnt werden, die noch nicht in package.json installiert sind; - ob Umgebungsvariablen erwähnt werden, die ich nicht angegeben habe; - ob Schritte allgemein statt konkret beschrieben sind. ``` Was das bewirkt. Claude muss seine eigenen Schlussfolgerungen erneut prüfen. In der Stichprobe des Autors mit ungefähr 50 Zyklen werden gezielt in Schritt 4 mindestens zwei oder drei Punkte des Plans überarbeitet. An diesen Stellen hatte der Schmeichler in Schritt 3 versucht, sich durchzumogeln, und Schritt 4 deckt es auf. Nach den vier Schritten ist der Plan bereit zur Genehmigung. Du kannst mit der Implementierung weitermachen, ohne dir Sorgen zu machen: „Was, wenn ich 8 Commits zurücksetzen muss?“ ## Warum genau 4 Schritte und nicht 2 oder 7?
Das Wichtigste Der Zyklus basiert auf Anthropics maßgeblicher Explore-Plan-Implement-Commit-Methode. Von Anthropics vier Phasen erweitere ich Plan zu vier Mikroschritten gegen Sykophantie. Jeder Schritt unterbindet eine eigene Fehlerklasse: Überspringt man einen davon, entsteht ein vorhersehbarer Fehlertyp.
Hier ist die Begründung, orientiert an der Methode, mit der Anthropic Claude in seiner offiziellen Dokumentation anleitet.
Wenn du Claude direkt zum Code springen lässt, kann eine Lösung für das falsche Problem herauskommen. Verwende den Plan-Modus, um Erkundung und Ausführung voneinander zu trennen.
— Claude Code Docs, https://code.claude.com/docs/en/best-practices
Die Dokumentation empfiehlt einen Arbeitsablauf mit vier Phasen: Explore, Plan, Implement, Commit. Mein vierstufiger Zyklus ist eine Spezialisierung der Plan-Phase, um Sykophantie entgegenzuwirken. Von Anthropics vier Phasen erweitere ich eine zu vier Mikroschritten: Lösungen verbieten, Präzedenzfälle finden, den Plan schreiben und ihn selbst überprüfen. Daraus entsteht ein detaillierter Plan, der anschließend in die Phasen Implement und Commit einfließt. Das geht schief, wenn du einen der vier Schritte überspringst: | Übersprungen | Was dabei herauskommt | |----|----| | Schritt 1 (Fakten) | Eine Lösung für das Problem einer anderen Person: Claude hat das Symptom anhand eines Musters erraten und ist in die falsche Richtung gegangen | | Schritt 2 (Präzedenzfälle) | Eine erfundene Lösung aus „allgemeinem Wissen“: Im Referenzfall funktioniert sie, in der Realität geht etwas kaputt | | Schritt 3 (Plan) | Implementierung ohne Risikoanalyse: Tests schlagen fehl, das Refresh-Token geht kaputt und du erfährst es von den Nutzern | | Schritt 4 (Selbstprüfung) | Ein Plan mit zwei oder drei unbegründeten Annahmen: eine nicht vorhandene Bibliothek, eine nicht angegebene Variable | Die Tabelle macht es deutlich: Jeder Schritt unterbindet eine eigene Fehlerklasse. Du brauchst alle vier, weil jeder eine andere Kategorie abfängt. Wenn die Aufgabe klein genug scheint, dass zwei Schritte reichen, ist sie tatsächlich klein – und du brauchst überhaupt keinen Plan-Modus. ## Wie `plans/`, der `/goal`-Befehl und die nächsten Schritte zusammenpassen
Das Wichtigste Die 4 Schritte existieren nicht losgelöst. Sie funktionieren innerhalb eines Systems aus Plan-Modus, dem Ordner `plans/` im Repository und dem Befehl `/goal`. Der Plan-Modus stellt den Modus bereit. Der Ordner `plans/` sorgt für Beständigkeit. `/goal` ermöglicht Automatisierung. Fehlt eine dieser drei Ebenen, verliert der Zyklus die Hälfte seines Nutzens.
Der Zyklus funktioniert in einem System, in dem Folgendes vorhanden ist: 1. Der Plan-Modus ist aktiviert (zweimal Umschalt+Tab in Claude Code). 2. Im Repository gibt es einen Ordner `plans/`, in dem Pläne gespeichert werden. 3. Optional gibt es den Befehl `/goal` zur autonomen Umsetzung langer Pläne. Zum Ordner `plans/` im Einzelnen. Nach Schritt 3 erhältst du eine Datei `plans/2026-05-27-fix-magic-link.md` mit Phasen und Checkboxen. Sie ist ein Artefakt. Öffne sie eine Woche später, und du erinnerst dich, warum du diesen Ansatz gewählt hast. In drei Monaten findest du eine ähnliche Aufgabe und verwendest ihn wieder. In sechs Monaten zeigst du sie einem Kollegen und ersparst ihm zwei Wochen Einarbeitung. Der Ordner `plans/` gehört zum Konzept eines [„Second Brain“ in Claude Code](https://ailoot.ai/blog/de/claude-code-second-brain/). Zu `/goal` im Einzelnen. Nachdem du die vier Schritte abgeschlossen und den Plan genehmigt hast, verlässt du den Plan-Modus und gibst Folgendes ein: ``` /goal führe alle Phasen aus plans/2026-05-27-fix-magic-link.md aus, alle Tests in test/auth bestehen oder stoppe nach 30 Durchläufen ``` Halte bei einer lokalen Claude-Code-Sitzung Terminal, Rechner und Netzwerkverbindung aktiv. Klappe den Laptop nur zu, wenn du ausdrücklich eine unterstützte Einrichtung zum Wachhalten eingerichtet hast. Prüfe bei der Rückkehr den Verlauf: Er kann Abschluss, Durchlauflimit, Berechtigungsanfrage oder Fehler zeigen. Ein Ziel garantiert keinen Fortschritt im Ruhezustand. Ohne den vierstufigen Zyklus verbraucht `/goal` Tokens für nutzlose Iterationen. Mit dem vierstufigen Zyklus führt `/goal` einen fertigen Plan zu bestandenen Tests. Wie es von hier aus weitergeht. Wenn du gerade erst mit Claude Code anfängst, probiere den Zyklus bei deiner nächsten nichttrivialen Aufgabe aus. Nicht bei einem Tippfehler. Nimm etwas, das 3+ Dateien betrifft oder ein Verhalten einschließt, das du nicht vollständig verstehst. Nimm die obigen Prompts, kopiere sie und ergänze deine eigenen Angaben. Du wirst merken, wie sich die Rollback-Rate verändert. Wenn du den Plan-Modus bereits verwendest, füge deinem Repository einen Ordner `plans/` hinzu. Lege für dich ein Dateinamensformat fest: `YYYY-MM-DD-feature-name.md`. In einem Monat hast du 20–30 Dateien, in sechs Monaten mehr als hundert. So entsteht das Second Brain des Projekts – eine lebendige Entscheidungshistorie. Wenn du dich eingehender mit dem Kontextmanagement vor dem Prompt beschäftigen möchtest, habe ich [Context Engineering in Claude Code](https://ailoot.ai/blog/de/context-engineering/) als eigene Disziplin behandelt. Wenn du bereits den Plan-Modus und `plans/` hast, probiere `/goal` bei einer autonomen Aufgabe aus. Wähle eine Aufgabe, die du normalerweise in 30–40 Minuten von Hand erledigen würdest. Lass sie die vier Schritte durchlaufen, speichere den Plan, starte `/goal` und halte lokales Terminal und Rechner wach. Soll die Arbeit bei ausgeschaltetem Rechner weiterlaufen, nutze zuerst einen ausdrücklich eingerichteten Fern- oder Cloud-Ausführungsweg und bestätige, dass die Aufgabe dort läuft.
### Quellen - [Anthropic Engineering – Best Practices für Claude Code](https://code.claude.com/docs/en/best-practices) - [Anthropic Engineering – Postmortem vom 23. April zu Qualitätsberichten](https://www.anthropic.com/engineering/april-23-postmortem) - [Anthropic Docs – Halluzinationen reduzieren](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations) - [Anthropic Docs – Berechtigungsmodi (Plan-Modus)](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs – Befehl /goal](https://code.claude.com/docs/en/goal)
Du kannst die Arbeit mit KI auf [Ailoot](https://ailoot.ai/) fortsetzen.
## Fragen und Antworten ### Arbeitet ein lokales /goal bei zugeklapptem Laptop weiter? Nur wenn der Host wach bleibt und der Terminalprozess weiterläuft; gewöhnlicher Ruhezustand kann lokale Arbeit anhalten. Halte Rechner und Netzwerk verfügbar oder prüfe den tatsächlichen Start in einer separaten Fern- oder Cloud-Umgebung. ### Wann lohnt sich der Vier-Prompt-Zyklus? Wenn Symptom, betroffene Dateien oder Ansatz unklar und falsche Änderungen teuer sind. Beginne mit einem reproduzierbaren Symptom und fehlenden Nachweisen, suche Quellen, schreibe den Plan und prüfe seine Annahmen. Ein einfacher Tippfehler braucht diesen Zyklus meist nicht. ## Ailoot · Das Unternehmen und sein Projektportfolio Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle. Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe. Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.