Prompt per Claude Opus 5.5: cosa togliere, cosa aggiungere, esempi

Con Claude Opus 5.5 il prompt cambia in una direzione precisa: si toglie più di quanto si aggiunga. Le righe che per due anni sono servite a far ragionare i modelli — "pensa con attenzione", "procedi passo passo" — con questo modello rallentano soltanto, perché Opus 5.5 pensa sempre prima di rispondere e decide da solo quanto.

Quello che va aggiunto è un'altra cosa: la linea di arrivo. Cosa vuol dire che il compito è finito, e quando il modello deve fermarsi a chiederti qualcosa. È il cambiamento più grande, e vale sia nell'app sia in Claude Code.

Questa guida è costruita sulla guida ufficiale pubblicata da Anthropic il giorno del lancio, con gli esempi riportati fedelmente e tradotti. Dati verificati il 23 settembre 2026.

Cosa togliere dai prompt

Se hai prompt scritti per Opus 5, Sonnet o modelli di altri fornitori, questa è la pulizia da fare prima di tutto.

Il punto sul ragionamento merita una riga in più. Con Opus 5.5 il ragionamento è adattivo: il modello sceglie quanto pensare in base al compito, dentro un livello che puoi impostare. Chiedergli di "pensare di più" nel testo del prompt non alza il livello: lo confonde. Il livello si sceglie altrove, come spiegato in i livelli di ragionamento di Opus 5.5.

Cosa aggiungere: la linea di arrivo

Per i compiti in più passaggi la guida ufficiale è netta: dai tutto il compito in un messaggio, e nomina la linea di arrivo. L'esempio testuale, tradotto:

"Migra gli endpoint dei pagamenti dal vecchio client al nuovo. Finito vuol dire: ogni endpoint usa il nuovo client, il vecchio client è cancellato, e la suite di test passa. Fermati e chiedimi qualcosa solo se un test fallisce per un motivo che non riesci a spiegare."

Tre elementi, sempre gli stessi:

1. Il compito intero, non il primo passo. Il modello pianifica meglio se vede dove deve arrivare.
2. La definizione di "finito", verificabile: i test passano, ogni record è migrato, il documento non ha contraddizioni.
3. La regola di stop: in quali casi deve fermarsi a chiederti, e in quali no.

Vale anche fuori dal codice. Per una bozza di contratto: "Finito vuol dire: tutte le clausole del modello sono presenti, i nomi delle parti sono coerenti in ogni pagina, nessuna data è nel passato. Fermati solo se manca un dato che non puoi dedurre."

Correggere in corsa

Su un lavoro lungo non serve interrompere e ricominciare: puoi mandare un messaggio mentre il modello sta lavorando. L'esempio della guida: "Tieni anche i vecchi nomi degli endpoint come alias." Il modello lo integra senza ripartire da zero, e tu risparmi il costo del riavvio.

Funziona bene per le precisazioni che ti vengono in mente strada facendo; non per cambiare obiettivo. Se l'obiettivo cambia, il messaggio nuovo è un compito nuovo.

Prompt per le risposte brevi

Se vuoi una risposta secca — un sì o no, una riga, un numero — scrivi "rispondi direttamente". Il modello riduce il ragionamento interno e la risposta arriva prima. È l'unico caso in cui ha senso parlare del ragionamento nel prompt: per chiederne meno, non di più.

Prompt per il design: escludere, non descrivere

Un caso specifico ma istruttivo. Per ottenere una pagina che non sembri generata, "evita un aspetto generico" non funziona. Funziona l'elenco delle abitudini da escludere. L'esempio della guida, tradotto:

"Costruisci un sito personale con contenuti segnaposto. Non usare un fondo crema o bianco sporco, parole in corsivo come accento nei titoli, etichette di sezione numerate 01 / 02 / 03, etichette in monospazio, o bottoni a forma di pillola."

Il principio vale ovunque: le esclusioni specifiche battono le istruzioni generiche. "Niente 'ci scusiamo per il disagio'" funziona; "sii cordiale ma non formale" no.

Chiedere verifiche, non rassicurazioni

