Design af produktionsprompts: system-, udvikler- og brugerlag

En prototype kan begynde med en streng direkte i koden. Produktionspresset viser sig, når prompten skal have en ejer, kunne gennemgås og rulles tilbage, håndtere data, understøtte flere funktioner eller sprog eller give en målbar adfærd. Det kan ske før lanceringen, og der findes ingen universel tidslinje.

I skal kunne ændre én del af instruktionerne uden at påvirke andre, variere adfærden mellem kundetyper, A/B-teste versioner, rulle tilbage ved fejl og se, hvornår prompten sidst blev ændret og hvorfor.

Et design til produktionsprompts gør disse valg udtrykkelige. Promptteksten er ét artefakt i et styret udgivelses- og runtime-system.

Artiklen bruger en redaktionel arkitektur med tre lag til at forklare ejerskab og ændringstakt og viser derefter, hvordan den kortlægges til udbyder-API’er. Det er et referencedesign, ikke et universelt wireformat. Brug OWASPs vejledning om promptinjektion som sikkerhedsgrundlag: Adskillelse af instruktioner og data hjælper gennemgang og evaluering, men ingen promptskabelon skaber en bemyndigelses- eller isolationsgrænse.

Produktionsprompts består af to adskilte artefakter: genbrugelige skabeloner og data pr. forespørgsel. Versionér skabelonerne som kode. Behandl genererede prompts og modelsvar som følsomme logdata, når de indeholder bruger-, kunde- eller interne data.

Tre redaktionelle lag kortlagt til et API

Designet adskiller tre redaktionelle ansvarsområder:

Systemlag. Relativt stabil adfærd, identitet og begrænsninger. Ejes af teamet med ansvar for AI-adfærd på tværs af funktioner.

Udviklerlag. Instruktioner pr. funktion, politik for værktøjsbrug og outputkrav. Ejes af funktionsteamet.

Bruger- og runtime-lag. Brugerens anmodning plus dynamisk kontekst som godkendte kundedata, samtalehistorik og hentet viden. Konstrueres til en anmodning eller samtalerunde.

Når ejerskab, stabil politik, funktionsinstruktioner og runtime-data blandes, bliver ændringer sværere at gennemgå, evaluere, cache og rulle tilbage. Adskil dem, hvor det forbedrer kontrollen; fremtving ikke tre API-felter, hvis udbyderen eller programmet har en anden repræsentation.

Instruktionsautoritet og dataplacering hænger sammen, men er ikke det samme. Tillidshierarkiet afgør, hvilken instruktion der vinder ved konflikt. Dataplacering afgør, hvor programmet bærer dynamisk eller utroværdigt indhold. Hentet tekst bliver ikke godkendt, korrekt eller sikker af at ligge i et bruger- eller kontekstfelt. Håndhæv identitet, tenant-adgang, dataminimering, værktøjstilladelser og outputvalidering uden for modellen.

At adskille dem er grundlæggende:

┌─────────────────────────────────────┐
│ Systemlag (relativt stabilt)        │  Identitet, adfærd, politisk hensigt
├─────────────────────────────────────┤
│ Udviklerprompt (pr. funktion)       │  Instruktioner, værktøjer, format
├─────────────────────────────────────┤
│ Brugerprompt (pr. kald)             │  Anmodning, kontekst, samtale
└─────────────────────────────────────┘

Model-API’erne udtrykker disse skel på forskellige måder:

• OpenAI: I Responses API’et bruger du parameteren instructions eller en developer-meddelelse til applikationens instruktioner og en user-meddelelse til brugerens input. Gå ikke ud fra, at instruktioner fra et tidligere svar følger med, når du selv håndterer et forløb med flere ture.
• Anthropic: Kortlæg designet til Claude Messages API, mekanismen til systeminstruktioner, meddelelsesroller og værktøjsdefinitioner; understøttet placering af roller kan variere mellem model og platform.
• Gemini: Kortlæg det til system_instruction og anmodningsindhold samt den separate værktøjskonfiguration i det valgte API.

Brug en udbyderspecifik adapter og integrationstest. Kopiér ikke rollenavne mellem API’er med en antagelse om samme prioritet, persistens eller værktøjsadfærd.

Lag 1: Systemprompten

