Den Karpathy-inspirerede CLAUDE.md: Et realitetstjek af 'Adversarial Planning'-evner

Et GitHub-repository med en enkelt CLAUDE.md-fil har i skrivende stund samlet over 100.000 stjerner. Det bliver ofte omtalt som 'Karpathy skill', en reference til Andrej Karpathys arbejde inden for AI og uddannelse. Denne popularitet rejser et kritisk spørgsmål for enhver udvikler, der forsøger at få mere ud af store sprogmodeller: virker dette mønster reelt?

Før vi analyserer resultaterne fra vores tests, er to præciseringer essentielle. For det første er det pågældende repository skabt af Forrest Chang; det er Karpathy-inspireret, ikke skrevet af Karpathy. For det andet er filen en CLAUDE.md, ikke en SKILL.md. Det er et sæt instruktioner, som et menneske kan kopiere og indsætte i en chatsession, ikke en formel 'skill', der kan installeres for at modificere modellens adfærd programmatisk.

Hos SkillProof tester vi ikke copy-paste-prompts. Vi tester 'skills'. Vi installerer dem, kører dem mod kode fra den virkelige verden og måler deres ydeevne op imod basismodellen. For at undersøge hypen identificerede og testede vi en gruppe af 'skills', der implementerer det samme underliggende mønster som Changs CLAUDE.md: adversarial planning. Denne artikel præsenterer vores resultater.

Dekonstruktion af 'Grill-Me'-mønsteret

Kerneideen bag den populære CLAUDE.md er en form for struktureret selvkritik. Prompten instruerer modellen i ikke blot at producere et svar, men at påtage sig en persona – et panel af ekspertkritikere – for at udfordre og forfine sit eget output, før den præsenterer en endelig version. Processen ser typisk således ud:

1. Indledende plan: Modellen genererer en overordnet plan for at løse brugerens anmodning.
2. Selvkritik: Modellen bliver bedt om at 'grille' sin egen plan, identificere potentielle fejl, edge cases og implementeringsrisici. Den kan opliste svagheder eller stille afklarende spørgsmål til sig selv.
3. Forfinet output: Baseret på kritikken producerer modellen et mere robust, endeligt svar.

Denne teknik er en form for 'adversarial planning'. Man tvinger modellen til at agere som sit eget 'red team' og simulerer en review-proces, der normalt ville kræve en anden person eller et separat verifikationstrin. Hypotesen er, at denne interne dialog producerer et mere gennemtænkt og korrekt resultat, især for komplekse opgaver som systemdesign eller implementering af algoritmer.

Dette er det mønster, vi satte os for at teste. Når udviklere spørger om en karpathy claude skill review, er det denne mekanisme, de spørger ind til. Fører det til målbart bedre kode at tvinge en model til at kritisere sig selv?

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

Forskellen mellem en CLAUDE.md og en SKILL.md er ikke kun semantisk; den er fundamental for, hvordan vi evaluerer ydeevne.

En CLAUDE.md er en manuel prompt. Dens effektivitet kan variere vildt afhængigt af brugerens evne til at tilpasse den, de specifikke detaljer i deres input og tilstanden af deres chatsession. Det er en opskrift, ikke et værktøj. Man kan ikke benchmarke en opskrift på en standardiseret måde.

En SKILL.md, som defineret og anvendt i SkillProof-biblioteket, er en kanonisk, versionskontrolleret fil, der programmatisk ændrer modellens system-prompt. Når du bruger en 'skill' fra vores bibliotek, installeres den én gang. Hver efterfølgende anmodning til modellen drager fordel af (eller hæmmes af) den pågældende 'skills' instruktioner, uden manuel kopiering og indsættelse. Dette muliggør gentagelig, objektiv testning.

Hele vores testmetodologi er bygget på dette princip. Vi tager en SKILL.md, installerer den og kører den mod en række opgaver fra den virkelige verden. Vi sammenligner dens output – med hensyn til korrekthed, effektivitet og overholdelse af krav – med præcis den samme model uden en 'skill' installeret. Den resulterende score er et direkte mål for den værdi, som den pågældende 'skill' tilføjer (eller trækker fra).

