7 System Prompt Voorbeelden voor Productie-apps (2026 Copy-Paste Templates)

De beste system prompt voorbeelden zijn niet de "you are a helpful assistant"-oneliners uit tutorials. Het zijn de specifieke instructieblokken die voorkomen dat een productie-app om 2 uur 's nachts ontspoort. In onze eigen contentpipeline draaien we meer dan een dozijn Claude-subagents, elk aangestuurd door een system prompt die we telkens hebben herschreven nadat hij een bug veroorzaakte op Claude Opus 4.8 of GPT-5. Deze post slaat de speelgoeddemo's over. Je krijgt 7 echte, kant-en-klare system prompts, twee daarvan rechtstreeks uit die productiestack, plus de 6-blokken-anatomie die onder elke betrouwbare prompt zit.

Belangrijkste Inzichten

• Een system prompt is een set permanente instructies (rol, beperkingen, outputformaat, guardrails) die je één keer instelt, vóór elk gebruikersbericht.
• Is de content identiek bij 1.000 requests? Zet het in de system prompt; content die per request verschilt hoort in de user turn.
• Zes blokken vormen een betrouwbare prompt: rol, context, beperkingen, outputformaat, guardrails, voorbeelden.
• Reasoning-modellen (o-serie, GPT-5, Claude Opus 4.5+) willen doelen op hoog niveau, geen agressieve "je MOET"-formuleringen.

Wat Zit Er in een System Prompt? De 6 Bouwstenen

Een system prompt is een set permanente instructies die de rol, het gedrag, de beperkingen en het outputformaat van een model voor een hele sessie vastleggen, ingesteld één keer vóór elk gebruikersbericht. De betrouwbare exemplaren delen zes bouwstenen: rol, context, beperkingen, outputformaat, guardrails en optioneel voorbeelden. Zet die op orde en je hebt de korte versie van hoe je een system prompt schrijft die het in productie overleeft.

Dit doet elk blok.

Het rol-blok is belangrijker dan het lijkt. Anthropic's documentatie zegt het ronduit: een rol instellen in de system prompt stuurt het gedrag en de toon van het model, en "zelfs één enkele zin maakt al verschil". Voor het guardrails-blok verdienen weigerings- en veiligheidsregels serieuze aandacht; daar gaan we dieper op in in onze guardrails-gids. En als je met Claude werkt, raadt Anthropic XML-tags aan (<instructions>, <context>, <input>) om elk type content te scheiden zodat het model ze niet door elkaar haalt.

Hier is een kant-en-klaar skelet dat alle zes blokken samenvoegt in één template:

# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.

# CONTEXT
{Stable facts the model needs on every request.}

# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.

# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}

# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.

# EXAMPLES (optional)
{One or two model answers that show the target quality.}

Zes blokken maken van een gevoel een specificatie. Dit is alleen de system-prompt-laag. Voor de bredere technieken (few-shot, chain-of-thought, prompt chaining) verwijzen we naar onze prompt engineering-gids, en die technieken horen niet thuis in de system prompt zelf. Een system prompt voor één sessie verschilt ook van een repo-breed bestand met permanente project-instructies zoals een CLAUDE.md, dat een hele codebase aanstuurt in plaats van één API-sessie.

7 System Prompt Voorbeelden voor Productie (Kant-en-klaar)

Hier zijn 7 system prompt voorbeelden die je vandaag nog in je system-parameter of developer-bericht kunt plakken. Elk voorbeeld richt zich op een echte taak (agent, RAG, support, coding, JSON, content-QA, vertaling) en laat zien waarom de kernblokken erin staan. De laatste twee draaien in onze eigen pipeline. De repo's die Cursor- en Devin-prompts lekken bewijzen de vraag; wat niemand levert is de annotatie die uitlegt waarom elk blok er staat.

1. Autonome Agent

Bepaal de rol nauw, leg de tool-regels expliciet vast en geef een stopconditie mee zodat hij niet eindeloos kan blijven loopen.

You are a research agent. Your only job is to answer the user's
question using the provided tools.

TOOLS: web_search, read_url, calculator.

RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.

STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
  human and explain why.

Waarom het werkt: de nauwe rol plus een expliciete stopconditie maken het verschil tussen een agent die klaar is en een agent die tokens verbrandt in een loop. Dit is de kern van goede agent system prompt best practices.

2. RAG / Retrieval Q&A

Bij retrieval draait alles om het model tegenhouden om te antwoorden vanuit zijn eigen geheugen. Eén regel doet het werk.

You answer questions using ONLY the context provided below.

CONTEXT
{retrieved_chunks}

RULES
- If the answer is not in the context, say: "I don't have that
  in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].

OUTPUT
Two to four sentences, plain text, with citations.

