Portare i Prompt tra Modelli Diversi

Intermedio

Hai un prompt che funziona alla perfezione su un modello. Ora ti serve su un altro — un cliente vive su GPT, un obiettivo di costo ti spinge verso un modello open, oppure stai facendo A/B testing di Claude contro Gemini. La buona notizia, ripetuta nella documentazione di ogni provider, è: l'ossatura di un buon prompt è universale. Ciò che cambia è un sottile strato di convenzioni di superficie. Questa pagina separa i due aspetti così puoi spostare un prompt senza riscriverlo, e ti fornisce un workflow di migrazione ripetibile più un template portabile.

What you'll learn

• Sapere quali parti di un prompt si trasferiscono senza problemi tra Claude, GPT, Gemini e modelli open
• Sapere quali parti necessitano di adattamento per ciascun modello — e perché
• Eseguire un workflow di migrazione ripetibile invece di riscrivere per tentativi ed errori
• Mantenere un template di prompt portabile e neutrale rispetto al modello, da specializzare per ciascun target

Ultima verifica: 2026-06-28.

Nomi esatti dei modelli, verbosità di default, tuning dei rifiuti, peso del system prompt, parametri supportati (prefill, sequenze di stop, limiti max-token) e la forma del JSON delle chiamate a tool cambiano tutti tra versioni presso ogni provider. Questa pagina insegna l'inquadramento duraturo — cosa si trasferisce e cosa adattare. Per qualsiasi comportamento specifico, nome di parametro o limite, verifica rispetto alla documentazione corrente del provider linkata in Fonti anziché fidarti di un valore memorizzato qui.

Conferma confrontando con la fonte ufficiale.

Il modello mentale: la struttura si trasferisce, le convenzioni no

Pensa a qualsiasi prompt come a due strati:

• Lo strato di ragionamento — cosa stai chiedendo, il contesto che fornisci, gli esempi, l'output che desideri. Riguarda la comunicazione, e si trasferisce quasi invariato tra i modelli.
• Lo strato di convenzione — come questo particolare modello vuole che quella comunicazione sia impacchettata: dove va il system prompt e con quanta forza viene seguito, se preferisce XML o Markdown, lo schema esatto delle chiamate a tool, la sua verbosità di default e la sua postura sui rifiuti, quali parametri di generazione esistono.

Portare un prompt non è quasi mai una riscrittura dello strato di ragionamento. È un ri-adattamento dello strato di convenzione. Cogli bene questa distinzione e la migrazione diventa meccanica invece che misteriosa. (Per il modo neutrale rispetto al provider di scegliere un target in primo luogo, vedi Scegliere un Modello.)

Cosa si trasferisce senza problemi

Questi valgono allo stesso modo su Claude, GPT, Gemini e i principali modelli open — le documentazioni di best practice di ciascun provider li raccomandano in modo indipendente:

• Un ruolo + task + istruzioni esplicite chiare. "Sei X. Il tuo compito è Y. Segui queste regole." Ogni provider documenta un costrutto di persona/ruolo e premia istruzioni specifiche e non ambigue rispetto a quelle vaghe.
  Ultima verifica: 2026-06-28. La guida al prompt-design di Gemini di Google raccomanda di collocare persona, regole e requisiti di formato dell'output come istruzioni di sistema esplicite; OpenAI e Anthropic danno lo stesso consiglio nelle loro guide — verifica la formulazione corrente presso ciascuna fonte. Conferma confrontando con la fonte ufficiale.
• Esempi concreti (few-shot). Mostrare 2–5 coppie input→output insegna un pattern in modo più affidabile che descriverlo. Tutti e tre i principali provider raccomandano esplicitamente gli esempi few-shot; la documentazione di Gemini arriva a raccomandare di includerli quasi sempre.
• Un formato di output specificato. "Restituisci una tabella Markdown con le colonne X, Y, Z" o "solo JSON, niente prosa" funziona ovunque. L'istruzione si trasferisce anche quando il meccanismo di strict-mode differisce (trattato più sotto).
• Chain-of-thought / "ragiona prima di rispondere". Chiedere un ragionamento passo-passo su task difficili migliora i risultati su tutti i modelli. Una precisazione che invece è specifica del modello: i modelli dedicati al reasoning/thinking spesso lo fanno internamente, quindi un esplicito "pensa passo per passo" può essere ridondante o persino controproducente — vedi l'elenco degli adattamenti.
• Grounding / RAG. "Usa SOLO il contesto qui sotto; se la risposta non è lì, di' che non lo sai." La disciplina di fornire contesto recuperato e di vincolarvi il modello è universale — ogni provider documenta il grounding in stile RAG come il modo per ridurre le allucinazioni.
• Mettere il contesto lungo prima, la domanda per ultima. Apri con i documenti/dati, chiudi con l'istruzione. Questo ordinamento aiuta su tutti i modelli ed è indicato esplicitamente nella guida di Gemini.

