Vi byggede den samme landingsside med og uden en skill

Skill Bench, del 1 af 4. Samme model, samme prompt, én skill installeret eller ej. Dette indlæg: en landingsside. Også i serien: en Telegram bot, debugging af et slangespil, og auditering af et Google zx script.

Hver skill-anmeldelse på dette site ender med det samme uafklarede spørgsmål: får denne skill Claude til at udføre bedre arbejde, eller får den bare Claude til at udføre mere arbejde? Det er ikke det samme, og de fleste testopsætninger kan ikke skelne dem fra hinanden, fordi kørslerne ikke er kontrolleret stramt nok til at isolere den ene variabel, der betyder noget.

Så vi udførte et eksperiment. To kørsler, samme model, samme brief, ned til tegnsætningen. Den eneste forskel mellem dem er én instruktion: "læs og følg denne installerede skill." Kørsel ét, modellen bygger uden hjælp. Kørsel to, vi peger den mod den faktiske frontend-design skill, den der ligger på 9.6 ud af 10 i vores katalog, og lader den læse den rigtige SKILL.md før den rører ved nogen kode. Derefter sammenligner vi de to landingssider linje for linje og tæller de tokens, hver kørsel kostede.

Dette er den første af fire sådanne sammenligninger. Vi valgte en landingsside til at starte med, fordi visuelt design er det domæne, hvor "bedre" er nemmest at diskutere og sværest at forfalske. En gradient-tung hero ser enten ud som enhver anden AI-bygget side eller også gør den ikke, og du behøver ikke en benchmark for at se hvilken.

Opsætningen

Briefen var den samme for begge kørsler, en enkelt-fils landingsside for "Nimbus", en fiktiv vejr-API, skrevet til en Stripe-kaliber standard: hero-sektion, tre feature-blokke, en pristabel med Free, $29 og $199 niveauer, en kodeeksempelblok og en footer. Ingen frameworks, intet build-step, én HTML-fil med indlejret CSS.

Kørsel ét fik den brief og intet andet. Kørsel to fik den identiske brief plus en henvisning til den installerede frontend-design skill, som modellen derefter læste fuldt ud, før den startede.

Én vigtig forbehold, klart angivet frem for skjult: dette er N=1. Én kørsel per arm, én model, én brief. Vi hævder ikke, at disse tal er statistisk stabile over hundrede forsøg, og hvis du gentager dette selv, får du forskellige specifikke tal. Hvad vi hævder er snævrere og, mener vi, mere nyttigt: dette er, hvad der skete, i detaljer, på en reel kørsel, med reel telemetri, og det er et mønster, vi har set ofte nok i mindre kontrolleret testning til at stole på formen af det, selv før vi kører runde to og tre.

Hvad baseline byggede

Overladt til sig selv producerede Claude en side, de fleste, der har set meget AI-output, ville genkende med det samme. 890 linjer, et lyst farveskema bygget op omkring papir- og ravfarver, og det er værd at være fair her: koden var ren, teksten var rimelig, layoutet fungerede, intet var ødelagt.

Kendemærkerne lå alle i detaljerne. Elleve separate gradients på tværs af siden, i hero-baggrunden, i knap-tilstande, i kortrammer, på steder hvor en gradient tilføjede visuel støj snarere end at udføre en funktion. To overskrifter brugte background-clip: text til at male selve teksten i en gradient, den mest genkendelige AI-designsignatur der findes på dette tidspunkt. Statistiknumre flød i deres egne kort over folden, løsrevet fra enhver layoutlogik, den slags element, der ser ud som om det blev tilføjet, fordi en skabelon et sted har et, ikke fordi denne specifikke side havde brug for det.

Intet af dette er inkompetent. Det er outputtet fra en model, der er god til webdesign generelt og ikke har et specifikt synspunkt om dette brand i særdeleshed, så den griber til de samme træk, der dukker op, når det samme spørgsmål stilles uden yderligere begrænsning. En 63,329-token kørsel købte en leveringsdygtig side. Den købte ikke en side, nogen ville huske, og det er den samme side, vi ville forvente fra de fleste af skills i vores oversigt over de bedste design skills, hvis du fjerner design skillen igen.

