Utforma prompter för produktion: system-, utvecklar- och användarlager

En prototyp kan börja med en sträng inne i koden. Produktionstrycket uppstår när prompten behöver ägarskap, granskning, återställning, datahantering, stöd för flera funktioner eller språk – eller ett mätbart beteende. Det kan inträffa redan före lansering och följer ingen universell tidslinje.

Du vill ändra en del av instruktionerna men inte andra, ha olika beteende för olika kundnivåer, A/B-testa versioner, återställa när något går sönder och veta när prompten senast ändrades och varför.

En produktionsdesign för prompter gör dessa val uttryckliga. Prompttexten är en artefakt i ett styrt system för lansering och körning.

Artikeln använder en redaktionell arkitektur med tre lager för att förklara ägarskap och ändringstakt och visar sedan hur den mappas till leverantörernas API:er. Det är en referensdesign, inte ett universellt dataformat. För säkerhetsgränsen, utgå från OWASP:s vägledning om promptinjektion: att skilja instruktioner från data hjälper granskning och utvärdering, men ingen promptmall skapar en auktoriserings- eller isoleringsgräns.

Produktionsarbete med prompter har två separata artefakter: återanvändbara mallar och data per begäran. Versionshantera mallarna som kod. Behandla renderade prompter och modellsvar som känsliga loggar när de innehåller användar-, kund- eller interna data.

Tre redaktionella lager mappade till ett API

Designen skiljer tre redaktionella ansvarsområden åt:

Systemlager. Relativt stabilt beteende, identitet och begränsningar. Ägs av teamet som ansvarar för AI-beteendet mellan funktioner.

Utvecklarlager. Funktionsspecifika instruktioner, policy för verktygsanvändning och utdatakrav. Ägs av funktionsteamet.

Användar- och körningslager. Användarens begäran samt dynamiskt sammanhang som auktoriserade kunddata, konversationshistorik och hämtad kunskap. Konstrueras för en begäran eller samtalstur.

Att blanda ägarskap, stabil policy, funktionsinstruktioner och körningsdata kan göra en ändring svårare att granska, utvärdera, cachelagra och återställa. Separera dem där det förbättrar kontrollen. Tvinga inte fram tre API-fält när leverantören eller applikationen har en annan representation.

Instruktionsauktoritet och dataplacering hänger samman men är olika saker. Tillitshierarkin avgör vilken instruktion som vinner när meddelanden strider mot varandra. Dataplacering avgör var applikationen bär dynamiskt eller otillförlitligt innehåll. Att lägga hämtad text i ett användar- eller kontextfält gör den inte auktoriserad, korrekt eller säker. Upprätthåll identitet, klientåtkomst, uppgiftsminimering, verktygsbehörigheter och utdatavalidering utanför modellen.

Separationen är grundläggande:

┌─────────────────────────────────────┐
│ Systemlager (relativt stabilt)       │  Identitet, beteende, policyavsikt
├─────────────────────────────────────┤
│ Utvecklarprompt (per funktion)      │  Funktionsinstruktioner, verktyg, format
├─────────────────────────────────────┤
│ Användarprompt (per anrop)          │  Fråga, kontext, konversation
└─────────────────────────────────────┘

Leverantörernas API:er uttrycker instruktions- och innehållsgränser på olika sätt:

• OpenAI: I Responses API använder du toppnivåparametern instructions eller ett developer-meddelande för applikationens instruktioner och ett user-meddelande för användarens indata. Utgå inte från att instruktioner från ett tidigare svar följer med när du hanterar ett flerstegsflöde.
• Anthropic: mappa designen till Claude Messages API, dess mekanism för systeminstruktioner, meddelanderoller och verktygsdefinitioner. Tillåten rollplacering kan variera mellan modell och plattform.
• Gemini: mappa den till system_instruction och innehållet i begäran, tillsammans med den separata verktygskonfigurationen i det valda API:et.

Använd en leverantörsspecifik adapter och integrationstester. Kopiera inte rollnamn mellan API:er och anta att de har samma prioritet, beständighet eller verktygsbeteende.

Lager 1: systemprompten

I detta redaktionella mönster definierar systemlagret roll och beteende mellan funktioner. Sträva efter att ändra det mer sällan än funktionsinstruktionerna, men versionshantera och utvärdera det varje gång det ändras.

En bra systemprompt omfattar:

Identitet. Vem AI:n är. ”Du är AI-assistent för [Company], specialiserad på [domain].”

