7 exemple de system prompt pentru aplicații în producție (Șabloane copy-paste 2026)

Cele mai bune exemple de system prompt nu sunt frazele de tipul „ești un asistent util” din tutoriale. Ele sunt blocurile specifice de instrucțiuni care împiedică o aplicație din producție să o ia razna la 2 noaptea. În propria noastră pipeline de conținut, rulăm peste o duzină de subagenți Claude, fiecare ghidat de un system prompt pe care l-am rescris în mod repetat după ce a livrat un bug pe Claude Opus 4.8 sau GPT-5. Acest articol omit demo-urile de joacă. Vei primi 7 system prompt-uri reale, gata de copy-paste, două dintre ele extrase direct din stiva noastră de producție, plus anatomia în 6 blocuri care stă la baza fiecărui prompt fiabil.

Principalele concluzii

• Un system prompt reprezintă instrucțiuni persistente (rol, constrângeri, format de ieșire, garde) stabilite o singură dată, înainte de orice mesaj al utilizatorului.
• Dacă conținutul este identic pentru 1.000 de cereri, pune-l în system prompt; conținutul specific fiecărei cereri merge în turul utilizatorului.
• Șase blocuri construiesc un prompt fiabil: rol, context, constrângeri, format de ieșire, garde și exemple.
• Modelele de raționament (seria o, GPT-5, Claude Opus 4.5+) doresc obiective de nivel înalt, nu formulări agresive de tipul „TREBUIE neapărat”.

Ce intră într-un System Prompt? Cele 6 blocuri constitutive

Un system prompt este un set de instrucțiuni persistente care definesc rolul, comportamentul, constrângerile și formatul de ieșire al modelului pentru întreaga sesiune, fiind stabilit o singură dată înainte de orice mesaj al utilizatorului. Cele fiabile împărtășesc șase blocuri constitutive: rol, context, constrângeri, format de ieșire, garde și exemple optionale. Pune-le în ordine și ai varianta scurtă a modului de a scrie un system prompt care rezistă în producție.

Iată ce face fiecare bloc.

Blocul de rol contează mai mult decât pare. Documentația Anthropic o spune clar: stabilirea unui rol în system prompt focalizează comportamentul și tonul modelului, iar „chiar și o singură propoziție face diferența”. Pentru blocul de garde, regulile de refuz și siguranță merită o gândire atentă; aprofundăm aceste aspecte în ghidul nostru despre garde. Și dacă configurezi Claude, Anthropic recomandă etichete XML (<instructions>, <context>, <input>) pentru a separa fiecare tip de conținut, astfel încât modelul să nu le amestece.

Iată un schelet gata de lipit care îmbină toate cele șase blocuri într-un singur șablon:

# 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.}

Șase blocuri transformă o impresie vagă într-o specificație. Aceasta este doar stratul system-prompt. Pentru tehnicile mai largi (few-shot, chain-of-thought, înlănțuirea prompturilor), consultă ghidul nostru de inginerie prompt și ține-le departe de system prompt-ul propriu-zis. Un system prompt de sesiune este diferit de un fișier la nivel de repo cu instrucțiuni persistente la nivel de proiect, cum ar fi un CLAUDE.md, care guvernează întreaga bază de cod, nu o singură sesiune API.

7 exemple de System Prompt pentru Producție (Gata de Copy-Paste)

Iată 7 exemple de system prompt pe care le poți lipi în parametrul tău system sau în mesajul developer chiar astăzi. Fiecare vizează o sarcină reală (agent, RAG, suport, coding, JSON, QA conținut, traducere) și fiecare arată de ce există blocurile sale cheie. Ultimele două rulează în propria noastră pipeline. Repository-urile care scurg prompturi Cursor și Devin dovedesc cererea; ceea ce nimeni nu livrează este adnotarea care explică de ce fiecare bloc este acolo.

1. Agent Autonom

Delimitează rolul strict, enunță regulile pentru instrumente și oferă o condiție de oprire ca să nu intre în buclă infinită.

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.

De ce funcționează: rolul îngust plus o condiție explicită de oprire fac diferența dintre un agent care termină treaba și unul care arde tokeni într-o buclă. Acesta este miezul celor mai bune practici pentru system prompt-urile de agenți.

2. RAG / Întrebări și Răspunsuri prin Recuperare

Tot jocul cu recuperarea constă în a împiedica modelul să răspundă din propria memorie. O singură regulă rezolvă asta.

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.

De ce funcționează: „doar din context” plus un format de citare este cea mai ieftină gardă împotriva halucinațiilor pe care o poți scrie pentru un system prompt RAG.

3. Bot de Suport Clienți