Til denne undersøgelse testede vi ikke Forrest Changs fil direkte. I stedet fandt vi flere 'skills' fra community'et, der formaliserer 'adversarial planning'-mønsteret til et genanvendeligt SKILL.md-format. Dette gjorde det muligt for os at besvare spørgsmålet: lever selve mønsteret, når det anvendes konsekvent, op til sit løfte?

Vores testmetodologi for 'Adversarial Skills'

For at udføre en fair grill-me claude skill tested-analyse, udvalgte vi et repræsentativt sæt af opgaver, der er almindelige smertepunkter for udviklere, og hvor en mere 'eftertænksom' model teoretisk set kunne excellere:

• Kompleks refaktorering: Omskrivning af en monolitisk funktion med høj cyklomatisk kompleksitet til mindre, testbare enheder.
• Generering af API-klient: Skrivning af et klientbibliotek til en moderat kompleks OpenAPI-specifikation, inklusive fejlhåndtering og request/response-modeller.
• Implementering af algoritme: Implementering af en ikke-triviel algoritme ud fra en prosabeskrivelse, såsom A*-vejfinding eller en prioritetskø.
• Generering af unit-tests: Skrivning af en omfattende suite af unit-tests til en klasse med flere afhængigheder og edge cases.

For hver opgave kørte vi to forsøg: et med ren Claude (basismodellen, ingen 'skill') og et med en 'adversarial planning skill' installeret. Vi scorede outputtene baseret på en rubrik, der inkluderer funktionel korrekthed, kodekvalitet, fuldstændighed og effektivitet. Den endelige score for en 'skill' repræsenterer dens gennemsnitlige performance-delta på tværs af alle testede opgaver.

Denne stringente proces er, hvordan vi har evalueret alle 1416 'skills', der i øjeblikket er sporet i vores system. Det er et støjende landskab: kun 889 (63%) af disse 'skills' klarer vores krav om at give en netto positiv fordel. Yderligere 467 kræver ikke-triviel opsætning eller er kun nyttige i meget specifikke sammenhænge. De 'adversarial planning skills', vi testede, faldt inden for alle disse kategorier.

Dommen: Virker den Karpathy-inspirerede 'Skill' reelt?

Svaret er nuanceret. Effektiviteten af 'adversarial planning'-mønsteret er stærkt afhængig af opgavens kompleksitet. Det er ikke en universel forbedring. For nogle opgaver er det direkte skadeligt.

Vores tests viste en klar tendens:

Opgavetype	Ydeevne for ren Claude	Ydeevne for 'Adversarial Skill'	Dom
Simpel boilerplate (f.eks. en React-komponent)	Hurtig, 95% korrekt	Langsommere, overkritiserer, 90% korrekt	Negativ effekt
Kompleks refaktorering	Misser ofte edge cases	Fanger flere edge cases, men er verbose	Netto positiv
Algoritmedesign fra bunden	Tilbøjelig til logiske huller	Bedre logisk struktur, langsommere	Netto positiv
Debugging af obskure fejl	Foreslår ofte overfladiske løsninger	Udforsker dybere årsager	Netto positiv

For simple, veldefinerede opgaver tilføjer 'adversarial'-mønsteret unødvendig overhead. Modellen bruger tokens og tid på at kritisere en plan, der allerede var tilstrækkelig. I nogle tilfælde introducerede selvkritikprocessen endda fejl, da modellen hallucinerede mangler og derefter 'rettede' dem, hvilket ødelagde fuldt funktionsdygtig kode. Dette er et afgørende fund for enhver, der overvejer, om karpathy claude md worth it til daglig kodning.

Men for komplekse, åbne opgaver – den slags, der ofte giver en juniorudvikler problemer – giver mønsteret en målbar fordel. Når den bliver bedt om at designe et system eller refaktorere et indviklet stykke legacy-kode, tvinger selvkritikfasen modellen til at overveje interaktioner og edge cases, som ren Claude ofte overser. Det endelige output er mere robust og kræver mindre menneskelig korrektion, selvom det tager længere tid at generere og er betydeligt mere verbose.

