Skill Bench: systematisk fejlfinding vs. baseline

Del 3 af Skill Bench stiller et snævrere spørgsmål end de to første: ikke "hjælper en færdighed," men "slår en færdighed, der er bygget til én opgave, en model uden hjælp, der udfører præcis den opgave." Fejlfinding er den reneste test, vi har til det, fordi vi selv kan indlejre fejlene, præcist ved, hvad der er galt, og kontrollere rapporten mod den faktiske sandhed linje for linje.

Så vi skrev et canvas Snake-spil, brød det med vilje på tre specifikke måder og kørte det samme ødelagte spil og den samme klage gennem to identiske Claude Sonnet-sessioner. Den ene havde systematic-debugging-færdigheden installeret. Den anden havde ikke. Samme prompt, samme model, samme fejl. Kun færdigheden adskiller sig.

Resultatet var ikke den klare sejr, vi forventede, og det er den del, der er værd at læse.

Fælden vi byggede

Vi startede fra en fungerende Snake-implementering og indlejrede derefter tre fejl med vilje:

1. Inverterede retningsvektorer. ArrowUp og ArrowDown var forbundet til de vektorer, man ville bruge i normale kartesiske koordinater, ikke canvas-koordinater, hvor y øges nedad. Tryk op, slangen går ned.
2. Madspawning i pixelrum i stedet for gitterrum. spawnFood brugte cv.width (400 pixels) som grænse for en koordinat, der skulle være et gitterindeks i et 20-celle gitter (GRID). Multiplicer et gittertrin med et 400-bredt område, og du får madkoordinater, der lander uden for det synlige bræt cirka 95% af tiden.
3. Score stiger for hvert tick. score++ sad i hovedspilsløkken i stedet for inde i "slangen spiste mad"-grenen, så scoren steg for hver frame uanset hvad slangen faktisk gjorde.

Vi fortalte ingen af Claude-sessionerne, hvad der var galt. Vi gav begge arme den samme fejlrapport i spillerstil, formuleret som en faktisk irriteret tester ville formulere den: "kontrollerne føles forkerte, mad dukker aldrig op, scoren stiger af sig selv." Derefter bad vi hver session om at finde og rette alt, der forårsagede dette.

Tre fejl, én ærlig klage, to Claudes. Her er, hvad der kom tilbage.

Hvad hver arm rapporterede

Baseline (ingen færdighed)

Baseline-sessionen arbejdede gennem koden uden nogen påtvungen metode, læste input-handleren, mad-spawneren og spil-løkken efter tur. Den fandt alle tre indlejrede fejl:

• Retningsvektorer var vendt for y-aksen i forhold til, hvordan canvas-rendering behandler "ned."
• spawnFood multiplicerede cv.width, hvor den skulle have brugt gitterkonstanten, hvilket producerede pixel-skala koordinater i et celleindekseret spil.
• Score-inkrementet sad uden for kollisionskontrollen med mad, så det blev udløst ubetinget hver frame.

Derefter fortsatte den med at læse og fandt et fjerde problem, som ingen havde indlejret: selv-kollisionskontrollen sammenlignede slangens hoved med halecellen, før halen var blevet fjernet for den frame. Når slangen bevæger sig ind i den firkant, dens egen hale forlader, ser kontrollen stadig den firkant som optaget og kalder det en kollision. Det er en reel, velkendt Snake edge case. Den eksisterede i vores kode, fordi vi skrev kollisionslogikken, før vi indlejrede noget, og baselinjen læste tilfældigvis langt nok til at ramme den.

Færdighedsarm (systematic-debugging installeret)

Færdighedsarmen læste obra/superpowers' systematic-debugging SKILL.md først (en færdighed, vi separat har scoret 9.6/10 for hypotesedrevet årsagsanalyse), og anvendte derefter sin metode: formuler en hypotese for hvert symptom, test den mod koden, bekræft før du rører noget.

Den fandt de samme tre indlejrede fejl, med strammere, mere præcist årsagssprog:

• "Retningsinversion sporet til canvas y-ned-konvention: ArrowUp mapper til {x:0,y:-1} antagende kartesisk y-op, men canvas render y stigende nedad, så op og ned er byttet om."
• "Madspawning bruger pixel-rumsgrænse (cv.width = 400), hvor beregningen skulle bruge gitter-rumsgrænse (GRID = 20). Bekræftet af enhedsmismatch: at multiplicere en tilfældig gitter-skala brøk med en pixel-skala grænse placerer ~95% af spawns uden for canvas.width."
• "Score stiger ubetinget i tick-løkken i stedet for at være begrænset af den mad-spiste gren. Bekræftet ved at spore løkkens krop: score++ udføres før kollisionskontrollen kører, på hver frame."