Waarom het werkt: "alleen vanuit context" plus een citatieformaat is de goedkoopste hallucinatie-vergrendeling die je voor een RAG system prompt kunt schrijven.

3. Klantenservice Bot

Toon, een escalatiepad en een harde geldregel houden een support bot behulpzaam zonder dat hij dingen belooft die hij niet waar kan maken.

You are a support agent for Northwind's billing team. Be warm,
brief, and factual.

CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.

CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.

GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
  human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.

Waarom het werkt: de refund-guardrail en de escalatie-terugval stoppen de twee faalmodi waardoor support bots uit productie worden gehaald.

4. Coding Assistant

Beperk het outputformaat en de versies, en laat hem uitleggen vóórdat hij bewerkt.

You are a coding assistant for a Next.js 15 + TypeScript codebase.

RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.

If a request is ambiguous, ask one clarifying question before editing.

Waarom het werkt: "diff, geen volledige bestanden" plus een versieplafond houdt de assistent binnen jouw stack. Promptontwerp voor coding agents is een onderwerp op zich, dus houden we dit voorbeeld compact.

5. Gestructureerde Data / JSON-Extractie

Zet het schema in het outputformaat-blok en verbied lopende tekst. Dat is het patroon voor betrouwbare structured outputs.

You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.

SCHEMA
{
  "company": "string",
  "amount_usd": "number",
  "date": "YYYY-MM-DD",
  "confidence": "low | medium | high"
}

RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.

Waarom het werkt: een letterlijk schema plus "alleen geldige JSON" wint altijd van een beschreven formaat. Voor handhavingspatronen die verder gaan dan de prompt (JSON schema-validatie, tool-based extractie), zie onze structured outputs-gids.

6. Content-QA / Validator Agent (uit onze productiepipeline)

Deze draait in onze eigen stack. De system prompt van onze validator is een voorbeeld van negatieve beperkingen: hij vertelt het model precies wat het NIET mag schrijven, waarna een script de regels letterlijk controleert.

You are a content QA agent. You check one blog draft against a
fixed style contract.

BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"

FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
  per 500 words of body.

ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
  exits non-zero on any hit. If it fails, the post does not publish.

Waarom het werkt: een opgesomde verbodslijst plus een grep is afdwingbaar op een manier waarop "vermijd buzzwoorden" dat nooit is. Het model kan discussiëren met een gevoel; het kan niet discussiëren met een non-zero exit code.

7. Vertaalagent (uit onze productiepipeline)

Ook van ons. De prompt van de vertaler is een outputformaat- en volledigheidscontract met een zelfcontrole die het model op zijn eigen output uitvoert.

You are an expert translator. You translate ONE blog post into ONE
target language.

COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.

DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
  "karşılaştırma" (Turkish), or "developpement" instead of
  "développement" (French), the translation is WRONG. Re-do it.

If you cannot meet the contract, report the problem. Do not ship a
truncated post.

Waarom het werkt: een volledigheidscontract plus een concreet fout-voorbeeld vangt de stille fouten die een vage regel als "vertaal accuraat" doorlaat.

Wat We Hebben Geleerd van System Prompts in Productie

Drie system-prompt-bugs in onze eigen pipeline leerden ons meer dan welke documentatiepagina dan ook. Alle drie kwamen ze voort uit instructies die prima klonken maar niet specifiek of verifieerbaar waren. Hier is wat er misging bij onze 16+ Claude-subagents, en de exacte fix die telkens bleef plakken. Het patroon is elke keer hetzelfde: zachte regels worden genegeerd, specifieke en extern gecontroleerde regels blijven staan.

De verboden-woorden-bug. Weken lang bleef het model leverage en robust terugsluipen in concepten, hoe vriendelijk we het ook vroegen. Een zachte "vermijd buzzwoorden"-regel deed niets. De fix was Voorbeeld #6: een opgesomde verbodslijst in de prompt plus een script dat de output grept en non-zero teruggeeft bij elke treffer, met bovenop een em-dash-limiet van 3 per 1.000 woorden. De les: vage beperkingen worden genegeerd; opgesomde, extern gecontroleerde beperkingen blijven staan.

De diakritische-tekens-bug. Onze vertaler produceerde stilletjes ASCII bij Turks, Frans en Spaans. karşılaştırma kwam eruit als karsilastirma, en niemand merkte het tot een native lezer het aankaartte. De fix was een tabel met native karakters in de prompt, een expliciet fout-voorbeeld en een grep na elke run (nul native karakters betekent opnieuw vertalen). De les: geef het model een concreet voorbeeld van de fout, niet alleen een regel.

