7 Esempi di System Prompt per App in Produzione (Template Copia-Incolla 2026)

I migliori esempi di system prompt non sono le battute da tutorial tipo "sei un assistente utile". Sono i blocchi di istruzioni specifici che impediscono a un'app in produzione di impazzire alle 2 di notte. Nella nostra pipeline di contenuti gestiamo più di una dozzina di subagent Claude, ognuno guidato da un system prompt che abbiamo riscritto più volte dopo un bug spedito su Claude Opus 4.8 o GPT-5. Qui niente demo giocattolo: trovi 7 system prompt reali, pronti da copiare, due presi direttamente da quello stack in produzione, più l'anatomia a 6 blocchi che sta sotto ognuno di quelli affidabili.

Punti Chiave

• Un system prompt è un insieme di istruzioni persistenti (ruolo, vincoli, formato di output, guardrail) impostate una sola volta prima di qualsiasi messaggio dell'utente.
• Se un contenuto è identico su 1.000 richieste, va nel system prompt; ciò che cambia a ogni richiesta va nel turno utente.
• Sei blocchi costruiscono un prompt affidabile: ruolo, contesto, vincoli, formato di output, guardrail, esempi.
• I modelli di ragionamento (serie o, GPT-5, Claude Opus 4.5+) vogliono obiettivi di alto livello, non un linguaggio aggressivo tipo "devi assolutamente".

Cosa Contiene un System Prompt? I 6 Blocchi Fondamentali

Un system prompt è un insieme di istruzioni persistenti che definiscono il ruolo, il comportamento, i vincoli e il formato di output di un modello per l'intera sessione, impostate una sola volta prima di qualsiasi messaggio dell'utente. Quelli affidabili condividono sei blocchi costitutivi: ruolo, contesto, vincoli, formato di output, guardrail ed esempi opzionali. Metti questi elementi in ordine e hai la versione breve di come scrivere un system prompt che sopravvive alla produzione.

Ecco cosa fa ciascun blocco.

Il blocco ruolo conta più di quanto sembri. La documentazione di Anthropic lo dice chiaramente: impostare un ruolo nel system prompt orienta comportamento e tono del modello, e "anche una singola frase fa la differenza". Per il blocco guardrail, le regole di rifiuto e sicurezza meritano attenzione vera; ne parliamo a fondo nella nostra guida ai guardrail. E se stai collegando Claude, Anthropic consiglia i tag XML (<instructions>, <context>, <input>) per separare ogni tipo di contenuto ed evitare che il modello li confonda tra loro.

Ecco uno scheletro pronto da incollare che cuce insieme tutti e sei i blocchi in un unico 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.}

Sei blocchi trasformano un'idea vaga in una specifica vera e propria. Questo è solo il livello system prompt. Per le tecniche più ampie (few-shot, chain-of-thought, prompt chaining), guarda la nostra guida al prompt engineering, tenendole fuori dal system prompt vero e proprio. Un system prompt di sessione è anche diverso da un file a livello di repository con istruzioni persistenti di progetto come un CLAUDE.md, che governa un intero codebase invece di una singola sessione API.

7 Esempi di System Prompt in Produzione (Pronti da Copiare)

Ecco 7 esempi di system prompt che puoi incollare subito nel tuo parametro system o nel messaggio developer. Ognuno copre un compito reale (agente, RAG, supporto, coding, JSON, content QA, traduzione), e ognuno mostra perché esistono i suoi blocchi chiave. Gli ultimi due girano nella nostra pipeline. I repository che trapelano i prompt di Cursor e Devin dimostrano la domanda; quello che nessuno pubblica è l'annotazione che spiega perché ogni blocco è lì.

1. Agente Autonomo

Definisci il ruolo in modo stretto, esplicita le regole sugli strumenti e dagli una condizione di stop, così non può girare in loop all'infinito.

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.

Perché funziona: il ruolo ristretto più una condizione di stop esplicita fanno la differenza tra un agente che finisce il lavoro e uno che brucia token in un loop. È il cuore delle buone pratiche per un system prompt da agente.

2. RAG / Domande e Risposte con Retrieval

Con il retrieval il gioco è tutto qui: impedire al modello di rispondere a memoria. Una regola sola basta.

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.

Perché funziona: "solo dal contesto" più un formato di citazione è la guardia anti-allucinazione più economica che puoi scrivere per un system prompt RAG.

3. Bot di Supporto Clienti

Tono, un percorso di escalation e una regola rigida sui soldi tengono un bot di supporto utile senza lasciargli promettere cose che non può mantenere.

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.

