
I prompt aiutano, i sistemi scalano
Che cosa rende buono o cattivo un prompt, con esempi, perché i soli prompt non bastano quando un’azienda cresce e perché skill, regole e un cervello aziendale funzionano meglio.
La maggior parte delle aziende ha incontrato l’IA attraverso una casella vuota e un cursore lampeggiante. Ciò che ne usciva dipendeva da ciò che vi entrava, così le persone hanno imparato a scrivere prompt. Alcune sono diventate molto brave. I loro colleghi chiedevano le parole magiche, le parole venivano incollate in documenti e chat, ed è nato un nuovo tipo di folklore.
Il prompting conta, e vale la pena farlo bene. Ma un’azienda non può funzionare sul folklore. Ecco che cosa rende buono un prompt, che cosa raccomandano gli stessi laboratori e perché le aziende che ottengono di più dall’IA smettono di affidarsi a prompt ingegnosi.
Un prompt cattivo e uno buono
Prendiamo una richiesta che ogni team marketing fa. La versione cattiva suona così: scrivi un post LinkedIn sul nostro nuovo servizio.
Il modello non ha nulla con cui lavorare, quindi scrive il post LinkedIn medio sul servizio medio, con una domanda in apertura, una fila di emoji e una call to action. Non è sbagliato. Non è di nessuno.
La versione buona dice chi scrive e per chi, che cos’è il servizio e quanto costa, che cosa dovrebbe fare poi chi legge, quanto può essere lungo il post e quali parole l’azienda non usa mai. Include due post precedenti che hanno funzionato, indicati come esempi. E dice perché: il post va a responsabili finanziari scettici verso l’IA, quindi dovrebbe aprirsi con un fatto, non con una promessa.
Il secondo prompt è molto più lungo, e molto più probabilmente produce una bozza utilizzabile. La differenza non è l’ingegno. È il contesto.
Che cosa raccomandano i laboratori
Le guide ufficiali dei tre grandi laboratori dicono più o meno la stessa cosa.
La guida di Anthropic per Claude chiede di «pensare a Claude come a un dipendente brillante ma nuovo, privo di contesto sulle vostre norme e sui vostri flussi di lavoro.» La sua regola d’oro: «Mostrate il vostro prompt a un collega che sa poco del compito e chiedetegli di seguirlo. Se fosse confuso, lo sarà anche Claude.» Mostra anche perché i motivi battono gli ordini. Invece di scrivere in maiuscolo «non usare mai i puntini di sospensione», spiegate che la risposta verrà letta ad alta voce da un motore di sintesi vocale che non sa pronunciarli. Il modello generalizza a partire dal motivo.
La guida di OpenAI raccomanda di dare al modello il contesto che gli serve ed esempi di possibili input con gli output desiderati, in una gamma varia. La definisce «un misto di arte e scienza.»
La guida di Google per Gemini raccomanda di includere sempre qualche esempio e avverte che i prompt che ne sono privi rischiano di essere meno efficaci. Per i compiti complessi suggerisce di trasformare ogni passaggio in un prompt a sé e di concatenarli. E con onestà ammette com’è il processo: «Il prompt engineering è iterativo.»
Perché i prompt non scalano
Rileggete quelle guide e notate che cosa presuppongono: qualcuno che conosce le norme dell’azienda, ha a portata di mano gli esempi giusti e ha tempo di iterare. Nella maggior parte dei team questo descrive poche persone, in una buona giornata.
Tutti gli altri copiano un prompt da una chat, cambiano una parola e ottengono un risultato diverso. Il prompt che funzionava in primavera si comporta diversamente dopo un aggiornamento del modello. Due team conservano due versioni, con regole che si contraddicono. Una delle guide di OpenAI sul prompting avverte che istruzioni contraddittorie o vaghe possono fare più danni a un modello di ragionamento, perché spende energie nel tentativo di conciliarle. Il suo esempio è un assistente sanitario a cui viene detto sia di non fissare mai un appuntamento senza il consenso registrato del paziente, sia di fissare il primo slot disponibile senza prima contattare il paziente.
OpenAI tratta i prompt come software per questo motivo. La sua guida dice agli sviluppatori di tenere i prompt di produzione nel codice dell’applicazione, di legare le applicazioni a snapshot specifici del modello e di costruire test e suite di valutazione che misurano come si comportano i prompt. È l’opposto di una biblioteca di prompt in un documento condiviso.
Il costo si vede nei risultati. L’iniziativa NANDA del MIT ha riferito lo scorso anno che solo circa il 5 per cento dei progetti pilota di IA che ha studiato ha ottenuto una rapida accelerazione dei ricavi. Fortune ne ha riassunto la causa come un divario di apprendimento: gli strumenti generici si arenano nelle aziende perché non imparano dal modo in cui il lavoro viene svolto né vi si adattano.
Dai prompt ai sistemi
I laboratori hanno tratto da soli la conclusione. Anthropic parla ora di ingegneria del contesto anziché di ingegneria dei prompt: curare tutto ciò che il modello vede, non solo l’istruzione, e trovare il più piccolo insieme possibile di token ad alto segnale che renda probabile il risultato giusto. I suoi ingegneri mettono in guardia da due modi di fallire: da un lato una logica fragile, cablata nei prompt, dall’altro indicazioni vaghe che non danno al modello nulla di concreto.
La risposta pratica sono le skill. Anthropic le descrive come «cartelle organizzate di istruzioni, script e risorse» che un agente carica quando gli servono, e paragona la stesura di una a «preparare una guida di inserimento per un nuovo assunto.» In un post sul design, la stessa azienda ha scritto che le skill rendono riutilizzabili e contestuali i prompt efficaci, così nessuno deve ripetere le stesse indicazioni in ogni richiesta. Da dicembre 2025 il formato è uno standard aperto.
Una skill è un buon prompt scritto una sola volta, corredato di motivi, esempi e verifiche, testato e messo dove ogni assistente dell’azienda può trovarlo. Aggiungete la conoscenza dell’azienda, le sue regole e i suoi collegamenti ai sistemi reali, e avete un cervello aziendale. A quel punto la qualità non dipende più da chi ha digitato.
Come aiutiamo
È il lavoro che sta dietro a Twin. Scopriamo come funziona davvero un’azienda, miglioriamo il processo dove serve e poi costruiamo il suo cervello: conoscenza con la fonte in ogni risposta, skill per ogni ruolo scritte secondo le convenzioni dell’azienda, integrazioni con i suoi sistemi, regole e diritti per ruolo. Funziona nell’assistente che il team usa già, Claude, ChatGPT o Codex, e l’azienda riceve il codice sorgente.
Senza Twin ogni prompt parte da zero e la qualità dipende da chi chiede. Con Twin ogni risposta parte dall’azienda, con un unico standard su ogni scrivania.
Gestiamo crue allo stesso modo: più di 80 skill e un cervello per ciascuno dei nostri prodotti, in Claude e ChatGPT e sul nostro hardware con un nostro modello. Quando i dati sono troppo sensibili per uscire dall’edificio, c’è Eigna, sviluppato dal nostro partner Eigna Labs: un modello privato addestrato sui file, sulle regole e sul linguaggio dell’azienda, che gira nel suo cloud o sui suoi server e viene riaddestrato per passi che entrano in servizio solo quando nei test risultano migliori.
Che cosa può fare un’azienda
Continuate a scrivere bene i prompt e imparate le basi dalle guide qui sopra. Poi raccogliete i dieci prompt che le vostre persone migliori usano davvero e chiedete che cosa sa ciascuno che il modello non sa. Scrivetelo una volta sola: il contesto, i motivi, gli esempi, le regole e la verifica finale. Date a ciascuno un responsabile e un test, e metteteli dove ogni assistente può raggiungerli. Questa è una skill.
Vogliamo che la macchina si prenda la routine, le prime bozze e le ricerche, e le faccia più in fretta e con più coerenza di qualunque di noi. Il giudizio, il contatto personale con i clienti e la responsabilità di ciò che viene inviato restano alle persone, e un buon sistema dà loro più tempo proprio per questo.
Un prompt ingegnoso rende più veloce una persona. Un sistema migliora l’intera azienda, e continua a funzionare quando la persona ingegnosa è tornata a casa.




