Prompt Engineering 101: Guida per Principianti a Risultati Migliori dall'IA
22 settembre 2026
"Prompt engineering" suona come una competenza tecnica specialistica, ma la maggior parte di ciò che migliora davvero i risultati dell'IA si riduce a un pugno di abitudini che chiunque può imparare in un pomeriggio. Nessuna di queste è un trucco o una formula magica — funzionano per il modo in cui i modelli linguistici elaborano davvero le istruzioni, e capire il perché le rende molto più facili da applicare in modo coerente.
Perché essere specifici conta più che essere arguti?
Un modello non ha accesso al contesto che hai in testa — ha solo le parole che hai effettivamente digitato. "Scrivi qualcosa sul nostro prodotto" lascia al modello il compito di indovinare il tuo tono, pubblico, lunghezza e obiettivo, e indovinerà qualcosa di plausibile ma generico. "Scrivi un post LinkedIn di 100 parole che annuncia il nostro prodotto a piccoli imprenditori, con un tono sicuro di sé ma non da venditore, che finisce con una domanda" elimina quasi tutte queste supposizioni. La specificità non è una preferenza stilistica, è fornire direttamente le informazioni di cui il modello ha bisogno e che altrimenti non avrebbe.
Perché gli esempi migliorano il risultato più delle istruzioni più lunghe?
Descrivere uno stile desiderato in astratto ("rendilo incisivo e professionale") è intrinsecamente ambiguo — incisivo e professionale significano cose diverse per persone diverse, e il modello deve indovinare quale versione intendi. Fornire uno o due esempi dello stile, formato o tono esatto che vuoi ancora il modello a qualcosa di concreto invece che a una descrizione astratta, il che è costantemente più affidabile che cercare di descrivere lo stile target con sempre più aggettivi.
Cosa ottiene davvero assegnare a un modello un ruolo o una persona?
Formulare una richiesta come "sei un commercialista esperto che spiega questo a chi presenta la dichiarazione dei redditi per la prima volta" fa due cose reali: restringe lo spazio delle risposte plausibili verso le convenzioni e il vocabolario di quel dominio, e imposta implicitamente un tono appropriato e un livello di conoscenza presunta senza che tu debba specificarli separatamente. È un modo compatto di codificare informazioni su pubblico e livello di competenza che altrimenti richiederebbero diverse frasi per essere specificate esplicitamente.
Perché suddividere una richiesta complessa in passaggi produce risultati migliori di un unico grande prompt?
Un unico prompt denso che chiede contemporaneamente ricerca, analisi e output formattato costringe il modello a destreggiarsi tra più obiettivi simultaneamente, e la qualità di ciascuno può risentirne. Suddividere la stessa richiesta in passaggi sequenziali — prima abbozzare la struttura, poi scrivere la bozza di ogni sezione, poi rivedere e affinare — permette al modello di concentrarsi pienamente su un obiettivo alla volta, e ti permette di rivedere e correggere i risultati intermedi prima che si accumulino nel risultato finale. Questo conta soprattutto per compiti genuinamente complessi e multi-parte; le richieste semplici non ne hanno bisogno.
Vale la pena dire a un modello cosa NON fare, o questo lo confonde soltanto?
Le istruzioni negative ("non usare gergo aziendale", "non includere un paragrafo conclusivo") funzionano, ma sono generalmente meno affidabili delle istruzioni positive che descrivono ciò che vuoi davvero, perché il modello deve comunque generare qualcosa e un'assenza è più difficile da centrare di una presenza. "Non essere troppo formale" è un'indicazione più debole di "scrivi con un tono informale e colloquiale, come se lo spiegassi a un amico" — la seconda dà al modello qualcosa di concreto a cui mirare, invece di un semplice confine da evitare.
Perché la prima bozza di un modello raramente sembra la versione finita?
La prima risposta di un modello a qualsiasi prompt non banale è il suo miglior tentativo unico di soddisfare tutto ciò che è nelle tue istruzioni in una sola volta — non ha ancora visto la tua reazione. Trattare il primo risultato come una bozza su cui iterare, invece che come una risposta finale da accettare o rifiutare in blocco, è costantemente più produttivo: segnalare specificamente cosa non va ("più corto", "esempi più concreti", "taglia il secondo paragrafo") e chiedere una revisione di solito avvicina a ciò che volevi davvero più velocemente che cercare di scrivere il prompt perfetto al primo tentativo.