Perché funziona: il guardrail sui rimborsi e il fallback di escalation bloccano le due modalità di fallimento che fanno ritirare i bot di supporto dalla produzione.

4. Assistente di Coding

Vincola il formato di output e le versioni, e fagli spiegare prima di modificare.

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.

Perché funziona: "diff, non file interi" più un tetto di versione tengono l'assistente dentro il tuo stack. Il prompt design per agenti di coding è un argomento abbastanza profondo da meritare una guida a parte, quindi qui teniamo l'esempio essenziale.

5. Dati Strutturati / Estrazione JSON

Metti lo schema nel blocco formato di output e vieta la prosa libera. Questo è il pattern che garantisce output strutturati affidabili.

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.

Perché funziona: uno schema letterale più "solo JSON valido" batte sempre un formato descritto a parole. Per pattern di enforcement oltre al prompt (validazione JSON schema, estrazione tool-based), guarda la nostra guida agli output strutturati.

6. Agente Content-QA / Validator (dalla nostra pipeline in produzione)

Questo gira nel nostro stack. Il system prompt del nostro validator è un esempio di vincoli negativi: dice al modello esattamente cosa NON scrivere, poi uno script controlla le regole alla lettera.

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.

Perché funziona: una lista di parole vietate enumerata più un grep è applicabile in un modo in cui "evita i buzzword" non lo sarà mai. Il modello può discutere con una sensazione vaga; non può discutere con un exit code diverso da zero.

7. Agente di Traduzione (dalla nostra pipeline in produzione)

Anche questo è nostro. Il prompt del translator è un contratto di formato di output e completezza, con un self-check che il modello esegue sul proprio output.

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.

Perché funziona: un contratto di completezza più un esempio concreto di output sbagliato intercetta i fallimenti silenziosi che una riga vaga come "traduci con precisione" lascerebbe passare.

Cosa Abbiamo Imparato Usando System Prompt in Produzione

Tre bug legati ai system prompt nella nostra pipeline ci hanno insegnato più di qualsiasi pagina di documentazione. Tutti e tre venivano da istruzioni che suonavano bene ma non erano né specifiche né verificabili. Ecco cosa si è rotto nei nostri 16+ subagent Claude, e la correzione esatta che ha tenuto ogni volta. Lo schema è sempre lo stesso: le regole morbide vengono ignorate, quelle specifiche e controllate esternamente reggono.

Il bug del vocabolario vietato. Per settimane il modello continuava a far scivolare leverage e robust nelle bozze, non importa quanto gentilmente glielo chiedessimo. Una riga morbida tipo "evita i buzzword" non serviva a niente. La correzione è stata l'Esempio #6: una lista di parole vietate enumerata dentro il prompt più uno script che fa grep sull'output e restituisce un exit code diverso da zero a ogni hit, con in più un tetto di em-dash di 3 ogni 1.000 parole. La lezione: i vincoli vaghi vengono ignorati; i vincoli enumerati e verificati esternamente reggono.

Il bug dei diacritici. Il nostro translator emetteva ASCII senza avvisare su turco, francese e spagnolo. karşılaştırma usciva come karsilastirma, e nessuno se n'è accorto finché un lettore madrelingua non l'ha segnalato. La correzione è stata una tabella di caratteri nativi dentro il prompt, un esempio esplicito di output sbagliato e un grep post-esecuzione (zero caratteri nativi vuol dire ritradurre). La lezione: dai al modello un esempio concreto del fallimento, non solo una regola.

Il bug dell'ID stabile. Questo è quello costoso. Un system prompt che ricalcolava lo slug localizzato a ogni ri-traduzione faceva sì che il publisher coniasse un secondo documento live per lo stesso post. Abbiamo spedito 54 documenti live duplicati il 2026-06-13 e non li abbiamo depubblicati fino al 2026-07-05, tre settimane di link equity divisa e segnalazioni di contenuto duplicato. La correzione: fissare l'identità in modo esplicito e riusare l'ID esistente parola per parola. Un system prompt che rigenera i propri identificatori in modo non deterministico produce duplicati; il nostro ne ha coniati 54 prima che fissassimo l'ID.

Quali Sono gli Errori Più Comuni nei System Prompt?

Gli errori più comuni nei system prompt sono istruzioni a muro di testo, regole contraddittorie, formulazioni solo in negativo, contesto per-richiesta buttato dentro un prompt statico, e nessun fallback. Sui modelli del 2026 ce n'è uno nuovo: il MAIUSCOLO aggressivo e frasi tipo "devi assolutamente" ora sovra-attivano Claude Opus 4.5+.