Tonul, o cale de escaladare și o regulă financiară strictă mențin botul de suport util, fără a-i permite să promită lucruri pe care nu le poate onora.

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.

De ce funcționează: garda de rambursare și fallback-ul de escaladare opresc cele două moduri de eșec care duc la scoaterea boților de suport din producție.

4. Asistent de Coding

Constrânge formatul de ieșire și versiunile și fă-l să explice înainte de a edita.

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.

De ce funcționează: „diff, nu fișiere complete” plus un plafon de versiune menține asistentul în interiorul stivei tale tehnologice. Designul prompturilor pentru agenții de coding este suficient de complex pentru a merita propriul ghid, așa că păstrăm acest exemplu concis.

5. Extracție Date Structurate / JSON

Pune schema în blocul de format de ieșire și interzice proza. Acesta este modelul pentru ieșiri structurate fiabile.

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.

De ce funcționează: o schemă literală plus „doar JSON valid” bate de fiecare dată un format descris verbal. Pentru modele de aplicare dincolo de prompt (validare schemă JSON, extragere bazată pe instrumente), vezi ghidul nostru despre ieșiri structurate.

6. Agent Content-QA / Validator (din pipeline-ul nostru de producție)

Acesta rulează în propria noastră stivă. System prompt-ul validatorului nostru este un exemplu de constrângeri negative: îi spune modelului exact ce să NU scrie, apoi un script verifică regulile literal.

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.

De ce funcționează: o listă enumerată de interdicții plus un grep este aplicabilă într-un mod în care „evită buzzword-urile” nu este niciodată. Modelul se poate certa cu o impresie; nu se poate certa cu un cod de ieșire non-zero.

7. Agent de Traducere (din pipeline-ul nostru de producție)

De asemenea, al nostru. Prompt-ul translatorului este un contract de format de ieșire și completitudine, cu o auto-verificare pe care modelul o rulează asupra propriei ieșiri.

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.

De ce funcționează: un contract de completitudine plus un exemplu concret de ieșire greșită prinde eșecurile silențioase pe care o linie vagă de tipul „traduce corect” le lasă să treacă.

Ce am învățat rulând System Prompts în Producție

Trei bug-uri de system prompt în propria noastră pipeline ne-au învățat mai multe decât orice pagină de documentație. Toate trei au provenit din instrucțiuni care sunau bine, dar nu erau specifice sau verificabile. Iată ce s-a stricat la cei 16+ subagenți Claude ai noștri și remedierea exactă care a funcționat de fiecare dată. Modelul este același de fiecare dată: regulile blânde sunt ignorate, regulile specifice și verificate extern rămân.

Bug-ul vocabularului interzis. Timp de săptămâni, modelul continua să strecoare leverage și robust în drafturi, indiferent cât de frumos îi ceream. O linie blândă de tipul „evită buzzword-urile” nu a făcut nimic. Soluția a fost Exemplul #6: o listă enumerată de interdicții în interiorul promptului plus un script care caută (grep) în ieșire și exită cu non-zero la orice potrivire, cu o limită suplimentară de 3 cratime lungi la 1.000 de cuvinte. Lecția: constrângerile vagi sunt ignorate; constrângerile enumerate și verificate extern rămân.

Bug-ul diacriticelor. Translatorul nostru emitea tacit ASCII pentru turcă, franceză și spaniolă. karşılaştırma ieșea ca karsilastirma, și nimeni nu a observat până când un cititor nativ a semnalat problema. Soluția a fost un tabel de caractere native în prompt, un exemplu explicit de ieșire greșită și un grep post-rulare (zero caractere native înseamnă re-traducere). Lecția: oferă modelului un exemplu concret al eșecului, nu doar o regulă.

Bug-ul ID-ului stabil. Acesta este cel costisitor. Un system prompt care rederiva un slug localizat la fiecare re-traducere a făcut ca editorul să genereze un al doilea document live per articol. Am livrat 54 de documente live duplicate pe 2026-06-13 și nu le-am retras până pe 2026-07-05, trei săptămâni de divizare a equity-ului link-urilor și flag-uri de conținut duplicat. Soluția: fixează identitatea explicit și reutilizează ID-ul existent verbatim. Un system prompt care își regenerează propriii identificatori nedeterminist livrează duplicate; al nostru a generat 54 de documente live înainte de a fixa ID-ul.

Care sunt cele mai comune greșeli de System Prompt?

Cele mai comune greșeli de system prompt sunt instrucțiunile de tip „zid de text”, regulile contradictorii, formularea doar negativă, turnarea contextului specific cererii într-un prompt static și omiterea unui fallback. La modelele din 2026 apare una nouă: CAPS aggressive și formularea „TREBUIE” declanșează excesiv acum Claude Opus 4.5+.