I dette redaktionelle mønster definerer systemlaget rolle og adfærd på tværs af funktioner. Sigt efter at ændre det sjældnere end funktionsinstruktioner, men versionér og evaluér enhver ændring.

En god systemprompt dækker:

Identitet. Hvem AI’en er. “Du er en AI-assistent for [Company], specialiseret i [domain].”

Stemme og stil. Hvordan den skal lyde. Specifikke egenskaber, ikke vage beskrivelser.

Påkrævede adfærdsbegrænsninger. Hvad modellen bør afvise, eskalere, oplyse eller formatere. Håndhæv sikkerhed, tilladelser og kontroller af irreversible handlinger i programkode og efterfølgende systemer frem for kun at stole på teksten.

Adfærdsmodeller. Hvordan den håndterer almindelige situationer. Afvisninger, eskaleringer, usikkerhed.

Sikkerhed og efterlevelse. Påkrævede oplysninger, regelbaserede regler, indholdspolitikker.

Det skal ikke indeholde:

• Funktionsspecifikke instruktioner (“til salgs e-mails, gør X”).
• Dynamisk kontekst (“brugerens bestillingshistorik er…”).
• Værktøjsbeskrivelser (disse går andre steder).
• Ting, der ændres ofte.

En systemprompt bør kun være så lang, som den evaluerede adfærd kræver. En kort prompt kan være tilstrækkelig, og en lang prompt kan stadig mangle afgørende regler. Mål instruktionskonflikter, opgavekvalitet, svartid og tokenforbrug i stedet for at sigte efter et bestemt antal ord.

En referenceskabelon:

Du er [name], en AI-assistent for [company / context].

## Din rolle
[2-3 sentences on what you do]

## Stemme og stil
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Undlad at bruge [anti-pattern 1]
- Undlad at bruge [anti-pattern 2]

## Ufravigelige begrænsninger
- Du må aldrig [hard rule 1]
- Du må aldrig [hard rule 2]
- Du skal altid [hard rule 3]

## Sådan håndterer du usikkerhed
- Hvis du ikke ved noget faktuelt, skal du sige det udtrykkeligt.
- Hvis en bruger beder om noget uden for området, skal du tilbyde den hjælp, du kan give.
- Hvis en anmodning kan forårsage skade, skal du afvise den og forklare hvorfor.

## Krav til format
- Brug som udgangspunkt ren tekst
- Brug Markdown til kode eller strukturerede data
- Svar kortfattet uden fyld

Dette kan være den stabile, politikbærende del af promptdesignet. Bekræft med evaluering og telemetri, at den tilsigtede adfærd holder under funktionsinstruktioner, lange kontekster, værktøjsresultater og fjendtlige input.

Lag 2: Udviklerprompten

Udviklerprompten er funktionsspecifik. Forskellige funktioner har forskellige udviklerprompts.

Udviklerprompten til en opsummeringsfunktion:

Opgave: Udarbejd et resumé af dokumentet nedenfor.

Krav:
- 3-5 punktopstillinger
- Hvert punkt skal være en hel sætning
- Fokusér på fakta og konkrete påstande, ikke indtryk
- Medtag de vigtigste tal, hvis dokumentet indeholder tal
- Medtag ikke markedsføringssprog eller spekulation
- Gør opmærksom på væsentlig uklarhed i dokumentet

Format: Enkle Markdown-punkter uden indledning.

En udviklerprompt til en kodegennemgangsfunktion:

Opgave: Gennemgå kodediffen nedenfor.

Returnér et JSON-objekt med:
- summary: oversigt over ændringen på 1-2 sætninger
- concerns: liste over konkrete problemer (hver med file, line, severity, description)
- suggestions: liste over forbedringer (hver med file, line, suggestion)
- approved: boolesk værdi (true, hvis der ikke er blokerende problemer)

Værdier for severity:
- "blocker": skal rettes før merge
- "warning": bør håndteres, men blokerer ikke
- "nit": stilistisk og valgfri

Fokusér på:
- Logikfejl
- Sikkerhedsproblemer
- Ydelsesproblemer
- Manglende testdækning
- Uklar navngivning eller struktur

Ignorér:
- Formatering (håndteres af formatteren)
- Subjektive stilpræferencer

Hver funktion har sin egen udviklerprompt. De gemmes separat, versioneres separat og evalueres separat.

