Il prompting preciso è specificazione del contesto
20 giugno 2026 · 10 min di lettura
Abstract
Nel prompting esiste una checklist per principianti ormai familiare: definire compito, pubblico, tono, ruolo, contesto, vincoli, esempi e formato di output. È utile. Ma non basta.
La mia ipotesi è che il prompting preciso stia diventando meno una checklist universale e più una scelta dei dettagli che contano davvero per uno specifico modello, compito, workflow, livello di rischio e metodo di valutazione. In altre parole: la precisione di un prompt non è la sua lunghezza. È la sua aderenza al compito.
Questo articolo rivede guide pratiche di OpenAI, Anthropic e Microsoft, insieme a lavori accademici su tassonomie di prompting, prompt pattern, ottimizzazione automatica dei prompt, attività di software engineering e context engineering. Le fonti puntano nella stessa direzione: i dettagli utili in un prompt cambiano molto in base al contesto. Un prompt per estrarre JSON strutturato richiede elementi diversi da un prompt per sintesi legale, generazione frontend, tutoring, uso di strumenti da parte di agenti o correzione di codice.
La tesi resta un'ipotesi di lavoro. Ma è già pratica.
Il problema della checklist dei prompt
La maggior parte delle persone che usa LLMs da più di qualche settimana conosce i consigli standard.
Di' al modello cosa vuoi. Dagli un ruolo. Specifica il pubblico. Definisci il tono. Aggiungi esempi. Indica il formato di output. Magari aggiungi vincoli.
Non è sbagliato. È un buon inizio. Ma quando ho iniziato a usare LLMs per aiutarmi a scrivere prompt più dettagliati, ho notato una cosa leggermente fastidiosa e piuttosto interessante: l'elenco dei dettagli utili continuava a cambiare.
Per una rassegna della letteratura, i dettagli decisivi erano gerarchia delle fonti, stile di citazione, linguaggio dell'incertezza e distinzione tra evidenza e interpretazione.
Per una task frontend, i dettagli decisivi erano comportamento responsive, design system esistente, stati di interazione, accessibilità e asset visivi.
Per un workflow agentico, i dettagli decisivi erano permessi degli strumenti, confini di approvazione, criteri di arresto, passaggi di verifica e stato da preservare.
Stessa parola: "prompt". Oggetto di engineering molto diverso.
Il problema quindi non è se un prompt debba contenere "più dettagli". La domanda è troppo grezza. La domanda migliore è:
Quali dettagli sono operativamente rilevanti per questa attività?
Definirei operativamente rilevante un dettaglio che, se aggiunto, cambia la probabilità che il modello produca un risultato accettabile.
Sembra un po' formale, ma conta. Un prompt lungo può restare vago. Un prompt breve può essere preciso. La differenza sta nel nominare le variabili che guidano davvero il modello.
Come ho letto le fonti
Questa è una rassegna narrativa, non uno studio benchmark. Ho cercato fonti che coprissero cinque prospettive:
| Tipo di fonte | Esempi | Perché conta |
|---|---|---|
| Documentazione dei provider | OpenAI, Anthropic, Microsoft | Mostra come i consigli cambiano per modello, workflow e tipo di output |
| Tassonomie di prompting | The Prompt Report e survey affini | Mostra il prompting come ampio spazio di progettazione |
| Prompt pattern | White et al. | Tratta i prompt come pattern riutilizzabili ma da adattare |
| Ottimizzazione e studi empirici | APE, studi su prompt per il codice | Mostra che i dettagli possono essere scoperti e testati sui risultati |
| Context engineering | Survey recenti | Sposta il focus dalla formulazione all'intero payload informativo |
L'obiettivo non era dimostrare che ogni prompt debba essere complesso. Anzi. La tesi utile è più stretta: i dettagli giusti dipendono dal lavoro che il prompt deve svolgere.
Cosa suggerisce già la documentazione dei provider
La documentazione attuale di OpenAI su prompt engineering e prompt generation mostra entrambi i lati del tema. Ci sono consigli generali, ma la guida diventa presto specifica per il tipo di output. La guida alla generazione dei prompt tratta tipo di output, schemi, esempi, ordine tra ragionamento e conclusione, costanti e complessità del compito come variabili da controllare, non come un template fisso [1][2].
Anthropic è ancora più esplicita sull'importanza dei criteri di successo. La sua panoramica sul prompt engineering dice che prima di migliorare un prompt bisogna avere una definizione chiara del successo, un modo per testarlo e una prima bozza del prompt [3]. È un punto discreto ma importante. Il prompting diventa iterazione verso un obiettivo, non formulazione magica.
Le best practice di Anthropic distinguono poi molte situazioni: esempi, struttura XML, ruoli, lungo contesto, formattazione dell'output, uso di strumenti, thinking, sistemi agentici, frontend, migrazione tra versioni di modello e altro [4]. Sembra meno "ecco la formula unica" e più "ogni workflow espone leve di controllo diverse".
La documentazione Microsoft Azure OpenAI aggiunge un'avvertenza utile: costruire prompt è più arte che scienza, e i modelli si comportano in modo diverso [5]. Non è una scusa per prompt approssimativi. È un motivo per testarli.
| Segnale | Cosa suggerisce |
|---|---|
| OpenAI separa task, output, schema ed esempi | I dettagli vanno scelti in base all'output atteso |
| Anthropic parte da criteri di successo e test | Un prompt è un'ipotesi su ciò di cui il modello ha bisogno |
| Anthropic tratta contesto lungo, strumenti, agenti e frontend separatamente | Il "buon prompting" dipende dal workflow |
| Microsoft ricorda che i modelli differiscono | La precisione è anche sensibile al modello |
La letteratura rende visibile lo spazio di progettazione
Il supporto accademico più forte viene dall'ampiezza stessa del campo.
The Prompt Report cataloga 58 tecniche di prompting per LLMs e 40 tecniche per altre modalità [6]. Non è una lista per principianti. È un segnale che "prompting" copre molti problemi diversi.
Il catalogo di prompt pattern di White et al. è utile per un altro motivo [7]. Tratta i prompt come pattern software: soluzioni riutilizzabili a problemi ricorrenti in un contesto particolare. Quest'ultima parte è fondamentale. Un pattern è riutilizzabile, ma non è senza contesto.
Automatic Prompt Engineer fa un passo ulteriore. Zhou et al. trattano le istruzioni come candidati che possono essere generati, valutati e selezionati in base alla performance su una task [8]. È un modello mentale diverso da "scrivere bene un prompt". La qualità dipende da task, funzione di scoring e spazio di ricerca.
Anche lo studio di Shin et al. sul software engineering è coerente. Confronta prompting di base, in-context learning e prompting specifico per il compito su generazione, sintesi e traduzione di codice. Il prompt engineering non domina sempre il fine-tuning, e il prompting conversazionale migliora quando le persone aggiungono contesto, feedback e istruzioni specifiche [9].
È anche quello che si vede lavorando. Scopri cosa manca al prompt guardando dove il modello fallisce.
I dettagli cambiano con il compito
La versione pratica dell'argomento è questa:
| Contesto | Dettagli spesso importanti |
|---|---|
| Sintesi di documenti lunghi | Gerarchia delle fonti, regole di citazione, metadati, conflitti, policy sulle citazioni |
| Generazione di codice | Convenzioni del repo, file target, test, architettura, dipendenze, vincoli di sicurezza |
| Frontend | Design system, responsive behavior, stati di interazione, accessibilità, asset visivi |
| Analisi legale o policy | Giurisdizione, data, autorità della fonte, incertezza, qualità delle fonti, escalation |
| Estrazione strutturata | Schema, valori ammessi, gestione di null, validazione, casi limite |
| Tutoring | Livello dello studente, misconception, ritmo, feedback, quando fare domande |
| Agenti con strumenti | Permessi, approvazioni, criteri di arresto, verifiche, audit |
| Lavoro creativo | Genere, pubblico, voce, esempi negativi, vincoli, criteri di novità |
Una checklist generica direbbe: "aggiungi contesto". Bene. Ma in una codebase il contesto può essere l'architettura locale e il comando di test. In una sintesi legale può essere giurisdizione e data della norma. In un'estrazione può essere lo schema e il trattamento dei campi mancanti.
La parola è la stessa. L'array di dettagli no.
Precisione non significa verbosità
Qui molte discussioni sul prompting si inceppano.
Le persone sentono "sii preciso" e lo traducono in "aggiungi più istruzioni". A volte funziona. Spesso produce solo un prompt più lungo, con più punti in cui le istruzioni possono entrare in conflitto.
La definizione migliore è:
Il prompting preciso è la selezione di contesto, vincoli, esempi e criteri di valutazione rilevanti per il compito, tali da influenzare concretamente il comportamento del modello.
Così la precisione è separata dalla lunghezza.
Un prompt che dice "scrivi in tono professionale per un pubblico generale" non è preciso se il problema reale è la fedeltà delle citazioni. Un prompt che dice "estrai i claim in JSON con claim, source_quote, confidence e needs_verification; usa null quando la fonte non dice nulla" può essere preciso anche se è breve.
Il primo suona pulito. Il secondo cambia il comportamento.
Il context engineering come cornice più ampia
La letteratura recente sul context engineering dice la stessa cosa su scala più ampia. Mei et al. descrivono il context engineering come ottimizzazione del payload informativo dato a un LLM: retrieval, processing del contesto, memoria, strumenti, RAG, ragionamento integrato con strumenti e sistemi multi-agente [10].
Il termine può diventare vago se diventa moda. Ma l'idea centrale è utile: il prompt visibile dell'utente è solo una parte della finestra di contesto.
In un'applicazione LLM seria, il modello può ricevere anche:
- istruzioni di sistema
- istruzioni developer
- documenti recuperati
- memoria
- definizioni di strumenti
- regole di policy
- preferenze utente
- esempi
- schemi
- output precedenti
- rubriche di valutazione
Vista così, la vecchia checklist è troppo piccola. Il lavoro non è solo formulare bene la richiesta. È assemblare l'ambiente informativo in cui il modello può riuscire.
Un piccolo modello per il prompting preciso
Le fonti suggeriscono un modello di lavoro semplice. Non lo chiamerei ancora teoria. Piuttosto, uno scaffold pratico.
| Livello | Domanda | Esempio |
|---|---|---|
| Allineamento al compito | Cosa rende l'output corretto o utile? | Citare fonti primarie |
| Allineamento al modello | Di cosa ha bisogno questo modello? | Richiedere esplicitamente dettagli frontend |
| Allineamento al workflow | Quali strumenti, file o stati sono coinvolti? | Leggere file, chiedere prima di scrivere |
| Allineamento al rischio | Cosa può andare storto se il modello agisce con sicurezza? | Segnalare incertezza legale |
| Allineamento alla valutazione | Come si verifica il successo? | JSON valido, test verdi, citazioni controllate |
Questo spiega anche perché gli LLMs possono aiutare a scrivere prompt. Quando chiedo a un LLM di migliorare un prompt, spesso fa emergere categorie dimenticate: casi limite, rubriche, policy sulle fonti, esempi negativi, failure mode, permessi degli strumenti.
Ma non sono automaticamente giuste. Sono dettagli candidati. Vanno testati.
Cosa significa in pratica
Se mantieni una libreria di prompt, non salvare solo il prompt finale. Salva tipo di compito, modello, criteri di successo, failure mode noti e perché certi dettagli sono stati inclusi.
Se chiedi a un LLM di migliorare un prompt, non chiedere solo "un prompt migliore". Chiedi quali categorie di dettaglio potrebbero influenzare il risultato.
Se un prompt fallisce, non renderlo subito più lungo. Chiediti quale tipo di contesto mancava.
Alcuni prompt hanno bisogno di esempi. Alcuni di uno schema. Alcuni di una gerarchia di fonti. Alcuni di una tool policy. Alcuni di una definition of done più netta. Alcuni hanno bisogno di meno istruzioni, perché il modello si aggancia troppo ai vincoli.
La parte scomoda è questa: il buon prompting non è una singola competenza. È una famiglia di piccole competenze diagnostiche.
Limiti
Questo articolo è speculativo nel senso giusto: parte da un'osservazione pratica e verifica se la letteratura va nella stessa direzione. Sì, ma non è un esperimento controllato.
Il passo successivo utile sarebbe rendere operativi i "dettagli" e testarli per famiglie di task. Una policy di citazione migliora una rassegna della letteratura più di una guida sul tono? Il dettaglio dello schema conta più degli esempi nell'estrazione? Quali dettagli si trasferiscono tra famiglie di modelli?
Sarebbe un buon benchmark. Anche disordinato, perché i prompt reali combinano dettagli che interagiscono.
Conclusione
La letteratura sostiene l'ipotesi: il prompting si sta spostando dal consiglio universale a checklist verso la specificazione del contesto.
La checklist per iniziare resta utile. Compito, pubblico, tono, esempi e formato sono buoni default. Ma il prompting avanzato comincia quando smettiamo di chiedere "di cosa ha bisogno ogni prompt?" e chiediamo "che cosa deve sapere, vincolare, usare, evitare e provare il modello per questa task?"
Questo è lo spostamento.
Il prompting preciso non significa aggiungere dettagli ovunque. Significa trovare i dettagli che cambiano il risultato.
Riferimenti
[1] OpenAI, Prompt engineering, OpenAI API documentation.
[2] OpenAI, Prompt generation, OpenAI API documentation.
[3] Anthropic, Prompt engineering overview, Claude API documentation.
[4] Anthropic, Prompting best practices, Claude API documentation.
[5] Microsoft, Prompt engineering techniques, Microsoft Learn.
[6] S. Schulhoff et al., The Prompt Report: A Systematic Survey of Prompting Techniques, arXiv:2406.06608, 2024.
[7] J. White et al., A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, arXiv:2302.11382, 2023.
[8] Y. Zhou et al., Large Language Models Are Human-Level Prompt Engineers, arXiv:2211.01910, 2022.
[9] J. Shin et al., Prompt Engineering or Fine Tuning: An Empirical Assessment of Large Language Models in Automated Software Engineering Tasks, arXiv:2310.10508, 2023.
[10] L. Mei et al., A Survey of Context Engineering for Large Language Models, arXiv:2507.13334, 2025.