Introduksjon: Koden bryr seg ikke om dine vibber
Her er greia med store språkmodeller og kode: de er forbløffende selvsikre og fullstendig likegyldige til om programmet ditt kompileres. Claude Haiku 4.5 vil gladelig skrive et Python-skript for deg som løser problemet ditt, pluss to den fant opp for moro skyld. Trikset – det eneste trikset som betyr noe – er å lære hvordan du skal Claude Haiku 4.5 for nøyaktig kode generering på en måte som gir null rom for vibber og maksimalt rom for sannhet. Du vil ikke ha prosa som høres ut som kode. Du vil ha kode som oppfører seg som kode. Det er en forskjell.
Folk behandler prompting som mystisk besvergelse – si de riktige ordene, få en perfekt app. Det er tankegang fra en lastkult. Kode er en kontrakt. Hvis du vil ha nøyaktighet fra Claude Haiku, må du skrive kontrakten. «Bygg en webapp» er ikke en kontrakt. «Generer et FastAPI-endepunkt i Python 3.12 som aksepterer JSON, validerer skjema med Pydantic v2 og returnerer 422 ved skjemafeil med et spesifikt nyttelastformat» er en kontrakt. Det er slik du Claude Haiku 4.5 for nøyaktig kode generering: du spikrer kontrakten.
Hva dette er (og ikke er)
- Det er en hvordan-du-guide for å få pålitelig, testbar kode fra Claude Haiku 4.5.
- Det er ikke en preken om «AI som erstatter utviklere». Verktøy erstatter ikke tenking.
- Det er fokusert på praktiske , struktur og sikkerhetsmekanismer: de kjedelige delene som får magien til å fungere.
Hvis du vil ha kode som kjører, må du gi Claude en fungerende definisjon av «kjører». Hvis du vil ha nøyaktig kode generering, må du definere nøyaktighet i klare, testbare termer. Det er hele spillet.
Definer nøyaktighet som en advokat, ikke en poet
«Nøyaktig» kode er ikke kode som «ser plausibel ut». Nøyaktighet er:
- Syntaktisk gyldighet: den kompileres eller kjører under tolken.
- Semantisk troskap: den gjør det spesifikasjonen sier.
- Deterministisk oppførsel: samme innganger, samme utganger, innenfor definerte feilmarginer.
- Versjonskorrekthet: den bruker de riktige SDK-ene, API-versjonene og språkfunksjonene.
Claude vil gi deg det du ber om. Hvis du ber om «en funksjon som sorterer en liste», vil du sannsynligvis få en. Hvis du ber om «en stabil, in-place sortering ved hjelp av Timsort-semantikk med O(1) ekstra plass», er det et annet løfte. «Hvordan Claude Haiku 4.5 for nøyaktig kode generering» starter med å skrive disse løftene inn i .
Det minimale levedyktige , oppgradert
Dårlig: «Skriv en Node API for oppgaver.»
Bedre: «Skriv en Node 20 Express 4 API med en /tasks POST-rute som validerer feltene {title: string, dueDate: ISO 8601} og svarer 201 med det opprettede objektet eller 400 med feildetaljer.»
Korrekt: «Generer en Node 20 Express 4-server med et enkelt /tasks POST-endepunkt. Krav: 1) Valider body med [email protected]; 2) Felter: title (ikke-tom streng, maks 140), dueDate (ISO 8601 fremtidig dato); 3) Ved suksess: 201 med {id: ULID, title, dueDate}; 4) Ved ugyldig: 400 med {error: 'VALIDATION', details: array}; 5) Ingen database; in-memory Map; 6) Inkluder Jest 29 testfil som dekker gyldig, ugyldig (tom tittel, tidligere dato); 7) Gi npm-skript for test og dev; 8) Bruk ESM; 9) Ikke inkluder overflødig kommentar.» Legg merke til formen: språkversjon, biblioteker, begrensninger, utganger, feil, tester og til og med pakkestrukturen. Du har fjernet tvetydighet. Claudes jobb er å fylle ut koden, ikke kravene.
Stillasmønsteret: System, Spesifikasjon, Tester, Deretter Kode
Hvis du vil ha nøyaktig kode generering fra Claude Haiku 4.5, må du gi den en rullebane:
- Systeminnramming (den korte snoren)
- Du: «Du skriver produksjonskvalitets TypeScript for Node 20. Gi kun kodeblokker med filnavn og ingenting annet.»
- Hvorfor: Du kontrollerer tone og utdataformat. Ikke overlat det til tilfeldighetene.
- Spesifikasjon (kontrakten)
- Inkluder språkversjoner, pakkevalg, feilsemantikk, I/O-formater, ytelsesgrenser og sikkerhetsbegrensninger.
- Be Claude om å skrive enhetstester først. Tester definerer «nøyaktig» bedre enn adjektiver. Hvis en kodelinje ikke tjener en test, er den dekorativ.
- Først etter testene. Ja, dette er i utgangspunktet TDD, men med en robot som aldri blir lei av å skrive .
- Instruksjoner for omkjøringer
- «Hvis tester mislykkes eller importer ikke stemmer, oppdater bare de mislykkede delene. Ikke skriv om hele prosjektet.»
Claude gjør det bra når den har kontekst og skinner. Gi den skinner.
Versjonsfesting er ikke valgfritt
Claudes treningsdata er fulle av gamle og nye dokumenter. Det er en høflig måte å si at den har sett mange motstridende råd. «Bruk React Router» er vagt. «Bruk [email protected] med datarutere» er retning. Ikke stol på standarder: - Språk: fest til Python 3.12, Node 20, Go 1.22, Java 21 – uansett hva du faktisk kjører.
- Rammeverk: spesifiser nøyaktige hovedversjoner og eventuelle flagg for endringer som bryter.
- Cloud SDK-er: fest versjoner; aws-sdk v2 vs v3 betyr noe.
- Linters/formaterere: spesifiser regler for å unngå «stil ping-pong»-omskrivninger.
Hvis du ikke fester, får du en greatest-hits medley fra fem år med blogginnlegg. Nøyaktig kode generering er allergisk mot nostalgi.
Skjema først, alltid
Ikke be om «brukerprofil»-strukturer. Definer skjemaer i og krev validering:
- JSON-skjema eller Zod/Yup-typer i JS/TS
- Pydantic-modeller i Python
- Protobuf eller Avro for tjenester
Få deretter Claude til å håndheve skjemaer ved grensene – API-innganger, databaseskrivinger og meldingskøer. Be om eksplisitte feilnyttelaster og -koder. Nøyaktighet elsker skjemaer. Tvetydighet gjør det ikke.
Gjør det observerbart, ellers ikke lat som om det er ekte
Be Claude om å legge til logging, metrikker og sporing der du trenger dem – og å holde dem stille der du ikke gjør det. En god inkluderer:
- Loggingspolicy: nivåer, redigering av PII, struktur (JSON-logger, takk)
- Metrikker: tid per forespørsel, antall feil
- Helseendepunkter: /healthz som beviser at avhengigheter er oppe
Claude vil legge til det du ber om. Hvis du ikke spør, får du utskriftssetninger – hvis du er heldig.
Test-først- slår «Bare stol på meg»
En god måte å Claude Haiku 4.5 for nøyaktig kode generering er å gjøre tester til kilden til sannhet. Eksempel:
«Skriv pytest-tester for en funksjon normalize_email(s) som:
- gjør de lokale og domene delene til små bokstaver;
- fjerner prikker i den lokale delen bare for gmail.com;
- fjerner underadresser (+tag) bare for gmail.com;
- avviser innganger uten en enkelt @ eller med mellomrom;
- beholder unicode domene punycode som-er. Dekk kanttilfeller. Etter å ha skrevet tester, implementer funksjonen for å bestå dem.»
Claude vil ofte skrive bedre kode når den blir tvunget til å tilfredsstille testene du beskrev. Hvis den ikke gjør det, har du en konkret feil, ikke et vibb-argument.
Ingen hallusinasjoner ved konstruksjon
Du kan ikke eliminere hallusinasjoner, men du kan gjerde dem inn:
- Be om sitater eller kilde-URL-er bare når kilder finnes. For SDK-metoder, krev dokumentlenker og krev at koden samsvarer med disse dokumentene.
- For private API-er, lim inn spesifikasjonen i . Ikke forvent at Claude skal kjenne dine interne endepunkter.
- For biblioteker med forvirrende API-er, inkluder et eksempelutdrag fra de offisielle dokumentene og be Claude om å overholde det.
Nøyaktig kode er for det meste nøyaktige referanser. Gi Claude referansene.
Stilguider: Det minst sexy, mest nyttige
Claude skriver kode i hvilken som helst stil den utleder. Det er en oppskrift på churn. Lim inn stilguiden din. Spesifiser:
- Formatering (Prettier, Black, gofmt standard)
Krev også en kort begrunnelseskommentar for ikke-åpenbare valg. Fremtidige deg vil takke deg, og nåværende Claude vil produsere færre «fix-up» PR-er.
Lange , korte utganger
En annen måte å tenke på hvordan du skal Claude Haiku 4.5 for nøyaktig kode generering: bruk ordene dine på , ikke utdataene. Du vil ha:
- Uttømmende begrensninger i
- Minimal overflødig fortelling i utdataene
Be den om å undertrykke forklaringer og returnere bare kodeblokker med filnavn og en kort README. Hvis du vil ha kommentarer, be om det i en separat kjøring. Å flette prosa og kode er hvordan feil sniker seg inn iført monokkel og flosshatt.
Forbedring: Den tette løkken som faktisk fungerer
Den raskeste veien til pålitelig kode er ikke «få det riktig første forsøk». Det er korte, korrigerende løkker:
- Kjør lokalt. Lim inn mislykket testutdata og kompileringsfeil tilbake i Claude ordrett.
- Instruer: «Endre bare de minimum nødvendige linjene; ikke endre funksjonssignaturer med mindre det kreves av mislykkede tester.»
Claude er utmerket til å bruke differ når du forteller den nøyaktig hva som gikk galt. Ikke omskriv feillogger. Lim dem inn. Loggene er sannheten.
Sikkerhet er en funksjon, ikke et postscript
Fordi modeller er trent på offentlig kode (bra, dårlig og forbannet), vil du gjøre sikkerhet til et førsteklasses krav:
- Forby eksplisitt eval, shell=True og strengt-typede SQL
- Krev parametriserte spørringer, CSRF-beskyttelse og hastighetsbegrensning
- Be om versjonsfesting av avhengigheter pluss en låsefil
- Krev håndtering av hemmeligheter via miljøvariabler eller en hemmelighetsadministrator
En sikker-som-standard gir tryggere kode. En «vi skal fikse det senere»- gir overskrifter.
Ytelse: Si hva «rask» betyr
«Gjør det raskt» oversettes til «gjør hva som helst». Spesifiser i stedet metrikker:
- Latensmål (p95 < 50 ms for minne, p95 < 300 ms for DB-operasjoner)
- Minnebegrensninger (RSS < 150 MB)
- Tidskompleksitet (må være O(n log n), ikke O(n^2))
Claude vil velge algoritmer som passer til budsjettet du setter. Gi den et budsjett.
Dokumentasjon: Nok til å onboarde en fremmed
Be Claude om en README som inkluderer:
- Oppsettsinstruksjoner med nøyaktige versjoner
- Kommandoer for test, lint, typecheck, run
- Eksempel på forespørsler/svar
- Begrensninger og kjente kompromisser
«Nøyaktig kode» inkluderer nøyaktige dokumenter. De er en del av leveransen.
Konkrete -maler du kan stjele
Mal: Backend-endepunkt
System: Du er en grundig Python 3.12-ingeniør. Gi kun kodeblokker med filnavn.
Bruker:
- Bygg en FastAPI 0.111-app med et POST /convert-endepunkt.
- Forespørsel: {amount: Decimal as string, from: 'USD'|'EUR', to: same}.
- Valider med pydantic v2; returner 422-form ved skjemafeil.
- Bruk en ren funksjon convert(amount, from, to) med faste kurser {USD:1, EUR:1.1}.
- Returner {amount: string, currency: string} med 200.
- Inkluder pytest-tester som dekker gyldig, ugyldig (dårlig desimal, ukjent kode) og kant (0).
- Gi pyproject.toml med avhengigheter festet; inkluder ruff og mypy-konfigurasjoner.
- Ingen nettverksanrop, ingen kommentarer.
Mal: CLI-verktøy
System: Du skriver Go 1.22. Gi kun kodeblokker med filnavn.
Bruker:
- Lag en CLI kalt slugify som leser stdin og skriver ut URL-sikre slugs.
- Regler: små bokstaver, bare ASCII, bindestreksseparatorer, kollaps mellomrom, fjern tegnsetting.
- Gi main.go og slugify_test.go med tabelltester.
- Inkluder Makefile med test- og build-mål.
Mal: Frontend-komponent
System: Du er en pragmatisk React-ingeniør som retter seg mot React 18 + TypeScript.
Bruker:
- Implementer en <DebouncedInput>-komponent.
- Props: value: string, onChange(value): void, delay=300.
- Bruk useRef/useEffect; ingen tredjeparts hooks.
- Inkluder vitest-tester med falske tidtakere.
- Gi minimal Storybook-historie.
Disse malene demonstrerer hvordan du kan Claude Haiku 4.5 for nøyaktig kode generering ved å feste versjoner, definere atferd og kreve tester.
Nekter å være smart: Når du skal si «Ikke optimaliser»
Hvis du ikke vil ha for tidlige mikrooptimaliseringer (og det vil du ikke), si det:
- «Foretrekk lesbarhet fremfor smarthet; ingen bit-twiddling med mindre testene krever det.»
- «Ingen rekursjon hvis iterativ er tydeligere.»
- «Ingen metaprogrammering; eksplisitt > implisitt.»
Claude elsker å imponere. Ikke la den gjøre det. Få den til å bestå tester og være lesbar. Det er imponerende nok.
Sider.AI i arbeidsflyten, der det faktisk hjelper Jeg har sett folk sjonglere i tilfeldige chat-faner som om det er et produktivitetsrituale. Bruk et arbeidsområde som forstår kodekontekst. Sider.AI er for eksempel bygget rundt å holde spesifikasjonen, koden, differensene og testloggene synlige, slik at «lim inn feilen, fiks linjen»-løkken faktisk er stram. Det er ikke magi; det er kjedelig stillas som hindrer deg i å miste plottet. Hvis verktøyet ditt holder kontrakten, testene og koden i samme samtale – uten å mase på deg med konfetti – bruk det. Sider gjør det. Slik feilsøker du med Claude som en lagkamerat, ikke et orakel
- Lim inn den mislykkede testutdataen nøyaktig som den er. Ikke oppsummer.
- Be om en diff: «Svar med enhetlig diff mot fil X bare.»
- For runtime-feil, legg til det minste reproduserbare utdraget og krev en forklaring pluss en oppdatering.
- For biblioteksfeil, lim inn dokumentutdraget du tror gjelder, og spør: «Er dette den riktige API-en for versjon X? Hvis ikke, oppdater koden og siter det riktige utdraget.»
Målet er å få Claude til å argumentere med bevis. Du kommer med bevisene.
Pitfall-paraden (og hvordan du unngår den)
- «Siste» API-fellen: Ikke si «bruk siste». Si «bruk versjon X.Y» og hold deg til den.
- Den tomme testfilen: Hvis du ikke krever tester, får du dem ikke.
- Den éngangs-feilslutningen: Planlegg to eller tre korte forbedringer. Det er raskere enn én oppblåst .
- Den tvetydige feilpolicyen: Definer statuskoder og nyttelaster. «Returner en feil» betyr ingenting.
- Den ueeide avhengigheten: Hvis koden er avhengig av en tjeneste du ikke kan kontrollere, den. Be om falske.
Sjekklisten din for (Tape dette i nærheten av skjermen)
- Språk- og runtime-versjon festet
- Biblioteksversjoner festet
- Feilsemantikk definert (koder, former)
- Tester først, deretter kode
- Sikkerhetsbegrensninger eksplisitte
- Ytelsesbudsjetter oppgitt
- Stil og struktur spesifisert
- Utdataformat begrenset (filnavn, kodeblokker, differ)
- Kort forbedringsløkke med innlimte logger
Hvis du treffer alle ti, produserer Claude Haiku 4.5 generelt nøyaktig kode generering som overlever dagslys.
Et utarbeidet eksempel: Fra vagt til verifisert
Vag : «Skriv en funksjon for å parse CSV trygt.»
Resultat: Sannsynligvis ok, muligens feil, absolutt utestet.
Presis :
«Du skriver Python 3.12. Gi kun kodeblokker med filnavn. Opprett csvsafe/init.py og csvsafe/reader.py med en funksjon read_rows(path: Path) -> list[dict[str,str]]. Krav: bruk csv.DictReader med newline='' og encoding='utf-8'; ikke tillat null-bytes; avvis filer >10MB; begrens kolonner til 100; fjern BOM; behandle tomme celler som tomme strenger; raise ValueError med meldingskoder {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS}. Inkluder tester i tests/test_reader.py med pytest som dekker happy path, null byte, 11MB fil, 101 kolonner og BOM-håndtering. Gi pyproject.toml med avhengigheter festet og black-konfigurasjon.»
Du får kode, tester og kant behandling. Deretter kjører du tester, limer inn feil og itererer med minimale differ. Det er nøyaktig kode generering i praksis.
Om «Kreativitet» og andre markedsføringsord
Jeg trenger ikke «kreativ» kode. Jeg trenger riktig kode. Spar kreativitet til å navngi katten din. Når du Claude, er kreativitet det naturlige biproduktet av solide begrensninger. De riktige testene og klare spesifikasjonene gir elegante løsninger. Den feil produserer «gjenfunnet base64 med emojier.» Ikke frist den.
Den ikke-hemmelige hemmeligheten
Måten å Claude Haiku 4.5 for nøyaktig kode generering er kjedelig: skriv ned hva du trenger, fest versjonene, definer skjemaene, krev tester og iterer med faktiske feil. Det er det. Ingen mystikk. Bare ingeniørdisiplin, med en modell som kan skrive veldig raskt og ikke har noe imot å skrive femten nesten identiske testtilfeller.
Og det er vendingen: nøyaktighet er lite glamorøst. De som fungerer, leses som en TSA-sjekkliste. Koden som leveres, leses som om den var skrevet av et menneske som brydde seg. Du får begge deler ved å behandle modellen som en junioringeniør som trives under klare krav og visner under vag veiledning. Gi den en kontrakt. Få den til å bestå testene. Da, kanskje, kan du stole på den – med den typen tillit du gir et verktøy, ikke en profet.
Konklusjon: Mindre trolldom, mer garanti
Hvis du vil ha trolldom, gå på et magisk show. Hvis du vil ha programvare som kompileres og oppfører seg, skriv som fungerer som garantier. Hvordan Claude Haiku 4.5 for nøyaktig kode generering handler ikke om blomstrende formuleringer eller hemmelige nøkkelord. Det handler om begrensninger, tester, versjoner og tilbakemeldingssløyfer. Gjør de fire tingene, så får du kode som kjører. Hopp over dem, så får du vakkert formatert fiksjon.
Koden bryr seg ikke om dine vibber. Heldigvis gjør ikke tester det heller.
FAQ
Spørsmål 1: Hva er den enkleste måten å instruere Claude Haiku 4.5 for nøyaktig kode generering?
Behandle det som en kontrakt: fest versjoner, definer skjemaer, spesifiser feilformater, og krev tester først. Jo tydeligere begrensningene er, desto mer nøyaktig blir koden.
Spørsmål 2: Hvordan reduserer jeg hallusinasjoner når Claude skriver kode?
Lim inn autoritative dokumenter eller spesifikasjoner og krev overholdelse av nøyaktig de API-ene. For private endepunkter, inkluder din egen spesifikasjon – ikke forvent at den gjetter.
Spørsmål 3: Bør jeg be Claude om tester eller skrive dem selv?
Be Claude om å generere tester først, og implementer deretter kode for å tilfredsstille dem. Tester definerer nøyaktighet bedre enn adjektiver og holder modellen ærlig.
Spørsmål 4: Hvor spesifikk bør versjonsfesting være i prompter?
Veldig spesifikk: språk runtime, rammeverk major/minor, og SDK-versjoner. "Siste" inviterer til motstridende mønstre; nøyaktighet avhenger av stabile mål.
Spørsmål 5: Hvor passer Sider.AI inn i prompting for nøyaktig kode?
Bruk Sider.AI for å holde spesifikasjoner, kode, diffs og testlogger i en sløyfe. Det gjør ingen magi – det bevarer bare kontekst slik at Claudes rettelser sporer dine faktiske feil. 