Lag 3: Brugerprompten

Brugerlaget er dynamisk. Det indeholder typisk:

Brugerens faktiske anmodning. “Opsummér dette dokument for mig.”

Kontekst, systemet har hentet. Dokumenter fra RAG, kundehistorik og samtalehistorik.

Variabler pr. kald. Brugernavn, tidszone, sprogpræference og kontoniveau.

Dette lag bygges programmatisk ved hvert kald. Strukturen ser typisk sådan ud:

{conversation_history_summary}

{retrieved_context}

Brugerens anmodning: {user_query}

Yderligere kontekst:
- Brugernavn: {name}
- Brugerens tidszone: {timezone}
- Brugerens kontoniveau: {tier}

Den præcise struktur afhænger af funktionen og udbyderen. Hold flygtige, brugerspecifikke og hentede data ude af genbrugelige instruktionsskabeloner, medmindre API-kontrakten kræver en anden placering. Bevar proveniens, og anvend bemyndigelse, minimering, afgrænsning og validering, uanset hvor dataene transporteres.

Disciplin i brugen af skabeloner

Sammensætning af produktionsprompts har ofte gavn af skabeloner. Direkte strengsammenkædning bliver sværere at gennemgå og teste, når forgreninger, datafelter og funktioner vokser.

Et enkelt skabelonsystem:

from string import Template

SUMMARIZE_TEMPLATE = Template("""
$conversation_summary

Document to summarize:
$document

User's specific instructions: $user_instructions
""")

prompt = SUMMARIZE_TEMPLATE.substitute(
    conversation_summary=summarize_conversation(history),
    document=document_text,
    user_instructions=user_query,
)

Mere avanceret: et skabelonbibliotek som Jinja2 eller Handlebars med betingelser og delskabeloner.

{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}

{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}

User's request: {{ user_query }}

Skabeloner holder promptstrukturen ensartet, muliggør betinget logik og gør det lettere at afgrænse eller escape brugerinput. De stopper ikke i sig selv promptinjektion. Behandl tekst fra kilder, værktøjer og brugere som data, aldrig som betroede instruktioner.

Vælg en styret autoritativ kilde

Behandl produktionsprompts som versionerede udgivelsesartefakter. Den autoritative kilde kan være et repository, et eget register eller en tjeneste eller et administreret produkt med redigeringsbrugerflade. Vælg ud fra styrings- og driftsbehov, ikke antagelsen om, at ét lagermønster passer alle teams.

Til kodestyrede prompts er en prompts/-mappe med én fil pr. prompt et tydeligt udgangspunkt:

prompts/
  system/
    main.txt
    customer-support.txt
    code-assistant.txt
  features/
    summarize.txt
    classify-ticket.txt
    generate-email.txt
  templates/
    base.j2

Hver fil kan have sin egen commit-historik og PR-gennemgang, mens produktionsudrulninger henviser til en kendt kodeversion.

Hvorfor det betyder noget:

• Diff. Når en prompt ændres, vises forskellen i pull requesten. Kontrollanter kan se præcist, hvad der er ændret.
• Tilbagerulning. Hvis en ændring giver fejl, kan den forrige version gendannes.
• Historik. Spørgsmål som “Hvornår ændrede vi refunderingspolitikken?” og “Hvorfor findes dette afsnit?” kan besvares via git blame.
• Værktøjer. Linters, validatorer og evalueringssuiter kan integreres med filbaserede prompts.

Sammenlign hovedmulighederne udtrykkeligt:

Indlejrede strenge kan fungere i en lille prototype, men er sværere at finde og udgive uafhængigt. En redigeringsbrugerflade kan være egnet, når dens tilladelser, gennemgang, proveniens, udrulning og tilbagerulning passer til arbejdsgangens risiko. Prompts kopieret fra chatvinduer skal gennem samme gennemgang, rensning og evaluering som andre kandidater.

Læg ikke produktionssamtaler, kundedata, supportsager, interne dokumenter eller genererede prompts med følsomme variabler i versionsstyring. Den er til genbrugelige skabeloner, testdata og rensede evalueringseksempler. Virkelige spor hører til i et observerbarhedssystem med opbevaringsregler, adgangskontrol og maskering.

