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

I en prototyp är en prompt en sträng du skrev en eftermiddag. I produktion faller det arbetssättet sönder ungefär under den första månaden.

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.

Ett produktionssystem för prompter hanterar allt detta. Det handlar inte om att ”skriva en sträng”, utan om en arkitektur.

Artikeln beskriver arkitekturen: de tre lagren, malldisciplinen, versionskontrollen, utvärderingen och de operativa arbetssätt som förvandlar prompter från artefakter till infrastruktur.

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.

De tre lagren

Produktionsprompter har tre skilda lager med olika ansvarsområden:

Systemlager. Stabilt beteende, identitet och begränsningar. Ändras sällan. Ägs av teamet som utformar AI-beteendet.

Utvecklarlager. Funktionsspecifika instruktioner, verktygsbeskrivningar och krav på utdataformat. Ändras när funktionerna ändras. Ägs av funktionsteamet.

Användarlager. Användarens specifika begäran samt dynamisk kontext – användardata, konversationshistorik och hämtad kunskap. Skiljer sig för varje anrop.

Att blanda lagren är det vanligaste produktionsfelet. Systemprompten växer till 5 000 ord med identitet, funktionsinstruktioner och dynamisk kontext, och då bryter en ändring andra delar.

Separationen är grundläggande:

┌─────────────────────────────────────┐
│ Systemprompt (stabil)               │  Identitet, beteende, hårda begränsningar
├─────────────────────────────────────┤
│ Utvecklarprompt (per funktion)      │  Funktionsinstruktioner, verktyg, format
├─────────────────────────────────────┤
│ Användarprompt (per anrop)          │  Fråga, kontext, konversation
└─────────────────────────────────────┘

Modell-API:erna stöder uttryckligen detta:

• OpenAI: rollerna system, developer, user.
• Anthropic: system, därefter messages med rollerna user och assistant. Verktygsbeskrivningar är en separat parameter.
• Gemini: systemInstruction, därefter contents med roller.

Använd uppdelningen medvetet.

Lager 1: systemprompten

Systemprompten definierar vem AI:n är och hur den beter sig. Den ändras sällan.

En bra systemprompt omfattar:

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

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

Hårda begränsningar. Sådant den aldrig får göra: producera visst innehåll, fatta vissa beslut eller ignorera vissa instruktioner.

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 bra systemprompt är 300–1 000 ord. Längre blir svårhanterligt, kortare underspecificerar beteendet.

En fungerande mall:

Du är [namn], AI-assistent för [företag/kontext].

## Din roll
[2–3 meningar om vad du gör]

## Röst och stil
- [Specifik egenskap 1]
- [Specifik egenskap 2]
- [Specifik egenskap 3]
- Gör inte [antimönster 1]
- Gör inte [antimönster 2]

## Hårda begränsningar
- Gör aldrig [hård regel 1]
- Gör aldrig [hård regel 2]
- Gör alltid [hård regel 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 är ryggraden som varje interaktion passerar. Ändringar är avsiktliga och sällsynta.

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}

Strukturen beror på funktionen. Principen är att data hör hemma här, inte i system- eller utvecklarprompten.

Malldisciplin

Produktionsprompter byggs av mallar. Infogad strängkonkatenering är prototypmetoden och skalar inte.

Ett enkelt mallsystem:

from string import Template