Röst och stil. Hur den ska låta. Specifika egenskaper, inte vaga adjektiv.

Obligatoriska beteendebegränsningar. Vad modellen ska avböja, eskalera, upplysa om eller formatera. Upprätthåll säkerhet, behörigheter och kontroller för oåterkalleliga åtgärder i applikationskod och efterföljande system i stället för att förlita dig enbart på texten.

Beteendemönster. Hur vanliga situationer hanteras: avslag, eskaleringar och osäkerhet.

Säkerhet och regelefterlevnad. Obligatoriska upplysningar, regelverk och innehållspolicyer.

Den ska INTE innehålla:

• Funktionsspecifika instruktioner, exempelvis ”gör X för säljmejl”.
• Dynamisk kontext, exempelvis användarens orderhistorik.
• Verktygsbeskrivningar – de hör hemma någon annanstans.
• Sådant som ändras ofta.

En systemprompt ska bara vara så lång som det utvärderade beteendet kräver. En kort prompt kan räcka, och en lång kan ändå sakna avgörande regler. Mät instruktionskonflikter, uppgiftskvalitet, latens och tokenkostnad i stället för att sikta på ett antal ord.

En referensmall:

Du är [name], AI-assistent för [company / context].

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

## Röst och stil
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Gör inte [anti-pattern 1]
- Gör inte [anti-pattern 2]

## Hårda begränsningar
- Gör aldrig [hard rule 1]
- Gör aldrig [hard rule 2]
- Gör alltid [hard rule 3]

## Så hanterar du osäkerhet
- Om du inte känner till ett faktum: säg det uttryckligen.
- Om användaren ber om något utanför omfattningen: erbjud det du kan hjälpa till med.
- Om begäran kan orsaka skada: avvisa och förklara varför.

## Formatkrav
- Oformaterad text som standard
- Använd Markdown för kod eller strukturerade data
- Var kortfattad; fyll inte ut svaren

Detta kan vara den stabila policybärande komponenten i promptdesignen. Bekräfta med utvärdering och telemetri att det avsedda beteendet består under funktionsinstruktioner, långa sammanhang, verktygsresultat och fientliga indata.

Lager 2: utvecklarprompten

Utvecklarprompten är funktionsspecifik. Olika funktioner har olika utvecklarprompter.

För en sammanfattningsfunktion:

Uppgift: sammanfatta dokumentet nedan.

Krav:
- 3–5 punktposter
- Varje punkt är en fullständig mening
- Fokusera på fakta och konkreta påståenden, inte intryck
- Ta med de viktigaste talen om dokumentet innehåller siffror
- Ta inte med marknadsföringsspråk eller spekulationer
- Notera om dokumentet är tvetydigt i någon viktig fråga

Format: enbart punktlista i Markdown, ingen inledning.

För en kodgranskningsfunktion:

Uppgift: granska kod-diffen nedan.

Returnera ett JSON-objekt med:
- summary: översikt av ändringen i 1–2 meningar
- concerns: lista över specifika problem (vart och ett: file, line, severity, description)
- suggestions: lista över förbättringar (vart och ett: file, line, suggestion)
- approved: booleskt värde (true om inga blockerande problem finns)

Allvarlighetsgrader:
- "blocker": måste rättas före sammanslagning
- "warning": bör åtgärdas men blockerar inte
- "nit": stilfråga, valfri

Fokusera på:
- Logikfel
- Säkerhetsproblem
- Prestandaproblem
- Saknad testtäckning
- Otydlig namngivning eller struktur

Hoppa över:
- Formatering (hanteras av formateraren)
- Subjektiva stilpreferenser

Varje funktion har en separat utvecklarprompt som lagras, versionshanteras och utvärderas för sig.

Lager 3: användarprompten

Användarlagret är dynamiskt och innehåller vanligen:

Användarens faktiska begäran. ”Sammanfatta dokumentet åt mig.”

Kontext som systemet hämtat. Dokument från RAG, kundhistorik och konversationshistorik.

Variabler per anrop. Användarnamn, tidszon, språkpreferens och kontonivå.

Lagret byggs programmatiskt vid anropet:

{conversation_history_summary}

{retrieved_context}

Användarens begäran: {user_query}

Ytterligare kontext:
- Användarnamn: {name}
- Användarens tidszon: {timezone}
- Användarnivå: {tier}

