Prompt Engineering i 2026: 10 teknikker, der stadig virker (og 4, der døde med reasoning-modeller)

Prompt Engineering i 2026: 10 teknikker, der stadig virker (og 4, der døde med reasoning-modeller)

Prompt engineering døde ikke i 2026. Det delte sig i to. OpenAIs egne dokumenter om reasoning fortæller dig nu, at du skal holde op med at skrive "tænk trin for trin", og et arXiv-paper fra 2024 (2410.21333) målte en nøjagtighedsnedgang på op til 36,3 %, når chain-of-thought blev tvunget ind på den forkerte opgave. Det er den underlige del. Den afslappede halvdel af prompt engineering blev lettere, mens produktionsdelen – den del, der deployes på GPT-5 og Claude – blev langt mere stringent. Denne guide sorterer de 10 teknikker, der stadig er din tid værd, fra de 4 vaner, som reasoning-modeller har udfaset.

Vigtigste pointer:

• Prompt engineering delte sig i 2026 i afslappet prompting (lettere) og produktions-prompting (mere stringent).
• På reasoning-modeller er det overflødigt at tvinge "tænk trin for trin", og det kan reducere nøjagtigheden. OpenAI siger, undgå det.
• Fire vaner er udfaset: CoT-tvang, refleksiv tung few-shot, response prefilling og manuel budget_tokens-justering.
• Det, der stadig vinder: klarhed, strukturerede outputs, opgavedekomposition og eval-drevet iteration.

Hvad Prompt Engineering faktisk er i 2026

Prompt engineering er praksissen med at designe og forfine de instruktioner, du giver en stor sprogmodel for at få præcise, relevante outputs. Kernteknikker inkluderer zero-shot, few-shot, chain-of-thought og rolle-prompting. I 2026 deler det sig i to job: afslappet prompting i en chat og produktions-prompting inde i et system.

Her er det, ingen sagde højt før i år: det er to forskellige færdigheder. At få et godt svar i ChatGPT er næsten trivielt nu, fordi modellerne tilgiver sjusket formulering. At få et pålideligt svar fra et system, der kører tusindvis af gange om dagen, på ti sprog, uden menneskelig overvågning, er det ikke. Det andet job er, hvad denne guide handler om.

Vi skriver til produktionssegmentet: udviklere og AI-ingeniører, der har brug for instruktioner, der holder stand på GPT-5, Claude Opus 4.8 og Gemini. Introen, denne definition og FAQ'en forbliver læsbare for alle andre. Hvis du vil have den neutrale taksonomi over enhver navngivet teknik, er dair-ai promptingguide.ai-referencen stadig den bedste encyklopædi på nettet. I 2026 er prompt engineering ikke én færdighed. Det er to.

Prompt Engineering vs. Context Engineering: Hvad er forskellen?

Prompt engineering handler om at udforme instruktionen. Context engineering handler om at designe alt, der går ind i kontekstvinduet omkring den: hentning (retrieval), hukommelse, værktøjer, rækkefølge. Prompt engineering er en delmængde af context engineering. Denne guide dækker halvdelen med prompt-udformning; den linkede guide dækker resten.

Så hvilken har du brug for? Hvis din kontekst er statisk og passer i én besked, er prompt engineering rigeligt. I det øjeblik dit input ændres pr. anmodning, har du trådt ind i context engineering, og prompt engineering bliver ét værktøj inden for det. Vi tegnede det fulde billede i vores komplette guide til context engineering; dette indlæg holder sig på prompt-udformningssiden af linjen.

En bemærkning til entitets-samlerne: Google Autocomplete strækker dette nu til en firevejsopdeling af ingeniørdiscipliner, og vi ejer de første to: prompt og context. Kort sagt: prompt engineering er at vælge de rigtige ord til spørgsmålet; context engineering er at beslutte, hvad der ligger på skrivebordet, før spørgsmålet stilles.