SUMMARIZE_TEMPLATE = Template("""
$conversation_summary

Dokument att sammanfatta:
$document

Användarens specifika instruktioner: $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" %}
Du har tillgång till avancerade analysfunktioner.
{% endif %}

{% if retrieved_context %}
Relevant kontext från din kunskapsbas:
{{ retrieved_context }}
{% endif %}

Användarens begäran: {{ user_query }}

Mallar förebygger promptinjektion via variabler när användarindata escapas där det behövs, möjliggör villkorslogik och håller strukturen konsekvent.

Versionskontroll

Prompter är kod. Lagra dem i versionskontroll.

Ett fungerande mönster är katalogen prompts/ med en fil per prompt:

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

Varje prompt har egen ändringshistorik, granskas i PR och produktionen refererar specifika versioner.

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.

Undvik strängar inbäddade i kod, prompter som endast lagras i ett gränssnittsverktyg och prompter inklistrade från chattfönster. De är svåra att hitta, jämföra, spåra och testa (versionshanteringen är verktygets, inte din).

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.

Prompt som data: extern lagring

För ofta ändrade prompter – A/B-test, kundnivåvarianter och lokalspecifika prompter – är filbaserad versionskontroll för långsam.

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 hanterar:

• 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.

Verktyg: PromptLayer, Helicone eller ett eget system. För de flesta team räcker ett enkelt internt databasschema.

Gränssnittet är avgörande. Både tekniska och icke-tekniska roller inom produkt och innehåll ska kunna redigera prompter, men ändringar måste granskas och klara utvärderingar före produktionssättning.

Utvärderingsstyrda ändringar

Varje promptändring utvärderas före driftsättning. För seriösa produktionssystem är detta inte förhandlingsbart.

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.

I praktiken har varje prompt en utvärderingssvit som körs i CI vid promptändringar. Utan grinden bryter ändringar saker oförutsägbart. Med den kan teamet arbeta snabbt och tryggt.

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

Att jämföra nya prompter med befintlig version på en liten del av produktionstrafiken ger verkliga signaler utöver utvärderingarna:

• 95 procent använder produktionsprompt v3.
• 5 procent får kandidat v4.
• Mät användaråterkoppling, nedströmsmått och utvärderingspoäng på verklig trafik.
• Besluta efter tillräckligt med data om v4 ska gå till 100 procent eller v3 behållas.

Verktyg: funktionsflaggor som LaunchDarkly eller egna, promptversionstjänster som PromptLayer och 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.
• Kör inte för många test samtidigt; interaktionerna blir svårtolkade.

Observerbarhet för prompter

Varje LLM-anrop i produktion bör logga:

• 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.

Utan dessa data gissar du när frågan är ”varför gav modellen just den användaren ett märkligt svar?”.

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.

Granska varje vecka ett urval av verkliga produktionsprompter och svar. Det fångar sådant utvärderingarna missar.

Antimönster för prompter

Några mönster att undvika:

Antimönster 1: Megaprompten. En systemprompt på 10 000 ord för alla situationer är svår att ändra och felsöka och senare instruktioner ignoreras ofta. Dela upp i lager och fokuserade prompter, en per funktion.

Antimönster 2: Infogad strängkonkatenering.

prompt = "Du är hjälpsam. " + (
    "Användaren är betalande kund. " if user.tier == "paid" else ""
) + f"Användaren heter {user.name}. " + ...

Skört, svårläst och injektionskänsligt. 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 forskning optimerar inget. Lägg funktionsspecifika utvecklarprompter ovanpå en gemensam systemprompt.

Antimönster 4: Hårdkodade prompter.

response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "Du är en hjälpsam assistent..."},
        {"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. Varje prompt behöver en utvärderingssvit.

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 systemprompten per anrop, cachelagring bryts och förvirring uppstår. Dynamiska data hör hemma i användar-/kontextlagret.

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.

Viktiga instruktioner försvinner. Strukturera med tydliga avsnitt och placera kritiska instruktioner i början och slutet; närhetseffekten hjälper.

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": "<ett av värdena ovan>", "confidence": "<high|medium|low>", "reasoning": "<1 mening>"}

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:
[Ge ett exempel på önskad röst]

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: explicita resonemangssteg, verktygsbudget, skydd mot hallucinationer och reflektion.

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 90-dagarsplan för promptmognad

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

Dag 1–30: Grund.

• Extrahera alla prompter till särskilda filer i versionskontroll.
• Inför tre lager: system, utvecklare och användare.
• Bygg ett enkelt mallager.
• Inför grundläggande loggning av prompter och svar.

Dag 31–60: Utvärdering.

• Bygg utvärderingssviter för de fem viktigaste prompterna.
• Kör utvärderingar vid ändringar, först manuellt.
• Integrera automatisk körning i CI för PR:er.

Dag 61–90: Drift.

• Implementera promptversionering i databas eller tjänst.
• Lägg till A/B-test för minst en kritisk prompt.
• Bygg instrumentpaneler för produktionskvalitet.
• Inför en granskningsprocess för promptändringar.

Efter 90 dagar är prompterna hanterad infrastruktur. Ändringar är avsiktliga, testbara, granskningsbara och återställningsbara. Kvalitet kan mätas och drift upptäckas.

Prompter som infrastruktur

Produktionsprompter är inte strängar. De är ett skiktat system med disciplin kring versionering, mallar, utvärdering och observerbarhet.

Trelagersarkitekturen separerar ansvarsområden och håller prompterna underhållbara. Mallar minskar skörhet. Versionskontroll eller en prompttjänst ger historik. Utvärderingar styr ändringar. Observerbarhet fångar resten.

Det är inte valfritt i seriöst produktionsarbete. Team som hoppar över stegen får promptkaos: spridda strängar, okänd produktionsversion, omätt kvalitet och ständiga oförklarliga beteendeförändringar.

Team som investerar får ett AI-beteende som kan styras, mätas och förbättras. Det skiljer en funktion som åldras väl från teknisk skuld.

Börja med arkitekturen. Allt annat blir enklare.