Zurück zu Anleitungen
Builder

Best Practices für Claude Code: Gewohnheiten für bessere Ergebnisse

12 Min. Lesezeit

Läuft eine Claude-Code-Sitzung schlecht, liegt es fast immer an einem von zwei Dingen. Claude hat etwas anderes gebaut, als du im Kopf hattest, oder es hat „fertig“ gesagt, obwohl die Arbeit es nicht war. Beides ist keine Schwäche des Werkzeugs. Beides kommt von Informationen, die Claude nicht hatte.

Sag Claude, was es nicht sehen kann, und gib ihm eine Möglichkeit, seine eigene Arbeit zu prüfen.

Die folgenden Gewohnheiten sind die wichtigsten, in der Reihenfolge, in der du sie brauchst. Sie setzen voraus, dass du Claude Code bereits installiert und eine Sitzung ausgeführt hast. Wenn nicht, beginne mit Claude Code für Einsteiger.

So läuft eine gute Sitzung

Claude Code arbeitet in einer Schleife: Es sammelt Kontext, handelt und prüft das Ergebnis. Du sitzt ebenfalls in dieser Schleife. Du kannst jederzeit eingreifen, um zu lenken. Jede Gewohnheit in diesem Leitfaden verbessert einen Teil der Schleife.

Gewohnheit 1: Sag Claude nur, was es nicht sehen kann

Claude beginnt jede Aufgabe damit, deinen Code zu lesen, und das kann es gut. Es findet deinen Ordneraufbau, dein Test-Framework und die Art, wie bestehende Komponenten gebaut sind, meist schneller, als du sie erklären könntest. Das heißt: Das meiste, was du aufschreiben möchtest, ist bereits bekannt.

Nicht finden kann es, was nie im Repo stand: eine Entscheidung aus einem Meeting, einen Deploy-Prozess, der nur in einem Kopf existiert, die Umgebungsvariable, die deine Integrationstests brauchen. Stelle zwei Fragen, bevor du eine Zeile in einen Prompt oder in CLAUDE.md schreibst:

  • Könnte Claude das herausfinden, indem es den Code liest?

  • Würde es auch wirklich nachsehen?

Lauten beide Antworten Ja, lass es weg. Lange Listen offensichtlicher Fakten begraben den einen Fakt, auf den es ankommt. Der nächste Leitfaden, CLAUDE.md erklärt, zeigt, wohin die dauerhaften gehören.

Gewohnheit 2: Schreibe einen konkreten Prompt

Ein konkreter Prompt wirkt aus demselben Grund: Er gibt Claude Informationen, die es nicht hat. Nenne die Datei oder den Bereich, beschreibe das Symptom und sag, woran man „behoben“ erkennt. Bevorzugst du von zwei vernünftigen Vorgehensweisen eine, sag welche, denn das kann Claude nicht aus dem Code lesen.

StattBesser
fix the login bugusers report login fails after the session times out. look at token refresh in src/auth/, write a failing test that reproduces it, then fix it
add a calendar widgetfollow the pattern in HotDogWidget.php and build a calendar widget that lets you pick a month and page between years. no new libraries
clean up this filesplit utils.ts into one file per concern. keep every export name the same so no import breaks

Die besseren Prompts nennen den Ort, den Beweis und die Grenzen. Sie sind nicht um der Länge willen länger. Jede ergänzte Wendung beseitigt eine Vermutung.

Prompt
“

Checkout fails for users with an expired card. The relevant code is in src/payments/. Investigate first and tell me what you find. Do not change anything until I say so.

”

Beachte die Delegation in diesem Prompt. Du gibst Kontext und Richtung und lässt Claude herausfinden, welche Dateien es liest und welche Befehle es ausführt.

Zauberwörter gibt es nicht

Wendungen wie „think step by step“ oder „be thorough“ sind gewöhnlicher Prompt-Text, keine Schalter. Wie intensiv Claude nachdenkt, bestimmt die Effort-Stufe, die du über die Modelleinstellungen änderst, nicht die Formulierung.

Gewohnheit 3: Übergib die Sache, statt sie zu beschreiben

