Den Karpathy-inspirerade CLAUDE.md: En verklighetskontroll av adversariell planering

Ett GitHub-repository med en enda CLAUDE.md-fil har i skrivande stund samlat över 100 000 stjärnor. Den kallas ofta för "Karpathy skill", en referens till Andrej Karpathys arbete inom AI och utbildning. Denna popularitet väcker en kritisk fråga för alla utvecklare som försöker få ut mer av stora språkmodeller: fungerar detta mönster verkligen?

Innan vi analyserar resultaten från våra tester är två förtydliganden nödvändiga. För det första skapades det aktuella repositoryt av Forrest Chang; det är Karpathy-inspirerat, inte skrivet av Karpathy. För det andra är filen en CLAUDE.md, inte en SKILL.md. Det är en uppsättning instruktioner för en människa att kopiera och klistra in i en chattsession, inte en formell 'skill' som kan installeras för att programmatiskt ändra modellens beteende.

På SkillProof testar vi inte copy-paste-prompter. Vi testar 'skills'. Vi installerar dem, kör dem mot verklig kod och mäter deras prestanda mot basmodellen. För att undersöka hypen identifierade och testade vi en grupp 'skills' som implementerar samma underliggande mönster som Changs CLAUDE.md: adversariell planering. Denna artikel presenterar våra resultat.

Att dissekera "Grill-Me"-mönstret

Kärnan i den populära CLAUDE.md är en form av strukturerad självkritik. Prompten instruerar modellen att inte bara producera ett svar, utan att anta en persona – en panel av expertkritiker – för att utmana och förfina sin egen output innan den presenterar en slutgiltig version. Processen ser vanligtvis ut så här:

1. Initial plan: Modellen genererar en övergripande plan för att lösa användarens förfrågan.
2. Självkritik: Modellen uppmanas att "grilla" sin egen plan, identifiera potentiella brister, kantfall och implementeringsrisker. Den kan lista svagheter eller ställa förtydligande frågor till sig själv.
3. Förfinad output: Baserat på kritiken producerar modellen ett mer robust, slutgiltigt svar.

Denna teknik är en form av adversariell planering. Man tvingar modellen att agera som sitt eget 'red team', och simulerar en granskningsprocess som normalt skulle kräva en annan person eller ett separat verifieringssteg. Hypotesen är att denna interna dialog producerar ett mer genomtänkt och korrekt resultat, särskilt för komplexa uppgifter som systemdesign eller algoritmimplementering.

Detta är mönstret vi avsåg att testa. När utvecklare frågar efter en 'karpathy claude skill review' är det denna mekanism de frågar om. Leder det till mätbart bättre kod att tvinga en modell att kritisera sig själv?

CLAUDE.md vs. SKILL.md: En kritisk skillnad

Skillnaden mellan en CLAUDE.md och en SKILL.md är inte bara semantisk; den är fundamental för hur vi utvärderar prestanda.

En CLAUDE.md är en manuell prompt. Dess effektivitet kan variera kraftigt beroende på användarens förmåga att anpassa den, detaljerna i deras input och tillståndet i deras chattsession. Det är ett recept, inte ett verktyg. Man kan inte benchmarka ett recept på ett standardiserat sätt.

En SKILL.md, som den definieras och används i SkillProof-katalogen, är en kanonisk, versionshanterad fil som programmatiskt ändrar modellens systemprompt. När du använder en 'skill' från vår katalog installeras den en gång. Varje efterföljande anrop till modellen drar nytta av (eller hindras av) den 'skillens' instruktioner, utan manuell kopiering och inklistring. Detta möjliggör repeterbara, objektiva tester.

Vår hela testmetodik bygger på denna princip. Vi tar en SKILL.md, installerar den och kör den mot en serie verkliga uppgifter. Vi jämför dess output – gällande korrekthet, effektivitet och efterlevnad av krav – mot exakt samma modell utan någon 'skill' installerad. Den resulterande poängen är ett direkt mått på det värde som den 'skillen' har tillfört (eller dragit ifrån).