Runtime-registre og tjenester

Når promptudgivelser kræver en anden takt end programudrulninger, eller bemyndigede redaktører har brug for en kontrolleret brugerflade, giver et repository alene måske ikke det rette forløb. Et register eller en tjeneste kan vælge en godkendt version ved runtime.

Mønstret er en database eller tjeneste, der gemmer promptversioner med metadata.

prompt = prompt_service.get(
    name="summarize",
    version="v3",
    locale="en",
    user_tier="enterprise",
)

Tjenesten bør vedligeholde:

• Aktuelle og historiske versioner af hver prompt.
• Metadata: hvornår tilføjet, af hvem, hvorfor.
• Evalueringsscorer knyttet til hver version.
• Mulighed for tilbagerulning.

Lagermotoren er kun én del af designet. Sammenlign rollebaseret adgang, revisionshistorik, autentificeret runtime-adgang, promovering mellem miljøer, ensartet udrulning, tilbagerulning, eksport, kryptering, databehandling, tilgængelighed og driftsomkostninger. En lille database er kun tilstrækkelig, når de omgivende kontroller opfylder kravet.

Definér, hvem der må skrive udkast, gennemgå, godkende, udgive, rulle tilbage og læse genererede prompts. Redigeringsadgang medfører ikke adgang til produktionsudgivelse. Følsomme arbejdsgange kan kræve særskilte roller, maskerede forhåndsvisninger, dobbelt godkendelse eller en brugerflade, der aldrig viser levende kundedata.

Ændringer med evalueringsport

Promptændringer, der kan påvirke brugerresultater, værktøjsbrug, databehandling, politikoverholdelse eller efterfølgende beslutninger, bør gennemgå review og risikoproportionale evalueringer før udrulning. En tekstændring med lav risiko kan kræve et lille regressionssæt; en prompt, der kan påvirke en betaling, konto eller reguleret beslutning, kræver stærkere offline-tilfælde, fjendtlige test, godkendelse og trinvis udgivelse. Definér en nødprocedure med afgrænset udrulning, overvågning, godkendelse og tilbagerulning i stedet for stiltiende at omgå porten.

Flow:

1. Ingeniør eller ikke-ingeniør skriver en promptændring.
2. Ændringen køres mod evalueringssættet.
3. Evalueringsresultaterne gennemgås sammen med ændringen.
4. Hvis evalueringerne består uden regression og helst med forbedring, kan ændringen godkendes.
5. Godkendte ændringer udrulles.
6. Overvågning efter udrulning opdager det, evalueringerne overså.

Bevar et repræsentativt evalueringssæt til væsentlige prompts, og kør stabile, automatiserbare kontroller i CI, når signalet er pålideligt nok til at fungere som port. Brug ekspert- eller menneskelig gennemgang, hvor acceptkriteriet ikke kan reduceres til en automatisk score. Registrér, hvad der blev testet, tærsklen, kontrollanten og den resterende usikkerhed.

Porten beviser ikke korrekthed. Den gør udgivelsesbeslutningen kontrollerbar og giver teamet et udgangspunkt til at opdage regressioner efter udrulning.

En praktisk frigivelsescheckliste

Før en promptversion går i produktion, kræves en kort tjekliste:

Den tilhørende tjekliste gør kontrollerne til en gentagelig udgivelsesgennemgang.

A/B-testning i produktion

Til prompts, der egner sig til onlineeksperimenter, kan en trinvis sammenligning med den nuværende version give signaler ud over offlineevalueringer. Brug ikke levende trafik som første sikkerhedstest, og udsæt ikke mennesker for en væsentligt mere risikabel behandling alene for at indsamle data.

Illustrativt mønster, ikke en standardfordeling:

• 95% af trafikken bruger produktionsprompt v3.
• 5% får den nye kandidat v4.
• Hold modeladgang, værktøjstilladelser og handlingsgrænser inden for den godkendte produktionsgrænse.
• Mål opgavesucces, sikkerheds- og politikfejl, brugerfeedback, efterfølgende mål og gennemgåede evalueringsscorer på berettiget trafik.
• Definér mindste stikprøve, stopbetingelser, ejer og tilbagerulning i ét trin før start.
• Afgør efter tilstrækkelig dokumentation, om kandidaten skal udvides, revideres eller stoppes.