De 10 centrale prompt-udformningsteknikker (rangeret efter ROI i 2026)

De ti teknikker, det er værd at kende i 2026, groft sorteret efter afkast i forhold til indsats: zero-shot, few-shot, rolle-prompting, chain-of-thought, opgavedekomposition, prompt-chaining, self-consistency, strukturerede outputs, prompt-skabeloner og meta-prompting. Nogle er daglige drivere; to opfører sig anderledes på reasoning-modeller, hvilket næste afsnit reder ud.

Navnene nedenfor følger taksonomien i "The Prompt Report", en systematisk undersøgelse af mere end 50 prompting-teknikker. Betragt dette som et værktøjssæt, du trækker fra, ikke en tjekliste, du kører fra top til bund.

1. Zero-shot prompting

Zero-shot betyder, at du giver en klar instruktion og ingen eksempler, og lader modellen finde ud af det. På 2026-modeller er dette dit standard første træk, fordi en præcis, specifik instruktion normalt slår en rodet en. Tricket er ikke magisk formulering, det er at fjerne tvetydighed: sig, hvilket output du vil have, i hvilket format, og til hvem.

# Target: GPT-5 / Claude Opus 4.8
Classify this support ticket as: billing, technical, or account.
Return only the single lowercase label.

Ticket: "My card was charged twice this month."

2. Few-shot prompting

Few-shot betyder, at du inkluderer to til fem eksempler for at forme det format eller den adfærd, du ønsker. Det er den hurtigste måde at låse en output-stil fast, som modellen ellers driver væk fra. En forbehold: på reasoning-modeller siger OpenAIs bedste praksis for reasoning, at du skal prøve zero-shot først og kun tilføje eksempler, hvis de målbart hjælper. På 2026-modeller er zero-shot standarden, og few-shot er fallback'en, ikke omvendt.

# Target: GPT-5
Extract the product and sentiment. Follow the examples.

Input: "The battery dies in an hour." -> product: battery, sentiment: negative
Input: "Setup took two minutes, loved it." -> product: setup, sentiment: positive
Input: "The screen is gorgeous but it's heavy." ->

3. Rolle / persona prompting

Rolle-prompting fastsætter, hvem modellen er, før den svarer, hvilket former tone, ordforråd og format mere, end det former rå ræsonnement. "Du er en senior skatterevisor, der gennemgår en selvangivelse" trækker andet sprog frem end en tom prompt. Hold det funktionelt, ikke teatralsk. Rollen bør kodificere reelle begrænsninger: målgruppe, format, hvad der skal udelades. Vores kommende samling af eksempler på system-prompts vil samle de mønstre, vi genbruger mest.

# Target: Claude Opus 4.8
You are a senior tax accountant. Review the figures below for a
small-business owner who is not an accountant.
Format: 3 bullet points, plain English, flag any number that looks wrong.

4. Chain-of-thought (CoT)

Chain-of-thought beder modellen om at vise sine ræsonnementstrin før det endelige svar. På almindelige GPT-lignende modeller er det stadig et af de mest værdifulde tricks til matematik, logik og flerstegs-problemer. Men på reasoning-modeller kan det være overflødigt eller endda skadeligt, hvilket næste afsnit dækker med reelle tal. Vores kommende deep-dive i chain-of-thought prompting gennemgår hele teknikken. Husk foreløbigt, at det ikke længere er en refleks, du anvender på alt.

5. Opgavedekomposition

Dekomposition betyder at bryde én stor anmodning ned i ordnede underopgaver, som modellen håndterer én ad gangen. I stedet for "skriv en lanceringsplan" beder du om målgruppen, derefter kanalerne, derefter kalenderen. Mindre trin betyder færre steder, det kan gå galt, og lettere debugging, når noget alligevel gør.

# Target: any 2026 model
Task: draft a product launch email.
Work in order and label each step:
1) Identify the audience and their main objection.
2) Write one subject line that answers that objection.
3) Write a 90-word body.
4) End with a single CTA.