Ecco la lista rapida delle correzioni:

• Muro di testo. Correzione: dividilo nei sei blocchi e metti prima il contenuto stabile.
• Istruzioni contraddittorie. Correzione: una regola per riga; risolvi i conflitti prima di pubblicare.
• Formulazioni solo in negativo. Correzione: di' cosa fare, non solo cosa evitare.
• Sovraccarico di MAIUSCOLE e "DEVI". Sui modelli più recenti di Anthropic questo si ritorce contro. La loro documentazione dice che dove prima avresti scritto "CRITICAL: You MUST use this tool", ora puoi usare un linguaggio normale come "Use this tool when." Il consiglio del 2025 è diventato l'errore di oggi.
• Contesto dinamico in un prompt statico. Tieni i dati per-richiesta nel turno utente. Cosa va dove è una disciplina a sé; la nostra guida al context engineering lo spiega.
• Nessun fallback. Definisci sempre un percorso di rifiuto e di escalation.
• Ignorare lunghezza e costo. Prompt più lunghi aggiungono latenza e costo in token a ogni chiamata; taglia tutto ciò che non si guadagna il proprio posto.

Per le basi di chiarezza delle istruzioni, l'articolo sulle best practice di OpenAI resta una checklist solida.

Come Si Testa e Si Itera su un System Prompt?

Testa un system prompt come testeresti del codice. Costruisci un piccolo golden set di input con gli output attesi, poi verifica la risposta del modello rispetto a quelli a ogni modifica. Metti a confronto A/B due versioni del prompt sugli stessi input e tieni quella che supera più controlli. Le assertion battono sempre il controllo a occhio.

Un eval loop minimo è fatto così:

# 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

Il grep dell'Esempio #6 è l'assertion più economica che puoi eseguire: non costa niente e non si stanca mai. Quando la tua libreria di prompt cresce oltre una manciata di file, versiona e testa i tuoi prompt con veri strumenti di gestione dei prompt invece di copiaincollare tra file diversi. Il punto resta lo stesso a qualsiasi scala: non cambiare mai un prompt in produzione senza un controllo che ti dica se l'hai migliorato o peggiorato.

System Prompt vs User Prompt vs Developer Message

Un system prompt imposta un comportamento fisso; uno user prompt porta il compito specifico della richiesta; un developer message è il ruolo dei modelli di ragionamento di OpenAI che contiene istruzioni a livello di app, classificate sopra i messaggi utente nella catena di comando. Anthropic usa un parametro system di primo livello invece di un messaggio role: "system". Ecco la distinzione a tre vie che i concorrenti di solito si perdono.

OpenAI è esplicita sulla gerarchia: "i developer message sono istruzioni fornite dallo sviluppatore dell'applicazione, con priorità superiore rispetto ai messaggi utente". Quindi se un utente prova a scavalcare le regole della tua app, il developer message vince la catena di comando.

I Modelli di Ragionamento Hanno Bisogno di System Prompt Diversi? (2026)

Sì. I modelli di ragionamento come la serie o di OpenAI, GPT-5 e Claude Opus 4.5+ vogliono obiettivi di alto livello, non copioni passo-passo. OpenAI paragona un modello di ragionamento a un collega senior di cui ti fidi per i dettagli, contro un modello GPT che si comporta come un junior che ha bisogno di istruzioni esplicite.

Questa cornice cambia il modo in cui scrivi il prompt. Per un modello di ragionamento, dichiara l'obiettivo e i vincoli e "fidati che lavorerà i dettagli da solo"; per un modello GPT, esplicita i passaggi. Iper-specificare un modello di ragionamento spesso lo peggiora, non lo migliora.

Sul lato Claude c'è un cambiamento tutto suo nel 2026. Siccome Opus 4.5+ risponde di più al system prompt, la vecchia abitudine di accumulare CRITICAL: e MUST adesso lo sovra-attiva. Riporta quel linguaggio a un registro normale. Una nota sui costi: metti il contenuto stabile e riutilizzato all'inizio del prompt, così il prompt caching può entrare in gioco e tagliare la latenza sulle chiamate ripetute. E se il tuo modello di ragionamento fa un lavoro passo-passo, il chain-of-thought prompting è un argomento a sé con una guida propria, quindi qui non lo rispieghiamo.

Come Techsy Affronta Questo Tema