Den exakta strukturen beror på funktionen och leverantören. Håll flyktiga, användarspecifika och hämtade data utanför återanvändbara instruktionsmallar om inte API-kontraktet kräver en annan placering. Bevara proveniens och tillämpa auktorisering, minimering, avgränsning och validering oavsett var data färdas.

Malldisciplin

Sammansättning av produktionsprompter gynnas ofta av mallar. Infogad strängkonkatenering blir svårare att granska och testa när grenar, datafält och funktioner blir fler.

Ett enkelt mallsystem:

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,
)

Mer avancerat: ett mallbibliotek som Jinja2 eller Handlebars med villkor och delmallar.

{% 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 }}

Mallar håller promptstrukturen konsekvent, möjliggör villkorslogik och gör det enklare att avgränsa eller escapa användarindata. Men de stoppar inte i sig promptinjektion – behandla otillförlitlig text som data, aldrig som instruktioner.

Välj en styrd sanningskälla

Behandla produktionsprompter som versionshanterade lanseringsartefakter. Sanningskällan kan vara ett kodarkiv, ett eget register eller en egen tjänst eller en hanterad produkt med redigeringsgränssnitt. Välj efter styrnings- och driftbehov, inte utifrån idén att ett lagringsmönster passar alla team.

För kodhanterade prompter är katalogen prompts/ med en fil per prompt en tydlig utgångspunkt:

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

Varje fil kan ha egen ändringshistorik och PR-granskning medan produktionsdriftsättningar hänvisar till en känd kodversion.

Det ger:

• Synliga diffar. Granskare ser exakt vad som ändrades. När en prompt ändras finns diffen i pull requesten.
• Återställning. En trasig ändring kan återställas.
• Historik. ”När ändrade vi återbetalningspolicyn i prompten?” ”Varför finns det här stycket här?” Frågor som dessa kan besvaras med git blame.
• Verktygsstöd. Linters, validerare och utvärderingssviter integreras med filbaserade prompter.

Jämför huvudalternativen uttryckligen:

Infogade strängar fungerar för en liten prototyp men är svårare att hitta och lansera oberoende. Ett redigeringsgränssnitt kan vara lämpligt när dess behörigheter, granskning, proveniens, driftsättning och återställning uppfyller arbetsflödets riskkrav. Prompter som klistras in från chattfönster ska gå igenom samma granskning, sanering och utvärdering som alla andra kandidater.

Checka inte in produktionskonversationer, kundposter, supportärenden, interna dokument eller renderade prompter med känsliga variabler. Källkodslagret är för återanvändbara mallar, fixturer och sanerade utvärderingsexempel. Verkliga spår hör hemma i ett observerbarhetslager med lagringstid, åtkomstkontroll och maskering.

Register och tjänster för körning

När promptlanseringar behöver en annan takt än applikationsdriftsättningar eller auktoriserade redaktörer behöver ett kontrollerat gränssnitt kanske ett kodarkiv inte ger rätt arbetsflöde på egen hand. Ett register eller en tjänst kan välja en godkänd version vid körning.

Använd en databas eller tjänst som lagrar promptversioner och metadata:

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

Tjänsten bör hantera:

• Aktuella och historiska versioner av varje prompt.
• Metadata om när, av vem och varför versionen lades till.
• Utvärderingspoäng kopplade till varje version.
• Möjlighet till återställning.

Lagringsmotorn är bara en del av designen. Jämför rollbaserad åtkomst, revisionshistorik, autentiserad körningsåtkomst, befordran mellan miljöer, konsekvent driftsättning, återställning, export, kryptering, datahantering, tillgänglighet och driftkostnad. En liten databas räcker endast när de omgivande kontrollerna uppfyller kravet.

Definiera vem som får skriva utkast, granska, godkänna, lansera, återställa och läsa renderade prompter. Redigeringsåtkomst innebär inte åtkomst att lansera till produktion. Känsliga arbetsflöden kan kräva separata roller, maskerade förhandsvisningar, dubbelt godkännande eller ett gränssnitt som aldrig visar levande kunddata.

Utvärderingsstyrda ändringar

Promptändringar som kan påverka användarutfall, verktygsanvändning, datahantering, policyefterlevnad eller efterföljande beslut bör granskas och utvärderas i proportion till risken före driftsättning. Kopieredaktörsändringar med låg risk kan behöva en liten regressionsuppsättning. En prompt som kan påverka en betalning, ett konto eller ett reglerat beslut behöver starkare offlinefall, fientliga tester, godkännande och stegvis lansering. Definiera en nödväg med avgränsad utrullning, övervakning, godkännande och återställning i stället för att tyst kringgå grinden.