6. Prompt chaining

Chaining fører outputtet fra én prompt ind som input i den næste. Det er dekomposition gjort virkelig i kode: prompt A udtrækker nøglefakta, prompt B udkaster fra disse fakta, prompt C tjekker udkastet mod en regel. Hvert led er simpelt, testbart og udskifteligt. Når ét trin regresserer, retter du det led i stedet for at filtre en gigantisk monolit-prompt ud.

7. Self-consistency

Self-consistency sampler det samme spørgsmål flere gange og tager derefter flertalsvaret. Det bytter tokens mod pålidelighed ved svær ræsonnering, hvor et enkelt gennemløb er ustabil, men du betaler for tre til fem completions for at få ét. På stærke reasoning-modeller indsnævres gevinsten ofte, så reserver det til genuinely tvetydige opgaver, hvor det er vigtigere at have ret end regningen.

8. Output-formatering / strukturerede outputs

Strukturerede outputs betyder at begrænse svaret til et skema i stedet for at håbe, at modellen returnerer ren JSON. Denne fortjener sit eget afsnit nedenfor. One-line-versionen: tig ikke om JSON i prompten, begræns modellen til et skema og hold op med at gætte.

9. Prompt-skabeloner og variabler

Skabeloner omdanner en god engangsprompt til et parameteriseret, genanvendeligt aktiv: faste instruktioner plus pladser til de variable dele. Det er sådan, prompts holder op med at være ad-hoc tekst og begynder at blive versionerede artefakter, du kan teste, hvilket er pipeline-historien længere nede. Genanvendelige projekt-regelfiler, som de cursor rules, udviklere holder i deres repos, er levende prompt-skabeloner under et andet navn.

10. Meta-prompting

Meta-prompting er at bruge en model til at skrive eller forbedre din prompt. Det er blevet den hurtigste vej fra en tom boks til et solidt udkast, og det har reelle data bag sig, dækket lige nedenfor. Kort version: start fra et model-forbedret udkast, og rediger derefter i hånden.

Hvilke prompt-teknikker har reasoning-modeller gjort valgfrie (eller ødelagt)?

Fire vaner, der plejede at være gode råd, slår nu bagud på reasoning-modeller som OpenAIs o-serie, GPT-5 og Claudes thinking-modes: at tvinge eksplicit chain-of-thought, at stable tung few-shot som standard, response prefilling og manuel justering af budget_tokens. Reasoning-modeller tænker allerede internt, så at scripte trinnene er overflødigt og nogle gange værre end overflødigt.

Hver enkelt døde af en anden grund.

Tvang af chain-of-thought. OpenAIs bedste praksis for reasoning er bramfri: "Undgå chain-of-thought-prompts", fordi disse modeller ræsonnerer internt, så at fortælle dem at "tænke trin for trin" er "unødvendigt" og "måske ikke forbedrer ydeevnen (og kan nogle gange hæmme den)". ArXiv-papiret 2410.21333 satte et tal på ulempen: op til 36,3 % lavere absolut nøjagtighed for o1-preview versus GPT-4o på en opgave, hvor bevidst trin-for-trin-tænkning faktisk skader. En anden undersøgelse, 2412.21187, viser, at reasoning-modeller overforbruger compute på trivielle problemer. Vi stoppede med at tilføje "tænk trin for trin" til reasoning-model-prompts for måneder siden, og intet blev værre.

Refleksiv tung few-shot. OpenAIs vejledning er "hold prompts simple og direkte" og "prøv zero shot først, derefter few shot hvis nødvendigt". At smide eksempler ind som standard koster nu tokens og kan indsnævre en capable model. Tilføj eksempler, når de målbart hjælper, ikke som en opvarmningsritual.