De stabiele-ID-bug. Dit is de dure. Een system prompt die bij elke hervertaling een nieuwe gelokaliseerde slug afleidde, liet de publisher een tweede live document per post aanmaken. We publiceerden 54 dubbele live documenten op 2026-06-13 en haalden ze pas op 2026-07-05 offline, drie weken gesplitste linkwaarde en duplicate-content-meldingen. De fix: pin de identiteit expliciet en hergebruik de bestaande ID letterlijk. Een system prompt die zijn eigen identifiers niet-deterministisch regenereert, levert duplicaten op; die van ons zette 54 live documenten neer voordat we de ID vastpinden.

Wat Zijn de Meest Voorkomende System Prompt Fouten?

De meest voorkomende system prompt-fouten zijn muur-van-tekst-instructies, tegenstrijdige regels, alleen-negatieve formuleringen, per-request context in een statische prompt dumpen, en een fallback overslaan. Bij 2026-modellen is er een nieuwe: agressief hoofdlettergebruik en "je MOET"-taal triggert nu te veel bij Claude Opus 4.5+.

Hier is de snelle fixlijst:

• Muur van tekst. Fix: splits het op in de zes blokken en zet stabiele content vooraan.
• Tegenstrijdige instructies. Fix: één regel per lijn; los conflicten op vóór je live gaat.
• Alleen-negatieve formuleringen. Fix: zeg wat wél moet, niet alleen wat je moet vermijden.
• Hoofdletters en "MOET"-overload. Bij Anthropics nieuwere modellen werkt dit averechts. Hun documentatie zegt nu dat waar je vroeger schreef "KRITIEK: Je MOET deze tool gebruiken", je nu normale taal kunt gebruiken zoals "Gebruik deze tool wanneer." Het advies van 2025 is nu de fout.
• Dynamische context in een statische prompt. Houd per-request data in de user turn. Wat waar hoort is een discipline op zich; onze context engineering-gids behandelt het.
• Geen fallback. Definieer altijd een weigering en een escalatiepad.
• Lengte en kosten negeren. Langere prompts voegen latency en tokenkosten toe bij elke call; snoei tot wat zijn plek verdient.

Voor de basale instructie-helderheid is OpenAI's best-practices-artikel nog altijd een solide checklist.

Hoe Test en Itereer Je op een System Prompt?

Test een system prompt zoals je code test. Bouw een kleine golden set van inputs met verwachte outputs, en assert het antwoord van het model daar telkens tegen bij elke wijziging. A/B-test twee promptversies op dezelfde inputs en houd de versie aan die meer checks doorstaat. Assertions verslaan oogballen elke keer.

Een minimale eval loop ziet er zo uit:

# pseudo eval loop
for case in golden_set:
    out = model(system=PROMPT, user=case.input)
    assert is_valid_json(out)              # format check
    assert case.expected_field in out      # content check
    if case.no_context:
        assert "I don't have that" in out  # refusal check
# ship the prompt version that passes the most cases

De grep in Voorbeeld #6 is de goedkoopste assertion die je kunt draaien: hij kost niets en wordt nooit moe. Zodra je promptbibliotheek voorbij een handjevol groeit, versioneer en test je prompts met echte prompt management tools in plaats van tussen bestanden te knippen en plakken. Het punt blijft hetzelfde op elke schaal: verander nooit een productieprompt zonder een check die je vertelt of je hem beter of slechter hebt gemaakt.

System Prompt vs User Prompt vs Developer Message

Een system prompt bepaalt vast gedrag; een user prompt draagt de taak per request; een developer message is de reasoning-model-rol van OpenAI die app-niveau-instructies bevat, hoger gerangschikt dan user messages in de commandoketen. Anthropic gebruikt een top-level system-parameter in plaats van een role: "system"-bericht. Hier is de driedeling die concurrenten meestal missen.

OpenAI is expliciet over de rangschikking: "developer messages zijn instructies van de applicatieontwikkelaar, met prioriteit boven user messages". Als een gebruiker dus probeert je app-regels te overschrijven, wint de developer message de commandoketen.

Hebben Reasoning-Modellen Andere System Prompts Nodig? (2026)

Ja. Reasoning-modellen zoals OpenAI's o-serie, GPT-5 en Claude Opus 4.5+ willen doelen op hoog niveau, geen stap-voor-stap-scripts. OpenAI vergelijkt een reasoning-model met een senior collega die je de details toevertrouwt, tegenover een GPT-model dat zich gedraagt als een junior die expliciete instructies nodig heeft.

Dat kader verandert hoe je de prompt schrijft. Bij een reasoning-model noem je het doel en de beperkingen en "vertrouw je erop dat het de details uitwerkt"; bij een GPT-model leg je de stappen uit. Een reasoning-model te veel detail geven maakt het vaak slechter, niet beter.