In Techsy costruiamo sistemi ad agenti per clienti B2B, e i prompt del validator e del translator descritti sopra girano proprio in quello stack di produzione. Trattiamo ogni system prompt come codice: lo versioniamo, lo testiamo contro un golden set, e imponiamo le regole non negoziabili con uno script invece che con la speranza. Se stai portando una funzionalità LLM da una demo alla produzione e vuoi una mano con il lavoro di integrazione AI, richiedi una consulenza gratuita.

Chi è l'Autore

Mert Batur è co-fondatore di Techsy.io, dove il team sviluppa agenti AI, sistemi di automazione e pipeline voice/SDR per clienti B2B. Scrive dello stack di strumenti LLM che il team Techsy usa davvero in produzione.

Co-fondatore, Techsy.io · LinkedIn

Domande Frequenti

Cos'è un system prompt?

Un system prompt è un insieme di istruzioni persistenti, impostate una sola volta prima di qualsiasi messaggio dell'utente, che definiscono ruolo, comportamento, vincoli e formato di output del modello per l'intera sessione. È il livello fisso del "come si comporta", e resta identico mentre i messaggi per-richiesta dell'utente cambiano a ogni turno.

Qual è la differenza tra un system prompt e uno user prompt?

Il system prompt è il "come si comporta" fisso, identico a ogni richiesta; lo user prompt è il "cosa fare" specifico di quella richiesta. Una regola pratica semplice: se il contenuto sarebbe identico su 1.000 richieste, appartiene al system prompt; tutto ciò che cambia a ogni chiamata va nel turno utente.

Cos'è un developer message rispetto a un system prompt?

I modelli di ragionamento di OpenAI (serie o, GPT-5) usano un messaggio developer invece di un messaggio system. Contiene istruzioni a livello di app classificate sopra i messaggi utente nella catena di comando, quindi vince se un utente prova a scavalcare le tue regole. Anthropic mantiene un unico parametro system di primo livello invece di un messaggio basato su ruolo.

Quanto dovrebbe essere lungo un system prompt?

Il più corto possibile, purché copra ruolo, vincoli, formato di output e guardrail. Prompt troppo lunghi aggiungono costo in token e latenza a ogni chiamata e possono sovra-attivare ragionamento extra su Claude Opus 4.5+. Se un prompt stabile deve per forza essere lungo, metti il contenuto riutilizzato all'inizio così il prompt caching compensa il costo.

I system prompt funzionano allo stesso modo in ChatGPT/GPT e Claude?

Stesso concetto, meccaniche diverse. OpenAI usa un role system o developer dentro il messages array, mentre Anthropic usa un parametro system separato di primo livello e preferisce i tag XML per separare istruzioni, contesto ed esempi. Le istruzioni si trasferiscono da un provider all'altro; il cablaggio e le convenzioni di formattazione no.

Si può cambiare il system prompt a metà conversazione?

Tramite API reinvii l'intero payload dei messages a ogni chiamata, quindi tecnicamente puoi cambiare il system prompt tra un turno e l'altro. Ma modificarlo a metà conversazione può rompere la continuità e confondere il modello sulle proprie regole. Meglio impostarlo una volta sola, oppure cambiarlo deliberatamente per un prompt specifico per un compito distinto.

Devo usare tag XML o markdown in un system prompt?

Anthropic consiglia i tag XML per Claude, per separare istruzioni, contesto ed esempi senza che il modello li confonda. I modelli OpenAI gestiscono bene markdown e titoli semplici. Segui la convenzione del provider invece di forzare uno stile unico su entrambi, e mantieni coerente quello che scegli all'interno di un singolo prompt.

I modelli di ragionamento hanno bisogno di system prompt diversi?

Sì. I modelli di ragionamento vogliono obiettivi di alto livello, come dare un briefing a un collega senior, non un micromanagement passo-passo. Lascia perdere il MAIUSCOLO aggressivo e il linguaggio "devi assolutamente" che sovra-attivano i modelli più recenti come Claude Opus 4.5+, dichiara l'obiettivo e i guardrail, e lascia che sia il modello a pianificare il percorso per arrivarci.

Quali sono le parti di un buon system prompt?

Sei blocchi: ruolo, contesto, vincoli, formato di output, guardrail o fallback e, facoltativamente, un paio di esempi. Ruolo e vincoli fanno la maggior parte del lavoro; il blocco formato di output è quello che rende le risposte parsabili; i guardrail definiscono cosa succede ai margini. Vale la pena aggiungere esempi solo quando la qualità target è difficile da descrivere a parole.