Hast du bereits, was Claude braucht, gib es direkt. Eine Beschreibung eines Fehlers zu tippen ist langsamer und ungenauer als der Fehler selbst.

  1. 1

    Eine Datei mit @ referenzieren

    Tippe @ und den Pfad, etwa @src/auth/session.ts, um den Inhalt dieser Datei in deine Nachricht zu übernehmen.

  2. 2

    Ein Bild einfügen

    Füge einen Screenshot des gewünschten Designs oder des Fehlers ein, den du siehst. Claude liest Bilder.

  3. 3

    Befehlsausgabe weiterleiten

    Schicke Ausgabe direkt aus deiner Shell, zum Beispiel cat error.log | claude -p "what's going on here".

Gewohnheit 4: Lass Claude dich interviewen, wenn du unsicher bist

Du musst nicht den ganzen Plan ausarbeiten, bevor du promptest. Ist eine Idee noch unscharf, bitte Claude, dich zu befragen, bis es die Spezifikation schreiben kann:

Prompt
“

I want to add rate limiting to the public API but have not thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.

”

Claude kommt mit Fragen zu den Teilen zurück, die du noch nicht festgelegt hast: pro Nutzer oder pro Schlüssel, was mit Anfragen über dem Limit passiert, was nicht dazugehört. Passen die Antworten zusammen, schreibt es SPEC.md. Starte eine frische Sitzung, um auf Basis dieser Datei zu bauen, damit der Bau mit sauberem Kontext und einer schriftlichen Definition von „fertig“ beginnt.

Ergänze bei allem mit echtem Risiko den Planschritt aus dem Leitfaden zu Berechtigungen. Berechtigungsmodi und Plan-Modus von Claude Code erklärt zeigt, wie Claude erkundet und vorschlägt, bevor es bearbeitet.

Gewohnheit 5: Gib Claude eine Prüfung zum Ausführen

Diese Gewohnheit hat die größte Wirkung. Claude hört auf, wenn die Arbeit fertig aussieht. Hat es nichts zum Ausführen, das ihm sagt, ob die Arbeit tatsächlich fertig ist, bleibt ihm nur „sieht fertig aus“. In der Praxis wirst du zur Testsuite, und jeder Fehler wartet darauf, dass du ihn bemerkst.

Gib ihm etwas, das mit bestanden oder durchgefallen zurückkommt, und Claude kann die Schleife selbst schließen: Es nimmt die Änderung vor, führt die Prüfung aus, liest den Fehlschlag, behebt ihn und führt die Prüfung erneut aus.

Die Prüfung kann fast alles sein, dessen Ergebnis Claude lesen kann:

  • eine Testdatei
  • der Exit-Code eines Builds
  • ein Linter oder eine Typprüfung
  • ein Skript, das die Ausgabe mit einem gespeicherten Beispiel vergleicht
  • ein Browser-Screenshot neben dem Mockup

Hat dein Projekt bereits eine, ist die nützlichste Zeile in deiner CLAUDE.md der Befehl, der sie ausführt. Wie streng du die Prüfung machst, liegt bei dir:

StufeWieGut für
Im Promptrun the auth tests after, and keep going until they passJede Aufgabe, ohne Einrichtung
Als Ziel/goal all tests in tests/auth pass and lint is clean legt eine Bedingung fest, die ein separates Modell nach jedem Zug prüftLange Läufe, die niemand beobachtet
Als Stop-HookEin Skript, das läuft, wenn Claude fertig werden will, und es zurück an die Arbeit schickt, wenn es fehlschlägtEine Regel, die immer gelten muss
Durch eine frische Prüferin/code-review prüft den Diff in einem neuen Subagenten, der dein Gespräch nie gesehen hatEine zweite Meinung

Die eine Prüfung für den Anfang

Trage den genauen Testbefehl in CLAUDE.md ein und beende dann deine Prompts mit „run it and show me the output“. Allein das behebt die meisten „es hat gesagt, es sei fertig“-Probleme.

Gewohnheit 6: Verlange Belege, keine Beruhigung

„Alle Tests bestehen“ allein sagt dir sehr wenig. Bitte Claude, den ausgeführten Befehl und die Ausgabe zu zeigen, oder den Screenshot. Die Ausgabe zu lesen geht schneller, als die Prüfung selbst auszuführen, und bei einer Sitzung, die du nicht beobachtet hast, ist es der einzige Beweis, den du hast.