Flödet:

1. En teknisk eller icke-teknisk medarbetare utarbetar ändringen.
2. Ändringen körs mot utvärderingssviten.
3. Resultaten granskas tillsammans med ändringen.
4. Klarar den kraven utan regressioner och helst med förbättringar kan den godkännas.
5. Godkända ändringar driftsätts.
6. Övervakning efter driftsättning fångar sådant utvärderingarna missade.

För väsentliga prompter ska du behålla en representativ utvärderingsuppsättning och köra stabila, automatiserbara kontroller i CI när signalen är tillräckligt tillförlitlig för att grinda en ändring. Använd expert- eller mänsklig granskning när acceptanskriteriet inte kan reduceras till ett automatiserat mått. Dokumentera vad som testades, tröskelvärdet, granskaren och den kvarstående osäkerheten.

Grinden bevisar inte korrekthet. Den gör lanseringsbeslutet granskningsbart och ger teamet en baslinje för att upptäcka regressioner efter driftsättning.

Praktisk checklista inför lansering

Innan en promptversion går i drift, kräv en kort checklista:

Den länkade checklistan gör kontrollerna till en upprepningsbar lanseringsgranskning.

A/B-testning i produktion

För prompter som lämpar sig för onlineexperiment kan en stegvis jämförelse med den aktuella versionen ge verkliga signaler utöver offlineutvärderingar. Använd inte verklig trafik som första säkerhetstest och utsätt inte människor för en väsentligt mer riskfylld behandling enbart för att samla data.

Illustrativt mönster, inte en standardsplit:

• 95 procent använder produktionsprompt v3.
• 5 procent får kandidat v4.
• Håll modellåtkomst, verktygsbehörigheter och åtgärdsgränser inom den godkända produktionsgränsen.
• Mät uppgiftsframgång, säkerhets- och policyfel, användaråterkoppling, nedströmsmått och granskade utvärderingspoäng på kvalificerad trafik.
• Definiera minsta urval, stoppvillkor, ägare och återställning i ett steg före start.
• Besluta efter tillräckliga belägg om kandidaten ska utökas, revideras eller stoppas.

Leveransmekanismer är bland annat egna funktionsflaggor, driftsättningskonfiguration, ett godkänt promptregister eller egen dirigering.

Förbehåll:

• A/B-test fångar bara mätta signaler. Utan återkoppling eller konverteringsmått säger testet lite.
• Statistisk signifikans kräver volym. A/B är svårt för lågvolymsfunktioner.
• Samtidiga experiment kan samverka och försvåra attribuering. Kontrollera överlapp medvetet.
• Beakta skyldigheter kring information, samtycke, uteslutning och granskning för produkten, populationen och jurisdiktionen. Åtgärder med stora konsekvenser eller utan enkel återställning kräver vanligtvis starkare godkännande och reversibilitet än en trafiksplit kan ge.

Observerbarhet för prompter

Definiera integritetssäker telemetri för varje produktionsflöde. För anrop som påverkar väsentliga utfall ska du samla in tillräckligt av följande för att identifiera det driftsatta beteendet och återskapa fel:

• Promptmallens namn och version.
• Ersatta variabler, med tillåtna namn och maskerade värden där det behövs.
• Den renderade prompten endast när policyn tillåter; annars en maskerad, samplad eller hashad representation.
• Modellsvar, maskerade eller samplade i känsliga flöden.
• Latens, token och kostnad.
• Nedströmssignaler som återkoppling och framgångsmått.

Målet är att kunna svara på vilken version som kördes, vilka auktoriserade belägg den fick, vilka validerade utdata den skapade, vilka verktyg eller policyer som var inblandade och vad som hände efteråt. Logga inte dolt resonemang som ersättning för dessa fakta.

Lagra i databas eller observerbarhetsverktyg. Att logga allt kostar volym × token × lagring och medför integritetsrisk. Avgör per flöde vilka fält som får lagras, maskera hemligheter och personuppgifter som standard och håll lagringstiden kort om inte efterlevnad kräver längre tid. Vissa team samplar.

Fastställ granskningsintervall och urvalsmetod utifrån volym, risk, förändringstakt, incidenter och rättsliga begränsningar. Granska maskerade eller på annat sätt godkända spår, ta med kända specialfall och återför bekräftade fel till utvärderingarna. Ett veckourval kan passa ett arbetsflöde men vara olämpligt eller otillräckligt för ett annat.

