Hvad er prompt engineering? En praktisk guide for ikke-udviklere

Prompt engineering er at skrive og forfine instruktioner til en AI-model, så den pålideligt producerer det, du ønsker. En prompt er alt, hvad du giver modellen — et spørgsmål, en opgave, noget kontekst, eksempler — og at engineere den betyder at være bevidst om, hvad der kommer ind, teste hvad der kommer ud og justere. Det handler mindre om magiske formuleringer og mere om klar kommunikation.

Hvorfor det betyder noget, når du bygger med AI

Med et AI-værktøj til at bygge apps er dine prompts specifikationen. AI'en kan kun bygge det, du beskriver, og når din forespørgsel har huller, udfylder den dem med fornuftige gæt. Nogle gange er gætterierne gode. Ofte er de ikke, hvad du mente: de forkerte felter i en formular, en funktion du ikke ville have, et design der ikke passer til din målgruppe.

En klar prompt sparer dig for flere runder med rettelser, og hver runde koster tid og typisk credits. Prompting betyder også noget, hvis du tilføjer AI inde i din app: de instruktioner du giver den model, afgør hvordan din chatbot taler med kunderne, hvad den afviser, og om den holder sig til dine fakta. Til app-bygning specifikt, se sådan skriver du prompts til AI-app-builders.

En hverdagsanalogi

Forestil dig, at du briefer en dygtig freelancer, som aldrig har mødt dig, ikke kender din virksomhed, og som går i gang lige så snart du holder op med at tale.

"Lav mig et logo" giver dig et logo. "Et logo til en svømmeskole for børn i Dubai; venligt, ikke babyagtigt; blå og orange; skal virke småt på en badehætte; her er to vi kan lide og et vi ikke kan lide" giver dig noget, der ligner det, du vil have.

En AI-model er den freelancer — talentfuld, hurtig og fuldstændig afhængig af din brief. Prompt engineering er at lære at skrive en god brief.

De centrale teknikker

Et eksempel: før og efter

Før:

Lav en træningsapp.

AI'en skal gætte alting: medlemmer eller personale? Hold eller personlig træning? Betalinger? Du får sandsynligvis et generisk dashboard med opdigtede træningsprogrammer.

Efter:

Byg en webapp til et lille boksegym med cirka 150 medlemmer.

Hvem bruger den: Medlemmerne booker hold på deres telefoner. Ejeren, Sam, administrerer skemaet på en computer.

Medlemmer kan: se ugens hold (tidspunkt, træner, ledige pladser) og booke eller afmelde op til 2 timer før start.

Sam kan: oprette, redigere og aflyse hold og se, hvem der er booket til hvert hold.

Regler: maks. 12 personer pr. hold. Ingen dobbeltbookinger af samme tidspunkt.

Ikke nu: betalinger, træningslog, en mobilapp.

Stil: mørk baggrund, røde accenter, store knapper.

Før du bygger, så list alt, der er uklart, og beskriv de sider du vil oprette.

Den anden prompt er ikke smart; den er komplet. Den nævner brugere, handlinger, regler, hvad der skal udelades, og hvordan man starter. Den sidste linje inviterer AI'en til at planlægge og stille spørgsmål, hvilket fanger misforståelser, inden der skrives kode.

Prompts i din app

Når din app selv kalder en LLM, skriver du prompts, der kører mange gange, for mange brugere. De samme principper gælder, plus nogle få flere:

• System-prompt: faste instruktioner, der former hvert svar — rolle, tone, regler. "Du er assistenten for Leaf & Pot, en planteforretning. Svar kun på spørgsmål om ordrer, planter og levering."
• Forankring (grounding): inkluder de fakta, modellen skal bruge, fx dine politikker eller produktkatalog, og bed den om at bygge på dem. Se hvad er en LLM for hvorfor det er vigtigt.
• Reserveplaner: fortæl den, hvad den skal gøre, når den er usikker: "Hvis svaret ikke findes i de givne oplysninger, så sig det og tilbyd supportmailen."
• Outputformat: hvis din kode læser svaret, så bed om et strengt format som JSON.
• Test: prøv upraktiske input — uhøflige beskeder, emner uden for området, forsøg på at få den til at ignorere sine instruktioner (kaldet prompt injection) — før rigtige brugere gør det.

Vigtige begreber forklaret

Almindelige fejl og misforståelser

• At lede efter magiske ord. "Du er en eksperthed i verdensklasse" betyder langt mindre end at sige, hvad du faktisk har brug for.
• At bede om alt på én gang. En forespørgsel med 20 funktioner giver 20 halvfærdige funktioner. Byg i skiver.
• At beskrive løsningen i stedet for problemet. "Tilføj en tabel med tre kolonner" er mindre nyttigt end "Sam skal kunne se, hvem der er booket til hvert hold, med et blik."
• At udelade, hvad der ikke skal gøres. Hvis du ikke vil have login, betalinger eller et redesign endnu, så sig det.
• At læse resultatet ikke. Test det, der er bygget, mod din definition af 'færdig', før du går videre.
• At starte forfra i stedet for at forfine. Normalt slår en kort opfølgning ("det er tæt på; ændr X") det at omskrive hele prompten.
• At indsætte hemmeligheder i prompts. Indsæt ikke adgangskoder eller aktive API-nøgler i chatten, medmindre værktøjet har en sikker måde at gemme dem på.

Hvad du beder din AI-builder om

• "Før du bygger, så stil mig eventuelle spørgsmål og vis mig din plan."
• "Gentag med tre sætninger, hvad du tror jeg vil have."
• "Ændr kun booking-formularen; rør ikke ved andet."
• "Hvad antog du, som jeg ikke har specificeret?"
• "Lav mine noter om til en kort specifikation med brugere, funktioner, regler og 'ikke nu'-punkter." Se sådan skriver du et produktkravsdokument med AI.
• "Foreslå, hvordan jeg kunne have formuleret den anmodning bedre."

Prompting i Mythex

Mythex har tre chat-tilstande, der passer til denne måde at arbejde på: Plan for at blive enige om en tilgang, før noget ændres, Build for at lave ændringer, og Ask til spørgsmål, der ikke må ændre filer. Du kan vedhæfte skærmbilleder eller mockups som kontekst, og hvis en ændring går galt, kan du rulle tilbage til et checkpoint. Dokumentationssiderne om effektive prompts og itération har flere eksempler, og sådan itererer du på en AI-bygget app dækker opfølgningsloopet.

Spørgsmål