Sagt Claude, es sei fertig, kannst du außerdem /verify ausführen, wobei Claude die App baut, startet und sich das Ergebnis ansieht. Das fängt Probleme, die Tests und Typprüfungen übersehen, etwa eine Seite, die technisch lädt, aber sichtbar kaputt ist.

In Claude Tutorial

Die Arbeit zu prüfen gehört zur Fähigkeit

Zu wissen, was zu überprüfen ist, und Belege zu verlangen, gilt für jede Art von Arbeit mit Claude, und die App übt es an echten Aufgaben, nicht nur an Code.

Bald verfügbar
Laden imApp Store
ERHÄLTLICH BEIGoogle Play

Gewohnheit 7: Beobachte die erste Minute und lenke früh

Keine Einrichtung ersetzt es, den Anfang einer Aufgabe zu beobachten und einzugreifen, wenn Claude in eine Richtung läuft, die du nicht wolltest. Lerne diese Steuerungen auswendig:

  • Esc stoppt Claude mitten in der Aktion und behält alles bis zu diesem Punkt, sodass du umlenken kannst, ohne Arbeit zu verlieren.
  • Tippen und Enter drücken, während Claude arbeitet, stellt eine Korrektur in die Warteschlange. Claude liest sie, sobald seine laufenden Werkzeugaufrufe fertig sind, und passt sich an.
  • /rewind, oder zweimal Esc bei leerer Eingabe, öffnet ein Menü, in dem du Code, Gespräch oder beides auf einen früheren Punkt zurücksetzt. So ist es risikoarm, zuerst den mutigeren Ansatz auszuprobieren.
  • /btw stellt eine kurze Nebenfrage, ohne sie dem Gesprächsverlauf hinzuzufügen.

Rewind betrifft von Claude bearbeitete Dateien, nicht alles

Dateien, die nur durch einen Shell-Befehl geändert wurden, werden nicht wiederhergestellt, ebenso wenig Datenbanken oder Deployments. Rewind arbeitet neben git. Es ersetzt es nicht.

Gewohnheit 8: Nach zwei gescheiterten Korrekturen neu anfangen

Hast du dasselbe zweimal korrigiert und es ist immer noch falsch, fügt eine dritte Korrektur einem Gespräch etwas hinzu, das bereits zwei gescheiterte Versuche enthält, die Claude immer wieder liest. Führe /clear aus und schreibe einen neuen Prompt, der enthält, was du gelernt hast.

Es fühlt sich an, als verlörest du Fortschritt. Fast immer funktioniert es besser. /clear zwischen unabhängigen Aufgaben ist außerdem für sich eine gute Gewohnheit, denn ein fokussierter Kontext liefert bessere Antworten und kostet weniger.

Für Arbeit über mehrere Tage benenne die Sitzung mit /rename oauth-migration und nimm sie später mit claude --resume oauth-migration wieder auf. claude --continue setzt die jüngste fort.

Gewohnheit 9: Halte Regeln kurz und verlagere harte Regeln aus dem Fließtext

Alles, was du Claude in einem Prompt oder in CLAUDE.md sagst, ist eine Bitte, die das Modell liest und meist befolgt. Ein Hook, eine Deny-Regel oder eine verwaltete Einstellung ist anders: Claude Code setzt sie jedes Mal durch, egal was das Modell entscheidet.

Nutze die erste Art für fast alles, denn Claude beurteilt gut, wann eine Richtlinie passt. Nutze die zweite Art für die wenigen Regeln, die keine Ausnahmen haben dürfen, etwa „never edit the generated client“ oder „always run the formatter after creating a file“.

Ein Signal, das du beachten solltest

Fügst du einer CLAUDE.md-Zeile immer mehr Nachdruck hinzu und Claude übersieht sie trotzdem, gehört die Zeile in einen Hook. Auch das Umgekehrte gilt: Hast du Hooks für Dinge gebaut, die nur Vorlieben sind, lösche sie.

Wird deine Sitzung lang, sieh mit /context nach, was Platz belegt. Claude verdichtet das Gespräch automatisch, und eine Zusammenfassung kann ausführliche Anweisungen vom Anfang verlieren. Dauerhafte Regeln gehören in CLAUDE.md, die nach /compact erneut von der Festplatte gelesen wird. Du kannst die Zusammenfassung auch lenken: /compact focus on the API changes.