Se hai interiorizzato le Basi del Prompting, possiedi già l'80% portabile.

Cosa necessita di adattamento per ciascun modello

Questo è lo strato di convenzione — la parte che davvero differisce. Ri-adatta questi elementi quando ti sposti:

Aspetto	Cosa cambia tra i modelli	Cosa fare
Gestione e peso del system prompt	Ogni modello ha un messaggio di system/developer, ma quanto fortemente sovrasti il turno dell'utente varia. Alcuni pesano un ruolo dedicato developer/system al di sopra delle istruzioni dell'utente; altri sfumano il confine.	Non dare per scontato che il tuo system prompt venga seguito con la stessa forza. Ri-testa che i vincoli reggano davvero; promuovi le regole critiche più in alto se scivolano.
XML vs Markdown vs delimitatori	Claude analizza i tag XML particolarmente bene per separare istruzioni/contesto/esempi; GPT e Gemini accettano l'XML ma si appoggiano anche a heading e delimitatori Markdown.	Mantieni un po' di struttura esplicita; cambia il formato secondo la preferenza del target. Far combaciare il formato del tuo prompt con l'output desiderato influenza anche lo stile dell'output.
Forma del JSON di tool / function-calling	Il ciclo (dichiara i tool → il modello richiede una chiamata → esegui → restituisci il risultato) è identico ovunque; il formato di trasmissione no — i nomi dei campi, come chiamate/risultati si collocano nella lista dei messaggi e le opzioni di strict-mode differiscono.	Non copiare mai il JSON dei tool grezzo tra provider. Ri-mappalo sullo schema del target. Vedi Uso dei Tool.
Verbosità di default	I modelli più recenti tendono di default a essere concisi e si aspettano che tu chieda i dettagli; quelli più vecchi erano più loquaci.	Se hai portato un prompt e le risposte si sono accorciate/allungate, imposta la verbosità esplicitamente invece di dare la colpa al prompt.
Postura su rifiuti / sicurezza	Ogni modello ha una propria soglia per rifiutare o essere cauto su richieste borderline, e queste vengono ri-tarate a ogni release.	Ri-testa i casi limite dopo il porting. Un prompt che non ha mai innescato rifiuti su un modello potrebbe necessitare di una riformulazione su un altro.
Prefill della risposta	Mettere parole in bocca all'assistente per forzare un formato è una leva classica dell'era Claude — ma i modelli Claude più recenti (4.6+) rifiutano un turno finale dell'assistente in prefill, e il supporto altrove varia completamente.	Sostituisci il prefill con un'istruzione diretta ("rispondi senza preamboli"), uno schema di output o l'uso dei tool.
Sequenze di stop e max token	Tutti espongono un tetto di lunghezza e la maggior parte espone sequenze di stop, ma nomi dei parametri, default e tetti differiscono — e alcune manopole di budget di thinking vengono deprecate in favore di effort/max_tokens.	Ri-controlla i nomi dei parametri e i tetti sul target; non dare per scontato che i tuoi vecchi valori si trasferiscano.

Ultima verifica: 2026-06-28.

Due delle righe qui sopra sono esempi concreti di drift: la documentazione corrente di best practice di Anthropic afferma che i turni finali dell'assistente in prefill restituiscono un errore su Claude 4.6 e modelli successivi (usa invece un'istruzione diretta o un output strutturato), e che i tag XML sono il modo raccomandato per separare istruzioni, contesto, esempi e input per Claude. Entrambi i comportamenti sono specifici della versione — conferma alla fonte prima di farci affidamento.

Conferma confrontando con la fonte ufficiale.

Un workflow di migrazione

Tratta il porting come un ciclo breve e disciplinato, non come una riscrittura a tentativi.

Guided walkthrough1 of 6