Antimönster för prompter

Några mönster att undvika:

Antimönster 1: En oägd prompt för många ändamål. En stor systemprompt som blandar orelaterade funktioner, policyer, exempel och antaganden om körningen kan vara svår att granska, utvärdera och återställa. Längden i sig är inte felet. Det är den omätta komplexiteten.

Lösning: dela där det är användbart upp komponenterna efter ägarskap och ändringsgräns, ta bort dubbla eller inaktuella instruktioner och jämför den reviderade designen i representativa utvärderingar.

Antimönster 2: Infogad strängkonkatenering.

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

Skört och svårläst. Strängkonkatenering gör dessutom gränsen mellan instruktion och data svår att granska – men att flytta samma värden in i en mall oskadliggör inte skadliga instruktioner. Använd ett mallsystem.

Antimönster 3: Samma prompt för för många fall. En generell assistentprompt för e-post, kodgranskning, support och informationssökning kan dölja uppgiftsspecifika acceptanskriterier och ägarskap. Lägg funktionsspecifika utvecklarprompter ovanpå en gemensam systemprompt.

Antimönster 4: Hårdkodade prompter.

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

Prompten ligger begravd i koden, kräver driftsättning för redigering och kan inte A/B-testas eller versionshanteras separat. Extrahera till promptfil eller tjänst.

Antimönster 5: Ingen utvärderingstäckning. En funktion lanseras med en prompt som aldrig har testats systematiskt. Kvalitet bedöms på känsla och drift går inte att upptäcka. Lägg till riskproportionerlig utvärderingstäckning för de beteenden som spelar roll, inklusive fel- och eskaleringsfall.

Antimönster 6: Data i systemprompten.

Du är assistent åt Johan, en premiumkund som anslöt 2023, bor i Tallinn och har 47 öppna ärenden.

Nu ändras det återanvändbara instruktionsprefixet vid varje anrop, vilket kan minska återanvändningen av cache och göra skillnaden mellan policy och kunddata otydlig.

Lösning: bär dynamiska data i leverantörens mekanism för körningsindata eller kontext, med proveniens, auktorisering och minimering. Härled inte tillit från dess meddelanderoll.

Antimönster 7: Instruktioner begravda i mitten.

Hjälp användaren. Var artig. Formatera utdata som JSON. Använd inte Markdown. Användaren frågar om priser, så var försiktig med siffror. Svaret ska vara 1–2 meningar. Hjälp nu användaren.

Kritiska krav blir svårare för en granskare att hitta och kan stå i konflikt med närliggande text.

Lösning: samla kritiska instruktioner i ett tydligt märkt block, ange varje regel en gång och testa om den valda modellen följer dem i representativa långa och fientliga kontexter.

Specifika mönster för vanliga funktioner

Några funktionsspecifika mönster:

Klassificering

Uppgift: klassificera texten i en av kategorierna:
- billing: betalning, återbetalning, abonnemang
- technical: fel, avbrott, integrationsproblem
- account: inloggning, lösenord, profiländringar
- feature_request: önskemål om ny funktionalitet
- complaint: allmänt missnöje utan specifikt åtgärdsbart problem

Returnera ett JSON-objekt: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Text att klassificera:
{text}

Mönster: uppräknade kategorier med definitioner, strukturerade utdata, tilltro och motivering.

Extraktion

Uppgift: extrahera strukturerade data ur dokumentet.

Schema:
- vendor_name: företaget som utfärdade fakturan
- invoice_number: som det står i dokumentet
- date: formatet ISO 8601
- line_items: lista av {description, quantity, unit_price, total}
- subtotal, tax, total: tal

Regler:
- Använd null om fältet saknas
- Tal ska vara numeriska, inte strängar
- Sätt "needs_review": true och förklara vid tvetydighet

Dokument:
{document}

Mönster: explicit schema, typkrav, hantering av saknade data och eskalering vid tvetydighet.

Generering med stil

Uppgift: skriv en {format} om {topic}, riktad till {audience}.

Stil:
- {Specifik stilegenskap 1}
- {Specifik stilegenskap 2}
- Undvik: {antimönster 1}, {antimönster 2}

Begränsningar:
- Längd: {N} ord
- Ta med: {required elements}
- Uteslut: {forbidden elements}

Röstreferens:
[Provide a sample of the desired voice]

Utdata: endast {format}, utan inledning eller eftertext.

Mönster: specifika stilegenskaper, explicita begränsningar och röst förankrad i ett referensexempel.