Aan de Claude-kant speelt een eigen verschuiving in 2026. Omdat Opus 4.5+ gevoeliger reageert op de system prompt, triggert de oude gewoonte om CRITICAL: en MUST te stapelen nu te veel. Draai die taal terug naar normale formuleringen. Eén kostennotitie: zet je stabiele, herbruikte content aan het begin van de prompt zodat prompt caching kan aanslaan en latency verlaagt bij herhaalde calls. En als je reasoning-model stap-voor-stap werkt, is chain-of-thought prompting een onderwerp op zich met een eigen gids, dus dat leren we hier niet opnieuw aan.

Hoe Techsy Dit Aanpakt

Bij Techsy bouwen we agent-systemen voor B2B-klanten, en de validator- en vertaler-prompts hierboven draaien in die productiestack. We behandelen elke system prompt als code: versioneren, testen tegen een golden set, en de niet-onderhandelbare regels afdwingen met een script in plaats van hoop. Wil je een LLM-feature van demo naar productie brengen en heb je een hand nodig bij AI-integratie, vraag dan een gratis consult aan.

Veelgestelde Vragen

Wat is een system prompt?

Een system prompt is een set permanente instructies, één keer ingesteld vóór elk gebruikersbericht, die de rol, het gedrag, de beperkingen en het outputformaat van het model voor de hele sessie vastleggen. Het is de vaste "hoe het zich gedraagt"-laag, en die blijft identiek terwijl de per-request berichten van de gebruiker elke beurt veranderen.

Wat is het verschil tussen een system prompt en een user prompt?

De system prompt is het vaste "hoe het zich gedraagt", identiek bij elk request; de user prompt is het per-request "wat te doen". Een simpele vuistregel: is de content identiek bij 1.000 requests, dan hoort het in de system prompt, en alles wat per call verandert gaat in de user turn.

Wat is een developer message versus een system prompt?

OpenAI's reasoning-modellen (o-serie, GPT-5) gebruiken een developer-bericht in plaats van een system-bericht. Dat bevat app-niveau-instructies die hoger staan dan user messages in de commandoketen, dus wint het als een gebruiker probeert je regels te overschrijven. Anthropic houdt één top-level system-parameter aan in plaats van een rol-gebaseerd bericht.

Hoe lang moet een system prompt zijn?

Zo kort mogelijk, zolang rol, beperkingen, outputformaat en guardrails maar gedekt blijven. Te lange prompts voegen tokenkosten en latency toe bij elke call en kunnen extra reasoning triggeren bij Claude Opus 4.5+. Moet een stabiele prompt toch lang zijn, zet dan herbruikte content vooraan zodat prompt caching de kosten compenseert.

Werken system prompts hetzelfde in ChatGPT/GPT en Claude?

Zelfde concept, andere mechaniek. OpenAI gebruikt een system- of developer-rol binnen de messages-array, terwijl Anthropic een aparte top-level system-parameter gebruikt en de voorkeur geeft aan XML-tags om instructies, context en voorbeelden te scheiden. De instructies zijn overdraagbaar tussen providers; de bekabeling en de opmaakconventies niet.

Kun je de system prompt tijdens een gesprek veranderen?

Via de API stuur je bij elke call de volledige messages-payload opnieuw, dus je kunt technisch gezien de system prompt tussen beurten verwisselen. Maar hem tijdens een gesprek veranderen kan de continuïteit breken en het model in de war brengen over zijn eigen regels. Stel hem liever één keer in, of wissel bewust voor een aparte taakspecifieke prompt.

Moet ik XML-tags of markdown gebruiken in een system prompt?

Anthropic raadt XML-tags aan voor Claude om instructies, context en voorbeelden te scheiden zodat het model ze niet door elkaar haalt. OpenAI-modellen gaan goed om met markdown en gewone kopjes. Sluit aan bij de conventie van de provider in plaats van één stijl op beide te forceren, en houd wat je kiest consistent binnen één prompt.

Hebben reasoning-modellen andere system prompts nodig?

Ja. Reasoning-modellen willen doelen op hoog niveau, alsof je een senior collega briefte, geen stap-voor-stap-micromanagement. Laat de agressieve HOOFDLETTERS en "je MOET"-taal vallen die nieuwere modellen zoals Claude Opus 4.5+ te veel triggert, benoem het doel en de guardrails, en laat het model zelf het pad ernaartoe plannen.

Wat zijn de onderdelen van een goede system prompt?

Zes blokken: rol, context, beperkingen, outputformaat, guardrails of fallbacks, en optioneel een paar voorbeelden. Rol en beperkingen doen het meeste werk; het outputformaat-blok maakt antwoorden parseerbaar; guardrails bepalen wat er aan de randen gebeurt. Voorbeelden zijn het pas waard om toe te voegen als de gewenste kwaliteit moeilijk in woorden te vatten is.