Un prompt è l’input con cui comunichi a un sistema di intelligenza artificiale ciò che vuoi ottenere. Può essere una domanda, un’istruzione, un testo da analizzare oppure, nei sistemi multimodali, includere immagini, audio e altri contenuti. OpenAI usa questa definizione estesa nelle sue best practice ufficiali sul prompt engineering.
La definizione, però, spiega solo il punto di partenza. Scrivere una buona richiesta non significa trovare una formula magica capace di obbligare l’AI a produrre la risposta perfetta. Significa descrivere con sufficiente chiarezza il compito, fornire il contesto necessario, indicare eventuali vincoli e verificare se il risultato soddisfa davvero l’obiettivo.
È qui che prompting e prompt engineering diventano interessanti. La documentazione corrente dei principali provider converge su un principio molto più concreto delle formule che circolano online: il processo è iterativo. Google lo dichiara esplicitamente nella propria guida alla progettazione delle istruzioni per Gemini, mentre Anthropic suggerisce addirittura di definire criteri di successo e un metodo per testarli prima di iniziare l’ottimizzazione.
In questa guida vedremo quindi cosa sono i prompt, come vengono utilizzati dall’intelligenza artificiale, come formulare richieste efficaci e quali tecniche meritano davvero attenzione. Ma soprattutto chiariremo un punto spesso trascurato: l’input è soltanto una parte del sistema. Modello, contesto, fonti disponibili, strumenti e qualità della verifica possono incidere quanto le parole che scrivi.
Che cos’è un prompt nell’intelligenza artificiale
Nel contesto dell’AI generativa, un prompt è l’insieme di informazioni e istruzioni fornite a un modello per orientarne l’output.
La versione più semplice può essere una domanda:
Spiegami che cos’è il DNS.
Una richiesta più precisa potrebbe invece essere:
Spiega a un proprietario di un sito WordPress, senza competenze sistemistiche, che cos’è il DNS e perché un errore nei record può rendere irraggiungibile il sito. Usa un esempio concreto e limita la risposta a circa 300 parole.
La seconda formulazione non contiene parole segrete. Specifica semplicemente obiettivo, pubblico, contesto e caratteristiche del risultato atteso.
Questo è il punto da tenere a mente: un input efficace riduce lo spazio lasciato alle interpretazioni che non ti interessano.
Prompt, prompting e prompt engineering: cosa cambia
I tre termini sono collegati, ma non sono sinonimi perfetti.
Prompt indica l’input fornito al modello.
Prompting descrive più generalmente l’attività di interazione con un sistema AI attraverso richieste e istruzioni.
Prompt engineering, o ingegneria dei prompt, indica un approccio più sistematico: progettare, testare e modificare gli input per migliorare il comportamento del modello rispetto a uno specifico obiettivo.
La distinzione conta soprattutto quando passi dall’uso occasionale a un workflow ripetibile.
Se chiedi una volta a un chatbot di riassumere un documento, stai semplicemente fornendo un’istruzione. Se devi costruire un processo che riassuma centinaia di documenti rispettando sempre gli stessi criteri, la progettazione dell’input diventa parte di un problema più ampio di affidabilità e valutazione.
Anthropic, per esempio, nella sua documentazione sul prompt engineering parte da tre elementi: criterio di successo, possibilità di testarlo e una prima versione della richiesta da migliorare.
È una prospettiva utile perché sposta l’attenzione dalla frase “bella” al risultato verificabile.
Dal prompt informatico al prompt per l’AI generativa
Il termine prompt non nasce con ChatGPT.
Nell’informatica tradizionale può indicare il segnale mostrato da un programma o da una shell per comunicare che il sistema è pronto a ricevere un comando. Con l’AI generativa il significato si è allargato: oggi indica comunemente l’input attraverso cui orientiamo un modello verso un compito o un risultato.
Cambia soprattutto il tipo di interazione.
In una shell, un comando deve rispettare una sintassi abbastanza precisa. Con un modello linguistico puoi usare il linguaggio naturale, aggiungere esempi, correggere la richiesta durante la conversazione e fornire materiale su cui lavorare.
Questa flessibilità rende i sistemi generativi molto accessibili, ma crea anche una falsa impressione: che basti “parlare bene” all’AI per controllarla completamente. Non è così.
Come funziona davvero una richiesta inviata all’AI
Per capire perché alcune istruzioni funzionano meglio di altre bisogna separare intenzione umana e informazioni effettivamente disponibili al modello.
Tu puoi sapere perfettamente cosa intendi con:
Scrivimi una buona landing page.
Il modello, invece, non possiede automaticamente il contesto che hai in testa: prodotto, pubblico, obiezioni, posizionamento, tone of voice, vantaggi competitivi, CTA, vincoli legali e obiettivo della pagina.
Deve lavorare con ciò che riceve nel contesto della conversazione e con le capacità del sistema utilizzato.
Per approfondire il meccanismo di base puoi partire dalla nostra guida sui Large Language Model e su come funzionano.
Il modello non conosce automaticamente il risultato che hai in mente
Considera questa richiesta:
Scrivi una descrizione per un hosting WordPress.
È formalmente corretta, ma lascia aperte moltissime decisioni. Il modello deve scegliere da solo pubblico, profondità, tono, caratteristiche da enfatizzare e formato.
Puoi renderla più utile:
Scrivi una descrizione di circa 150 parole per una pagina che presenta un hosting WordPress gestito a piccole aziende italiane. Il lettore non conosce la terminologia server. Spiega soprattutto backup, sicurezza e supporto, evitando superlativi e affermazioni non verificabili. Chiudi con una frase che inviti a confrontare il servizio con le proprie esigenze tecniche.
Qui non stai utilizzando una tecnica esoterica. Stai trasformando un’intenzione implicita in una specifica più leggibile.
Ed è proprio questo uno degli usi migliori del prompting.
Perché lo stesso input può produrre risultati diversi
Una richiesta non esiste nel vuoto.
L’output può cambiare in funzione del modello utilizzato, della versione, del contesto della conversazione, delle istruzioni di sistema, dei documenti forniti, degli strumenti disponibili e delle impostazioni dell’applicazione.
Anche per questo non conviene trattare una formula trovata online come una ricetta universale.
Un template può essere un ottimo punto di partenza. Ma se è stato progettato per un altro modello, un altro pubblico o un altro tipo di risultato, devi comunque verificarlo nel tuo scenario.
La documentazione di Google descrive infatti le tecniche di prompting per Gemini come punti di partenza da sperimentare e perfezionare sulla base degli output osservati, non come regole capaci di garantire sempre lo stesso risultato.
Com’è fatto un input efficace
Non esiste una struttura obbligatoria valida per qualsiasi richiesta.
Alcuni compiti hanno bisogno di due righe; altri richiedono documenti, esempi, criteri e molte informazioni.
Esiste però un modello mentale utile:
obiettivo → contesto necessario → istruzioni → vincoli → formato → criteri di successo
Non devi compilare sempre tutte queste parti. Devi capire quali sono necessarie per ridurre l’ambiguità del compito.
Obiettivo: definire cosa deve ottenere l’AI
La prima domanda non è:
Come formulo il prompt?
È:
Che risultato voglio ottenere?
“Parlami della SEO” è una richiesta.
“Spiega a un ecommerce manager quali problemi SEO possono nascere quando filtri e faceted navigation generano migliaia di URL” è un obiettivo molto più concreto.
Quando il risultato desiderato è chiaro, diventa anche più semplice valutare se la risposta è utile.
Contesto: dare al modello le informazioni che gli servono
Contesto non significa raccontare tutto.
Significa fornire le informazioni che cambiano materialmente il risultato.
Per riscrivere una mail possono servire destinatario, relazione professionale, problema e azione richiesta. La storia completa dell’azienda probabilmente no.
Per analizzare una strategia SEO possono invece servire dati Search Console, URL, mercato, query, obiettivi commerciali e modifiche già apportate.
Aggiungere informazioni inutili rende l’input più lungo senza renderlo necessariamente migliore.
Vincoli, esempi e dati: delimitare il problema
I vincoli sono utili quando eliminano alternative che non vuoi.
Puoi specificare, per esempio:
- informazioni che non devono essere inventate;
- fonti che devono essere utilizzate;
- elementi da preservare;
- aspetti che non devono essere modificati;
- limiti del perimetro della risposta.
Gli esempi diventano particolarmente utili quando è difficile spiegare il risultato atteso soltanto con una descrizione.
Google include il few-shot prompting fra le tecniche che forniscono esempi al modello. Anthropic indica anch’essa gli esempi come uno strumento utile per orientare formato, struttura e comportamento dell’output.
Output e criteri di successo: specificare cosa significa una buona risposta
Chiedere semplicemente:
Dammi una risposta completa.
è poco informativo.
Molto meglio:
Confronta le tre soluzioni in una tabella con costo, vantaggio principale, limite principale e scenario d’uso. Dopo la tabella, indica quale sceglieresti per un ecommerce con catalogo superiore a 10.000 prodotti e spiega il motivo.
Adesso puoi controllare se il modello ha davvero soddisfatto il compito.
Questo passaggio è particolarmente importante nei workflow professionali: se non sai definire quando l’output è corretto, diventa difficile migliorare l’input in modo razionale.
Come scrivere un prompt AI passo per passo
Il modo più semplice per migliorare il prompting è smettere di cercare subito la formula definitiva.
Parti da una prima versione sufficientemente chiara, prova il modello, osserva dove sbaglia e correggi soltanto ciò che serve.
Parti dal risultato, non dalla formulazione
Supponiamo di voler creare una sequenza di email per recuperare carrelli abbandonati.
Un approccio debole sarebbe cercare online un template enorme e incollarlo senza adattarlo.
Un approccio migliore parte dal problema:
Devo creare tre email per utenti che hanno aggiunto prodotti al carrello ma non hanno acquistato.
Ora puoi aggiungere le informazioni realmente utili:
Il negozio vende arredamento di fascia media. Il pubblico principale ha 30-55 anni. Non voglio usare sconti nella prima email. Il tono deve essere professionale e semplice. La sequenza deve distinguere reminder, gestione delle obiezioni e ultima chiamata.
La richiesta cresce perché cresce l’informazione utile, non perché deve sembrare sofisticata.
Scrivi la prima istruzione con il minimo contesto necessario
Un errore frequente è cercare di anticipare qualsiasi possibile problema inserendo pagine di istruzioni.
Meglio partire con un input abbastanza completo da rendere il task interpretabile.
OpenAI raccomanda per ChatGPT richieste chiare, specifiche e dotate del contesto necessario, ma sottolinea anche il valore del raffinamento iterativo nelle sue best practice: partire da una formulazione, osservare la risposta e modificarla in base a ciò che effettivamente manca.
Questo evita due estremi:
richieste troppo vaghe, che costringono il modello a colmare molti vuoti;
istruzioni troppo costruite, nelle quali eccezioni e regole iniziano a interferire fra loro.
Controlla l’output e modifica solo ciò che non funziona
Questa è la fase che trasforma un’interazione casuale in prompting consapevole.
Se la risposta è troppo generica, chiediti perché.
Manca il pubblico?
Mancano dati?
Il risultato atteso non è chiaro?
Hai chiesto cinque attività diverse insieme?
Serve un esempio?
L’output richiede fonti che non sono state fornite?
Il principio è semplice: diagnostica il problema del risultato prima di complicare l’input.
Trasforma una struttura riuscita in un template riutilizzabile
Quando trovi una formulazione che funziona in uno scenario ripetitivo, puoi separare parti stabili e variabili.
Per esempio:
Analizza [URL/PAGINA] per il pubblico [TARGET] con l’obiettivo [OBIETTIVO].
Usa esclusivamente [FONTI/DATI].
Valuta [CRITERI].
Restituisci [FORMATO].
Se un dato necessario non è disponibile, segnalalo invece di inventarlo.
Questo è molto più utile di un “super prompt” universale: hai creato una specifica parametrica per un compito reale.
Tecniche di prompting che vale davvero la pena conoscere
Il prompt engineering ha prodotto una quantità enorme di tecniche, tassonomie e framework. Non devi impararle tutte per usare bene l’intelligenza artificiale.
Alcune, però, aiutano a comprendere cosa stai facendo.
Zero-shot e few-shot prompting
Nel zero-shot prompting chiedi direttamente al modello di svolgere un compito senza fornirgli esempi del risultato.
Classifica questa recensione come positiva, neutra o negativa.
Nel few-shot prompting aggiungi invece uno o più esempi che mostrano la relazione tra input e output.
Recensione: “Consegna veloce, prodotto perfetto.”
Classificazione: positivaRecensione: “Il prodotto funziona ma è arrivato in ritardo.”
Classificazione: neutraOra classifica: “Assistenza inesistente e articolo difettoso.”
Gli esempi sono particolarmente utili quando la categoria, il formato o il criterio che hai in mente non è ovvio soltanto dalla descrizione.
Role prompting: utile quando il ruolo definisce criteri reali
“Agisci come un esperto mondiale” è spesso quasi decorativo.
Un ruolo diventa più utile quando modifica concretamente il criterio con cui il modello deve affrontare il compito.
Per esempio:
Analizza questo checkout dal punto di vista di un consulente UX che deve individuare attriti prima del pagamento.
Il valore non sta nell’etichetta “consulente UX”. Sta nel fatto che stai definendo la prospettiva attraverso cui osservare l’oggetto.
Se puoi esprimere direttamente i criteri, spesso è ancora meglio:
Analizza il checkout concentrandoti su chiarezza dei costi, error prevention, campi obbligatori, fiducia e frizione prima del pagamento.
Prompt chaining: dividere i compiti complessi in passaggi
Una singola istruzione può chiedere:
Analizza la SERP, trova i gap, costruisci la strategia, scrivi l’articolo, verifica tutte le fonti e prepara il piano editoriale.
Ma queste attività dipendono una dall’altra. Se la prima analisi è sbagliata, l’errore si propaga.
Con il prompt chaining il risultato di un passaggio alimenta quello successivo:
analisi → decisione → struttura → sviluppo → verifica
Il vantaggio non è semplicemente avere richieste più corte. È poter controllare i punti intermedi e correggere il workflow prima che un errore diventi parte del risultato finale.
Input multimodali: quando non c’è soltanto testo
Nei modelli multimodali puoi combinare istruzioni con immagini, documenti, audio e altri contenuti.
Per esempio puoi fornire lo screenshot di una landing page e chiedere di analizzarne la gerarchia visiva, oppure allegare un PDF e richiedere un confronto fra alcune clausole.
Per la generazione visuale, invece, la richiesta deve descrivere ciò che deve essere rappresentato. Se questo è il tuo caso specifico, abbiamo una guida separata dedicata ai prompt per Midjourney.
Il principio resta lo stesso: il tipo di input deve essere coerente con il problema da risolvere.
Prompt semplice o dettagliato: quando aggiungere informazioni peggiora il risultato
“Più dettagli = risultato migliore” è una regola troppo semplicistica.
Le informazioni aiutano quando eliminano ambiguità significativa. Possono diventare un problema quando aggiungono rumore, ripetizioni o istruzioni in conflitto.
Il problema delle richieste troppo vaghe
Prendi:
Migliora questa pagina.
“Migliora” può significare quasi tutto: copy, SEO, accessibilità, conversione, design, velocità, struttura informativa.
Una formulazione più utile potrebbe essere:
Analizza il testo di questa landing page e individua i punti in cui la proposta di valore non è chiara. Non riscrivere ancora il contenuto: restituisci prima problema, conseguenza e modifica consigliata.
Il risultato diventa più prevedibile perché hai delimitato il task.
Il problema opposto: istruzioni sovraccariche e in conflitto
Ora immagina una richiesta che chiede contemporaneamente di essere:
“molto sintetica”, “estremamente approfondita”, “adatta a principianti”, “tecnica per specialisti”, “informale”, “istituzionale”, “creativa” e “rigorosamente aderente a un template”.
Il modello deve risolvere compromessi che l’utente non ha risolto prima.
I sistemi più recenti rendono ancora meno utile la complessità fine a sé stessa. Nella guida corrente a Gemini 3, Google consiglia istruzioni dirette, chiare e concise e segnala che tecniche verbose o molto complesse progettate per modelli precedenti possono portare a un’elaborazione inutile.
È un consiglio specifico per quella famiglia di modelli, non una legge universale, ma mostra bene perché il prompting deve essere model-aware.
Esempi pratici: da una richiesta generica a una specifica utilizzabile
La differenza si vede bene confrontando scenari reali.
| Obiettivo | Richiesta vaga | Formulazione più utile | Cosa cambia |
|---|---|---|---|
| Scrittura | Scrivi un articolo sulla SEO | Spiega a un responsabile marketing quali segnali indicano che un articolo SEO deve essere aggiornato. Distingui calo di domanda, perdita di ranking e mismatch di intent. | definisce pubblico, problema e confini |
| Analisi | Analizza questi dati | Analizza il CSV allegato e individua le query con molte impressioni e posizione media 8-20. Non dedurre causalità dai soli dati. | definisce dataset, criterio e limite |
| Ecommerce | Scrivi una scheda prodotto | Scrivi una descrizione usando solo le caratteristiche presenti nella scheda tecnica. Se manca un’informazione, non aggiungerla. | riduce invenzioni e definisce la fonte |
| Ricerca | Fammi una ricerca sull’argomento | Confronta le fonti allegate, separa fatti confermati, opinioni e punti di disaccordo. Indica quali conclusioni non sono supportate dalle fonti. | trasforma ricerca in verifica |
| Immagini | Crea un’immagine tecnologica | Crea una hero 16:9 che rappresenti un modello AI mentre trasforma istruzioni e contesto in un output, senza UI reali, testo o loghi. | definisce soggetto, formato e divieti |
Nessuno di questi esempi contiene formule particolarmente elaborate.
La qualità deriva dal fatto che il compito è stato progettato prima di essere formulato.
Un buon prompt può impedire errori e allucinazioni dell’AI?
No. Può ridurre alcuni errori, ma non rende un modello infallibile.
Puoi chiedere al sistema di dichiarare quando non possiede informazioni sufficienti, utilizzare esclusivamente un documento fornito, distinguere fatti da ipotesi o associare le affermazioni alle fonti disponibili.
Sono precauzioni utili.
Anthropic, nella propria documentazione sulla riduzione delle allucinazioni, suggerisce fra le altre cose di permettere al modello di ammettere l’incertezza e di verificare i claim attraverso fonti e citazioni.
Ma rimane necessario controllare il risultato, soprattutto quando la risposta riguarda dati, medicina, diritto, sicurezza, prezzi, versioni software o altre informazioni dove l’errore può avere conseguenze concrete.
Per approfondire il fenomeno trovi la nostra guida dedicata alle AI hallucination.
Cosa puoi controllare con istruzioni, fonti e vincoli
Immagina di chiedere:
Qual è il prezzo attuale di questo software?
Il sistema potrebbe basarsi su informazioni incomplete o non aggiornate.
È molto più robusto costruire il task così:
Usa esclusivamente la pagina prezzi ufficiale che ti fornisco. Riporta i piani disponibili e la data della verifica. Se un prezzo non è esplicitamente presente, indicarlo come non disponibile.
Qui la formulazione migliora il processo perché stabilisce fonte, data e comportamento in caso di informazione mancante.
Per informazioni correnti, però, serve anche accesso a dati correnti. Google descrive il grounding con Google Search come un modo per collegare Gemini a informazioni web reali, fornire citazioni e aumentare l’accuratezza fattuale rispetto alla sola conoscenza del modello.
Il punto è importante: un problema di informazione non si risolve sempre riscrivendo la richiesta.
Cosa il prompting non può correggere da solo
Una buona formulazione non può:
- trasformare una fonte sbagliata in una fonte corretta;
- conoscere automaticamente un’informazione non disponibile al modello;
- garantire che una conclusione sia vera;
- sostituire un database, una ricerca o un sistema di retrieval quando sono necessari;
- compensare sempre la scelta di un modello inadatto al compito;
- eliminare completamente l’incertezza della generazione.
È uno dei motivi per cui nei workflow avanzati il prompting viene affiancato da retrieval, strumenti, validazione, eval e controllo umano.
Un esempio concreto è l’approccio dei notebook basati sulle fonti: nella nostra guida a Gemini Notebook abbiamo visto come un ambiente costruito attorno a documenti selezionati cambi il tipo di lavoro possibile rispetto a una semplice domanda isolata.
Gli errori più comuni quando si scrivono prompt
L’errore più comune non è dimenticare una formula. È non aver definito il problema.
Se chiedi all’AI di “creare una strategia marketing” senza specificare azienda, pubblico, obiettivo, dati disponibili e vincoli, riceverai facilmente una strategia generica. Non perché la richiesta sia troppo corta in senso assoluto, ma perché manca informazione decisionale.
Un secondo errore è confondere contesto e quantità. Incollare dieci pagine di background non garantisce una risposta migliore se solo tre informazioni sono realmente pertinenti.
C’è poi il problema opposto: dirigere ogni dettaglio dell’output. Se specifichi decine di regole contemporaneamente, alcune possono sovrapporsi o creare compromessi non risolti. In quel caso è spesso meglio dividere il compito.
Un altro errore frequente è chiedere al modello di fare qualcosa senza fornirgli ciò che serve per riuscirci. “Verifica questi dati” non funziona se non gli dai dati o accesso a una fonte verificabile.
Infine c’è l’errore più pericoloso: giudicare la qualità dell’input dall’aspetto della risposta.
Un testo può essere fluido, professionale e perfettamente formattato ma contenere un dato falso. Un codice può sembrare sensato ma non funzionare. Una sintesi può eliminare proprio la clausola più importante del documento.
Il risultato va quindi giudicato rispetto al compito, non rispetto alla sua eleganza formale.
Il prompt engineering sta diventando meno importante?
Dipende da cosa intendiamo per prompt engineering.
Se intendiamo la ricerca di formule, parole speciali e lunghe sequenze necessarie per “sbloccare” un modello, quella parte sta perdendo importanza in molti utilizzi.
OpenAI osserva nelle proprie indicazioni per creare buone richieste che l’interazione può basarsi sempre più su un linguaggio naturale orientato all’obiettivo e sul raffinamento progressivo.
Google, come abbiamo visto, offre una raccomandazione simile ma specifica per Gemini 3: istruzioni concise e precise possono funzionare meglio di scaffolding progettati per generazioni precedenti.
Non significa che il prompting non conti più. Significa che la competenza si sposta dalla retorica dell’input alla progettazione del compito.
Modelli più capaci richiedono meno formule, non meno chiarezza
Immagina due scenari.
Nel primo memorizzi un framework di dodici elementi e lo applichi a qualsiasi richiesta.
Nel secondo sai definire il problema, scegliere i dati necessari, dare un esempio quando serve, stabilire il formato, verificare l’output e cambiare modello o workflow quando la formulazione non basta.
Il secondo approccio è molto più resistente all’evoluzione della tecnologia.
Le tecniche specifiche possono cambiare. Chiarezza dell’obiettivo, qualità del contesto e capacità di verificare il risultato restano competenze utili anche quando i modelli diventano più capaci.
Dal “prompt perfetto” alla progettazione del contesto e del workflow
Qui emerge una distinzione importante.
In un chatbot semplice l’input è molto visibile: scrivi una domanda e ricevi una risposta.
In un sistema professionale, invece, la richiesta può essere soltanto l’ultimo pezzo di un ambiente composto da:
dati aziendali, documenti, cronologia, istruzioni permanenti, strumenti, API, permessi, retrieval e criteri di validazione.
Per questo parlare soltanto di prompt engineering rischia, in alcuni scenari, di essere riduttivo.
Lo stesso principio emerge anche nell’evoluzione dei website builder AI. Nell’analisi di Elementor 4.2, Atomic Editor e Angie abbiamo visto che generare un elemento non richiede soltanto una frase ben formulata: brand, pubblico, design system, componenti, vincoli e criteri di qualità costituiscono il contesto che impedisce all’automazione di produrre decisioni incoerenti.
L’input rimane l’interfaccia con cui esprimi una parte della richiesta. Il risultato dipende sempre più dall’ambiente informativo e operativo costruito intorno al modello.
Come capire se la tua formulazione funziona davvero
Non chiederti:
Questo è un prompt professionale?
Chiediti:
Produce con sufficiente affidabilità il risultato che mi serve?
La differenza sembra piccola, ma cambia completamente il metodo.
Valutare il risultato invece della bellezza dell’input
Per una classificazione puoi verificare quante risposte sono corrette.
Per una sintesi puoi controllare se mantiene i fatti essenziali e non introduce informazioni nuove.
Per un contenuto editoriale puoi verificare factuality, copertura dell’intento, aderenza alle fonti, tono e utilità.
Per codice puoi eseguire test.
Per un processo ripetibile puoi costruire un piccolo set di casi reali e controllare se una modifica migliora davvero il comportamento medio invece di correggere soltanto un esempio.
È questo il passaggio dal prompting occasionale alla progettazione.
Iterare, confrontare e conservare ciò che funziona
Quando una struttura viene utilizzata ripetutamente, conviene conservarne le versioni.
Non per creare una collezione infinita di template, ma per poter rispondere a domande concrete:
Quale variante ha funzionato meglio?
Quale istruzione ha ridotto gli errori?
Il nuovo modello richiede ancora quel vincolo?
Possiamo eliminare parti che non producono differenze?
La specifica è diventata così complessa perché sta cercando di compensare un problema che dovrebbe essere risolto altrove?
Quest’ultima domanda è particolarmente importante.
Anche Anthropic avverte nella propria documentazione sul prompt engineering che non tutti i problemi di una pipeline AI sono problemi risolvibili intervenendo sull’input: in alcuni casi può essere più efficace cambiare modello o modificare altri componenti del sistema.
Prompt AI: la regola da ricordare
Se devi ricordare un solo metodo, usa questo:
obiettivo → contesto utile → istruzioni → criteri → output → verifica → iterazione
Parti da ciò che vuoi ottenere. Fornisci soltanto le informazioni che cambiano il risultato. Specifica vincoli e formato quando servono. Controlla ciò che ricevi. Poi modifica la richiesta sulla base di un problema osservato, non perché un template online contiene cinquanta righe in più.
Il prompting rimane una competenza utile, ma il suo valore non sta nel conoscere una formula segreta.
Sta nel saper trasformare un problema ambiguo in un compito comprensibile, verificabile e ripetibile.
Ed è proprio questo che distingue una richiesta semplicemente lunga da una richiesta realmente efficace.