Response prefilling. At putte ord i mundens på modellen for at tvinge et format plejede at være et standardtrick. På Claude 4.6+, Fable 5 og Mythos 5 understøttes prefilled assistant-turns ikke længere og returnerer en 400-fejl, jf. Anthropics bedste praksis for prompting. Brug strukturerede outputs i stedet, hvilket næste afsnit dækker.

Manuel mikrostyring af budget_tokens. Manuel indstilling af et thinking-token-budget er også udfaset (en 400-fejl på Opus 4.7+ og nyere). Anthropics modeller bruger nu adaptiv thinking, og du styrer indsatsen med parameteren effort i stedet for at scripte et tal. OpenAI gjorde det samme træk: developer messages er de nye system messages, og reasoning effort er en indstilling. Det klassiske trick, "lad os tænke trin for trin", er nu, på reasoning-modeller, nogle gange den ting, der gør dem værre.

Hvordan får du pålidelig JSON fra en LLM i 2026?

Skema-begrænsede strukturerede outputs, ikke prompt-tiggeri. I 2026 er den pålidelige vej at give modellen et JSON-skema og lade API'en garantere gyldigt output imod det. At skrive "returnér venligst JSON" i prompten er skrøbeligt; den udfasede prefill-hack er væk. Både OpenAI og Anthropic leverer en funktion til strukturerede outputs netop til dette formål.

Hvorfor er "returnér venligst gyldig JSON" så skrøbeligt? Fordi du beder et probabilistisk system om at være perfekt syntaktisk på æresord. Én vildfaren kommentar eller efterfølgende komma, og din parser kaster en fejl. Structured Outputs løser dette på API-niveau: du sender et skema, og modellen er begrænset til at matche det. Anthropic bemærker, at nyere modeller "kan matche komplekse skemaer pålideligt, når de bliver bedt om det."

Her er et lille, realistisk respons-skema til en support-ticket-klassificerer:

{
  "name": "ticket_classification",
  "schema": {
    "type": "object",
    "properties": {
      "category": { "type": "string", "enum": ["billing", "technical", "account"] },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "summary": { "type": "string", "maxLength": 120 }
    },
    "required": ["category", "priority", "summary"],
    "additionalProperties": false
  }
}

Send det til OpenAIs eller Anthropics strukturerede outputs, og du får parsebar JSON tilbage hver gang, uden retry-loop. For det fulde cross-provider-mønster, inklusive Pydantic- og Zod-validering, se vores guide til at få pålidelig JSON fra enhver LLM. I 2026 beder du ikke en model om JSON. Du begrænser den til et skema og holder op med at håbe.

Meta-prompting: Lad modellen skrive din prompt

Meta-prompting betyder at bruge en LLM til at udkaste eller forfine den prompt, du faktisk vil køre. Det er den hurtigste vej fra en grov idé til en fungerende prompt, og værktøjet er indbygget: Anthropics prompt improver og OpenAIs prompt optimizer omskriver begge dit udkast efter bedste praksis. Start fra maskinens version, og rediger derefter i hånden.

Hjælper det faktisk, eller er det et party-trick? Anthropic kørte sine egne tal: deres prompt improver leverede en 30 % nøjagtighedsgevinst på en multilabel-klassifikationstest og 100 % overholdelse af ordantal på en opsummeringsopgave, ifølge deres write-up. OpenAIs prompt optimizer gør det samme job.

Det workflow, vi kan lide: beskriv opgaven, lad værktøjet producere et struktureret første udkast, og stram det derefter op i hånden til dine data. Den sidste håndredigering er grunden til, at prompts stadig har brug for et menneske og en test. Den hurtigste vej til en bedre prompt i 2026 er at lade modellen omskrive din, og derefter redigere. Ikke at stirre på en tom boks.

Modelspecifik prompting-cheat sheet (OpenAI vs. Anthropic vs. Google)