Iată lista rapidă de remedieri:

• Zid de text. Remediere: împarte-l în cele șase blocuri și pune conținutul stabil primul.
• Instrucțiuni contradictorii. Remediere: o regulă pe linie; rezolvă conflictele înainte de livrare.
• Formulare doar negativă. Remediere: spune ce să facă, nu doar ce să evite.
• Supraîncărcare cu CAPS și „TREBUIE”. La modelele mai noi de la Anthropic, acest lucru dă înapoi. Documentația lor spune acum că acolo unde ai fi scris „CRITICAL: You MUST use this tool”, poți folosi o formulare normală precum „Folosește acest instrument când...”. Sfatul din 2025 este acum greșeala.
• Context dinamic într-un prompt static. Păstrează datele specifice cererii în turul utilizatorului. Ce aparține unde este o disciplină în sine; ghidul nostru de inginerie context acoperă acest aspect.
• Fără fallback. Definește întotdeauna un refuz și o cale de escaladare.
• Ignorarea lungimii și costului. Prompturile mai lungi adaugă latență și cost de tokeni la fiecare apel; taie tot ce nu își merită locul.

Pentru elementele de bază ale clarității instrucțiunilor, articolul cu cele mai bune practici de la OpenAI rămâne o listă de verificare solidă.

Cum testezi și iterezi un System Prompt?

Testează un system prompt așa cum testezi codul. Construiește un set mic „gold” de intrări cu ieșiri așteptate, apoi afirmă răspunsul modelului față de ele la fiecare schimbare. A/B testează două versiuni de prompt pe aceleași intrări și păstrează cea care trece mai multe verificări. Afirmările bat inspectarea vizuală de fiecare dată.

O buclă minimală de evaluare arată astfel:

# 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

Grep-ul din Exemplul #6 este cea mai ieftină afirmație pe care o poți rula: nu costă nimic și nu obosește niciodată. Pe măsură ce biblioteca ta de prompturi crește peste câteva exemplare, versionează și testează prompturile cu instrumente reale de gestionare a prompturilor în loc să faci copy-paste între fișiere. Ideea este aceeași la orice scară: nu schimba niciodată un prompt de producție fără o verificare care să îți spună dacă l-ai îmbunătățit sau înrăutățit.

System Prompt vs User Prompt vs Developer Message

Un system prompt stabilește comportamentul fix; un user prompt poartă sarcina specifică cererii; un developer message este rolul pentru modelele de raționament de la OpenAI care deține instrucțiuni la nivel de aplicație, clasate deasupra mesajelor utilizatorului în lanțul de comandă. Anthropic folosește un parametru system de nivel superior în loc de un mesaj role: "system". Iată împărțirea în trei pe care competitorii o omit de obicei.

OpenAI este explicită privind ierarhia: „mesajele developer sunt instrucțiuni furnizate de dezvoltatorul aplicației, prioritizate înaintea mesajelor utilizatorului”. Deci, dacă un utilizator încearcă să suprascrie regulile aplicației tale, mesajul developer câștigă în lanțul de comandă.

Au nevoie modelele de raționament de System Prompts diferite? (2026)

Da. Modelele de raționament precum seria o de la OpenAI, GPT-5 și Claude Opus 4.5+ doresc obiective de nivel înalt, nu scripturi pas cu pas. OpenAI compară un model de raționament cu un coleg senior căruia ai încredere să gestioneze detaliile, spre deosebire de un model GPT care se comportă ca un junior care are nevoie de instrucțiuni explicite.

Această încadrare schimbă modul în care scrii promptul. Pentru un model de raționament, enunță obiectivul și constrângerile și „ai încredere că vor rezolva detaliile”; pentru un model GPT, detaliază pașii. Supraspecificarea unui model de raționament îl face adesea mai rău, nu mai bun.

Partea Claude are propria sa schimbare în 2026. Deoarece Opus 4.5+ este mai receptiv la system prompt, vechiul obicei de a stivui CRITICAL: și MUST îl declanșează acum excesiv. Redu acel limbaj la o formulare normală. O notă de cost: pune conținutul stabil, reutilizat, la începutul promptului, astfel încât caching-ul promptului să intre în acțiune și să reducă latența la apelurile repetitive. Și dacă modelul tău de raționament face muncă pas cu pas, promptarea chain-of-thought este un subiect în sine cu propriul ghid, așa că nu o vom reexplica aici.

Cum abordează Techsy acest aspect