Den fandt ikke den fjerde fejl. Selv-kollisionsproblemet dukkede aldrig op, fordi de rapporterede symptomer (forkerte kontroller, manglende mad, løbsk score) ikke pegede på kollisionslogik, og færdighedens hypotesedrevne metode forbliver forankret til de symptomer, den fik. Den afsluttede rapporten overbevist om, at alle problemer var løst, og ifølge klagens ord var de det.

Den fjerde-fejl plot-twist

Dette er det twist, vi verificerede manuelt ved at genlæse begge diffs mod den faktiske kode: færdighedsarmen var mere præcis omkring de fejl, den blev bedt om at finde, og baseline-armen fandt en mere reel fejl, som ingen havde spurgt om.

Det er ikke en kritik af systematic-debugging som færdighed. Hypotesedrevet fejlfinding er bygget til at gøre præcis, hvad den gjorde her: tage et rapporteret symptom, indsnævre til en testbar årsag, bekræfte før rettelse, og stoppe, når symptomet er forklaret. Den disciplin er præcis pointen, når du stirrer på en produktionshændelse med en stack trace og et ur, der tikker. Den er også, per konstruktion, symptom-afgrænset. Den vandrer ikke ind i kode, der ikke er impliceret af klagen.

Baseline-sessionen havde ikke en sådan afgrænsning. Den læste mere af filen, end den strengt taget behøvede, og at læse mere af filen er, hvordan man snubler over en fejl, ingen nævnte. Fritgående udforskning er ineffektivt af design, og her betalte ineffektiviteten sig.

Den ærlige læsning: ingen af armene er "bedre" generelt. Den ene arm er præcis og billig i opmærksomhed, forankret til det, den blev fortalt. Den anden er ufokuseret og, denne ene gang, grundig nok til at fange noget, billetten ikke nævnte. Hvis din fejlrapport er komplet, er færdighedsarmens rapport den, du ønsker at læse. Hvis din fejlrapport muligvis mangler noget, ønsker du det andet sæt øjne, baselinjen gav dig gratis.

Tallene

	Baseline (ingen færdighed)	Færdighedsarm (systematic-debugging)
Fundne fejl (ud af 3 indlejrede)	3 / 3	3 / 3
Uindlejret reel fejl fundet	Ja (hale-forlad kollision)	Nej
Årsagspræcision	Korrekt, mindre formaliseret	Korrekt, navngivet mekanisme pr. fejl
Rapportstruktur	Ad hoc	Hypotese → test → bekræft, pr. fejl
Brugte tokens	50,338	58,357
Token-delta	—	+16%

Færdigheden kostede 16% flere tokens for en rapport, der læses bedre og fastslår mekanismen mere præcist, men den fandt ikke flere fejl end en baseline, der simpelthen fik lov til at fortsætte med at læse. Det er det fund, vi ikke forventede, da vi startede, og det er grunden til, at vi udgiver den rå sammenligning i stedet for en dom, der smigrer færdigheden.

Hvornår du ønsker systematic-debugging

Snake-testen undervurderer færdighedens reelle værdi, fordi et spil med indlejrede fejl og en fuld kildekodefil i syne er tæt på det bedste scenarie for en model uden hjælp: alt relevant passer ind i én læsning. Produktionsfejlfinding ser sjældent sådan ud.

Hvor hypotesedrevet årsagsanalyse tjener sig ind, er den fejl, der vender tilbage. I vores egne katalognoter om systematic-debugging var et testtilfælde en race condition, som Claude allerede havde "rettet" tre separate gange i den samme kodebase, hver gang ved at lappe et plausibelt udseende gæt i stedet for den faktiske årsag. Færdighedens disciplin (opstil hypotesen, design en test, der ville falsificere den, rør ikke koden, før testen bekræfter den) var det, der endelig fastslog den reelle interaktion i stedet for at producere et fjerde gæt. Det er den type fejl systematic-debugging er til for: tilbagevendende, undvigende, gættet på tre gange allerede, i en kodebase, der er for stor til at læse fra ende til anden på et indfald.

Det er også det rigtige værktøj i det øjeblik, du triagerer en produktionshændelse. Du har et symptom, et ur, og ingen lyst til, at en model vandrer afsted for at læse urelaterede moduler. Afgræns til rapporten, bekræft årsagen, send rettelsen. Det er en funktion, ikke en begrænsning, i præcis den situation.

