Hva er prompt engineering? En praktisk guide for ikke-utviklere

Prompt engineering er å skrive og forbedre instruksjoner til en AI-modell, slik at den pålitelig produserer det du ønsker. En prompt er alt du gir modellen – et spørsmål, en oppgave, litt kontekst, eksempler. Å jobbe med prompt engineering betyr å være bevisst på hva som settes inn, teste hva som kommer ut, og justere. Det handler mindre om magiske fraser og mer om klar kommunikasjon.

Hvorfor det betyr noe når du bygger med AI

Med et AI-verktøy for å bygge apper er prompten din spesifikasjonen. AI-en kan bare bygge det du beskriver, og når forespørselen din har hull, fyller den dem med fornuftige gjetninger. Noen ganger er gjetningene gode. Ofte er de ikke det du mente: feil felt i et skjema, en funksjon du ikke ville ha, en design som ikke passer målgruppen din.

En tydelig prompt sparer deg for runder med rettelser, og hver runde koster tid og som regel kreditter. Prompting betyr også noe hvis du legger AI inne i appen din: instruksjonene du gir den modellen, bestemmer hvordan chatboten din snakker med kunder, hva den nekter å svare på, og om den holder seg til fakta dine. For apputvikling spesifikt, se hvordan skrive prompter til AI-verktøy for apper.

En hverdagslig analogi

Tenk deg at du gir en dyktig frilanser en brief. Hen har aldri møtt deg, kjenner ikke virksomheten din, og starter arbeidet så snart du er ferdig med å snakke.

«Lag meg en logo» gir deg en logo. «En logo for en svømmeskole for barn i Dubai; vennlig, ikke barnslig; blå og oransje; må fungere liten på en badehette; her er to vi liker og én vi ikke liker» gir deg noe nær det du vil ha.

En AI-modell er den frilanseren – talentfull, rask og helt avhengig av briefen din. Prompt engineering er å lære seg å skrive en god brief.

De viktigste teknikkene

Et arbeidseksempel: før og etter

Før:

Lag en treningsapp.

AI-en må gjette alt: medlemmer eller ansatte? Gruppetimer eller personlig trening? Betaling? Du får sannsynligvis et generisk dashbord med oppdiktede treningsøkter.

Etter:

Bygg en nettapp for et lite boksestudio med rundt 150 medlemmer.

Hvem bruker den: Medlemmer booker timer på mobilen sin. Eieren, Sam, administrerer timeplanen på en laptop.

Medlemmer kan: se ukens timer (tidspunkt, trener, ledige plasser) og booke eller avbestille opptil 2 timer før start.

Sam kan: legge til, redigere og avlyse timer, og se hvem som er påmeldt hver time.

Regler: maks 12 personer per time. Ingen dobbeltbooking av samme tidspunkt.

Ikke nå: betalinger, treningslogg, en mobilapp.

Stil: mørk bakgrunn, røde aksenter, store knapper å trykke på.

Før du bygger, list opp alt som er uklart og beskriv sidene du vil lage.

Den andre prompten er ikke smart; den er komplett. Den nevner brukere, handlinger, regler, hva som skal utelates og hvordan man skal starte. Den siste linjen inviterer AI-en til å planlegge og stille spørsmål, noe som fanger misforståelser før det skrives noe kode.

Prompter inne i appen din

Når appen din selv kaller en LLM, skriver du prompter som kjøres mange ganger, for mange brukere. De samme prinsippene gjelder, pluss noen til:

• Systemprompt: faste instruksjoner som former hvert svar – rolle, tone, regler. «Du er assistenten for Leaf & Pot, en plantebutikk. Svar kun på spørsmål om bestillinger, planter og levering.»
• Forankring (grounding): ta med fakta modellen skal bruke, for eksempel retningslinjene dine eller produktkatalogen, og be den basere seg på dem. Se hva en LLM er for hvorfor dette betyr noe.
• Reserveløsninger: si hva den skal gjøre når den er usikker: «Hvis svaret ikke finnes i informasjonen som er gitt, si det og tilby support-e-posten.»
• Utdataformat: hvis koden din leser svaret, be om et strengt format, for eksempel JSON.
• Testing: prøv vanskelige innspill – stygge meldinger, spørsmål utenfor temaet, forsøk på å få den til å ignorere instruksjonene sine (kalt prompt injection) – før ekte brukere gjør det.

Viktige begreper forklart

Vanlige feil og misforståelser

• Å lete etter magiske ord. «Du er en ekspert i verdensklasse» betyr langt mindre enn å si hva du faktisk trenger.
• Å be om alt på én gang. En forespørsel med 20 funksjoner gir 20 halvferdige funksjoner. Bygg i biter.
• Å beskrive løsningen i stedet for problemet. «Legg til en tabell med tre kolonner» er mindre nyttig enn «Sam må se hvem som er påmeldt hver time med et blikk».
• Å utelate hva som ikke skal gjøres. Hvis du ikke vil ha innlogging, betaling eller en redesign ennå, si det.
• Å ikke lese resultatet. Test det som er bygget mot din definisjon av «ferdig» før du går videre.
• Å starte på nytt i stedet for å forbedre. Som regel er en kort oppfølging («nesten bra; endre X») bedre enn å skrive hele prompten på nytt.
• Å lime inn hemmeligheter i prompter. Ikke lim inn passord eller live API-nøkler i chatten, med mindre verktøyet har en sikker måte å lagre dem på.

Hva du kan be AI-verktøyet om

• «Før du bygger, still meg eventuelle spørsmål og vis meg planen din.»
• «Gjenta hva du tror jeg vil ha, i tre setninger.»
• «Endre bare bookingskjemaet; ikke rør noe annet.»
• «Hva antok du som jeg ikke har spesifisert?»
• «Gjør notatene mine om til en kort spesifikasjon med brukere, funksjoner, regler og «ikke nå»-punkter.» Se hvordan skrive et produktkrav med AI.
• «Foreslå hvordan jeg kunne ha formulert den forespørselen bedre.»

Prompting i Mythex

Mythex har tre chatmodi som passer til denne måten å jobbe på: Plan for å bli enige om en tilnærming før noe endres, Build for å gjøre endringer, og Ask for spørsmål som ikke skal redigere filer. Du kan legge ved skjermbilder eller skisser som kontekst, og hvis en endring går galt, kan du rulle tilbake til et checkpoint. Dokumentasjonssidene om effektive prompter og iterering har flere eksempler, og hvordan iterere på en AI-bygget app dekker oppfølgingsløkken.

Spørsmål