Leveringsmekanismer omfatter egne feature flags, udrulningskonfiguration, et godkendt promptregister eller specialbygget routing.

Advarsler:

• A/B-test opdager kun de signaler, I måler. Uden brugerfeedback eller efterfølgende konverteringsmål fortæller testen kun lidt.
• Statistisk betydning kræver volumen. For lavvolumens funktioner er A/B-testning svær.
• Samtidige eksperimenter kan påvirke hinanden og gøre årsagstildeling uklar; kontrollér overlap bevidst.
• Overvej krav om oplysning, samtykke, udelukkelse og gennemgang for produkt, målgruppe og jurisdiktion. Handlinger med stor eller irreversibel virkning kræver normalt stærkere godkendelse og reversibilitet, end en trafikfordeling kan give.

Observerbarhed for prompts

Definér privatlivssikker telemetri for hver produktionsarbejdsgang. Til kald, der påvirker væsentlige resultater, skal du registrere nok af følgende til at identificere den udrullede adfærd og rekonstruere fejl:

• Hvilken promptskabelon der blev brugt (navn, version).
• Hvilke variabler der blev indsat, med tilladte navne og maskerede værdier, hvor det er nødvendigt.
• Den endelige genererede prompt kun, når politikken tillader det; ellers en maskeret, stikprøvebaseret eller hashet repræsentation.
• Modellens svar, maskeret eller stikprøvebaseret ved følsomme arbejdsgange.
• Latens, tokens, omkostninger.
• Nedstrøms signaler (brugertilbagemeldinger, succesmål).

Målet er at kunne besvare, hvilken version der kørte, hvilken godkendt dokumentation den modtog, hvilket valideret output den gav, hvilke værktøjer eller politikker der indgik, og hvad der skete efterfølgende. Log ikke skjult ræsonnement som erstatning for disse kendsgerninger.

Lagring: en databasetabel eller et observerbarhedsværktøj. Omkostningen er reel, hvis alt logges (kaldsvolumen × tokenantal × lagring). Det samme gælder risikoen for følsomme data. Beslut pr. arbejdsgang, hvilke felter der må gemmes, maskér hemmeligheder og personoplysninger som standard, og brug kort opbevaring, medmindre efterlevelseskrav kræver længere spor. Nogle teams bruger stikprøver.

Fastlæg gennemgangstakt og stikprøvemetode ud fra volumen, risiko, ændringstakt, hændelser og juridiske begrænsninger. Gennemgå maskerede eller på anden måde godkendte spor, medtag kendte særtilfælde, og før bekræftede fejl tilbage til evalueringerne. En ugentlig stikprøve kan passe til én arbejdsgang og være uhensigtsmæssig eller utilstrækkelig til en anden.

Prompt anti-mønstre

Få mønstre at undgå:

Anti-mønster 1: En uforvaltet prompt til mange formål. En stor systemprompt, der blander uvedkommende funktioner, politikker, eksempler og runtime-antagelser, kan være svær at gennemgå, evaluere og rulle tilbage. Længden er ikke i sig selv fejlen; det er den umålte kompleksitet.

Løsning: Adskil komponenter efter ejerskab og ændringsgrænse, hvor det hjælper, fjern dublerede eller forældede instruktioner, og sammenlign det reviderede design på repræsentative evalueringer.

Anti-mønster 2: Inline strengkonkatenation.

prompt = "You are helpful. " + (
    "The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...

Skrøbelig og svær at læse. Strengsammenkædning gør også grænsen mellem instruktioner og data vanskelig at kontrollere, men det neutraliserer ikke skadelige instruktioner blot at flytte de samme værdier til en skabelon.

Løsning: Brug et skabelonsystem.

Anti-mønster 3: Samme prompt til for mange anvendelser.

En enkelt prompt til en »generel assistent«, der bruges til mailskrivning, kodegennemgang, kundesupport og research, kan skjule opgavespecifikke acceptkriterier og ejerskab.

Løsning: funktionsspecifikke udviklerprompts oven på en fælles systemprompt.

Anti-mønster 4: Hardcodede prompts.

response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "You are a helpful assistant..."},
        {"role": "user", "content": query}
    ]
)

Prompten er skjult i koden. Den kan ikke redigeres uden en udrulning, A/B-testes eller versioneres uafhængigt.