En 'adversarial-planning skill', vi testede, slog klart baselinen på åbne systemdesignopgaver, men scorede under den på generering af simpel boilerplate. Dette understreger behovet for at anvende den rette 'skill' til den rette opgave, i stedet for at søge efter en enkelt 'god prompt', der kan det hele.

Den skjulte omkostning: Verbosity og negative scores

Den mest umiddelbare ulempe ved dette mønster er verbosity. Et svar fra en 'skill', der bruger 'adversarial planning', kan være 3-5x længere end et svar fra ren Claude. Det inkluderer planen, den fulde kritik og derefter det endelige svar. Selvom de mellemliggende trin kan give indsigt i modellens 'tankegang', øger de også token-forbruget og den kognitive belastning for udvikleren, der skal læse det hele.

Mere bekymrende er risikoen for negativ ydeevne. En dårligt implementeret 'skill' er værre end slet ingen 'skill'. Hos SkillProof er vores vigtigste fund ikke listen over 'skills', der virker, men listen over dem, der ikke gør. Pr. dags dato har 60 'skills', vi har testet, scoret UNDER ren Claude. De gør aktivt modellen mindre præcis, mindre effektiv eller mindre pålidelig.

Flere af de 'adversarial planning skills', vi testede, faldt i denne kategori. Fejlmønsteret var konsistent: kritikfasen ville sidde fast i et loop, eller 'ekspert-personaer' ville modsige hinanden, hvilket førte til et forvirret og ukorrekt endeligt output. I en test gik en 'skill' rettet mod SQL-query-optimering ind i et kritik-loop, hvor den debatterede fordelene ved JOIN vs. INNER JOIN (som er funktionelt identiske i de fleste dialekter) og undlod helt at producere en query.

Dette er anti-hype-realiteten i AI 'skill'-økosystemet. Popularitet og GitHub-stjerner er ikke korreleret med ydeevne. Et smart prompt-mønster kan lige så vel skade som gavne. Den eneste måde at vide det på er at teste det.

Så, er mønsteret det værd?

Lad os vende tilbage til det oprindelige spørgsmål. Er mønsteret fra den Karpathy-inspirerede CLAUDE.md det værd?

Som et læringsværktøj, absolut. At læse igennem Changs CLAUDE.md og lignende prompts er en fremragende måde at forstå konceptet 'chain-of-thought' og selvkorrektion. At eksperimentere med det manuelt kan hjælpe dig med at udvikle en bedre intuition for prompting.

Som et produktionsværktøj i form af en installeret SKILL.md er svaret et klart 'det kommer an på'. Vores data viser, at for specifikke, høj-kompleksitetsopgaver kan en velimplementeret 'adversarial skill' være et stærkt værktøj for senior-ingeniører. Den kan fungere som en utrættelig, logisk sparringspartner for komplekse problemer. Til dagligdags kodning vil den sandsynligvis være langsom, dyr og potentielt kontraproduktiv.

Dette er præcis det problem, SkillProof blev bygget til at løse. I stedet for at stole på hype eller antal stjerner, kan du stole på vores data. Vi adskiller de 'skills', der giver et reelt, målbart løft, fra dem, der blot er smarte, men ineffektive prompts.

Relateret læsning: andelen af 'skills', der reelt slår ren Claude · hvordan vi kører hver 'skill', før vi lister den.

Vi har testet dusinvis af 'skills', der bruger 'adversarial planning' og andre avancerede teknikker. For at se, hvilke der bestod vores tests fra den virkelige verden og opnåede en SkillProof-score, kan du gennemse kategorien Produktivitet & Workflow i vores bibliotek. Vi samler også de bedst ydende 'skills' på tværs af alle kategorier i en startpakke for $10, hvilket giver dig et sæt verificerede værktøjer, der reelt virker.