andrej-karpathische fähigkeiten

Karpathie-inspirierte Claude Code Richtlinien > Schauen Sie sich mein neues Projekt Multica an - eine Open-Source-Plattform zum Ausführen und Verwalten von Programmieragenten mit wiederverwendbaren Fähigkeiten. > > Folgen Sie mir auf X: https://x.com/jiayuan jy Eine einzelne "CLAUDE.md" -Datei zur Verbesserung des Verhaltens von Claude Code, abgeleitet von Andrej Karpathys Beobachtungen zu LLM-Codierungsfallen. Englisch | 简体中 Zealand Die Probleme Aus Andrejs Post: > "Die Modelle machen falsche Annahmen in Ihrem Namen und laufen einfach mit ihnen, ohne zu überprüfen." Sie verwalten ihre Verwirrung nicht, suchen keine Klärungen, stoßen keine Ungereimtheiten auf, präsentieren keine Kompromisse, schieben nicht zurück, wenn sie sollten. "Sie mögen es wirklich, Code und APIs zu verkomplizieren, aufzublähende Abstraktionen, bereinigen keinen toten Code ... implementieren Sie eine aufgeblähte Konstruktion über 1000 Zeilen, wenn 100 es tun würden." "Sie ändern oder entfernen manchmal Kommentare und codieren sie nicht ausreichend als Nebenwirkungen, auch wenn sie orthogonal zur Aufgabe stehen." Die Lösung Vier Prinzipien in einer Datei, die diese Probleme direkt ansprechen: | Grundsatz | Adressen | |---------------------------------------------------------------------------------------------------------------------------------------------------- | **Think Before Coding** | Falsche Annahmen, versteckte Verwirrung, fehlende Kompromisse | | ** Einfachheit zuerst ** | Überkomplikation, aufgeblähte Abstraktionen | | **Chirurgische Veränderungen ** | Orthogonale Bearbeitungen, Code berühren, den Sie nicht sollten | | **Goal-Driven Execution** | Nutzen Sie Tests-First, überprüfbare Erfolgskriterien | Die vier Prinzipien im Detail 1. Denken Sie vor der Codierung ** Nicht annehmen. Verstecke keine Verwirrung. Oberflächenabwägungen.** LLMs wählen oft eine Interpretation still und laufen damit. Dieses Prinzip erzwingt eine explizite Argumentation: - ** Staatliche Annahmen ausdrücklich ** — Wenn unsicher, fragen statt raten - **Gegenwartige Mehrfachinterpretationen ** - Wählen Sie nicht schweigend aus, wenn Mehrdeutigkeit besteht - ** Zurückdrücken, wenn es gerechtfertigt ist** Wenn es einen einfacheren Ansatz gibt, sagen Sie es - **Stoppen Sie, wenn Sie verwirrt sind ** - Nennen Sie, was unklar ist, und bitten Sie um Klärung 2. Einfachheit zuerst ** Mindestcode, der das Problem löst. Nichts spekulativ.** Bekämpfen Sie die Tendenz zum Über-Engineering: - Keine Features, die über das hinausgehen, was gefragt wurde - Keine Abstraktionen für Single-Use-Code - Keine "Flexibilität" oder "Konfigurierbarkeit", die nicht angefordert wurde Keine Fehlerbehandlung für unmögliche Szenarien - Wenn 200 Zeilen 50 sein könnten, schreiben Sie es um **Der Test:** Würde ein leitender Ingenieur sagen, dass dies zu kompliziert ist? Wenn ja, Vereinfachung. 3. Chirurgische Veränderungen ** Berühren Sie nur das, was Sie brauchen. Reinige nur dein eigenes Durcheinander.** Beim Bearbeiten des vorhandenen Codes: - Verbessern Sie nicht benachbarten Code, Kommentare oder Formatierung Refactoring von Dingen, die nicht kaputt sind - Passen Sie den vorhandenen Stil an, auch wenn Sie es anders machen würden - Wenn Sie nicht verwandten toten Code bemerken, erwähnen Sie ihn - löschen Sie ihn nicht Wenn Ihre Änderungen Waisenkinder schaffen: - Importe/Variablen/Funktionen entfernen, die IHRE Änderungen nicht verwendet haben Entfernen Sie keinen bereits vorhandenen toten Code, es sei denn, Sie werden gefragt **Der Test:** Jede geänderte Zeile sollte direkt auf die Anforderung des Benutzers zurückgeführt werden. 4. Zielgerichtete Ausführung **Erfolgskriterien definieren. Loop bis verifiziert.** Verwandeln Sie zwingende Aufgaben in überprüfbare Ziele: | Statt... | Transformation zu... | |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | "Validierung hinzufügen" | "Tests auf ungültige Eingaben schreiben und sie dann bestehen lassen" | | "Fix the bug" | "Schreiben Sie einen Test, der es reproduziert, dann lassen Sie es passieren" | | "Refactor X" | "Stellen Sie sicher, dass die Tests vorher und nachher bestehen" | Für mehrstufige Aufgaben geben Sie einen kurzen Plan an: Starke Erfolgskriterien lassen die LLM-Schleife selbstständig. Schwache Kriterien ("make it work") erfordern eine ständige Klärung. Installieren **Option A: Claude Code Plugin (empfohlen)** In Claude Code fügen Sie zuerst den Marktplatz hinzu: Installieren Sie dann das Plugin: Dadurch werden die Richtlinien als Claude Code-Plugin installiert und die Fähigkeiten für alle Ihre Projekte verfügbar gemacht. **Option B: CLAUDE.md (pro Projekt)** Neues Projekt: Bestehendes Projekt (Anhang): Verwenden mit Cursor Dieses Repository enthält eine engagierte Cursor-Projektregel (".cursor/rules/karpathy-guidelines.mdc"), so dass die gleichen Richtlinien gelten, wenn Sie das Projekt in Cursor öffnen. Siehe **CURSOR.md** zum Setup mit der Regel in anderen Projekten und wie sich dies auf Claude Code bezieht. Key Insight Aus Andrej: > "LLMs sind außergewöhnlich gut im Looping, bis sie bestimmte Ziele erreichen ..." Sagen Sie ihm nicht, was er tun soll, geben Sie ihm Erfolgskriterien und sehen Sie zu, wie es geht. Das Prinzip "Zielgesteuerte Ausführung" fängt dies ein: Konvertieren Sie zwingende Anweisungen in deklarative Ziele mit Verifikationsschleifen. Wie man weiß, dass es funktioniert Diese Richtlinien funktionieren, wenn Sie sehen: **Weniger unnötige Änderungen in