Dein KI-Agent läuft. Er antwortet, er ruft Werkzeuge auf und liefert Ergebnisse. Aber wenn du deinen KI-Agenten noch nie systematisch getestet hast, weißt du eigentlich nicht, ob er wirklich das Richtige tut.
Stell dir vor, du bekommst diese Nachricht von einem Nutzer: "Irgendetwas stimmt nicht mehr. Früher war er besser." Was machst du damit? Du hast keine Benchmarks, keine Testfälle und kein System, das dir zeigt, wo genau es schiefläuft. Du fängst an zu raten.
Genau das ist der reaktive Kreislauf, in dem die meisten Agenten-Bauer feststecken. Die Lösung hat einen Namen: Evals.
Mir ist das mit meinem Blog-Agenten passiert. Drei Monate lang hat er Artikel ohne externe Links produziert. Kein Nutzer hat es gemeldet. Ich habe es nicht bemerkt. Erst als ich den ersten Code-Prüfer aufgesetzt habe, sah ich, dass fast jeder Artikel gegen meine eigenen Richtlinien verstößt.
Ohne Evals fliegst du blind
Ohne systematische Tests arbeitest du ausschließlich reaktiv. Das bedeutet konkret:
- Du erfährst Probleme erst, wenn Nutzer sie melden.
- Eine einzelne Anpassung an der Agenten-Anweisung (dem sogenannten System-Prompt, also dem Text, der dem Agenten bei jedem Start sagt, wer er ist und was er tun soll) verbessert eine Sache und verschlechtert heimlich zwei andere.
- Du kannst echtes Feedback kaum von subjektivem Eindruck trennen.
- Du hast keine Möglichkeit zu prüfen, ob eine Verbesserung wirklich eine Verbesserung ist.
Das ist kein theoretisches Problem. Agenten, die ursprünglich gut funktionierten, werden schlechter, weil neue Anforderungen dazukommen. Der System-Prompt wird länger und unübersichtlicher. Und niemand hat ein objektives Maß, an dem er die Qualität messen kann.
"Fühlt sich schlechter an" ist keine Grundlage für Entscheidungen. Evals schon.
# Neuer Artikel? Du erfährst es als Erstes.
# Kein Spam. Ein kurzes Mail, wenn etwas erscheint.
Was Evals eigentlich sind
Evals (kurz für Evaluations, also systematische Bewertungstests) messen, wie gut ein KI-Agent eine definierte Aufgabe erfüllt. Stell sie dir vor wie eine Qualitätsprüfung am Ende einer Produktionslinie: Du definierst vorher, was ein gutes Ergebnis aussieht und lässt deinen Agenten dieselben Aufgaben immer wieder durchlaufen. So siehst du sofort, wenn etwas schlechter wird.
Was Evals von normalen Software-Tests unterscheidet: KI-Agenten sind nicht berechenbar im klassischen Sinne. Dieselbe Eingabe kann unterschiedliche gültige Ausgaben erzeugen. Deshalb braucht es ein flexibleres Bewertungssystem.
Evals bestehen aus zwei Teilen:
- Aufgaben definieren Szenarien: Was soll der Agent tun? Was ist die Eingabe?
- Bewerter (Grader) kodieren die Erwartung: Wie sieht eine akzeptable Antwort aus?
Der wichtigste Nebeneffekt: Evals zwingen dich zu definieren, was Erfolg eigentlich bedeutet. Wer das nicht in Worte fassen kann, kann auch keinen zuverlässigen Agenten bauen.
KI-Agent testen: die sechs Schritte
Du brauchst kein Programmierstudium und keinen Entwickler im Team. Was du brauchst: Claude Code und echte Beispiele aus deinem Anwendungsfall. Die folgenden sechs Schritte zeigen dir, wie du ein funktionierendes Eval-System aufbaust.
Schritt 1: Erst beobachten, dann definieren
Der häufigste Fehler: du setzt dich hin und fragst dich sofort, "Was will ich messen?" Besser ist es, deinen Agenten zuerst laufen zu lassen und zu schauen, was er wirklich tut.
Nimm fünf bis zehn echte Eingaben aus deinem Alltag. Das könnten echte Kundenanfragen sein, reale Support-Tickets oder typische Aufgaben, die der Agent lösen soll. Lass den Agenten sie bearbeiten. Dann schaust du dir die Ausgaben an und schreibst auf, was dich stört.
Diese Liste muss nicht schön sein:
- klingt wie eine Vorlage
- ignoriert das spezifische Problem des Kunden
- Preis fehlt komplett
- viel zu lang
- hat "Sehr geehrte Damen und Herren" geschrieben obwohl ich das hasse
Das ist dein Ausgangspunkt. Aus dieser Beobachtungsliste entstehen deine Evals. Nicht umgekehrt.
Warum das so wichtig ist: Du kannst nicht sinnvoll messen, was du nicht erst beobachtet hast. Wer Evals baut, bevor er seinen Agenten wirklich bei der Arbeit gesehen hat, baut am Problem vorbei.
Schritt 2: Den richtigen Prüfer wählen
Nicht jede Frage aus deiner Beobachtungsliste lässt sich auf die gleiche Weise beantworten. Je nach Art der Frage brauchst du einen anderen Prüfer-Typ.
Deterministische Code-Prüfer
Für alles, was sich zählen oder eindeutig abgleichen lässt. Diese Prüfer sind schnell, günstig und vollständig berechenbar. Kein KI-Urteil, keine Interpretation. Entweder stimmt die Bedingung oder nicht.
Du beschreibst Claude Code, was du prüfen willst und es schreibt dir das Script in Sekunden:
angebot = open("angebot.txt").read()
checks = [
("Preis vorhanden", "€" in angebot),
("Unter 600 Wörter", len(angebot.split()) < 600),
("Kein generische Anrede", not angebot.startswith("Sehr geehrte")),
]
for name, bestanden in checks:
print("✓" if bestanden else "✗", name)
Ergebnis:
✓ Preis vorhanden
✓ Unter 600 Wörter
✗ Keine generische Anrede
Hundert Angebote in einer Sekunde geprüft. Null Interpretationsspielraum.
Schwachpunkt: Qualität können sie nicht beurteilen. Ob der Text wirklich überzeugend klingt, ob er das Problem des Kunden trifft, darüber sagt ein Code-Prüfer nichts.
Modellbasierte Prüfer (LLM als Richter)
Hier übernimmt ein zweites KI-System die Rolle des Richters. Du gibst ihm Kriterien und eine Ausgabe, es bewertet auf einer Skala. Für alles, was Urteilsvermögen braucht:
- Geht die Antwort auf die konkrete Situation ein oder ist sie generisch?
- Würde ein professionelles Unternehmen diese E-Mail wirklich so verschicken?
- Ist der Nutzen klar formuliert oder wird nur aufgelistet, was gemacht wird?
Gut für Qualitätsurteile. Braucht aber Kalibrierung, dazu kommt Schritt 4.
Zwei besonders nützliche Varianten:
Paarweiser Vergleich: Du legst dem Richter zwei Ausgaben vor und fragst, welche besser ist. Nützlich, wenn du keine klare Rubrik definieren kannst.
Multi-Richter-Konsens: Drei unabhängige KI-Richter urteilen, die Mehrheit gewinnt. Das reduziert die Schwankungen einzelner Urteile deutlich.
Menschliche Prüfer
Am teuersten und aufwendigsten. Aber unersetzlich für die Kalibrierung: Schau dir Ausgaben an, die deinen Richter verwirren und entscheide selbst. So erkennst du, ob dein Eval-System noch das misst, was du messen willst.
In der Praxis kombinierst du alle drei: Code-Prüfer für objektive Mindestanforderungen, LLM-Richter für Qualitätsurteile und gelegentlich menschliche Überprüfung, wenn du merkst, dass etwas nicht stimmt.
Schritt 3: Deinen ersten Eval aufbauen
Nehmen wir ein konkretes Beispiel: ein Agent, der Angebote für Kundenanfragen schreibt. Ob eine E-Mail wirklich gut ist, lässt sich nicht einfach maschinell messen. Es gibt kein "richtig" oder "falsch" wie bei einer Rechenaufgabe.
Aber du kannst trotzdem definieren, was ein gutes Angebot ausmacht.
So sieht ein einfaches Eval-Setup für Claude Code aus:
Erstelle einen Ordner evals/ in deinem Projekt mit drei Dingen:
evals/
kriterien.md ← deine Beobachtungsliste aus Schritt 1
testfaelle/
anfrage-01.md ← eine echte Kundenanfrage
anfrage-02.md
anfrage-03.md
ergebnisse.md ← deine Bewertungstabelle
Jede Testfall-Datei enthält einfach eine echte Eingabe:
Hallo Wolfgang, ich bin Marketingleiterin bei einem mittelständischen
Pharmaunternehmen und brauche dringend eine neue Website. Unser alter
Auftritt ist von 2015 und funktioniert auf dem Handy kaum. Können Sie
mir sagen, was das kostet und wie schnell Sie das umsetzen könnten?
Dann läuft der Prozess so:
- Du gibst Claude Code den Testfall und lässt deinen Agenten die Antwort schreiben.
- Du kopierst die Ausgabe.
- Du öffnest eine neue Claude-Sitzung und gibst ihr die Kriterien aus
evals/kriterien.md, die ursprüngliche Kundenanfrage und die Agentenantwort. - Claude bewertet, du trägst den Score in
evals/ergebnisse.mdein.
Das klingt manuell. Das ist es auch. Für die ersten fünf bis zehn Testfälle ist das genau richtig. Du lernst dabei, was deine Evals wirklich messen und ob sie das messen, was dir wichtig ist.
Messbare Mindestanforderungen prüft ein einfacher Code-Prüfer sofort und ohne Kosten für dich:
- Enthält das Angebot einen Preis?
- Ist es kürzer als 600 Wörter?
- Enthält es einen klaren nächsten Schritt (Termin vereinbaren, zurückschreiben)?
- Beginnt es mit dem Namen des Kunden?
Wenn ein Angebot diese Grundbedingungen nicht erfüllt, braucht es gar keinen weiteren Test.
Qualitätsfragen übernimmt der LLM-Richter mit diesem Auftrag:
Hier sind meine Qualitätskriterien: [Inhalt von kriterien.md einfügen]
Hier ist die Kundenanfrage: [Anfrage einfügen]
Hier ist das generierte Angebot: [Angebot einfügen]
Schritt 1: Nenne alle Hinweise, dass dieses Angebot auf die spezifische
Situation des Kunden eingeht.
Schritt 2: Nenne alle Hinweise, dass es generisch ist oder die Anfrage ignoriert.
Schritt 3: Vergib eine Note von 1 bis 5. (5 = vollständig individuell,
1 = reines Template)
Die Reihenfolge ist dabei kein Zufall. Warum das so wichtig ist, erklärt Schritt 4.
Deine Kriterien müssen nicht schön formuliert sein. Du brainstormst einfach runter, was für dich ein gutes Angebot ausmacht. Roh, unformatiert, so wie es dir in den Sinn kommt:
- klingt nicht wie eine Vorlage
- geht auf das Problem ein das der Kunde beschrieben hat
- nennt konkret was ich mache nicht nur "Beratung"
- Preis ist klar
- nächster Schritt ist eindeutig
- nicht zu lang, kommt auf den Punkt
- kein "Sehr geehrte Damen und Herren"
Diese Liste gibst du dem LLM-Richter mit. Er weiß, was er daran ausrichten soll. Du musst daraus keine perfekte Rubrik formulieren.
Dasselbe Prinzip für einen anderen Kontext: Blog-Artikel-Qualitätsprüfung
Evals funktionieren genauso für Inhalte wie für Agenten-Outputs. Wenn du einen Blog-Artikel nach einem festen Workflow schreibst, hast du die Kriterien bereits. Du musst sie nur noch in einen Eval-Bogen verwandeln.
Messbare Pflichtfelder prüft ein Code-Prüfer sofort und ohne Kosten für dich. Du sagst Claude Code einfach, was du hast und was du prüfen willst:
Ich habe hier einen fertigen Blog-Artikel als Text-Datei.
Schreibe mir ein Script, das folgendes automatisch prüft:
- Ist der Meta-Titel zwischen 50 und 60 Zeichen?
- Ist die Meta-Description kürzer als 160 Zeichen?
- Enthält der Text mindestens 3 Links zu meiner eigenen Website?
- Enthält der Text mindestens 3 Links zu externen Quellen?
- Sind alle verlinkten URLs erreichbar (kein 404)?
- Kommt das Wort "KI-Agent testen" in den ersten 100 Wörtern vor?
- Hat jedes Bild eine Bildbeschreibung?
- Gibt es am Ende einen FAQ-Abschnitt?
Das Format des Files ist dabei egal. Claude erkennt, womit es arbeitet und schreibt das passende Script. Je spezifischer du bist, desto besser. Wenn du sagst "das ist eine MDX-Datei mit YAML-Frontmatter", bekommt du ein präziseres Script als mit "irgendeine Textdatei". Aber beides funktioniert. Du führst es aus. Fertig. Kein Copy-Paste, kein manuelles Nachzählen.
Ein Artikel, der hier scheitert, braucht keinen LLM-Richter mehr.
Qualitätsfragen für den LLM-Richter:
- Enthält der Einstieg einen konkreten Hook ohne KI-Klischees wie "In der heutigen schnelllebigen Welt..."?
- Beantwortet der Artikel die Suchintention vollständiger als die Top-5-Suchergebnisse?
- Sind eingebaute Statistiken mit Quellenangaben belegt und nicht einfach behauptet?
- Klingt der Text nach einem Menschen, der einem Freund erklärt, oder nach generiertem Inhalt?
- Sind externe Links wirklich zitierbare Quellen oder nur generische Verweise?
Das Besondere: Diese Checkliste entspricht genau dem Workflow, nach dem der Artikel produziert wurde. Du verwandelst deine Produktionsregeln direkt in einen Eval-Bogen. Die Kriterien sind schon da. Du musst sie nur noch in Fragen formulieren.
Schritt 4: Den LLM-Richter kalibrieren
Modellbasierte Prüfer haben ein hartnäckiges Problem: Anchoring Bias, also einen Anker-Effekt. Wenn du dem Richter zuerst eine Note abfragst und danach nach Begründungen fragst, tut er alles, um diese erste Note zu rechtfertigen. Selbst wenn die Ausgabe objektiv schlecht war.
Das Ergebnis sind Bewertungen, die nicht messen, was sie messen sollen.
Die Lösung ist verblüffend einfach. Drehe die Reihenfolge um:
- Zuerst: "Nenne mir alle Gründe, warum diese Ausgabe gut ist. Nenne mir alle Gründe, warum sie schlecht ist."
- Danach: "Gib mir basierend auf all diesen Argumenten jetzt eine Note."
Begründungen vor der Note. Nie danach.
So urteilt der Richter auf Basis der Argumente und nicht auf Basis einer vorschnellen ersten Einschätzung. Der Richter-Auftrag in Schritt 3 folgt exakt dieser Logik: Schritt 1 und 2 sammeln Beweise, Schritt 3 fällt das Urteil.
Ankerpunkte für konsistentere Noten
Ein weiteres Problem: Ein LLM-Richter ohne Referenzpunkte vergibt willkürliche Noten. Was ist eine 3? Was ist eine 5? Du weißt es nicht, er auch nicht.
Gib ihm Beispiele als Anker. Zeig ihm eine Ausgabe, die du für gut hältst und eine, die du für schlecht hältst:
Zur Orientierung:
- Eine 5 klingt so: [füge eine gute Musterantwort ein]
- Eine 1 klingt so: [füge eine schlechte Musterantwort ein]
Das reduziert die Streuung in den Noten und macht deinen Richter deutlich zuverlässiger.
Wenn du trotzdem Schwankungen siehst: Nutze Multi-Richter-Konsens. Lass drei unabhängige Claude-Sitzungen urteilen und nimm den Mehrheitswert. Das kostet mehr Zeit, aber die Ergebnisse sind deutlich stabiler.
Schritt 5: Einen QA-Loop einbauen
Das ist die eine Technik, die in fast jedem Anwendungsfall funktioniert. Nicht nur bei Agenten, auch bei Code, Dokumenten und jedem anderen Inhalt, den ein Agent erstellt.
Der Gedanke ist einfach: Statt deinen Agenten eine Ausgabe produzieren zu lassen und dann zu hoffen, dass sie gut ist, fügst du eine zweite Instanz hinzu. Diese zweite Instanz hat eine einzige Aufgabe: Fehler finden.
Alles hängt davon ab, wie du diesen zweiten Prüfer anweist. Nicht so:
Bitte überprüfe, ob diese Antwort in Ordnung ist.
Sondern so:
Gehe davon aus, dass es Probleme gibt. Deine Aufgabe ist, sie zu finden,
nicht zu bestätigen, dass alles gut ist. Behandle das wie eine Fehlersuche,
nicht wie eine Abnahme.
Dieser Unterschied macht alles. Ein Prüfer, der eine Bestätigung sucht, findet sie meistens. Ein Prüfer, der nach Fehlern sucht, findet auch welche.
So setzt du es in Claude Code um
Öffne eine neue Claude-Sitzung (oder starte einen Subagenten in Claude Code) mit diesem System-Prompt:
Du bist ein kritischer Prüfer. Du bekommst eine Aufgabe und eine Antwort gezeigt.
Gehe davon aus, dass es Probleme gibt. Deine Aufgabe ist, sie zu finden:
- Was fehlt?
- Was ist unklar formuliert?
- Was wirkt generisch statt spezifisch?
- Was würde ein professioneller Empfänger stören?
- Was würde der Absender bereuen, wenn er es am nächsten Morgen nochmal liest?
Liste konkrete Probleme auf. Keine Bestätigungen, keine Lobeshymnen.
Du gibst dieser Instanz die ursprüngliche Anfrage und die Agentenantwort. Das Feedback gibst du zurück an deinen Agenten, der dann überarbeitet. Dieser Loop kann manuell laufen (du übernimmst das Hin und Her) oder du automatisierst ihn, indem jede Ausgabe automatisch durch den Prüfer läuft.
Der Anthropic-Workshop zeigt diesen Loop anhand eines Slide-Agenten: Der Agent erstellt eine Präsentation, der Prüfer schaut sie sich an, findet Probleme und gibt sie zurück. Dann überarbeitet der Agent und der Prüfer schaut nochmals hin. Der Loop läuft so lange, bis mindestens ein vollständiger Fix-und-Prüf-Zyklus abgeschlossen ist.
Wenn du Claude Code nutzt, kennst du das vielleicht schon unter einem anderen Namen: /goal. Du setzt ein Ziel ("die Präsentation soll keine Emojis enthalten, konsistente Schriftgrößen haben und auf jeder Folie ein Diagramm zeigen"), Claude arbeitet, prüft selbst gegen dieses Ziel und korrigiert so lange, bis es erfüllt ist. Das ist derselbe Loop, nur nativ in Claude Code eingebaut.
Das Prinzip funktioniert für jeden Agenten, der Inhalte erstellt: Angebote, Berichte, E-Mails, Code, Präsentationen.
Schritt 6: Iterieren bis es besser wird
Evals allein sind wertlos, wenn du nicht weißt, wie du auf ihre Ergebnisse reagierst. Das Prinzip dahinter nennt sich Hill Climbing (schrittweise Optimierung durch wiederholtes Testen und Verbessern):
- Baseline messen: Lass alle Evals gegen deinen aktuellen Agenten laufen. Das ist dein Ausgangspunkt.
- Fehler triagen: Welche Evals schlagen fehl? Gibt es Muster? Liegt das Problem bei Effizienz, Qualität oder Korrektheit?
- Eine Sache ändern: System-Prompt anpassen, ein Werkzeug ersetzen oder die Kriterien im Richter-Prompt präzisieren.
- Evals neu laufen lassen: Hat die Änderung geholfen? Hat sie etwas anderes verschlechtert?
- Wiederholen.
Du hast jetzt ein objektives Maß für Fortschritt. Keine Spekulation, kein "fühlt sich besser an". Zahlen.
Wichtig: Ändere immer nur eine Sache auf einmal. Wenn du gleichzeitig den System-Prompt anpasst und den Richter-Prompt überarbeitest, weißt du nicht, was geholfen hat.
Anthropic nutzt dieses Prinzip intern beim Training jedes neuen Modells. Der identische Prozess gilt für deine Agenten-Architektur.
Evals weiterentwickeln
Evals sind keine einmalige Sache. Sie sind lebende Artefakte, die mit deinem Agenten wachsen.
Wenn die Scores zu leicht werden
Das nennt sich Eval-Saturation. Dein Agent erfüllt alle Testfälle, weil er sie inzwischen zu gut kennt. Dann ist es Zeit für härtere Szenarien: ungewöhnliche Anfragen, Edge Cases, Fälle, die in der Vergangenheit schiefgelaufen sind.
Beim Modellwechsel
Statt zu raten, ob Claude Opus 4.7 in deinem Anwendungsfall besser ist als Claude Sonnet 4.6, misst du es einfach. Lass dieselbe Eval-Suite gegen beide Modelle laufen. Die Zahlen entscheiden. Das nimmt eine riesige Last von der Entscheidung, wann du auf ein neues Modell wechseln solltest.
Wenn die Noten deines Richters schwanken
Das ist ein Kalibrierungsproblem. Überprüfe, ob dein Richter noch Ankerpunkte hat. Füge neue Beispiele hinzu, die den aktuellen Stand deines Agenten besser repräsentieren. Oder steig kurz als menschlicher Prüfer ein und kontrolliere ein paar Fälle manuell.
Fang klein an. Zwei oder drei Code-Prüfer für die kritischsten Verhaltensweisen. Ein LLM-Richter für die wichtigste Qualitätsdimension. Dann iteriere.
Praxisbeispiel: Von 62% auf 92% mit dem StockPilot-Agenten
Beim "Code with Claude London"-Workshop im Mai 2025 zeigte Will vom Applied-AI-Team bei Anthropic, was in der Praxis passiert, wenn ein Agent über Monate ohne strukturierte Tests wächst.
Der StockPilot-Agent (ein Bestandsverwaltungs-Agent für einen mittelgroßen Einzelhändler) startete klein. Mit der Zeit kamen neue Anforderungen dazu: Nachfrageprognosen, Berichterstellung, Lieferantenauswahl. Jede neue Funktion wurde direkt in den System-Prompt gepackt oder als neuer Sub-Agent (eigenständiger KI-Helfer, den der Haupt-Agent bei Bedarf aufruft) ergänzt.
Das Ergebnis nach einigen Monaten: Der System-Prompt war 400 Zeilen lang, das System hatte 12 verschiedene Werkzeuge. Die Eval-Quote brach auf 62% ein. Nur 7 von 12 definierten Tests bestanden noch.
Das Team identifizierte drei Ursachen:
- Context Bloat: Der System-Prompt war so lang und widersprüchlich, dass das Modell bei einer Prognose einen falschen Multiplikator verwendete. Kein Modellproblem. Ein Kontextproblem.
- Kommunikationsfehler zwischen Sub-Agenten: Ein Sub-Agent lieferte die richtige Antwort. Der Haupt-Agent interpretierte sie falsch. Ein klassischer Übersetzungsfehler im System.
- Widersprüchliche Regeln: Zwei Richtlinien standen an verschiedenen Stellen im System-Prompt und widersprachen sich. Das Modell wurde davon verwirrt.
Das Team startete ein Eval-gesteuertes Hill-Climbing-Vorgehen. Die Änderungen:
- System-Prompt auf 15 Zeilen reduziert
- Geschäftsregeln als Skills ausgelagert (der Agent zieht sich Informationen nur dann in seinen Kontext, wenn er sie für die aktuelle Aufgabe wirklich braucht)
- Die meisten Spezialwerkzeuge durch einfache Grundoperationen ersetzt (Bash-Befehle, Dateien lesen und schreiben)
- Nur einen Sub-Agenten behalten, den für Prognosen
Ergebnis: 92% Eval-Erfolgsquote. Weniger Token-Verbrauch, geringere Kosten, schnellere Ausführung.
Das ist kein Einzelfall. Es ist das Muster. Agenten degradieren, weil Komplexität wächst und niemand eine objektive Messlatte hat.
Wenn du gerade deinen ersten Agenten aufbaust, findest du in meinem Artikel über das Erstellen eines KI-Assistenten einen guten Einstieg. Wer verstehen will, wie KI-Agenten dauerhaftes Gedächtnis bekommen und warum das die Eval-Basis verändert, kann bei meinem Artikel über dauerhaftes KI-Agenten-Gedächtnis weiterlesen.
Alles auf einen Blick: dein erster Eval in 8 Schritten
Noch einmal der gesamte Prozess, kompakt:
- Agent auf echten Beispielen laufen lassen und aufschreiben, was dich stört. Keine schöne Liste, einfach runterschreiben.
- Beobachtungsliste aufteilen: Was lässt sich zählen oder eindeutig prüfen? Das wird ein Code-Prüfer. Was braucht ein Urteil? Das wird ein LLM-Richter.
- Ordner anlegen:
evals/kriterien.md,evals/ergebnisse.md. - Code-Prüfer schreiben: Claude Code beschreiben, was zu prüfen ist. Es schreibt das Script. Du führst es aus.
- LLM-Richter aufsetzen: Kriterien rein, Begründungen vor der Note abfragen, Ankerpunkte setzen wenn möglich.
- QA-Loop einrichten: Einen zweiten Claude-Prompt, der aktiv nach Fehlern sucht statt nach Bestätigungen.
- Baseline messen: Alle Testfälle durchlaufen, Ergebnisse notieren. Das ist dein Ausgangspunkt.
- Eine Sache ändern, neu messen, wiederholen. Nie zwei Dinge gleichzeitig. Immer dokumentieren, was sich verändert hat.
Drei Regeln, die alles zusammenhalten: Jede Eval muss actionable sein. Immer nur eine Änderung auf einmal. Und Evals, die zu leicht werden, brauchen härtere Szenarien.
Direkt loslegen: Eval-Skill für Claude Code
Damit du nicht bei null anfängst, gibt es diesen Prozess als Claude Code Skill zum Herunterladen. Speichere die Datei unter ~/.claude/skills/build-evals.md in deinem System. Danach kannst du in Claude Code einfach /build-evals eingeben und wirst Schritt für Schritt durch den gesamten Aufbau geführt: Beobachtungsliste, Code-Prüfer, LLM-Richter, QA-Loop, Testfälle und Bewertungstabelle.