Hvad skill-armen byggede anderledes

Den skill-guidede kørsel læste den faktiske anthropics/skills frontend-design SKILL.md før den skrev noget, og den resulterende side læses, som om den kom fra en helt anden designbrief. Mørk marineblå baggrund (--bg: #0B1119) parret med en messing-accent (--brass: #D2A25C), en kombination der ikke findes noget sted i baselinens søgerum og læses som et bevidst valg snarere end en standard. 985 linjer, fire gradients i stedet for elleve, og nul forekomster af gradient-text. Ikke færre, nul. Typesystemet var disciplineret på en måde, baselinens ikke var: konsistent skala, konsistent vægtlogik, overskrifter der ser valgte ud snarere end tilpasset i størrelse.

Intet ved denne side skriger "premium" på samme måde som et stockfoto af et håndtryk skriger "corporate". Den er mere afdæmpet end det. Paletten er usædvanlig nok til, at den ikke læses som en skabelon, og tilbageholdenheden med gradients betyder, at de resterende faktisk bærer vægt i stedet for at dekorere alt, de rører ved. Hvis du gav begge sider til en klient og spurgte, hvilken en en designbevidst grundlægger ville sende ud, er dette ikke en svær afgørelse.

Tallene

	Baseline (ingen skill)	Skill arm (frontend-design)	Delta
Tokens brugt	63,329	125,165	+98%
Værktøjskald	6	57	+51
Output længde	890 linjer	985 linjer	+95 linjer
Gradients	11	4	-7
Gradient-tekst forekomster	2	0	-2
Palette	Lys, papir + rav	Mørk marineblå + messing	—

Token-antallet er overskriften, og det er ikke subtilt: skill-kørslen kostede næsten dobbelt så meget. Det er ikke en afrundingsfejl, du kan tilskrive støj, og det er det tal, alle andre påstande i dette stykke skal læses op imod.

Hvorfor skillen koster mere

Token-gabet handler ikke rigtig om skillens filstørrelse. SKILL.md-filer er typisk et par tusinde tokens, ikke nok i sig selv til at fordoble en 63k-token kørsel. Hvad der faktisk skete, er synligt i antallet af værktøjskald: 6 versus 57. Baseline-kørslen skrev siden og var færdig. Skill-kørslen læste skillen, itererede derefter mod den, kontrollerede sit eget output mod en tjekliste, skillen opstiller, justerede afstand, genovervejede farvevalg, genovervejede en layoutbeslutning, den allerede havde truffet én gang.

Det er mekanismen, og den er værd at nævne, fordi det betyder, at token-omkostningen ikke er "at læse et længere dokument." Det er "at udføre arbejdet mere end én gang." En skill, der beskriver, hvordan godt design ser ud, forvandler en enkelt-pass generationsopgave til noget, der ligner en selv-review-loop, og selv-review-loops er af natur dyre i tokens, uanset om et menneske eller en model kører dem.

Hvornår +98% tokens er et kup, og hvornår det ikke er

Hvis leverancen er designet, er dette ikke en svær afgørelse. En landingsside, en klient vil se på, et porteføljestykke, alt hvor "ser dette ud som om det er lavet af en med smag" er en del af jobbeskrivelsen: token-omkostningen her er tættere på en afrundingsfejl end en budgetpost. Ingen diskuterer at betale en designer for et andet udkast. At betale en model i tokens for den tilsvarende iteration er den samme handel til en meget lavere pris, selv ved dobbelt så høj baseline-omkostning.

Hvis leverancen er et internt værktøj, en prototype ingen uden for teamet vil se, eller en side der eksisterer for at bevise at et API-endpoint virker snarere end at repræsentere et brand, så spring det over. Baselinens papir-og-ravfarvede side med dens tilfældige gradients gør arbejdet. Ingen, der evaluerer et internt adminpanel, vil bemærke, at overskriften brugte background-clip: text, og at betale dobbelt så mange tokens for at rette en fejl, ingen vil se, er ikke et kvalitetskøb, det er bare en større regning.

Beslutningspunktet er ikke skillens kvalitet, som er reel. Det er, om nogen vil se resultatet tæt nok på til at bekymre sig.

Sådan reproducerer du dette selv

Du behøver ikke vores præcise brief for at køre denne sammenligning på dit eget arbejde. Opsætningen er enkel nok til at gentage på en eftermiddag.

• Skriv en brief med konkrete begrænsninger: et produktnavn, et specifikt sæt sektioner, en specifik prisstruktur, "ingen frameworks" hvis det betyder noget for dig. Vage briefs producerer vage deltaer, fordi der er mindre for en design skill at arbejde imod.
• Kør den én gang med en ren model og ingen skills installeret. Gem outputtet og noter token-antallet fra din harness-telemetri, ikke et estimat.
• Installer frontend-design (eller hvilken som helst design skill du evaluerer), genstart din session, så skillens beskrivelse er frisk indlæst, og kør den identiske brief igen, kun ændret af en linje, der beder modellen om at læse og følge skillen.
• Sammenlign de to outputs for de specifikke kendetegn, vi fandt her: antal gradients, brug af background-clip: text, om paletten ser valgt eller standard ud, om typeskalaen er konsistent. Læs vores testprotokol for den fulde version af denne proces, inklusive den trigger-batteri vi kører før enhver output-sammenligning.
• Sammenlign token-antal sidst, efter du har dannet dig en mening om outputtet. Hvis du ser på regningen først, farver det, hvor generøs du er med den visuelle sammenligning, og den rækkefølge betyder mere, end det lyder som om den burde.

Ofte stillede spørgsmål

Fordobler frontend-design skillen altid token-forbruget?

Ikke nødvendigvis, og vi hævder ikke en fast multiplikator. Denne kørsel viste +98% på én brief med én model. Mekanismen bag stigningen, flere værktøjskald fordi modellen kontrollerer sit output mod skillens egen vejledning, bør generalisere, men den præcise procentdel vil variere med briefens kompleksitet og hvor meget frem og tilbage modellen beslutter, den har brug for.

Er én kørsel per arm nok til at stole på disse tal?

Nok til at stole på mønsteret, ikke nok til at stole på den præcise procentdel. Vi kalder dette N=1 bevidst, så ingen forveksler det med en kontrolleret undersøgelse. Hvad vi kan sige med større sikkerhed er retningen: skill-guided iteration koster mere og producerer et synligt mere gennemtænkt resultat, et mønster der viser sig på tværs af enhver design-skill sammenligning, vi har kørt mindre formelt i normal testning.

Hvorfor ikke bare prompte Claude til at "undgå gradient-tekst og generisk AI-design"?

Det kan du, og det vil hjælpe lidt. Men en enkelt-linjes instruktion bærer ikke den ræsonnement, en fuld skill gør, den specifikke palette-logik, type-skala-reglerne, den tjekliste modellen itererer imod. Vores fulde testprotokol dækker, hvorfor prompt-niveau instruktioner og skill-niveau instruktioner har tendens til at producere forskellige dybder af resultat, selv når de peger mod det samme mål.

Hvordan sammenligner dette sig med Claudes output på andre typer opgaver?

Designopgaver er det tilfælde, hvor en skill har mest åbenlys plads til at hjælpe, fordi "ser dette særpræget ud" er læseligt selv uden et scorecard. Vores andre Skill Bench-indlæg tester skills mod en Telegram bot-bygning, en debugging-session og en script-audit, tre domæner hvor sejren, hvis der er en, ser anderledes ud end en pænere palette. Se den fulde metodologi for, hvordan vi scorer på tværs af alle fire.

Vi valgte denne brief, fordi en landingsside taler for en design skill uden behov for fortolkning. Se på de to sider side om side, og paletten, antallet af gradients og type-disciplinen fortæller dig alt, hvad token-tabellen ikke kan. Det næste indlæg i denne serie bytter den visuelle klarhed ud med noget sværere at bedømme visuelt: en fungerende bot, hvor "bedre" skal bedømmes ud fra, om tingen kører.