För denna undersökning testade vi inte Forrest Changs fil direkt. Istället hämtade vi flera 'skills' från communityt som formaliserar det adversariella planeringsmönstret till ett återanvändbart SKILL.md-format. Detta gjorde det möjligt för oss att besvara frågan: levererar själva mönstret, när det tillämpas konsekvent, vad det lovar?

Vår testmetodik för adversariella 'skills'

För att genomföra en rättvis grill-me claude skill tested-analys valde vi ut en representativ uppsättning uppgifter som är vanliga smärtpunkter för utvecklare och där en mer "eftertänksam" modell teoretiskt skulle kunna excellera:

• Komplex refaktorering: Att skriva om en monolitisk funktion med hög cyklomatisk komplexitet till mindre, testbara enheter.
• Generering av API-klient: Att skriva ett klientbibliotek för en måttligt komplex OpenAPI-specifikation, inklusive felhantering och request/response-modeller.
• Algoritmimplementering: Att implementera en icke-trivial algoritm från en prosabeskrivning, såsom A*-sökvägssökning eller en prioritetskö.
• Generering av enhetstester: Att skriva en omfattande uppsättning enhetstester för en klass med flera beroenden och kantfall.

För varje uppgift körde vi två försök: ett med ren Claude (basmodellen, ingen 'skill') och ett med en 'skill' för adversariell planering installerad. Vi poängsatte resultaten baserat på en matris som inkluderar funktionell korrekthet, kodkvalitet, fullständighet och effektivitet. Den slutliga poängen för en 'skill' representerar dess genomsnittliga prestandadelta över alla testade uppgifter.

Denna rigorösa process är hur vi har utvärderat alla 1416 'skills' som för närvarande spåras i vårt system. Det är ett stökigt landskap: endast 889 (63%) av dessa 'skills' klarar vår ribba för att ge en netto positiv fördel. Ytterligare 467 kräver icke-trivial konfiguration eller är endast användbara i mycket specifika sammanhang. De 'skills' för adversariell planering som vi testade föll inom alla dessa kategorier.

Utslaget: Fungerar den Karpathy-inspirerade 'skillen' verkligen?

Svaret är nyanserat. Effektiviteten hos det adversariella planeringsmönstret är starkt beroende av uppgiftens komplexitet. Det är inte en universell förbättring. För vissa uppgifter är det direkt skadligt.

Våra tester visade en tydlig trend:

Uppgiftstyp	Prestanda (ren Claude)	Prestanda (adversariell 'skill')	Utslag
Enkel boilerplate (t.ex. en React-komponent)	Snabb, 95% korrekt	Långsammare, överkritiserar, 90% korrekt	Negativ påverkan
Komplex refaktorering	Missar ofta kantfall	Fångar fler kantfall, men mångordig	Netto positivt
Algoritmdesign från grunden	Benägen till logiska luckor	Bättre logisk struktur, långsammare	Netto positivt
Felsökning av oklara fel	Föreslår ofta ytliga lösningar	Utforskar djupare grundorsaker	Netto positivt

För enkla, väldefinierade uppgifter lägger det adversariella mönstret till onödig overhead. Modellen spenderar tokens och tid på att kritisera en plan som redan var tillräcklig. I vissa fall introducerade självkritikprocessen till och med fel, då modellen hallucinerade brister och sedan "fixade" dem, vilket förstörde fullt fungerande kod. Detta är ett avgörande resultat för alla som undrar om 'karpathy claude md worth it' för daglig kodning.

Men för komplexa, öppna uppgifter – den typ som ofta ställer en junior utvecklare – ger mönstret en mätbar fördel. När den ombeds att designa ett system eller refaktorera en trasslig bit legacy-kod, tvingar självkritikfasen modellen att överväga interaktioner och kantfall som ren Claude ofta missar. Det slutliga resultatet är mer robust och kräver mindre mänsklig korrigering, även om det tar längre tid att generera och är betydligt mer mångordigt.