La Techsy construim sisteme de agenți pentru clienți B2B, iar prompturile de validator și translator de mai sus rulează în acea stivă de producție. Tratăm fiecare system prompt ca pe cod: îl versionăm, îl testăm față de un set gold și impunem regulile non-negociabile cu un script în loc de speranță. Dacă muti o funcționalitate LLM de la un demo la producție și vrei ajutor cu munca de integrare AI, obține o consultație gratuită.

Despre autor

Mert Batur Gurbuz este Co-Founder al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voice/SDR pentru clienți B2B. Studiază la University of Birmingham și scrie despre stiva de tooling LLM pe care echipa Techsy o folosește efectiv în producție.

Co-Founder, Techsy.io, University of Birmingham · LinkedIn

Întrebări frecvente

Ce este un system prompt?

Un system prompt este un set de instrucțiuni persistente stabilite o singură dată, înainte de orice mesaj al utilizatorului, care definesc rolul, comportamentul, constrângerile și formatul de ieșire al modelului pentru întreaga sesiune. Este stratul fix „cum se comportă” și rămâne identic în timp ce mesajele specifice cererii ale utilizatorului se schimbă la fiecare tur.

Care este diferența dintre un system prompt și un user prompt?

System prompt-ul este „cum se comportă” fix, identic pentru fiecare cerere; user prompt-ul este „ce trebuie făcut” specific cererii. O regulă simplă: dacă conținutul ar fi identic pentru 1.000 de cereri, acesta aparține system prompt-ului, iar orice se schimbă per apel merge în turul utilizatorului.

Ce este un developer message față de un system prompt?

Modelele de raționament de la OpenAI (seria o, GPT-5) preiau un mesaj developer în loc de un mesaj system. Acesta poartă instrucțiuni la nivel de aplicație, clasate deasupra mesajelor utilizatorului în lanțul de comandă, deci câștigă dacă un utilizator încearcă să suprascrie regulile tale. Anthropic menține un singur parametru system de nivel superior, în loc de un mesaj bazat pe rol.

Cât de lung ar trebui să fie un system prompt?

Cât de scurt poate fi, acoperind în același timp rolul, constrângerile, formatul de ieșire și gardele. Prompturile prea lungi adaugă cost de tokeni și latență la fiecare apel și pot declanșa excesiv raționamentul suplimentar pe Claude Opus 4.5+. Dacă un prompt stabil trebuie să fie lung, pune conținutul reutilizat primul, astfel încât caching-ul promptului să compenseze costul.

Funcționează system prompts la fel în ChatGPT/GPT și Claude?

Același concept, mecanisme diferite. OpenAI folosește un rol system sau developer în interiorul array-ului de mesaje, în timp ce Anthropic folosește un parametru system separat, de nivel superior, și favorizează etichetele XML pentru a separa instrucțiunile, contextul și exemplele. Instrucțiunile se transferă între provideri; cablarea și convențiile de formatare nu.

Poți schimba system prompt-ul în mijlocul conversației?

Prin API, retrimiți întregul payload de mesaje la fiecare apel, deci tehnic poți schimba system prompt-ul între tururi. Dar schimbarea lui în mijlocul conversației poate rupe continuitatea și poate confunda modelul regarding propriile sale reguli. Preferă să îl stabilești o singură dată sau să îl schimbi deliberat pentru un prompt distinct, specific unei sarcini.

Ar trebui să folosesc etichete XML sau markdown într-un system prompt?

Anthropic recomandă etichete XML pentru Claude pentru a separa instrucțiunile, contextul și exemplele, astfel încât modelul să nu le amestece. Modelele OpenAI gestionează bine markdown-ul și titlurile simple. Potrivește-te convenției providerului în loc să impui un stil pentru ambele și păstrează consecvent stilul ales în interiorul unui singur prompt.

Au nevoie modelele de raționament de system prompts diferite?

Da. Modelele de raționament doresc obiective de nivel înalt, ca și cum ai briefa un coleg senior, nu micromanagement pas cu pas. Renunță la limbajul agresiv cu CAPS și „TREBUIE” care declanșează excesiv modelele mai noi precum Claude Opus 4.5+, enunță obiectivul și gardele și lasă modelul să planifice calea pentru a ajunge acolo.

Care sunt părțile unui system prompt bun?

Șase blocuri: rol, context, constrângeri, format de ieșire, garde sau fallback-uri și, opțional, câteva exemple. Rolul și constrângerile fac cea mai mare parte a muncii; blocul de format de ieșire este cel care face răspunsurile parsabile; gardele definesc ce se întâmplă la margini. Exemplele merită adăugate doar atunci când calitatea țintă este greu de descris în cuvinte.