Skill Bench: systematic-debugging vs. základ

Třetí část Skill Bench klade užší otázku než první dvě: ne „pomáhá dovednost?“, ale „překoná dovednost vytvořená pro konkrétní úkol model bez pomoci, který dělá přesně tentýž úkol?“. Ladění je pro to nejčistší test, protože chyby můžeme sami vložit, přesně vědět, co je špatně, a zkontrolovat zprávu proti skutečnosti řádek po řádku.

Napsali jsme tedy hru Snake na canvasu, záměrně ji rozbili třemi specifickými způsoby a spustili stejnou rozbitou hru a stejnou stížnost ve dvou identických relacích Claude Sonnet. Jedna měla nainstalovanou dovednost systematic-debugging. Druhá ne. Stejný prompt, stejný model, stejná chyba. Liší se pouze dovednost.

Výsledek nebyl tak jednoznačné vítězství, jak jsme očekávali, a to je ta část, která stojí za přečtení.

Past, kterou jsme postavili

Začali jsme s funkční implementací hry Snake a poté jsme záměrně vložili tři chyby:

1. Převrácené směrové vektory. ArrowUp a ArrowDown byly připojeny k vektorům, které byste použili v normálních kartézských souřadnicích, nikoli v souřadnicích canvasu, kde y roste směrem dolů. Stisknete nahoru, had jde dolů.
2. Generování jídla v pixelovém prostoru namísto mřížkového prostoru. spawnFood použil cv.width (400 pixelů) jako hranici pro souřadnici, která měla být indexem mřížky v mřížce s 20 buňkami (GRID). Vynásobíte-li krok mřížky rozsahem 400 pixelů, získáte souřadnice jídla, které přistanou mimo viditelnou desku přibližně v 95 % případů.
3. Skóre se zvyšuje s každým tikem. score++ se nacházelo v hlavní herní smyčce namísto uvnitř větve „had snědl jídlo“, takže skóre rostlo s každým snímkem bez ohledu na to, co had skutečně dělal.

Ani jedné relaci Claude jsme neřekli, co je špatně. Oběma jsme dali stejnou zprávu o chybě ve stylu hráče, formulovanou tak, jak by ji formuloval skutečný naštvaný tester: „ovládání je špatné, jídlo se nikdy neobjeví, skóre se samo zvyšuje.“ Poté jsme každou relaci požádali, aby našla a opravila vše, co to způsobovalo.

Tři chyby, jedna upřímná stížnost, dva Claude. Zde je, co se vrátilo.

Co nahlásila každá větev

Základní model (bez dovednosti)

Základní relace prošla kódem bez jakékoli vnucené metody, postupně četla obsluhu vstupu, generátor jídla a herní smyčku. Narazila na všechny tři vložené chyby:

• Směrové vektory byly převráceny pro osu y vzhledem k tomu, jak vykreslování canvasu interpretuje „dolů“.
• spawnFood násobil cv.width tam, kde měl použít konstantu mřížky, což vedlo k souřadnicím v pixelovém měřítku ve hře indexované buňkami.
• Zvyšování skóre se nacházelo mimo kontrolu kolize s jídlem, takže se spouštělo bezpodmínečně v každém snímku.

Poté pokračovala ve čtení a našla čtvrtý problém, který nikdo nevložil: kontrola vlastní kolize porovnávala hlavu hada s buňkou ocasu předtím, než byl ocas pro daný snímek odstraněn. Když se had přesune do čtverce, který jeho vlastní ocas opouští, kontrola stále považuje tento čtverec za obsazený a označí to za kolizi. To je skutečný, dobře známý okrajový případ hry Snake. Existoval v našem kódu, protože jsme logiku kolizí napsali předtím, než jsme cokoli vložili, a základní model se prostě dostal dostatečně daleko, aby na něj narazil.

Větev s dovedností (nainstalovaný systematic-debugging)

Větev s dovedností nejprve přečetla systematic-debugging SKILL.md od obra/superpowers (dovednost, kterou jsme samostatně ohodnotili 9.6/10 za hledání příčin na základě hypotéz), a poté aplikovala svou metodu: vytvořit hypotézu pro každý symptom, otestovat ji proti kódu, potvrdit před jakoukoli změnou.

Našla stejné tři vložené chyby, s přesnější a konkrétnější formulací příčin:

• „Inverze směru vysledována k konvenci canvasu y-dolů: ArrowUp se mapuje na {x:0,y:-1} za předpokladu kartézského y-nahoru, ale canvas vykresluje y rostoucí směrem dolů, takže nahoru a dolů jsou prohozeny.“
• „Generování jídla používá hranici v pixelovém prostoru (cv.width = 400), kde by výpočet měl používat hranici v mřížkovém prostoru (GRID = 20). Potvrzeno neshodou jednotek: vynásobení náhodné frakce v měřítku mřížky hranicí v pixelovém měřítku umístí ~95% generování mimo canvas.width.“
• „Skóre se bezpodmínečně zvyšuje v cyklu tiků namísto toho, aby bylo podmíněno větví „jídlo snědeno“. Potvrzeno sledováním těla smyčky: score++ se provede před spuštěním kontroly kolize, v každém snímku.“

Čtvrtou chybu nenašla. Problém vlastní kolize se nikdy neobjevil, protože nahlášené symptomy (špatné ovládání, chybějící jídlo, nekontrolovatelné skóre) neukazovaly na logiku kolizí a metoda dovednosti založená na hypotézách zůstává ukotvena k symptomům, které jí byly dány. Zprávu uzavřela s důvěrou, že všechny problémy byly vyřešeny, a podle znění stížnosti tomu tak bylo.

Dějový zvrat se čtvrtou chybou

Toto je zvrat, který jsme ověřili ručně, opětovným přečtením obou rozdílů proti skutečnému kódu: větev s dovedností byla přesnější ohledně chyb, které měla najít, a základní větev našla ještě jednu skutečnou chybu, na kterou se nikdo neptal.

To není kritika systematic-debugging jako dovednosti. Ladění založené na hypotézách je navrženo tak, aby dělalo přesně to, co zde dělalo: vzít nahlášený symptom, zúžit ho na testovatelnou příčinu, potvrdit před opravou a zastavit se, jakmile je symptom vysvětlen. Tato disciplína je přesně to, co potřebujete, když se díváte na produkční incident se stack trace a běžícím časem. Je také, svou konstrukcí, omezena na symptomy. Nezabíhá do kódu, který není dotčen stížností.

Základní relace neměla takový rozsah. Přečetla více souboru, než bylo nezbytně nutné, a čtení více souboru je způsob, jak narazíte na chybu, o které se nikdo nezmínil. Volné prozkoumávání je ze své podstaty neefektivní, a zde se neefektivita vyplatila.

Upřímné hodnocení: ani jedna větev není obecně „lepší“. Jedna větev je přesná a nenáročná na pozornost, ukotvená k tomu, co jí bylo řečeno. Druhá je nezaostřená a tentokrát dostatečně důkladná, aby zachytila něco, co se v ticketu nezmínilo. Pokud je vaše zpráva o chybě kompletní, zpráva větve s dovedností je ta, kterou chcete číst. Pokud vaše zpráva o chybě může něco postrádat, chcete druhý pár očí, který vám základní model poskytl zdarma.

Čísla

	Základní model (bez dovednosti)	Větev s dovedností (systematic-debugging)
Nalezeno chyb (z 3 vložených)	3 / 3	3 / 3
Nalezena nevložená skutečná chyba	Ano (kolize při uvolnění ocasu)	Ne
Přesnost určení příčiny	Správná, méně formalizovaná	Správná, pojmenovaný mechanismus pro každou chybu
Struktura zprávy	Ad hoc	Hypotéza → test → potvrzení, pro každou chybu
Použité tokeny	50,338	58,357
Rozdíl tokenů	—	+16%

Dovednost stála o 16 % více tokenů za zprávu, která se lépe čte a přesněji určuje mechanismus, ale nepřekonala základní model, kterému bylo jednoduše umožněno pokračovat ve čtení. To je zjištění, které jsme neočekávali, a je to důvod, proč zveřejňujeme syrové srovnání namísto verdiktu, který by dovednost lichotil.

Kdy chcete systematic-debugging

Test Snake podceňuje skutečnou hodnotu dovednosti, protože hra s vloženými chybami a plným zdrojovým souborem na dohled je pro model bez pomoci téměř ideální případ: vše relevantní se vejde do jednoho přečtení. Produkční ladění takto vypadá zřídka.

Ladění příčin založené na hypotézách se osvědčuje u chyb, které se vracejí. V našich vlastních poznámkách ke katalogu o systematic-debugging byl jedním testovacím případem race condition, kterou Claude již „opravil“ třikrát v téže kódové základně, pokaždé opravoval věrohodně vypadající odhad namísto skutečné příčiny. Disciplína dovednosti (formulovat hypotézu, navrhnout test, který by ji vyvrátil, nedotýkat se kódu, dokud test nepotvrdí) byla to, co konečně určilo skutečnou interakci namísto produkce čtvrtého odhadu. To je typ chyby, pro kterou je systematic-debugging určen: opakující se, vyhýbavá, již třikrát odhadovaná, v kódové základně příliš velké na to, aby se dala přečíst od začátku do konce jen tak z rozmaru.

