Vi bygget samme landingsside med og uten en ferdighet

Ferdighetsbenken, del 1 av 4. Samme modell, samme prompt, én ferdighet installert eller ikke. Denne artikkelen: en landingsside. Også i serien: en Telegram-bot, feilsøking av et slangespill, og revisjon av et Google zx-skript.

Hver ferdighetsanmeldelse på dette nettstedet ender med det samme ubesvarte spørsmålet: får denne ferdigheten Claude til å gjøre bedre arbeid, eller får den bare Claude til å gjøre mer arbeid? Dette er ikke det samme, og de fleste testoppsett kan ikke skille dem fra hverandre fordi kjøringene ikke er kontrollert stramt nok til å isolere den ene variabelen som betyr noe.

Så vi kjørte et eksperiment. To kjøringer, samme modell, samme brief, ned til tegnsettingen. Den eneste forskjellen mellom dem er én instruksjon: "les og følg denne installerte ferdigheten." Kjøring én, modellen bygger uten hjelp. Kjøring to, vi peker den mot den faktiske frontend-design-ferdigheten, den som ligger på 9.6 av 10 i vår katalog, og lar den lese den virkelige SKILL.md før den rører noen kode. Deretter sammenligner vi de to landingssidene linje for linje og teller tokenene hver kjøring kostet.

Dette er den første av fire slike sammenligninger. Vi valgte en landingsside å starte med fordi visuell design er domenet der "bedre" er lettest å diskutere og vanskeligst å forfalske. En gradient-tung hero ser enten ut som alle andre AI-bygde sider eller den gjør det ikke, og du trenger ikke en benchmark for å se hvilken.

Oppsettet

Briefen var den samme for begge kjøringene, en enkeltfils landingsside for "Nimbus", en fiktiv vær-API, skrevet til en Stripe-kaliber standard: hero-seksjon, tre funksjonsblokker, en pristabell med Free, $29 og $199 nivåer, en kodeeksempelblokk og en bunntekst. Ingen rammeverk, ingen byggetrinn, én HTML-fil med innebygd CSS.

Kjøring én fikk den briefen og ingenting annet. Kjøring to fikk den identiske briefen pluss en peker til den installerte frontend-design-ferdigheten, som modellen deretter leste i sin helhet før den startet.

Én viktig forbehold, uttalt tydelig i stedet for begravd: dette er N=1. Én kjøring per arm, én modell, én brief. Vi hevder ikke at disse tallene er statistisk stabile over hundre forsøk, og hvis du kjører dette selv, vil du få forskjellige spesifikke tall. Det vi hevder er smalere og, vi tror, mer nyttig: dette er hva som skjedde, i detalj, på en reell kjøring, med reell telemetri, og det er et mønster vi har sett ofte nok i mindre kontrollert testing til å stole på formen selv før vi kjører runde to og tre.

Hva grunnlinjen bygget

Overlatt til seg selv produserte Claude en side de fleste som har sett mye AI-utdata ville gjenkjenne umiddelbart. 890 linjer, et lyst fargevalg bygget rundt papir- og ravtoner, og det er verdt å være rettferdig her: koden var ren, teksten var rimelig, layouten fungerte, ingenting var ødelagt.

Kjennetegnene lå alle i detaljene. Elleve separate gradienter over siden, i hero-bakgrunnen, i knappetilstander, i kortrammer, på steder der en gradient la til visuell støy i stedet for å gjøre en jobb. To overskrifter brukte background-clip: text for å male selve teksten i en gradient, den mest gjenkjennelige AI-designsignaturen som finnes på dette tidspunktet. Statistikktall fløt i egne kort over folden, løsrevet fra all layoutlogikk, den typen element som ser ut til å ha blitt lagt til fordi en mal et sted har en, ikke fordi denne spesifikke siden trengte det.

Ingenting av dette er inkompetent. Det er utdata fra en modell som er god på webdesign generelt og ikke har et spesifikt synspunkt om dette merket spesifikt, så den tyr til de samme grepene som dukker opp når det samme spørsmålet stilles uten mer begrensning. En kjøring på 63,329 tokens kjøpte en leverbar side. Den kjøpte ikke en side noen ville huske, og det er den samme siden vi ville forvente fra de fleste ferdighetene i vår oversikt over beste designferdigheter hvis du fjerner designferdigheten igjen.

