5 prompt-teknikker der faktisk virker i produktion
Konkrete prompt-strategier du kan bruge i morgen for at øge kvaliteten af AI-output i dine daglige workflows — uden buzzwords.
5 prompt-teknikker der faktisk virker i produktion
Langt de fleste guides om prompt engineering er skrevet af folk der ikke shipper production code. Det her er skrevet fra den anden side.
Jeg bruger disse fem teknikker dagligt hos Solar A/S — og de har ændret måden jeg arbejder med AI på mere end noget kursus nogensinde har gjort.
1. Giv altid en rolle og en kontekst
Dårligt prompt:
Skriv en funktion der henter data fra en API.
Godt prompt:
Du er en senior TypeScript-udvikler. Skriv en async funktion der henter data fra REST API'et
på /api/orders. Brug fetch, håndter HTTP-fejl med en custom Error-klasse, og returner en
stærkt typet Order[]. Vi bruger Node 20 og har ikke axios installeret.
Forskellen er ikke stil — det er output-kvalitet. Rollen aktiverer det rigtige "mode" i modellen.
Jeg testede det for nylig med en kollegas debugging-problem. Uden rolle fik vi generisk JavaScript. Med rollen "senior TypeScript-udvikler der arbejder i et Node 20 monorepo" fik vi kode der passede direkte ind i vores stack — første forsøg.
2. Chain of thought for komplekse problemer
For alt der ikke er trivielt, bed modellen om at tænke trin for trin inden den svarer.
Tænk igennem problemet trin for trin, og skriv dine overvejelser ned. Giv derefter din
endelige løsning.
Problem: Vores checkout-flow dropper 40% af transaktioner på betalingssiden. Hvilke tre
tekniske årsager bør vi undersøge først?
Du får bedre svar — og du kan faktisk følge ræsonnementet og spotte fejl.
3. Brug XML-tags til at strukturere komplekse inputs
Når du sender kode, specifikationer og instruktioner i samme prompt, brug tags:
<kode>
[din eksisterende kode her]
</kode>
<fejl>
TypeError: Cannot read property 'id' of undefined at line 47
</fejl>
<opgave>
Identificer den præcise årsag til fejlen og ret den. Ændr ikke andre dele af koden.
</opgave>
Så ved modellen præcis hvad der er kode, hvad der er fejlbesked, og hvad der er instruktion.
4. Negative constraints er mindst ligeså vigtige som positive
Fortæl altid hvad du ikke vil have. Specielt vigtigt i code review og refactoring:
Refactor denne funktion for at forbedre læsbarheden.
Constraints:
- Ændr IKKE den offentlige API eller parameternavne
- Introducer IKKE nye dependencies
- Behold kommentarerne intakte
- Gør det IKKE kortere på bekostning af klarhed
Uden constraints optimerer modellen mod det forkerte mål halvdelen af gangene.
Det lærte jeg den hårde vej, da en AI-refactoring pludselig omdøbte alle mine parametre til camelCase — selvom vores codebase konsekvent bruger snake_case. Ét constraint havde forhindret det.
5. Iterér med "hvad mangler?" frem for at starte forfra
Når et output er 80% rigtigt, start ikke forfra. Spørg:
Det er næsten rigtigt. Hvad mangler, og hvad ville du ændre for at gøre det produktionsklar?
Modellen har kontekst. Brug den. Det sparer dig for 60% af den tid folk spilder på at prompte.
Kort sagt
Ingen af disse teknikker kræver abonnement på et kursus. De kræver disciplin og lidt øvelse. Den største gevinst ligger ikke i at lære nye teknikker — men i at holde op med at sende sløve prompts.
Vil I have jeres team til at arbejde med disse teknikker i praksis — med jeres egen kodebase og jeres egne workflows? Det er præcis det vi gør i en Nordic Logic workshop.