Samme job, tre dialekter. OpenAI vil have developer messages og ingen tvungen chain-of-thought. Anthropic vil have XML-tags, adaptiv thinking og parameteren effort. Googles Gemini vil have et thinking-budget. Reasoning-modeller er dine planlæggere; klassiske GPT-lignende modeller er dine arbejdsheste. Match teknikken til niveauet.

Forskellene er små, men de bider. På OpenAI erstattede developer messages den gamle system message for o-serien og op, og dokumenterne styrer dig væk fra eksplicit CoT. På Anthropic er XML-tags stadig den anbefalede måde at strukturere en kompleks prompt på, og thinking er adaptiv som standard. Prompt-filer på projektniveau, som de CLAUDE.md-filer, kodeteams holder i deres repos, indeholder meget af denne providerspecifikke wiring. På Gemini giver du modellen et thinking-budget.

Fra prompt til pipeline: Skabeloner, versionering og evaluering

I produktion holder prompt engineering op med at handle om formulering og bliver en empirisk disciplin. Du versionerer prompts som kode, gate'er dem med evals og tilføjer regressionstests, så en ændring, der stille ødelægger outputtet, bliver fanget, før brugerne ser det. Det er her, prompt engineering møder evaluering, og det er den del, der faktisk afgør, om din app fungerer.

Sådan ser det ud på et rigtigt system. Denne blog kører på en Claude-drevet content-pipeline med 17 specialiserede under-agenter, hvor hver enkelt er en separat-promptet rolle: en researcher, en brief-skaber, en content-writer, en validator, en sprogoversætter, en sanity-publisher, en image-handler og mere. På tværs af tre af disse stadier (brief, writer og validator) håndhæver vi 8 anti-detektion guardrail-regler. Validatoren grep'er hvert udkast mod en blocklist med 52 forbudte fraser, og et enkelt hit blokerer publicering, bakket op af et separat leksikalt check-script. Den pipeline har shipped omkring 194 engelske indlæg på tværs af 4 sites, hver oversat til op til 10 sprog af parallelle per-sprog agenter.

Intet af det kom fra clever formulering. Det kom fra at behandle prompts som versionerede, eval-styrede artefakter, og to hændelser lærte os hvorfor.

Den første var en diakritik-bug. Vores oversættelses-prompt returnerede间歇vis ASCII i stedet for Unicode, så det tyrkiske ord "karşılaştırma" kom tilbage som "karsilastirma". Stille, grimt og let at overse i stor skala. Fixet var ikke en bedre sætning, det var en hærdet instruktion plus en grep-gate, der tæller native tegn og kører oversættelsen automatisk igen, hvis tællingen rammer nul. En regressionstest, på en prompt.

Den anden var værre. En re-translations-prompt begyndte at minte lidt forskellige lokaliserede slugs, så publisheren oprettede et helt nyt dokument, mens det gamle forblev live. Det producerede 54 duplikerede live-dokumenter, hvilket udløste Google Search Consoles eksklusioner af duplikater. Fixet var en prompt-guardrail, der tvinger genbrug af den eksisterende slug, plus en resolve-before-create-regel i publisheren.

Lektionen landede hårdt: prompten, der shippede 194 indlæg på ti sprog, vandt ikke på formulering. Den vandt, fordi en grep-gate kørte den igen, i det øjeblik den drifted. Det er LLM-evaluering i arbejde, og det er derfor, vi parrer hver vigtig prompt med prompt management-værktøjer for at versionere og rulle dem tilbage. For et stabilt præfiks, der gentages på tværs af tusindvis af kald, cacher vi det for at skære omkostninger. Det er præcis den slags prompt-og-eval-pipeline, vi bygger for kunder.

Almindelige fejl inden for prompt engineering (og 2026-fixene)

De dyre fejl i 2026 er ikke tastefejl. De er strukturelle: vage instruktioner, over-scripting af reasoning-modeller, shipping uden eval-loop, ignorering af modelspecifik adfærd, propping af prompten, når det egentlige problem er kontekst, og tillid til utroværdigt input. Hver har et rent fix, og de fleste koster intet andet end opmærksomhed.

