
Derfor lærer KI-kurs deg promptformelen, men aldri hvordan du fikser en prompt som feilet
Kort fortalt: promptformelen — rolle, oppgave, kontekst, format — er gratis. Enhver ti minutters video gir deg den. Trøbbelet begynner ett skritt senere: du skrev prompten etter boka, trykket send, og svaret kom tilbake som grøt. Derfra lærer ingen deg noe som helst. Du skriver om i blinde til noe faller i smak. Det er ikke en ferdighet, det er lotteri. Nedenfor står en metode: gi symptomet et navn, still en diagnose, gjør nøyaktig én endring, sammenlign. Og rekkefølgen du bør grave i: kontekst → oppgave → format → rolle. Promptene i artikkelen er ekte: trykk «Kjør» og se forskjellen med egne øyne.
Hva som er galt med formelen
Formelen lyver ikke for deg. Rolle, oppgave, kontekst og format er faktisk de fire knottene som former et svar. Grunnlaget går vi gjennom i hva en prompt er og hvordan du skriver en, og du trenger det. Men formelen svarer på ett spørsmål: hvordan skriver jeg en prompt fra bunnen? I virkelig arbeid skriver du nesten aldri fra bunnen. Du sitter foran en prompt som allerede følger alle reglene og likevel spyttet ut søppel.
Her tier formelen. Den sier ikke hvilken av de fire knottene som har skylda. Den sier ikke om du skal vri på én eller alle fire. Den sier ikke hvordan du vet om det nye svaret er bedre eller bare annerledes. Formelen er en tegning. Det du trenger, er en reparasjonsanvisning.
Det er forskjellen på «her er tegningen av motoren» og «bilen starter ikke — hva sjekker du først?». Det første lærer du på én kveld. Det andre er et fag. Og det andre finnes nesten ikke på kursmarkedet.
Kursdeltakerne ber om nøyaktig dette — ordrett
17. juli 2026 hentet vi data fra Udemy (via det interne API-et bak kurssidene deres) og fra anmeldelsessidene til Coursera. Vi leste bevisst mindretallet: de som ga lave karakterer. Den tetteste klumpen av klager dukket opp på kurs som har prompt engineering rett i tittelen. Folk kom for ferdigheten på etiketten og fikk den ikke. Ordrett, med forfattere og stjerner:
«There is nothing teached about creating a good prompt. It is just an overview of types of prompts» — Geralt O., 01.07.2026, 2★ (Prompt and Context Engineering 101, Mike Wheeler).
«No specific guidance on prompt engineering… what to avoid while asking, how to organize your thoughts, how to give feedback to AI based on its answers etc.» — Bharat Ram A., 05.06.2026, 1.5★ (Wheeler).
«i thought it would go deeper in prompts and have more examples and sessions to master or enhance our current prompts» — Manuel L., 15.06.2026, 2★ (Prompt Engineering for Everyone).
«Too much background on ChatGPT. Get me to how to prompt GPT» — Mark R., 16.09.2025, 1.5★ (Academind).
Stopp opp ved Bharat Ram A. Han nevner tre ting, og den tredje er «how to give feedback to AI based on its answers». Det er debugging, beskrevet med hans egne ord av en som lette etter det og kom tomhendt tilbake. Manuel L. ber om å «enhance our current prompts» — altså å reparere noe som allerede er skrevet og fungerer dårlig. Ulike folk, ulike kurs, samme hull.
Ved siden av står sitatet som viser hva som skjer når ingenting blir sjekket:
«you send your assignments and immediatly you got your results: 100% correct. I am still speechless. I put all that effort in and have no idea whether I my answer was correct or not» — Shinysheep, 21.09.2023, 1★ (Prompt Engineering, Vanderbilt).
Og i samme rekke: «quizzes give unhelpful feedback for incorrect answers and just say 'watch the video again'» — Cory Covino, 04.05.2024, 2★ (IBM). «All the coding is done in the labs for you. You won't have to debug anything or figure anything out, just press shift-enter» — Cornelius Griggs, 1★ (Generative AI with LLMs).
Griggs treffer skarpest av alle, uten å ville det. «You won't have to debug anything» beskriver et læringsprodukt der debuggingen er operert bort. Øvelsen kjører, det føles som praksis, og det sto aldri noe på spill.
Én til, fra et annet kurs, som lukker sirkelen: «Didnt meet expectations, only theory is discussed which we already know» — Aditya Nagavolu, 19.11.2023, 1★ (Generative AI for Everyone). Teorien alle allerede kan, er formelen. Det de ikke kan, er hva de skal gjøre når den svikter.
Hvorfor hullet finnes: det er arkitektur, ikke latskap
Det er fristende å skylde på late forelesere. Den forklaringen er dårligere enn sannheten. Sannheten er strukturell.
Det finnes nøyaktig én måte å sjekke en prompt på: kjøre den på en modell og se på svaret. Noen annen finnes ikke — en prompt kan ikke vurderes på utseendet, like lite som kode kan vurderes uten å kjøres. Og en videoplattform har ingen modell inne i leksjonen. Da er det ingenting å sjekke med. Igjen står en autoretter på nøkkelord, og den deler ut «100% correct» — nøyaktig det som gjorde Shinysheep målløs.
Så kommer detaljen som avgjør saken. Vanderbilts Prompt Engineering Specialization krever et betalt ChatGPT+-abonnement for å løse oppgavene. Kurset sender deltakeren ut, til en annen fane, på jakt etter en modell. Regnestykket for en Coursera-deltaker blir slik: Coursera Plus til 50 €/mnd. (eller 343 €/år med 14 dagers angrefrist), pluss et modellabonnement — rundt 70 €/mnd. for å se videoer og få automatiske 100%. Om den nøyaktige prisen på det modellabonnementet er vi ærlige: vi fikk den ikke fra en primærkilde, alle OpenAI-domener svarte 403, så vi trykker ikke noe tall. De 50 € for Coursera Plus står på deres egen side.
I det øyeblikket modellen bor utenfor kurset, slutter kurset å se arbeidet ditt. Det vet ikke hvilken prompt du skrev, hva som kom tilbake, eller hvorfor det kom dårlig tilbake. Debugging kan ikke læres bort i blinde. Så kurset lærer bort formelen — den eneste delen som får plass på en lysbilde.
Og derfra kommer en klage som ved første øyekast handler om noe annet:
«why read straight from the slide? I can do that. This was not a helpful course at all» — Janie I., 02.07.2026, 1★ (Justin Barnett).
«I can do that» er ingen dom over en dårlig foredragsholder. Det er konstateringen av at bare formelen får plass på en lysbilde. Debugging får ikke plass, for den består av et levende svar ingen kan forutsi på forhånd.
Debugging er diagnostikk, ikke omskriving
Nybegynnerens refleks ser slik ut: svaret er dårlig → merk hele prompten → skriv den om, lengre og penere. Iblant hjelper det. Hvorfor det hjalp, er umulig å vite, og neste gang starter du på nytt fra null.
Ingeniørtilnærmingen er en annen, og den har fire steg.
- Symptom. Si hva som er galt, med ord du kan sjekke. Ikke «dårlig», men: fant på et faktum; ignorerte formatet; for generelt; gjentok mitt eget innspill; svarte på et annet spørsmål; brøt sammen på en lang tekst. Så lenge symptomet ikke har et navn, er det ingenting å behandle.
- Diagnose. Hvert symptom har en typisk årsak. Det er en hypotese, ikke en dom — men den sier hvor du graver først.
- Én endring. Endre nøyaktig én ting. Én.
- Sammenligning. Kjør på nytt, og sammenlign med forrige svar etter ditt eget kriterium. Ikke «jeg liker det bedre», men «ble nettopp det jeg behandlet, bedre?».
Gjenta til symptomet er borte. Vanligvis er det to-tre runder, ikke tjue.
Regelen om én skrutrekker
Det mest undervurderte steget er det tredje. Endre én ting om gangen.
Du retter fem ting, svaret blir bedre — og du vet ikke hva som hjalp. Verre: kanskje fire endringer var nøytrale, én var direkte skadelig, og den femte veide den opp. Du drar med deg hele pakka inn i neste prompt, den skadelige linja inkludert, og en måned senere eier du en to sider lang vegg av tekst der halvparten av linjene jobber mot deg.
Dette er ikke vår oppfinnelse. Det er grunnregelen i all debugging — den samme som å endre én variabel om gangen i et eksperiment. Det er bare det at med tekst er fristelsen til å vri på alle knottene samtidig langt sterkere, fordi en endring koster ett sekund.
Et forbehold mot oss selv. Regelen har en pris. Én endring per runde er tregt, og på en ekte oppgave kommer du til å ta snarveier. Det ærlige kompromisset: regelen om én skrutrekker gjelder så lenge du fortsatt leter etter sykdommen. Så snart diagnosen er klar og du bare finpusser — endre i bunter, risikoen er liten nå.
Andre ærlighet: modeller er ikke deterministiske. Én kjøring er et utvalg på én. Ble svaret bedre etter endringen din? Kanskje endringen ikke hadde noe med det å gjøre, og du bare var heldig. Derfor fortjener en sammenligning minst tre ulike innspill, ikke ett favorittinnspill.
Rekkefølgen på hypotesene: kontekst → oppgave → format → rolle
Når symptomet har fått et navn, står spørsmålet om hvilken knott du skal ta i. Vi har en rekkefølge, og den er ikke tilfeldig: vanligste årsak først, sjeldneste sist; dyreste bom først, billigste sist.
- Kontekst først. De aller fleste dårlige svar er svar på et spørsmål uten fakta i. Modellen kjenner ikke produktet ditt, publikumet ditt, begrensningene dine, tallene dine, navnene dine, de tidligere beslutningene dine. Den fyller tomrommet med gjennomsnittsvatt — for gjennomsnittsvatt er det riktige svaret på et spørsmål uten kontekst. Er resultatet utvannet, generelt, brukbart for hvem som helst, er konteksten nesten alltid synderen, og ingen rolleleking kurerer det.
- Oppgave som nummer to. Sjekk at du ber om én handling og ikke tre, og at verbet kan sjekkes. «Analyser» er ikke et verb; under det får hva som helst plass. «List opp fem risikoer, én linje hver» er et verb. Svarer modellen på et annet spørsmål, eller på halve ditt, er det oppgaven som er skyld i det.
- Format som nummer tre. Billig å fikse, og resultatet vises umiddelbart. Er innholdet riktig og formen feil, så rett formatet og la resten være. Det som virker: lim inn en prøve på det utdataet du vil ha, to-tre linjer. En prøve slår en beskrivelse hver gang.
- Rolle sist. Rollen flytter først og fremst tone og ordvalg. «Du er en erfaren markedsfører» legger til null fakta om markedet ditt — det er den ene linja alle skriver først, og den avgjør nesten ingenting. Ta tak i rollen når alt annet sitter, og du rett og slett ikke liker stemmen.
Hvorfor akkurat den rekkefølgen? Fordi den følger hvor mye informasjon du legger til. Kontekst legger til fakta — maksimum. Oppgaven legger til presisjon i målet. Formatet legger til form. Rollen legger til stil. De fleste gjør det motsatt: bruker lang tid på rollen og blir så fornærmet over vattet.
Tabellen: symptom → diagnose → én endring
- Utvannet, generelt, passer for hvem som helst. Diagnose: ingen kontekst. Endring: lim inn fem konkrete fakta — hvem som leser, hva produktet er, hva begrensningen er, ett tall, ett eksempel. La resten være.
- Fant på et faktum, en lenke, et sitat. Diagnose: du ba om noe modellen ikke har. Endring: enten legger du dataene inn i prompten, eller så tillater du uttrykkelig et «jeg vet ikke». Linja «har du ikke dataene, så si det — ikke dikt» koster småpenger og fanger mye. Mer om det i hvorfor KI-hallusinasjoner oppstår.
- Ignorerte formatet. Diagnose: formatkravet druknet på midten, eller det kolliderer med lengden du ba om. Endring: dra formatet ut i sin egen blokk til slutt, og vis en utdataprøve.
- Svarte på et annet spørsmål. Diagnose: to handlinger i én oppgave, og modellen valgte den ene. Endring: la ett verb stå. Den andre handlingen blir en annen prompt.
- Gjentok mitt eget innspill. Diagnose: ingen verb for bearbeiding. «Her er teksten, ta en titt» er ikke en oppgave. Endring: si hva som skal gjøres med teksten — kortes ned, bygges om, finne motsigelser.
- Feil tone, «dette er ikke stemmen min». Diagnose: du beskrev en stil i stedet for å vise den. Endring: lim inn et eget avsnitt, og be om å treffe det. «Skriv vennlig, men profesjonelt» gjør ingenting; en prøve gjør.
- Brøt sammen på en lang tekst. Diagnose: instruksjonen forsvant inni dataene. Endring: skill med markører (---TEKST--- / ---OPPGAVE---), og gjenta oppgaven etter teksten, ikke bare før.
- For langt, endeløs innledning. Diagnose: du forbød det aldri. Endring: én linje — «Ingen innledning, ingen oppsummering til slutt. Bare lista».
Legg merke til: i seks av åtte tilfeller er fiksen ikke «skriv om prompten», men legg til eller flytt én ting.
Sjekk selv: en dårlig prompt, én endring, forskjellen
Nå kommer delen en videoplattform fysisk ikke kan tilby. Hver blokk nedenfor har en «Kjør»-knapp: trykk her og se et levende svar komme. Rekkefølgen betyr noe — kjør dem på rad, og sammenlign.
Steg 1. Kjør en bevisst dårlig prompt
Dette er en ekte prompt, skrevet «etter formelen»: det er en rolle, det er en oppgave, det er høflighet. Kjør den, og se hva som kommer tilbake. Sannsynligvis får du en tekst som ville passet enhver bedrift i verden.
Du er en erfaren markedsfører. Skriv en e-post til kundene våre om lanseringen av det nye produktet vårt. Sørg for at teksten er profesjonell, moderne og fengende.
Hva du ser etter. Finnes det én eneste påstand i svaret du ikke kunne flyttet uendret over i e-posten til en annen bedrift? Som regel ikke. Symptom navngitt: vatt. Diagnose etter rekkefølgen vår: kontekst.
Steg 2. Én endring — bare kontekst
Samme oppgave, samme tone, samme rolle. Vi endrer nøyaktig én ting: vi legger til fakta. Rollen rører vi ikke, formatet rører vi ikke — så vi ærlig kan se hva kontekst gir helt alene.
Du er en erfaren markedsfører. Skriv en e-post til kundene våre om lanseringen av det nye produktet vårt. Sørg for at teksten er profesjonell, moderne og fengende. KONTEKST: - Produkt: en vaktplanlegger for kafeer med 3-15 ansatte. - Lesere: kafeeiere som har brukt lagerappen vår i et halvt år. De stoler på oss, men de lette ikke etter en ny knapp. - Det nye: vaktplanene settes nå opp automatisk, med de ansattes ønsker om fri tatt med i beregningen. Før satte eieren opp planen i et regneark. - Ærlig begrensning: bare ett utsalgssted, kjeder støtter vi ikke ennå. - Pris: inkludert i dagens plan, ingen tilleggskostnad. - Hva leseren skal gjøre: slå på seksjonen «Vaktplaner» på kontoen sin.
Hva du ser etter. Svaret er blitt konkret — og er sannsynligvis fortsatt langt og åpner fortsatt med en innledning. Det er greit: vi behandlet bare konteksten. Legg merke til at «profesjonell, moderne og fengende» overlevde urørt som et krav som ikke kan sjekkes, og ikke utrettet noe.
Steg 3. Enda en endring — oppgave og format
Nå fikser vi lengde og form. Rollen fjerner vi helt, for å teste hypotesen om at den ikke bidrar med noe. Og «fengende» bytter vi ut med noe som kan sjekkes.
Skriv en e-post til kundene som kunngjør en ny funksjon. KONTEKST: - Produkt: en vaktplanlegger for kafeer med 3-15 ansatte. - Lesere: kafeeiere som har brukt lagerappen vår i et halvt år. De stoler på oss, men de lette ikke etter en ny knapp. - Det nye: vaktplanene settes opp automatisk, med de ansattes ønsker om fri tatt med i beregningen. Før satte eieren opp planen i et regneark. - Ærlig begrensning: bare ett utsalgssted, kjeder støtter vi ikke ennå. - Pris: inkludert i dagens plan, ingen tilleggskostnad. - Leserens handling: slå på seksjonen «Vaktplaner» på kontoen. FORMAT: - Emnefelt: maks 45 tegn. Forbudte ord: revolusjonerende, unik, innovativ. - Brødtekst: maks 120 ord. - Struktur: første linje - hva som er endret; andre - hva det sparer; deretter begrensningen sagt rett ut; én handling til slutt. - Ingen innledning, ingen «vi er glade for å kunne fortelle», ingen avskjedsavsnitt. Deretter, på en egen linje: tre grunner til at denne e-posten kan bli uåpnet eller slettet.
Hva du ser etter. Sammenlign de tre svarene. Du har akkurat kjørt en ordentlig debugging-økt: symptom navngitt, hypotese satt opp, én endring gjort, resultater sammenlignet. Og på kjøpet har du gjort et lite eksperiment med rollen — sammenlign stemmen i svar to og tre, og bestem selv om «du er en erfaren markedsfører» fortjente plassen alle kurs gir den.
Steg 4. Diagnosetreneren
Den vanskeligste ferdigheten er å navngi et symptom i andres arbeid. Her finner modellen på en case til deg og vurderer diagnosen din strengt. Det blir ingen automatisk «100% correct».
Eksaminer meg i diagnostikk av prompter. Regler: - Du gir meg ÉN case: oppgaven, hele prompten og det dårlige svaret fra modellen. Finn på casen selv: realistisk, fra kontorarbeid. Det dårlige svaret skriver du også selv - nøyaktig så dårlig som det ville vært i virkeligheten. - Jeg navngir symptomet med ett begrep og sier hva jeg ville endret FØRST. - Du vurderer strengt: er symptomet riktig, er hypotesen riktig, hvilken hypotese ville vært sterkere enn min, og hvorfor. Foreslår jeg å endre flere ting samtidig, så påpek det for seg. - Ikke vær enig av høflighet. Tar jeg feil, så si det rett ut. - Deretter neste case, vanskeligere. Fem caser til sammen. Begynn med den første casen. Ikke forklar teori på forhånd.
Hva en prompt ikke kan fikse
Halve debuggingen er å skjønne i tide at prompten ikke er problemet. Ellers står du og pusser formuleringer i et lag der ingenting er ødelagt.
- Manglende data. Ingen formulering henter fram et faktum modellen aldri fikk. Trenger du tallene fra regnearket ditt, så lim dem inn; ikke tigg om dem.
- Oppgaven kan ikke løses med tekst. «Regn nøyaktig», «sjekk på den oppdaterte nettsiden», «garanter» — det handler ikke om formulering, det handler om verktøy. Her går du inn på territoriet til KI-agenter.
- Ingen definisjon av «bra». Klarer du ikke selv å si hvorfor svar A slår svar B, så debugger du ikke: da stokker du varianter til du blir sliten. Kriteriet er den delen av prompten som bor i hodet ditt, og den må også skrives ned.
- Feil modell. Den samme oppgaven oppfører seg ulikt — se vår sammenligning av ChatGPT, Claude og Gemini. Før du retter en prompt tjue ganger, prøv den samme prompten på en annen modell: det er én endring, ikke tjue.
En versjonslogg: kjedelig og avgjørende
Opprett en fil. Tre kolonner: hva som sto i prompten, hva du endret, hva som skjedde med svaret. Én linje per debugging-runde.
Det høres ut som byråkrati. Det er det eneste som gjør kjøringene dine om til kunnskap. En måned senere åpner du den fila og ser: «utdataprøve i stedet for formatbeskrivelse» virket elleve av tolv ganger, mens «du er en ekspert i verdensklasse» ga null. Det er din egen statistikk, og den er verdt mer enn enhver liste med 500 ferdige prompter. Ta prompteksemplene våre som råstoff; loggen er det som gjør råstoff til ditt verktøy.
Bivirkning: etter en måned har du en portefølje. Ikke et sertifikat som 698 444 andre også har, men et titalls gjennomgåtte tilfeller med før og etter. På et jobbintervju er det to ulike vektklasser.
Slik tester du et kurs — også vårt
Målingene våre gir en test på fire spørsmål. Still dem til enhver opplæring.
- Hvor kjører jeg prompten? Er svaret «i en annen fane, for et eget abonnement», ser kurset aldri arbeidet ditt og kan ikke gå gjennom det. Se Vanderbilt og kravet om ChatGPT+.
- Hvem vurderer prompten min? En autoretter på nøkkelord rekker deg «100% correct» og null informasjon. Det er nøyaktig Shinysheep-tilfellet.
- Finnes det en leksjon der en prompt feiler? Åpne programmet, og let etter den. Finnes den ikke, handler kurset om en formel.
- Når ble innholdet faktisk oppdatert? Ikke etter datoen på kortet, men etter anmeldelsene fra den siste måneden.
Ærlig om dataene våre. Andelen negative anmeldelser (≤3.5★) på Udemy er 9,61% for Generative AI for Beginners og 10,36% for Complete AI Guide; for Prompt and Context Engineering 101 (den dårligste karakteren i utvalget vårt, 4.31) er den ≥4,00%. På Coursera er den 1,5–3,5%. Altså: de aller fleste deltakerne er fornøyde, og vi leste mindretallet med vilje. Ikke for å bevise at kursene er dårlige: en fornøyd deltaker skriver «flott kurs», mens en misfornøyd nevner nøyaktig den leksjonen som manglet. Andre forbehold: stjernefilteret til Coursera kjører i nettleseren, så sitatene vi kom fram til, stammer fra standardsiden enhver besøkende ser. Vi fisket dem ikke opp fra bunnen av et 1★-filter — men vi kan heller ikke påstå at vi så alle anmeldelsene.
Og et forbehold om oss selv. Sandkassen vår har en hard daglig grense for kjøringer. Det betyr at metoden ovenfor er verdt mer enn knappen. Knappen lar deg se forskjellen; metoden lar deg fikse prompter der det ikke finnes noen knapp — i din egen jobbchat.
Konklusjonen
Promptformelen er det som får plass på en lysbilde, og derfor selges den til millioner. Debugging får ikke plass på en lysbilde, kan ikke sjekkes uten en levende modell inne i leksjonen, og derfor selges den nesten ingen steder — mens deltakerne ber om den ordrett, anmeldelse etter anmeldelse. Hullet i markedet sitter akkurat der, og det er samtidig den raskeste veien til å bli bedre enn de fleste med et sertifikat.
Husk de fire stegene: symptom → diagnose → én endring → sammenligning. Og rekkefølgen på hypotesene: kontekst, oppgave, format, rolle. Start med grunnlaget i hva en prompt er; se hva markedet for dette «yrket» har blitt til i prompt engineer: hva det betaler, og om yrket fortsatt finnes; lær å ta modellen i å dikte i KI-hallusinasjoner. Og vil du ha det systematisk, med feilene gjennomgått med vilje, finnes kurset vårt i prompt engineering.
FAQ
Prompten ga søppel tilbake — hva endrer jeg først?
Konteksten. Rekkefølgen på hypotesene er: kontekst → oppgave → format → rolle. De fleste dårlige svar er svar på et spørsmål uten fakta i: modellen kjenner ikke produktet ditt, publikumet ditt, begrensningene eller tallene dine, så den fyller tomrommet med gjennomsnittsvatt. Lim inn fem konkrete fakta først, og kjør på nytt. Først når vattet er borte og resultatet fortsatt ikke stemmer, går du videre til oppgaven (ett verb? kan det sjekkes?), deretter til formatet (vis en utdataprøve), og aller sist til rollen — den flytter stort sett tonen.
Hvorfor ikke fikse flere ting på én gang — går ikke det raskere?
Raskere nå, dyrt senere. Du endrer fem ting, det blir bedre, og du vet ikke hvilken som gjorde det. Verre: én endring kan ha vært skadelig, og en annen veide den opp — da drar du den skadelige med deg inn i hver eneste framtidige prompt. En måned senere har du en vegg av tekst der halvparten av linjene jobber mot deg. Det ærlige kompromisset: regelen om én skrutrekker gjelder mens du jakter på årsaken; når diagnosen er klar og du bare finpusser, endre i bunter.
Hvorfor kan ikke et kurs sjekke prompten min?
Fordi det finnes nøyaktig én måte å sjekke en prompt på: kjøre den på en modell og se på svaret. En videoplattform har ingen modell inne i leksjonen, så oppgaven vurderes av en autoretter på nøkkelord. Derav denne anmeldelsen: «you send your assignments and immediatly you got your results: 100% correct… I put all that effort in and have no idea whether I my answer was correct or not» (Shinysheep, 21.09.2023, 1★, Prompt Engineering, Vanderbilt). Spesialiseringen fra Vanderbilt krever til og med et eget betalt ChatGPT+-abonnement for å løse oppgavene: modellen bor utenfor kurset. Det er ikke latskap, det er arkitektur.
Hvordan vet jeg at den nye prompten er bedre og ikke bare annerledes?
Gi egenskapen du behandler et navn før du kjører, og sammenlign bare på den. «Jeg liker det bedre» er ikke et kriterium. Var symptomet vatt, lyder kriteriet: hvor mange påstander i svaret kunne du ikke flyttet uendret over i prosjektet til en annen. Dem teller du på ti sekunder. Og test på minst tre ulike innspill: modeller er ikke deterministiske, så én god kjøring er et utvalg på én, ikke et bevis.
Hva om prompten rett og slett ikke lar seg fikse?
Sjekk om det i det hele tatt er prompten som er problemet. Fire tilfeller der formuleringen ikke betyr noe: manglende data (ingen setning henter fram et faktum modellen aldri fikk); oppgaven kan ikke løses med tekst (nøyaktig utregning, oppdaterte nettsider, garantier — det er verktøyproblemer); ingen definisjon av «bra» (da debugger du ikke, da stokker du varianter); feil modell. Det siste er billigst å teste: kjør den samme prompten på en annen modell. Det er én endring i stedet for tjue.
Er rollelinja i en prompt verdt noe i det hele tatt?
Noe, bare ikke først. Rollen flytter tone og ordvalg og rører nesten ikke innholdet: «du er en erfaren markedsfører» legger til null fakta om markedet ditt. Derfor står den sist i rekkefølgen vår på hypoteser, selv om alle kurs setter den på linje én. Test det selv med steg 2 og 3 ovenfor: først er rollen der, så er den borte, og alt annet står uendret. Sammenlign stemmen, og avgjør om den fortjente plassen sin.