Agentloop

Du har tillgång till följande verktyg:
{tool_descriptions}

För varje tur:
1. Tänk igenom vad som behöver göras.
2. Avgör om ett verktyg behövs. Anropa det i så fall.
3. Avgör efter resultatet om fler verktyg behövs eller om du kan svara.
4. Ge slutsvaret när du har tillräcklig information.

Begränsningar:
- Högst 5 verktygsanrop per begäran.
- Förklara vad som saknas om du inte kan slutföra efter 5 anrop.
- Hitta aldrig på verktygsnamn eller argument.
- Verifiera verktygsresultat före åtgärd.

Användarens begäran:
{user_query}

Mönster: en stegvis procedur för verktygsanvändning, en verktygsbudget, uttrycklig validering och avgränsad felhantering.

Teamaspekten

Produktionsprompter involverar vanligen flera roller:

• Ingenjörer kopplar in prompterna, underhåller mallar och hanterar driftsättning.
• Produkt definierar vad prompterna ska uppnå.
• Innehåll/marknad äger röst- och stilriktlinjer.
• Domänexperter vet vad som är korrekt i specifika fall, som juridiskt språk och medicinska termer.

Använd promptgranskning likt kodgranskning med rätt granskare per domän. Röständringar granskas av innehåll, logik av teknik och domäninnehåll av experten.

Känsliga juridiska, medicinska eller finansiella fall kan kräva formell granskning och attest. Bygg processen därefter.

En stegvis mognadsplan för prompter med kontrollpunkter

För team som går från ”prompter är kodsträngar” till ”prompter är hanterad infrastruktur”:

Steg 1: Grund.

• Inventera de prompter och den kod som bygger prompter och som påtagligt påverkar beteendet.
• Definiera modellen för instruktionsauktoritet, gränsen för körningsdata, ägarna och mappningen till leverantören.
• Välj en styrd sanningskälla och en mallmetod som passar lanseringsflödet.
• Inför integritetssäker telemetri som identifierar den driftsatta versionen och utfallet utan att lagra onödigt känsligt innehåll.

Steg 2: Utvärdering.

• Bygg först utvärderingssviter för de prompter som har högst risk och högst volym.
• Kör representativa utvärderingar vid väsentliga promptändringar, med domängranskning där den behövs.
• Lägg stabila automatiska kontroller i CI och gör icke-automatiserbara acceptansbeslut synliga i granskningsdokumentationen.

Steg 3: Drift.

• Implementera promptversionering i det valda kodarkivet, registret eller tjänsten.
• Lägg till en stegvis utrullning och stoppmekanism. Använd A/B-test endast där arbetsflödet lämpar sig för det.
• Bygg övervakning för de signaler om kvalitet, säkerhet, policy, latens, kostnad och nedströmsutfall som arbetsflödet kräver.
• Inför en granskningsprocess för promptändringar.

Lova inte det här utfallet efter en kalender. Lämna sekvensen först när tester visar att alla prompter är kartlagda, att kritiska ändringar är versionshanterade och grindade, att återställning fungerar, att telemetrin visar vilken version som är driftsatt och att ägarna kan öva en incidenthantering.

Prompter som infrastruktur

Produktionsprompter kan lagras som strängar, men de fungerar som versionshanterade systemkomponenter med omgivande kontroller för sammansättning, utvärdering, lansering, åtkomst och observerbarhet.

En instruktionshierarki definierar auktoritet. Den säkrar inte körningsdata eller verktygsåtgärder. Mallar kan minska sammansättningsfel men förhindrar inte promptinjektion. En styrd sanningskälla ger versionshistorik. Riskproportionerliga utvärderingar informerar lanseringsbeslut, och telemetri testar om det avsedda beteendet består utanför utvärderingsuppsättningen.

Hur mycket stringens som krävs beror på risk och omfattning, men varje kontroll du utelämnar behöver ett dokumenterat skäl. Påståenden du publicerar bör kunna visa den versionshantering, utvärdering, utrullning, återställning och telemetri som faktiskt är på plats.

Avsedd styrbarhet är en hypotes tills utvärderingar och produktionstelemetri visar att den valda modellen, promptversionen, datavägen, verktygen och policyerna beter sig inom acceptanströsklarna. Bevara underlaget med lanseringen, undersök fel per version och håll återställningen användbar.

Börja med den minsta arkitektur som gör ägarskap, auktoritet, datahantering, utvärdering, driftsättning, återställning och belägg uttryckliga.