Gå listen igennem og vær ærlig omkring, hvilke du er skyldig i:

• Vage instruktioner. "Gør det bedre" giver modellen intet at sigte efter. Sig, hvad "bedre" betyder: kortere, venligere, gyldig JSON, under 120 ord.
• Over-scripting af reasoning-modeller. At tvinge "tænk trin for trin" på en o-serie eller thinking-model er fejlen dækt ovenfor. Lad den ræsonnere; hæv effort i stedet.
• Ingen eval-loop. Hvis du ikke kan fortælle, om en prompt-ændring hjalp eller skadede, gætter du. Tilføj testtilfælde og en pass/fail-check.
• Ignorering af modelspecifik adfærd. Prompten, der synger på GPT-5, kan have brug for XML-tags på Claude. Læs cheat sheetet ovenfor.
• Prompt-stuffing. At proppe mere ind i én instruktion, når det egentlige gab er retrieval eller hukommelse, betyder, at du havde brug for context engineering, ikke en længere prompt.
• Tillid til utroværdigt input. Brugerindhold og hentede dokumenter kan bære skjulte instruktioner. Tilføj guardrails omkring dem; vores kommende deep-dive i prompt-injection-prevention dækker sikkerhedssiden fuldt ud.

Den dyreste prompt-fejl i 2026 er ikke en tastefejl. Det er at shippe uden en eval, der ville have fanget regressionen.

Er prompt engineering dødt? Et ærligt svar fra 2026

Nej. Prompt engineering er ikke dødt, det bifurkerede. Afslappet prompting blev lettere, fordi modellerne blev smartere og mere tilgivende. Produktions-prompting blev sværere, fordi pålidelighed, strukturerede outputs og evaluering nu betyder mere end clever formulering. Ordet "engineering" betyder endelig, hvad det siger.

Så hvorfor fortsætter alle med at erklære det dødt? Fordi den synlige halvdel, at taste en anmodning ind i ChatGPT, genuint blev trivial. Den halvdel, der ikke blev lettere – at shippe en prompt, der holder stand på tværs af tusindvis af kald og ti sprog – laver ikke overskrifter. Den rigtige 2026-færdighed er ikke en magisk frase. Det er evaluering, valg af model-tier (planlægger vs. arbejdshest) og at vide, hvornår et problem er vokset ud af prompten og er blevet context engineering. Den lette halvdel blev lettere, og den svære halvdel blev sværere, og kun den ene laver overskrifter.

Hvis der er én takeaway: 10 teknikker tjener stadig deres ophold, 4 gamle vaner koster dig nu på reasoning-modeller, og evaluering er færdigheden, der adskiller en demo fra et produkt. Bygger du noget, hvor promptsene skal holde stand i produktion? Få en gratis konsultation, så hjælper vi dig med at opsætte eval-loopen først.

Ofte stillede spørgsmål

Hvad er prompt engineering i konteksten af generativ AI?

Prompt engineering er praksissen med at designe og forfine de instruktioner, du giver en stor sprogmodel for at få præcist, relevant output. Det dækker teknikker som zero-shot, few-shot, chain-of-thought og rolle-prompting. I 2026 deler det sig i afslappet chat-prompting og stringent produktions-prompting inde i et system.

Er prompt engineering dødt i 2026?

Nej, prompt engineering er ikke dødt i 2026, det bifurkerede. Afslappet prompting blev lettere, efterhånden som modellerne blev mere tilgivende. Produktions-prompting blev mere stringent, fordi strukturerede outputs, evaluering og pålidelighed nu betyder mere end clever formulering. Færdigheden forsvandt ikke; den lette halvdel stoppede bare med at have brug for dig.

Hvad er forskellen mellem prompt engineering og context engineering?