Løsning: udtræk til en promptfil eller tjeneste.

Anti-mønster 5: Ingen evalueringsdækning.

En funktion lanceres med en prompt, der aldrig er blevet testet systematisk. Kvaliteten vurderes på mavefornemmelse, og kvalitetsdrift kan ikke opdages.

Løsning: Tilføj risikoproportional evalueringsdækning af den adfærd, der betyder noget, herunder fejl- og eskaleringstilfælde.

Anti-mønster 6: Dynamiske data i systemprompten.

Du er assistent for John, en premiumkunde, der blev kunde i 2023, bor i Tallinn og har 47 åbne sager.

Nu ændres det genbrugelige instruktionspræfiks ved hvert kald, hvilket kan mindske cachegenbrug og sløre forskellen mellem politik og kundedata.

Løsning: Transportér dynamiske data i udbyderens runtime-input eller kontekstmekanisme med proveniens, bemyndigelse og minimering. Udled ikke tillid af meddelelsesrollen.

Anti-mønster 7: Instruktioner skjult midt i.

Hjælp brugeren med anmodningen. Vær høflig. Formatér output som JSON. Brug ikke Markdown. Brugeren spørger om priser, så vær omhyggelig med at angive tal. Svaret skal være 1-2 sætninger. Hjælp nu brugeren.

Kritiske krav bliver sværere for en kontrollant at finde og kan være i konflikt med nærliggende prosa.

Løsning: Saml kritiske instruktioner i en tydeligt mærket blok, angiv hver regel én gang, og test, om den valgte model følger dem under repræsentative lange og fjendtlige kontekster.

Specifikke mønstre for almindelige funktioner

Få funktionsspecifikke mønstre:

Klassificering

Opgave: Klassificér følgende tekst i én af disse kategorier:
- billing: betaling, refusion, abonnement
- technical: fejl, driftsfejl, integrationsproblem
- account: login, adgangskode, profilændringer
- feature_request: ønske om ny funktionalitet
- complaint: generel utilfredshed uden et konkret problem, der kan handles på

Returnér et JSON-objekt: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Tekst, der skal klassificeres:
{text}

Mønstre: opstillet kategorier med definitioner, struktureret output, konfidens- og begrundelsesfelter.

Ekstraktion

Opgave: Udtræk strukturerede data fra dokumentet nedenfor.

Skema:
- vendor_name: virksomheden, der har udstedt fakturaen
- invoice_number: som angivet på dokumentet
- date: ISO 8601-format
- line_items: liste af {description, quantity, unit_price, total}
- subtotal, tax, total: tal

Regler:
- Brug null, hvis et felt ikke findes
- Tal skal være numeriske værdier, ikke strenge
- Sæt "needs_review": true i tvetydige tilfælde, og forklar hvorfor

Dokument:
{document}

Mønstre: eksplicit skema, forventede typer, håndtering af manglende data og eskalering ved usikkerhed.

Generering med stil

Opgave: Skriv en {format} om {topic} til {audience}.

Stil:
- {Specific style trait 1}
- {Specific style trait 2}
- Undgå: {anti-pattern 1}, {anti-pattern 2}

Begrænsninger:
- Længde: {N} ord
- Medtag: {required elements}
- Udelad: {forbidden elements}

Reference for stemmen:
[Provide a sample of the desired voice]

Output: Kun selve {format} uden indledning eller efterskrift.

Mønstre: konkrete stiltræk frem for generiske, eksplicitte begrænsninger og et referenceeksempel som anker for tonen.

Agent-loop

Du har adgang til følgende værktøjer:
{tool_descriptions}

For hver tur:
1. Vurdér, hvad der skal gøres.
2. Afgør, om du har brug for et værktøj. Kald værktøjet, hvis det er nødvendigt.
3. Kontrollér resultatet, og afgør derefter, om du har brug for flere værktøjer eller kan svare.
4. Giv det endelige svar, når du har tilstrækkelige oplysninger.

Begrænsninger:
- Højst 5 værktøjskald pr. anmodning.
- Forklar, hvad der mangler, hvis opgaven ikke kan fuldføres efter 5 kald.
- Opfind aldrig værktøjsnavne eller argumenter.
- Kontrollér værktøjsresultater, før du handler på dem.