Ratschläge, die du nicht mehr befolgen musst

Manche ältere Tipps waren Notlösungen für Dinge, die frühere Modelle nicht konnten. Aktuelle Modelle haben aufgeholt, und die Notlösungen kosten jetzt mehr, als sie bringen.

Alter RatWarum du ihn lassen kannst
Das Kontextfenster aggressiv verwaltenDie meisten aktuellen Modelle haben ein sehr großes Fenster, und die Verdichtung läuft automatisch. /clear zwischen Aufgaben lohnt sich weiterhin.
IMPORTANT oder GROSSBUCHSTABEN in RegelnSchlichte Formulierung wird befolgt, und Nachdruck lässt Claude die Regel übertreiben. Eine Regel, die nicht nachgeben darf, ist ein Hook.
„think hard“ oder „be thorough“ sagenEffort ist die eigentliche Steuerung. Diese Wendungen stupsen nur innerhalb davon an.
Claude sagen, es solle weitermachen und nicht faul seinModelle machen bei einer vereinbarten Aufgabe weiter. Claude eine Prüfung zum Bestehen zu geben ist etwas anderes und weiterhin sinnvoll.
Deine Architektur in CLAUDE.md beschreibenClaude liest das Repo. Schreibe nur, was es nicht finden kann.
Einen Subagenten für eine bessere Antwort nutzenDieselbe Aufgabe zu delegieren verbessert sie nicht. Eine frische Prüferin hilft, weil sie deine Überlegungen nicht gesehen hat, und das ist etwas anderes.

Häufige Fragen

Wie bekomme ich bessere Ergebnisse von Claude Code?

Gib ihm Informationen, die es nicht sehen kann, schreibe konkrete Prompts, übergib Dateien und Fehler, statt sie zu beschreiben, und gib ihm eine Prüfung, die besteht oder durchfällt. Lenke dann früh mit Esc und führe /clear aus, wenn Korrekturen nicht helfen.

Warum sagt Claude Code, es sei fertig, obwohl es das nicht ist?

Es hört auf, wenn die Arbeit fertig aussieht. Beweist nichts, was es ausführen kann, das Gegenteil, bleibt ihm nur „sieht fertig aus“. Gib ihm einen Test, Build oder Linter zum Ausführen und bitte es, die Ausgabe zu zeigen.

Soll ich jedes Mal den Plan-Modus nutzen?

Nein. Nutze ihn, wenn eine Änderung viele Dateien berührt, wenn du den Code noch nicht verstehst oder wenn ein Fehler teuer wäre. Bei einer Änderung in einem Satz bitte direkt darum.

Wann sollte ich /clear nutzen?

Zwischen unabhängigen Aufgaben und nach zwei gescheiterten Korrekturen desselben Problems. Beginne den neuen Prompt mit dem, was du gelernt hast.

Was ist der Unterschied zwischen CLAUDE.md und einem Hook?

CLAUDE.md sind Anweisungen, die Claude liest und meist befolgt. Ein Hook ist ein Skript, das Claude Code an einem festen Punkt ausführt, sodass es passiert, egal was das Modell entscheidet. Nutze einen Hook für eine Regel ohne Ausnahmen.

Wie nehme ich die Claude-Code-Sitzung von gestern wieder auf?

Führe claude --continue für das jüngste Gespräch aus oder claude --resume, um eines auszuwählen. Hast du eine Sitzung mit /rename benannt, nutze claude --resume <name>.

Deine Checkliste der Gewohnheiten

  • Dein Prompt nennt den Ort, das Symptom oder Ziel und woran man „fertig“ erkennt

  • Claude hat einen Befehl, den es ausführen kann und der mit bestanden oder durchgefallen zurückkommt, und du hast darum gebeten, die Ausgabe zu sehen

  • Du hast die erste Minute beobachtet und kennst Esc, /rewind und /clear

  • CLAUDE.md enthält nur, was Claude im Code nicht finden kann, und Regeln, die nie nachgeben dürfen, sind Hooks

  • Du liest den Diff vor dem Committen, wie den Pull Request einer Kollegin

Weiterlesen