Hva ferdighetsarmen bygget annerledes

Den ferdighetsstyrte kjøringen leste den faktiske anthropics/skills frontend-design SKILL.md før den skrev noe, og den resulterende siden leses som om den kom fra en helt annen designbrief. Mørk marineblå bakgrunn (--bg: #0B1119) paret med en messingaksent (--brass: #D2A25C), en kombinasjon som ikke dukker opp noe sted i grunnlinjens søkeområde og leses som et bevisst valg snarere enn en standard. 985 linjer, fire gradienter i stedet for elleve, og null forekomster av gradient-text. Ikke færre, null. Typesystemet var disiplinert på en måte grunnlinjens ikke var: konsistent skala, konsistent vektlogikk, overskrifter som ser valgt ut snarere enn tilpasset størrelse.

Ingenting ved denne siden skriker "premium" slik et stockfoto av et håndtrykk skriker "corporate". Det er roligere enn det. Paletten er uvanlig nok til at den ikke leses som en mal, og tilbakeholdenheten med gradienter betyr at de som gjenstår faktisk bærer vekt i stedet for å dekorere alt de berører. Hvis du ga begge sidene til en klient og spurte hvilken en designbevisst grunnlegger ville sende ut, er dette ikke en vanskelig avgjørelse.

Tallene

| | |---|---|---|---| | Grunnlinje (ingen ferdighet) | Ferdighetsarm (frontend-design) | Delta | | Tokens brukt | 63,329 | 125,165 | +98% | | Verktøykall | 6 | 57 | +51 | | Utdata lengde | 890 lines | 985 lines | +95 lines | | Gradienter | 11 | 4 | -7 | | Gradient-tekst forekomster | 2 | 0 | -2 | | Palett | Light, paper + amber | Dark navy + brass | — |

Token-antallet er hovedpoenget og det er ikke subtilt: ferdighetskjøringen kostet nesten dobbelt så mye. Det er ikke en avrundingsfeil du kan tilskrive støy, og det er tallet alle andre påstander i denne artikkelen har å leses opp mot.

Hvorfor ferdigheten koster mer

Token-gapet handler egentlig ikke om ferdighetens filstørrelse. SKILL.md-filer er typisk noen få tusen tokens, ikke nok i seg selv til å doble en 63k-token kjøring. Det som faktisk skjedde er synlig i antall verktøykall: 6 mot 57. Grunnlinjekjøringen skrev siden og var ferdig. Ferdighetskjøringen leste ferdigheten, deretter itererte den mot den, sjekket sin egen utdata mot en sjekkliste ferdigheten legger ut, justerte avstand, revurderte fargevalg, tvilte på en layoutbeslutning den allerede hadde tatt én gang.

Det er mekanismen, og det er verdt å nevne fordi det betyr at token-kostnaden ikke er "å lese et lengre dokument." Det er "å gjøre arbeidet mer enn én gang." En ferdighet som beskriver hvordan god design ser ut, gjør en enkeltpass-genereringsoppgave til noe nærmere en selvvurderingssløyfe, og selvvurderingssløyfer er av natur dyre i tokens, enten et menneske eller en modell kjører dem.

Når +98 % tokens er et kupp, og når det ikke er det

Hvis leveransen er designet, er dette ikke en vanskelig avgjørelse. En landingsside som en klient vil se på, et porteføljestykke, alt der "ser dette ut som det ble laget av noen med smak" er en del av stillingsbeskrivelsen: token-kostnaden her er nærmere en avrundingsfeil enn en budsjettpost. Ingen diskuterer å betale en designer for et andre utkast. Å betale en modell i tokens for tilsvarende iterasjon er den samme handelen til en mye lavere pris, selv til dobbel grunnlinjekostnad.

Hvis leveransen er et internt verktøy, en prototype ingen utenfor teamet vil se, eller en side som eksisterer for å bevise at et API-endepunkt fungerer snarere enn å representere et merke, hopp over det. Grunnlinjens papir- og ravfargede side med sine tilfeldige gradienter gjør jobben. Ingen som evaluerer et internt adminpanel vil legge merke til at overskriften brukte background-clip: text, og å betale dobbelt så mange tokens for å fikse en feil ingen vil se er ikke et kvalitetskjøp, det er bare en større regning.

Beslutningspunktet er ikke ferdighetens kvalitet, som er reell. Det er om noen kommer til å se nøye nok på resultatet til å bry seg.

Slik reproduserer du dette selv

Du trenger ikke vår eksakte brief for å kjøre denne sammenligningen på ditt eget arbeid. Oppsettet er enkelt nok til å gjøres om på en ettermiddag.

• Skriv en brief med konkrete begrensninger: et produktnavn, et spesifikt sett med seksjoner, en spesifikk prisstruktur, "ingen rammeverk" hvis det er viktig for deg. Vage briefer produserer vage deltaer, fordi det er mindre for en designferdighet å jobbe mot.
• Kjør den én gang med en ren modell og ingen ferdigheter installert. Lagre utdata og noter token-antallet fra din telemetri, ikke et estimat.
• Installer frontend-design (eller hvilken som helst designferdighet du evaluerer), start økten din på nytt slik at ferdighetens beskrivelse er ferskt lastet, og kjør den identiske briefen igjen, endret av ingenting bortsett fra en linje som forteller modellen å lese og følge ferdigheten.
• Sammenlign de to utdataene for de spesifikke kjennetegnene vi fant her: antall gradienter, bruk av background-clip: text, om paletten ser valgt eller standard ut, om typeskalaen er konsistent. Les vår testprotokoll for den fullere versjonen av denne prosessen, inkludert trigger-batteriet vi kjører før enhver utdatasammenligning.
• Sammenlign token-antall sist, etter at du har dannet deg en mening om utdataene. Hvis du ser på regningen først, farger det hvor generøs du er med den visuelle sammenligningen, og den rekkefølgen betyr mer enn det høres ut som den burde.

Ofte stilte spørsmål

Dobler frontend-design-ferdigheten alltid token-bruken? Ikke nødvendigvis, og vi hevder ikke en fast multiplikator. Denne kjøringen viste +98 % på én brief med én modell. Mekanismen bak økningen, flere verktøykall fordi modellen sjekker utdataene sine mot ferdighetens egen veiledning, bør generalisere, men den eksakte prosenten vil variere med briefens kompleksitet og hvor mye frem og tilbake modellen bestemmer seg for at den trenger.

Er én kjøring per arm nok til å stole på disse tallene? Nok til å stole på mønsteret, ikke nok til å stole på den nøyaktige prosenten. Vi kaller dette N=1 bevisst slik at ingen forveksler det med en kontrollert studie. Det vi kan si med mer sikkerhet er retningen: ferdighetsstyrt iterasjon koster mer og produserer et synlig mer gjennomtenkt resultat, et mønster som dukker opp på tvers av hver designferdighets-sammenligning vi har kjørt mindre formelt i vanlig testing.

Hvorfor ikke bare be Claude om å "unngå gradient-tekst og generisk AI-design"? Det kan du, og det vil hjelpe litt. Men en enlinjes instruksjon bærer ikke med seg resonnementet en full ferdighet gjør, den spesifikke palettlogikken, typeskala-reglene, sjekklisten modellen itererer mot. Vår fulle testprotokoll dekker hvorfor instruksjoner på prompt-nivå og ferdighets-nivå har en tendens til å produsere forskjellige dybder av resultat selv når de peker mot samme mål.

Hvordan sammenlignes dette med Claudes utdata på andre typer oppgaver? Designoppgaver er tilfellet der en ferdighet har mest åpenbar mulighet til å hjelpe, fordi "ser dette særegent ut" er lesbart selv uten et resultatkort. Våre andre Ferdighetsbenk-innlegg tester ferdigheter mot en Telegram-bot-bygging, en feilsøkingsøkt og en skriptrevisjon, tre domener der seieren, hvis det er en, ser annerledes ut enn en finere palett. Se den fulle metodikken for hvordan vi scorer på tvers av alle fire.

Vi valgte denne briefen fordi en landingsside fremmer en designferdighets sak uten behov for tolkning. Se på de to sidene side om side, og paletten, antall gradienter og typografidisciplinen forteller deg alt token-tabellen ikke kan. Neste innlegg i denne serien bytter den visuelle klarheten mot noe vanskeligere å bedømme: en fungerende bot, der "bedre" må bedømmes ut fra om tingen kjører.