En 'skill' för adversariell planering som vi testade slog tydligt baslinjen på öppna systemdesignuppgifter, men fick lägre poäng på generering av enkel boilerplate. Detta belyser behovet av att använda rätt 'skill' för rätt jobb, snarare än att söka efter en enda "god prompt" som styr allt.

Den dolda kostnaden: Mångordighet och negativa poäng

Den mest omedelbara nackdelen med detta mönster är mångordighet. Ett svar från en 'skill' som använder adversariell planering kan vara 3–5 gånger längre än ett svar från ren Claude. Det inkluderar planen, hela kritiken och sedan det slutliga svaret. Även om mellanstegen kan ge insikt i modellens "tänkande", ökar de också token-förbrukningen och den kognitiva belastningen på utvecklaren som måste läsa allt.

Mer oroande är risken för negativ prestanda. En dåligt implementerad 'skill' är sämre än ingen 'skill' alls. På SkillProof är vårt viktigaste resultat inte listan över 'skills' som fungerar, utan listan över de som inte gör det. I dagsläget har 60 'skills' vi har testat fått poäng UNDER ren Claude. De gör aktivt modellen mindre exakt, mindre effektiv eller mindre tillförlitlig.

Flera av de 'skills' för adversariell planering som vi testade föll inom denna kategori. Felläget var konsekvent: kritikfasen fastnade i en loop, eller så motsade "expertpersonerna" varandra, vilket ledde till ett förvirrat och felaktigt slutresultat. I ett test gick en 'skill' avsedd för SQL-frågeoptimering in i en kritikloop där den debatterade fördelarna med JOIN kontra INNER JOIN (som är funktionellt identiska i de flesta dialekter) och misslyckades med att producera någon fråga alls.

Detta är anti-hype-verkligheten i ekosystemet för AI-'skills'. Popularitet och GitHub-stjärnor korrelerar inte med prestanda. Ett smart promptmönster kan lika gärna skada som hjälpa. Det enda sättet att veta är att testa det.

Så, är mönstret värt det?

Låt oss återgå till den ursprungliga frågan. Är mönstret från den Karpathy-inspirerade CLAUDE.md värt det?

Som ett lärandeverktyg, absolut. Att läsa igenom Changs CLAUDE.md och liknande prompter är ett utmärkt sätt att förstå konceptet 'chain-of-thought' och självkorrigering. Att experimentera med det manuellt kan hjälpa dig att utveckla bättre intuition för prompting.

Som ett produktionsverktyg i form av en installerad SKILL.md är svaret ett bestämt "det beror på". Vår data visar att för specifika, högkomplexa uppgifter kan en väl implementerad adversariell 'skill' vara ett kraftfullt verktyg för seniora ingenjörer. Den kan agera som ett outtröttligt, logiskt bollplank för komplexa problem. För daglig kodning är den sannolikt långsam, dyr och potentiellt kontraproduktiv.

Detta är precis det problem som SkillProof skapades för att lösa. Istället för att förlita dig på hype eller antal stjärnor kan du förlita dig på vår data. Vi separerar de 'skills' som ger ett verkligt, mätbart lyft från de som bara är smarta men ineffektiva prompter.

Relaterad läsning: andelen 'skills' som faktiskt slår ren Claude · hur vi kör varje 'skill' innan vi listar den.

Vi har testat dussintals 'skills' som använder adversariell planering och andra avancerade tekniker. För att se vilka som klarade våra verkliga tester och fick en SkillProof-poäng kan du bläddra i kategorin Produktivitet & Arbetsflöde i vår katalog. Vi paketerar också de bäst presterande 'skills' i alla kategorier i ett startpaket för $10, vilket ger dig en uppsättning verifierade verktyg som faktiskt fungerar.