Per ricerca e analisi, una riga che cambia il risultato: "Segna tutto quello che non sei riuscito a confermare, e dimmi dove hai cercato." Ottieni una risposta con i punti deboli dichiarati invece di un testo sicuro di sé che poi devi verificare da capo. È la difesa più semplice contro le risposte inventate.

Per i documenti lunghi la guida propone: "Controlla che questo documento non contraddica sé stesso: numeri, date e nomi. Cita ogni problema e dimmi dov'è." Come usarlo su preventivi e contratti è in far controllare un documento a Opus 5.5.

Otto prompt pronti

Il prompt di sistema nei sistemi automatici

Nelle chat il prompt lo scrivi ogni volta; nei sistemi automatici c'è un prompt di sistema che viene rispedito identico a ogni chiamata. Con Opus 5.5 vale la pena riscriverlo per tre motivi.

Il primo è il costo: ogni riga inutile la paghi a ogni esecuzione, e con la cache a 0,20 dollari per milione di token la parte fissa del prompt costa poco solo se è davvero fissa. Il secondo è la latenza: le righe sul ragionamento allungano il tempo prima della prima parola, come spiegato in tempo al primo token. Il terzo è la qualità: un prompt di sistema che descrive il compito con la linea di arrivo produce output più stabili di uno che descrive il comportamento desiderato con aggettivi.

Una struttura che funziona, in quest'ordine: chi è l'utente e cosa fa l'azienda in due righe; il compito con la definizione di "finito"; il formato esatto dell'output; cosa non fare mai; cosa fare quando un dato manca. Niente "sei un assistente esperto e preciso": non cambia nulla, e occupa token.

Esempi pratici

Studio legale, 6 persone, Verona. Il prompt per la prima lettura dei contratti conteneva tre righe di "analizza con la massima attenzione, ragiona clausola per clausola". Tolte, la risposta arriva prima e non cambia nulla nella qualità. Aggiunta la linea di arrivo — "finito vuol dire: ogni clausola del nostro modello è presente o segnalata come mancante" — la risposta è diventata una lista verificabile invece di un commento.

Agenzia di comunicazione, 12 persone, Milano. Per le landing page il brief diceva "moderno, pulito, non generico" e usciva sempre lo stesso sito. Sostituito con un elenco di sette cose da non fare, prese dai lavori scartati nei mesi precedenti. Il risultato non è "migliore" in astratto: è diverso ogni volta, che era il problema.

Errori da evitare

• Copiare le "tecniche segrete" dai forum. Quasi tutte sono nate su modelli che non ragionavano da soli.
• Dare il primo passo invece del compito intero. Il modello pianifica peggio e ti chiede conferma continuamente.
• Definire "finito" in modo non verificabile. "Quando è fatto bene" non è una linea di arrivo.
• Chiedere di mostrare il ragionamento interno. Viene segnalato, e la risposta passa a un modello precedente.
• Descrivere lo stile con aggettivi. Le esclusioni concrete funzionano, "elegante" no.

Come applicarlo in azienda

Se hai prompt condivisi in azienda — nei sistemi automatici o nelle chat di lavoro — questa è la revisione da fare una volta sola:

1. Cerca e togli ogni riga sul ragionamento: "pensa", "ragiona", "passo passo", "con attenzione".
2. Aggiungi a ogni prompt di compito la riga "finito vuol dire:" con criteri verificabili.
3. Aggiungi la regola di stop dove il modello agisce su dati o sistemi.
4. Prova sugli stessi casi di prima e confronta: se peggiora, il problema è quasi sempre una linea di arrivo scritta male.

Per i prompt che devono funzionare anche su altri modelli, vedi prompt che funzionano su più modelli; per la raccolta generale, prompt per Claude.

Conclusione

Il prompt per Opus 5.5 è più corto di quello per i modelli precedenti e più preciso su una cosa sola: dove deve arrivare. Togli le istruzioni sul ragionamento, scrivi cosa vuol dire finito, di' quando fermarsi. Il resto — esempi, formato, esclusioni — vale come sempre.

Vuoi capire quali processi della tua azienda possono essere automatizzati con l'AI? Giallo Studio può aiutarti a trasformare il problema in un workflow reale.