1. Leggi il tuo prompt esistente e dividilo mentalmente: strato di ragionamento (ruolo, task, contesto, esempi, specifica dell'output) vs strato di convenzione (scelte XML/Markdown, prefill, JSON dei tool, parametri). Manterrai il primo e ri-adatterai il secondo.

:::tip Non riscrivere da zero Se ti ritrovi a ricostruire il ruolo, il task o gli esempi, fermati — quello è lo strato portabile. Un porting pulito cambia il packaging, non il significato. :::

Un template di prompt portabile

Scrivi il tuo prompt in una forma neutrale rispetto al modello, poi specializza solo lo strato di convenzione per ciascun target. Questo core usa una struttura leggera e compresa universalmente (si legge bene come Markdown, e i tag si convertono facilmente in XML per Claude):

Core di prompt neutrale rispetto al modello — specializza lo strato di convenzione per ciascun target

# ROLE
You are {role}.

# TASK
{One clear sentence describing the single goal.}

# RULES
- Use ONLY the information in CONTEXT below. If the answer is not there, say "I don't know" — do not guess.
- Be concise. Respond directly, with no preamble like "Here is..." or "Based on...".
- {Any other hard constraints.}

# OUTPUT FORMAT
{Exact format — e.g. "A Markdown table with columns Name, Value, Source." or "JSON only matching this schema: {...}".}

# EXAMPLES
Input: {example input 1}
Output: {ideal output 1}

Input: {example input 2}
Output: {ideal output 2}

# CONTEXT
{Retrieved documents / data go here — long content first.}

# REQUEST
{The actual user question, last.}

Ritocchi da sovrapporre per ciascun target:

• Claude — sposta i marcatori di sezione in tag XML (<role>, <rules>, <context>, <request>); li analizza in modo particolarmente pulito. Non usare un turno dell'assistente in prefill sui modelli attuali; affidati alla regola "no preamble" o a un tool/schema.
• GPT — metti le RULES nel messaggio system/developer così portano più peso; gli heading Markdown vanno bene; usa la modalità structured-output/strict JSON invece di descrivere solo lo schema in prosa.
• Gemini — passa ROLE + RULES + OUTPUT FORMAT tramite il campo system-instruction, mantieni il prompt diretto (i Gemini più recenti possono sovra-interpretare prompt verbosi) e tieni il CONTEXT per primo con la REQUEST per ultima.
• Modelli open (Llama/Mistral/Qwen, ecc.) — segui esattamente il chat template pubblicato del modello e appoggiati di più su esempi few-shot espliciti e vincoli di formato, dato che l'instruction-following è di solito meno robusto rispetto ai modelli closed di frontiera.

Verifica rapida

Mettiti alla prova

0/3

1. 1Stai spostando un prompt Claude funzionante su GPT. Quale parte dovresti aspettarti di mantenere sostanzialmente invariata?
2. 2Il tuo prompt portato produce improvvisamente risposte molto più corte sul nuovo modello. Causa più probabile?
3. 3Cosa è vero riguardo al tool/function calling quando si effettua il porting tra provider?

Cheat-sheet del porting

Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.

1 / 6

Key takeaways

• Un prompt è uno strato di ragionamento (si trasferisce) più uno strato di convenzione (ri-adattato per ciascun modello) — porta il secondo, mantieni il primo.
• Ruolo/task/istruzioni chiari, esempi few-shot, specifiche di formato dell'output, chain-of-thought e grounding RAG si trasferiscono tra Claude, GPT, Gemini e modelli open.
• Adatta per ciascun target il peso del system prompt, la struttura XML vs Markdown, il JSON di chiamata ai tool, la verbosità di default, la postura sui rifiuti, il prefill e i parametri di lunghezza.
• Esegui un piccolo set di eval su input reali prima/dopo; correggi le convenzioni prima di toccare il ragionamento.
• Mantieni nel version control un template neutrale rispetto al modello più i ritocchi per ciascun target così cambiare costa poco.
• I comportamenti specifici cambiano a ogni release — verifica parametri e limiti nella documentazione corrente di ciascun provider, mai a memoria.

Fonti e approfondimenti

• Panoramica sul prompt engineering — documentazione Anthropic (Claude) — le tecniche di prompting di Claude: chiarezza, esempi, strutturazione XML, thinking, ruoli.
• Best practice di prompting per Claude — documentazione Anthropic — tuning specifico del modello, tag XML, controllo di output/verbosità e la guida alla migrazione del prefill.
• Best practice di prompt engineering — documentazione API OpenAI (GPT) — ruoli dei messaggi/chain-of-command, delimitatori, few-shot e guida su modelli di reasoning vs GPT.
• Function calling — documentazione API OpenAI — lo schema di chiamata ai tool e il ciclo richiesta/risposta da mappare.
• Strategie di prompt design — documentazione API Google Gemini — istruzioni di sistema, few-shot, strutturazione, ordinamento con contesto prima e parametri di output/lunghezza.
• Guida per sviluppatori Gemini 3 — documentazione API Google Gemini — guida sui modelli più recenti riguardo prompt diretti, verbosità di default e collocazione delle istruzioni.

Prossimi passi

• Allinea la profondità di thinking tra provider → Modelli di Reasoning a Confronto
• Scegli il provider target in modo neutrale → Scegliere un Modello
• I fondamentali portabili → Basi del Prompting
• La leva strutturale di Claude → Tag XML
• Ri-mappa lo schema dei tool → Uso dei Tool