Karpathy-Methode Prompt-Builder-Fähigkeit

--- name: kp-prompting description: Fortgeschrittene Prompts, Aufgabenspezifikationen, Verifikationskriterien und Claude-Code-Setup mit Andrej Karpathys Spezifikations-/Verifizierer-/Umgebungsmethode erstellen. Diese Fähigkeit verwenden, wann immer eine Aufgabe oder ein Projekt spezifiziert, ein Prompt gestrafft/neu formuliert, Verifikations- oder Erfolgskriterien für Agentenausgaben definiert oder eine Wissensbasis, Fähigkeit oder Leitplanken für einen Agenten eingerichtet/aktualisiert werden soll. --- Spezifikation - was tatsächlich gewünscht ist, präzise genug, damit das Modell nicht raten muss Verifizierer - wie du (oder das Modell) wissen, dass die Ausgabe tatsächlich korrekt ist Umgebung - der persistente Kontext und die Leitplanken, damit der Agent nicht jedes Mal von null anfängt Der rote Faden durch alle drei: Du kannst die Ausführung abgeben, aber nicht das Verständnis. Jede Ebene unten muss Tom in die tatsächlichen Ermessensentscheidungen einbeziehen, nicht nur schön aussehende Ausgaben produzieren, die Lücken verdecken, nach denen er nie gefragt wurde. Zwei Modi - finde heraus, in welchem du dich befindest, bevor du irgendetwas anderes tust Coachingsmodus (Standard). Tom gibt dir eine Aufgabe, einen groben Entwurf oder eine Anfrage, um Anweisungen für etwas Bestimmtes zu schreiben. Straffe es mit der Drei-Ebenen-Linse unten und gib die verbesserte Version im Chat zurück - keine Dateien. Das ist der Standard für "hilf mir einen Prompt zu schreiben/verbessern". Full-Setup-Modus. Tom baut ein neues Projekt, Projektwerkzeug oder eine wiederkehrende Workflow auf und möchte tatsächliches Scaffolding: ein Spezifikationsdokument, Verifikationskriterien und Umgebungs-Setup (CLAUDE.md-Ergänzungen, Leitplanken, Wissensbasis-Verweise). Fordere dies bei Formulierungen wie "spezi hier" auszulösen. Wenn es unklar ist, welcher Modus passt: lies das Skript mit EINER kurzen Frage, statt zu raten - das Bauen des falschen Modus kostet mehr Zeit als das Fragen. Meistens ist es ableitbar: Eine einzelne Aufgabe und einen Prompt-Entwurf zur Hand → Coachingsmodus; ein neues Projekt mit noch keinem Prompt → Voll-Setup. Layer 1: Spezifikation Warum sie wichtig ist: Ein Karpathy's Beispiel: Man fragt ein Frontmodell, ob man zum 50 Meter entfernen Autowaschanlagen fahren oder zu Fuß laufen soll, und es sagt "zu Fuß" - da man übersieht, dass das Auto auch dort hinfahren muss. Modelle sind besonders gut bei allem Checkbaren und überraschend schlecht bei realen Ermessensentscheidungen, da genau diese aus der sauberen Trainingsignal fehlen. Aufgabe der Spezifikation ist es, dem Modell das Urteilsvermögen mitzugeben, das es nicht selbst ableiten kann, sodass es nicht das Such nach Kontext reduziert wird. Flaches, hochstufiges "Plan-Modus"-Prompting mitschreibt das nicht - es ist zu dünn in der Substanz. **So wird sie aufgebaut:** - Finde das eigentliche Ziel, nicht nur die Aufgabe. "Schreibe den Monatsbericht-Report" ist eine Aufgabe. Das Ziel ist die Entscheidung, die dieser Report unterstützen soll. Wenn dies nicht offensichtlich ist, frage nach - hier bei dir ein paar schnelle Fragen noch mal eine große Timing aufwand sparen. - Arbeite in kleinen Checkpoints, nicht in einem großen Dump. Alles auf einmal übergeben und dann erst wieder bei einem fertigen Produkt aufzurufen, lässt Abweichen sich unbemerkt kumulieren. Die Spezifikation so fein segmentieren, dass sie bei jedem Schritt prüfbar ist - besonders dort, wo echte Ambiguomen vorhanden. - Präzise darüber sein, was nicht einfach angenommen werden darf. Jedes vage Wort in einer Spezifikation wird zu Annahme, die das Modell selbst ausfüllt - überzeugt, in die statistisch wahrscheinlichste Richtung, nicht unbedingt in diejenige, die Tom tatsächlich will. Nenne die einzelnen Ermessensschritte (Namenskonvention , Randfälle, wie bei konkurrierenden Daten vorgegangen wird) statt sie implizit zu lassen. Eine Zeile wie "Markiere jede Annahme, die du triffst an, statt stillschweigend zu wählen – diese bietet realen Hebel. **Inhalt einer Spezifikation:** Ziel (die zugrunde liegende Entscheidung / das Ergebnis, nicht nur die Aufgabe) , Scope-Grenzen (explizit drin vs. draußen), zu flaggende Ermessenssachen statt stillschweigender Festlegung, Aufteilung der Einschränkungen in unverhandelbare vs. Präferenz. Layer 2: Verifizierer **Warum er wichtig ist:** Karpathys Rahmen: Diese Modelle sind eher "Geister" als Tiere - statistische Simulatoren, keine motivierten Agenten. Einem Modell zuschreien, es anbetteln oder sagen, dass etwas wirklich wichtig ist, verändert die Ausgabenqualität nicht. Was die Qualität verändert, ist ob es etwas gibt, dass die Arbeit wirklich prüft. Daher sind Modelle übermenschlich bei Code und Mathe (eindeutig prüfbar) und unzuverlässig bei Geschmack und Urteilswahlen (es gibt nichts zum Vergleichen) - je expliziter und prüfbarer "gut gemacht" bei einer richtig bestimmten Aufgabe ist, desto mehr kann die Ausgabe wirklich vertrauen geschrieben werden, statt mit "Review-Fatigue" überflogen zu werden. **So wird er gebaut:** - Bestimme Spar-/Fehl-Kriterien von vornherein, direkt im Prompt, nicht nachträglich. "Der Bericht soll gut aussehen" ist nicht prüfbar. "Der Bericht hat drei Abschnitte und jeder endet mit einer Empfehlung" ist es. Formuliere die Kriterien so, dass eine zweite Person (mensch oder LLM) prüfen kann, ohne in Toms Kopf zu lesen. - Nutze bei billigen Modelle eine Kritik oder ein anderes Modell (besser als das selbe in einem frischen Kontext), die die Antwort des ersten Modells gegen die Spezifikation bewertet - das fängt Dinge, die der erste Durchgang nachlogisch erklären würde. - Wenn es ein echtes externes Signal gibt, ziehe das ein. Bei Code: Kommt es wirklich zum Deploying? Praxis die Tests durch? Bei nicht-technischen Aufgaben: passt das Format/den Ton von bereits bekannten guten Beispiels dar? Eine Überprüfung, die nur interne Konsistenz prüft, ist für schwächster als eine, die an einem echten Referenzpunkt nett. **Inhalt eines Verifizierers:** - Konkrete, prüfbare Pass-/Fehlkriterien (nicht vibes) - Wer prüft (Selbst-Check, Zweitmodell, Deployment-/Testsignal) - Bei einem Fail: Retry mit welchem konkreten Feedback, oder Eskalation zu Tom Layer 3: Umgebung **Warum sie wichtig ist:** Die meisten bauen Kontext jedes Mal von Null neu. Indem sie das Projekt neu ok -Session erklären, die Regeln neu schreiben und hoffen, dass der Agent es sich merkt, auch wenn er das wissen nicht anfassen muss. Chatverlauf aufbewahren ist nicht dasselbe wie eine echte Umgebung. Eine Werkstatt mit bereits vorhandenen Brennen schlägt das "Repetieren des ganzen Shops bei jedem Besuch". **Wie sie aufgebaut wird:** 1. Eine CLAUDE.md, die der Agent automatisch liest. Deckt, abzugeben was/Aufgabe (Repo) ist, welche vorhandenen Skills es innerhalb und wann diese anzuwenden sind, wo man was findet (die Wissensarchitektur) und die dauerhaften Regeln. Das ist das höchste-Hebel zwei solchiges Teil, denn es wird bei jedem Prompt gelesen, ohne das du wiederholen musst. 2. Eine persönliche Wissensbibliothek. Ein strukturierter, auffindbarer Ort für Referenzmaterialien, das der Agent nutzen kann, statt es abzuleiten oder zu erfinden. Angehäuftes Material ist ein "Moat"; ein gut organisierte Abrufswindung macht bei jeder Nutzung stärker. 3. Wiederverwendbare Skills für alles, was sich wiederholt. Wenn Tom etwas ein zweites Mal macht, sollte es zu einem Skill werden statt als neu erklärte Einmaligkeit. 4. Leitplanken, nicht nur auf Prompt-Ebene, sondern tatsächlich auf Tool- Ebene gestuft. Ein regel wie das Verbot nicht entfernbarer Templates ist eine bloße Anweisung, die ein Modell unter Druck überschreiben kann. Dasselbe Rule als tatsächliche Tool-Einschränkung (blockierte Pfad, Permission- Gate) kann es nicht. Bringe Regeln in drei Stufen: - Immer tun - sicher auf Autopilot, du musst nicht fragen - Erst fragen - braucht vorab eine kurze Rückmeldung - Nie tun - hart gesperrt, nicht nur verbraten **Inhalt des Umgebungsaufbaus:** - Vorschlag für CLAUDE.md Ergänzungen (oder Volles CLAUDE.md, falls nicht existiert), - kurze Liste das gehört in die Wissensbibliothek vs. was weglassen, - neue Skills (die es wert sind, extrahiert zu werden) - Die drei Schutzstufen, gefüllt für das spezifische Projekt Output-Formate **Coaching-Modus-Ausgabe**: returnieren den verbesserten Prompt direkt in eine fenced Block, einfach zu kopieren. Darunter eine kurze Merge-Option (3-5 Sätze max.) du bei dem spezifischen Layer setzt - so siehst du, dass die Verbesserung nicht nur kosmetisch war. Keine Dateien für diesen Modus erstellt, außer ich bitte darum. **Full-Setup-Modus-Ausgabe**: erstelle drei schlanke Dokumente mit create_file. - SPEC.md - Ziel, Scope, Ermessensentscheidungen, Limitations - VERIFIER.md - Pass-/Fail-Kriterien, wer prüft, was bei Fehl passiert - Eine Umgebungs-Sektion - entweder neue CLAUDE.md oder klar gekennzeichnet zur bestehenden CLAUDE.md, plus die Schutzstufen Vor dem Schreiben die refences/templates.md für die vollständigen Füllvorlagen und ein durchgearbeitetes Beispiel lesen, nicht die Struktur jedes Mal neu improvisieren. - Alle drei zusammen mit einer kurzen Zusammenfassung präsentieren, jeweils eine geeignete Zuordnung und dort, wo du eine Ermessensentscheidung für Tom getroffen hast, die er noch einmal nachprüfen sollte, explizit kenntlich gemacht haben. Der ganze Kern Lass nicht zu, dass eines der Obigen zum Busywork wird, das beeindruckend aussieht, während Toms tatsächlichen Verständnis des Projekts dünn bleibt. Ziel aller drei Ebenen: Tom bleibt der, der weiß, warum das Projekt wichtig ist und wie "gut" aussieht. Die Ebenen machen dieses Wissen nur so leg bitte, dass ein Agent es zuverlässig nutzens kann. Wenn eine Spezifikations-, verifizierte Umgebungs-Dokument Fülltext ist statt einer echten Ermessenssituation einzufangen – streiche es. Vorlagen für den Voll-Modus Nur benötigt, wenn Kp-Prompt im Full-Modus ausgeführt wird (siehe SKILL.md). Dokumente nach dem echten Projekt ausfüllen – keine Platz-LaTeX-Klammern in den abgegebenen Dokumenten stehen lassen. **SPEC.md-Vorlage:** ```markdown # Spezifikation: [Projekt-/Aufgabenname] ## Ziel [Die tatsächliche Entscheidung oder das Ergebnis, dem das dient - nicht nur die Aufgabenzeschreibung. Beispiel: nicht "Tages Teilung zur Gebotslogik hinzufügen", sondern "verschwendete Ausgaben bei historisch niedrigen Conversion-Stunden reduzieren, ohne gleichzeitig das Volumen zu Stunden zu kürzen, die taten dass sie Zeit, die hoch convertiert, aber auf den ersten Blick langsam erscheinen.]</ %> ## Umfang **Im Scope:** - [...] **Nicht im Scope (vorerst):** - [...] ## Ermessenssachen, zu markieren, nicht still beantworten - [Konkreter, unklarer Punkt - z.B. "Was passiert mit zwei Kampagnen mit weniger als 2 Wochen Daten: Categorie-Benchmarks sofort anwenden, oder auf Kampagen-spezifische Daten warten?"] - [...] ```