Brugerens anmodning:
{user_query}

Mønstre: et trinvist forløb for værktøjsbrug, et værktøjsbudget, udtrykkelig validering og afgrænset fejlhåndtering.

Teamaspektet

Produktionsprompts involverer typisk flere personer:

• Ingeniører forbinder de enkelte prompts til systemet, vedligeholder skabelonerne og styrer udrulningen.
• Produkt definerer, hvad hver prompt skal opnå.
• Indhold/markedsføring ejer stemme- og stilvejledning.
• Domæneeksperter ved, hvad der er korrekt til konkrete anvendelser som juridiske formuleringer og medicinske begreber.

Et nyttigt mønster er en promptgennemgang, der minder om kodegennemgang og inddrager de rette kontrollanter for hvert domæne. Toneændringer gennemgås af indholdsteamet, logikændringer af ingeniører og domænespecifikt indhold af faglige eksperter.

Ved følsomme juridiske, medicinske eller finansielle anvendelser kan prompts kræve formel gennemgang og godkendelse. Tilpas processen derefter.

En faseopdelt plan for promptmodenhed

Til teams, der går fra “prompts er strenge i kode” til “prompts er styret infrastruktur”:

Fase 1: Grundlag.

• Registrér alle prompts og al kode til promptsammensætning, der væsentligt påvirker adfærden.
• Definér modellen for instruktionsautoritet, grænsen for runtime-data, ejerne og udbyderkortlægningen.
• Vælg en styret autoritativ kilde og en skabelontilgang, der passer til udgivelsesforløbet.
• Opsæt privatlivssikker telemetri, der identificerer udrullet version og resultat uden at gemme unødvendigt følsomt indhold.

Fase 2: Evaluering.

• Byg først evalueringssæt til de prompts, der har størst risiko og volumen.
• Kør repræsentative evalueringer ved væsentlige promptændringer med faglig gennemgang, hvor det kræves.
• Læg stabile automatiske kontroller i CI, og gør ikke-automatiserbare acceptbeslutninger synlige i gennemgangsregistreringen.

Fase 3: Drift.

• Implementér promptversionering i det valgte repository, register eller den valgte tjeneste.
• Tilføj en trinvis udrulnings- og stopmekanisme; brug kun A/B-test, hvor arbejdsgangen er egnet.
• Byg overvågning af de kvalitets-, sikkerheds-, politik-, svartids-, pris- og efterfølgende signaler, som arbejdsgangen kræver.
• Etablér en gennemgangsproces for promptændringer.

Lov ikke dette resultat på en kalender. Afslut først forløbet, når test viser, at alle relevante prompts er fundet, kritiske ændringer versioneres og går gennem en port, tilbagerulning virker, telemetrien identificerer den udrullede version, og ejerne kan øve en hændelseshåndtering.

Prompts som infrastruktur

Produktionsprompts kan være gemt som strenge, men de fungerer som versionerede systemkomponenter med omgivende kontroller for sammensætning, evaluering, udgivelse, adgang og observerbarhed.

Et instruktionshierarki definerer autoritet; det sikrer ikke runtime-data eller værktøjshandlinger. Skabeloner kan mindske sammensætningsfejl, men forhindrer ikke promptinjektion. En styret autoritativ kilde giver versionshistorik. Risikoproportionale evalueringer informerer udgivelsesbeslutninger, og telemetri tester, om den tilsigtede adfærd holder uden for evalueringssættet.

Den nødvendige grundighed afhænger af risiko og omfang, men en udeladt kontrol bør have en dokumenteret begrundelse. Påstande om produktionsmodenhed bør ledsages af den dokumentation for versionering, evaluering, udrulning, tilbagerulning og telemetri, som faktisk er implementeret.

Den tilsigtede kontrollerbarhed er en hypotese, indtil evalueringer og produktionstelemetri viser, at den valgte model, promptversion, datavej, værktøjer og politikker holder sig inden for accepttærsklerne. Bevar dokumentationen sammen med udgivelsen, undersøg fejl efter version, og hold tilbagerulning anvendelig.

Begynd med den mindste arkitektur, der gør ejerskab, autoritet, databehandling, evaluering, udrulning, tilbagerulning og dokumentation udtrykkelig.