Når en fri gennemgang vinder

Vores Snake-resultat argumenterer også for det modsatte tilfælde: når du mistænker, at fejlrapporten er ufuldstændig, eller når du foretager en pre-release gennemgang i stedet for at jagte et rapporteret symptom, gør en ubegrænset læsning af koden noget, en hypotesedrevet metode strukturelt ikke vil. Den ser på kode, som ingen endnu har klaget over.

Det er den samme form som en manuel kodeanmeldelse versus en målrettet hændelsesrespons. Begge har deres plads. Fejlen er at antage, at en fejlfindingsfærdighed erstatter en gennemgang i stedet for at sidde ved siden af den. Hvis du vil have den generelle gennemgangsvinkel på dette, se vores syn på, hvorfor færdigheder ikke altid udløses, som du forventer og hvordan vi strukturerer disse tests.

Reproducer det selv

Testen er lille nok til at genopbygge på tyve minutter, hvis du vil kontrollere vores tal i stedet for at tage dem på tro. Skriv et canvas Snake-spil (gitterbevægelse, en mad-spawner, en score-tæller, en spil-løkke) og indlejre disse tre defekter:

1. Forbind ArrowUp/ArrowDown til kartesiske vektorer (y: 1 for op, y: -1 for ned) i stedet for canvas-stil vektorer, hvor stigende y bevæger sig ned ad skærmen.
2. I din mad-spawn funktion, multiplicer din tilfældige brøk med canvas's pixelbredde i stedet for dit gittercelleantal, så den resulterende koordinat er en pixelværdi, der behandles som et gitterindeks.
3. Flyt score-inkrementet ud af "landede hovedet lige på mad"-grenen og ind i den ubetingede del af spil-løkken.

Giv en Claude-session kun spillerklagen ("kontrollerne føles forkerte, mad dukker aldrig op, scoren stiger af sig selv"), aldrig fejl-listen, og se hvad der kommer tilbage. Læs derefter din egen kollisionslogik for hale-forlad-tilfældet: kontroller hovedets næste position mod halens nuværende celle, før halen bevæger sig, og se om den også er der. Vores var, uden at vi indlejrede den.

Ofte stillede spørgsmål

Gør systematic-debugging-færdigheden Claude dårligere til at finde fejl?

Nej. Den fandt hver indlejret fejl med mere præcise årsager end baselinjen. Hvad den ikke gjorde, var at overskride omfanget af de rapporterede symptomer, hvilket var det, der lod baselinjen snuble over en fjerde, uindlejret fejl. Omfangsdisciplin er færdighedens designintention, ikke en defekt.

Hvorfor fandt baselinjen en fejl, færdigheden overså?

Baselinjen havde ingen hypotese at forblive forankret til, så den læste mere af kodebasen, end de rapporterede symptomer strengt taget krævede. At læse mere kode er, hvordan du finder ting, ingen spurgte om. Det er en ineffektiv strategi, der tilfældigvis betalte sig én gang, ikke en generel fordel.

Er en 16% token-stigning det værd for en fejlfindingsfærdighed?

Afhænger af fejlen. For et tilbagevendende, svært at fastslå problem er disciplinen langt mere værd end 16% i tokens, fordi alternativet er, at Claude gætter på den samme årsag gentagne gange, som den gjorde i vores egen katalogtest, før vi anvendte denne færdighed. For en fejl, der allerede er velafgrænset og overfladisk, giver overhead dig en renere rapport og ikke meget andet.

Skal jeg bruge systematic-debugging til hver fejlrettelse?

Ikke til hver eneste. Brug den, når en fejl er tilbagevendende, når et tidligere forsøg på at rette den ikke holdt, eller når du triagerer en live hændelse og skal holde dig inden for det rapporterede symptom. For en første gennemgang af en ny fejlrapport, eller når du ønsker en bredere gennemgang, der måske fanger tilstødende problemer, kan en almindelig fejlfindingssession eller en dedikeret gennemgang dække områder, som færdigheden ikke vil. Se vores bedste kodningsfærdigheder for hvordan vi rangerer fejlfindings- og gennemgangsfærdigheder mod hinanden.

---

Skill Bench, del 3 af 4. Læs de andre kontrollerede sammenligninger: del 1, landing page-bygningen, del 2, Telegram-botten, og del 4, auditering af Google zx.