Je to také správný nástroj v okamžiku, kdy řešíte produkční incident. Máte symptom, čas a žádnou chuť, aby se model toulal a četl nesouvisející moduly. Omezte se na zprávu, potvrďte příčinu, doručte opravu. To je v tomto konkrétním nastavení funkce, nikoli omezení.

Kdy vyhrává volné prohledávání

Náš výsledek ze hry Snake také argumentuje pro opačný případ: když máte podezření, že zpráva o chybě je neúplná, nebo když provádíte předběžnou kontrolu před vydáním namísto honby za jedním nahlášeným symptomem, neomezené čtení kódu dělá něco, co metoda založená na hypotézách strukturálně neudělá. Dívá se na kód, na který si ještě nikdo nestěžoval.

To má stejnou podobu jako ruční revize kódu versus cílená reakce na incident. Obojí má své místo. Chybou je předpokládat, že dovednost ladění nahrazuje revizní průchod, spíše než aby s ním koexistovala. Pokud chcete obecný pohled na revizní průchod, podívejte se na náš názor, proč se dovednosti nespouštějí vždy tak, jak očekáváte a jak strukturováme tyto testy.

Reprodukujte si to sami

Test je dostatečně malý, aby se dal znovu sestavit za dvacet minut, pokud chcete zkontrolovat naše čísla, spíše než jim věřit. Napište hru Snake na canvasu (pohyb po mřížce, generátor jídla, počítadlo skóre, herní smyčka) a vložte tyto tři vady:

1. Připojte ArrowUp/ArrowDown k vektorům kartézského stylu (y: 1 pro nahoru, y: -1 pro dolů) namísto vektorů stylu canvasu, kde rostoucí y posouvá dolů po obrazovce.
2. Ve vaší funkci pro generování jídla vynásobte svou náhodnou frakci šířkou pixelů canvasu namísto počtu buněk mřížky, takže výsledná souřadnice je hodnota pixelu, která je považována za index mřížky.
3. Přesuňte zvyšování skóre z větve „dopadla hlava právě na jídlo“ do bezpodmínečného těla herní smyčky.

Dejte relaci Claude pouze stížnost hráče („ovládání je špatné, jídlo se nikdy neobjeví, skóre se samo zvyšuje“), nikdy seznam chyb, a uvidíte, co se vrátí. Poté si přečtěte vlastní logiku kolizí pro případ uvolnění ocasu: zkontrolujte další pozici hlavy proti aktuální buňce ocasu předtím, než se ocas pohne, a uvidíte, zda tam také je. U nás byla, aniž bychom ji vložili.

Často kladené otázky

Zhoršuje dovednost systematic-debugging schopnost Claude nacházet chyby?

Ne. Našla každou vloženou chybu s přesnějšími příčinami než základní model. Co neudělala, bylo překročení rozsahu nahlášených symptomů, což umožnilo základnímu modelu narazit na čtvrtou, nevloženou chybu. Disciplína rozsahu je záměrem návrhu dovednosti, nikoli vada.

Proč základní model našel chybu, kterou dovednost přehlédla?

Základní model neměl žádnou hypotézu, ke které by se držel, takže přečetl více kódu, než striktně vyžadovaly nahlášené symptomy. Čtení více kódu je způsob, jak najdete věci, na které se nikdo neptal. Je to neefektivní strategie, která se jednou vyplatila, nikoli obecná výhoda.

Vyplatí se 16% nárůst tokenů pro dovednost ladění?

Záleží na chybě. Pro opakující se, těžko určitelný problém má disciplína mnohem větší hodnotu než 16 % tokenů, protože alternativou je, že Claude opakovaně hádá stejnou příčinu, jak tomu bylo v našem vlastním katalogovém testu předtím, než jsme tuto dovednost použili. Pro chybu, která je již dobře ohraničená a povrchní, vám dodatečné náklady přinesou čistší zprávu a nic moc víc.

Měl bych používat systematic-debugging pro každou opravu chyby?

Ne pro každou. Sáhněte po ní, když se chyba opakuje, když předchozí pokus o opravu nezafungoval, nebo když řešíte živý incident a potřebujete zůstat v rozsahu nahlášeného symptomu. Pro první průchod čerstvé zprávy o chybě, nebo když chcete širší prohledávání, které by mohlo zachytit související problémy, může obyčejná ladicí relace nebo vyhrazený revizní průchod pokrýt oblasti, které dovednost nepokryje. Podívejte se na naše nejlepší kódovací dovednosti, jak hodnotíme ladicí a revizní dovednosti navzájem.

---

Skill Bench, část 3 ze 4. Přečtěte si další kontrolovaná srovnání: část 1, sestavení vstupní stránky, část 2, bot pro Telegram a část 4, audit Google zx.