Prompt engineering udformer instruktionen; context engineering designer alt andet i kontekstvinduet: retrieval, hukommelse, værktøjer og rækkefølge. Prompt engineering er en delmængde af context engineering. Du har brug for context engineering, når dine inputs ændres pr. anmodning, som i agenter og RAG-systemer.

Har du stadig brug for chain-of-thought-prompting med reasoning-modeller?

Normalt ikke. På reasoning-modeller som OpenAIs o-serie, GPT-5 og Claudes thinking-modes er det overflødigt at tvinge "tænk trin for trin", fordi de ræsonnerer internt, og OpenAI siger, at det kan skade ydeevnen. Chain-of-thought hjælper stadig på klassiske GPT-lignende modeller, så match teknikken til niveauet.

Kræver prompt engineering kodning?

Nej, ikke for at komme i gang. Alle kan skrive klare instruktioner og få bedre svar fra ChatGPT eller Claude. Men produktions-prompt engineering, versionering af prompts, wiring af strukturerede outputs og opbygning af eval-loops er en udviklerdisciplin. Den afslappede halvdel kræver ingen kode; den professionelle halvdel gør.

Hvad er forskellen mellem zero-shot og few-shot prompting?

Zero-shot prompting giver en klar instruktion uden eksempler; few-shot inkluderer to til fem eksempler for at forme output-formatet eller adfærden. På 2026-modeller skal du starte med zero-shot, fordi de følger instruktioner godt, og kun tilføje few-shot, når eksempler målbart forbedrer resultaterne. Few-shot er fallback'en, ikke standarden.

Hvordan får jeg en LLM til pålideligt at returnere JSON?

Brug skema-begrænsede strukturerede outputs, ikke prompt-tiggeri. I stedet for at skrive "returnér venligst JSON" skal du sende et JSON-skema gennem OpenAIs eller Anthropics Structured Outputs-funktion, som begrænser modellen til gyldigt, parsebart output. Det gamle prefill-trick returnerer nu en 400-fejl på nyere Claude-modeller.

Hvad er meta-prompting?

Meta-prompting er at bruge en model til at udkaste eller forbedre den prompt, du vil køre. Værktøjer som Anthropics prompt improver og OpenAIs prompt optimizer omskriver dit udkast efter bedste praksis; Anthropic målte en 30 % nøjagtighedsgevinst på én test. Generér et første udkast, og rediger det derefter i hånden til dine data.

Er prompt engineering en rigtig karriere eller et job?

Ja, det er en rigtig færdighed, selvom den standalone "prompt engineer"-titel falmer ind i bredere AI-engineering-roller. Arbejdsgivere vil have folk, der kan udforme prompts og designe evals, strukturerede outputs og context-pipelines. Som karriere er det stærkest som én del af en AI-ingeniørs værktøjskasse.

Hvordan er prompting forskellig på tværs af ChatGPT, Claude og Gemini?

Jobbet er det samme; dialekten er forskellig. OpenAI bruger developer messages og styrer dig væk fra eksplicit chain-of-thought på reasoning-modeller. Anthropics Claude favoriserer XML-tags, adaptiv thinking og effort-parameteren. Googles Gemini bruger et thinking-budget. Reasoning-modeller er planlæggere; klassiske GPT-lignende modeller er arbejdsheste.

Kilder

• OpenAI: Bedste praksis for reasoning
• OpenAI: Strukturerede outputs
• OpenAI: Prompt optimizer
• Anthropic: Bedste praksis for Claude-prompting
• Anthropic: Strukturerede outputs
• Anthropic: Prompt improver (docs)
• Anthropic: Ankendelse af prompt improver
• arXiv 2410.21333: Mind Your Step (by Step)
• arXiv 2412.21187: Do NOT Think That Much for 2+3?
• arXiv 2406.06608: The Prompt Report
• Prompt Engineering Guide (dair-ai)