Scrivere un buon prompt per Claude è la differenza tra ottenere una risposta generica, che potresti trovare ovunque, e ottenere un output che sembra scritto da un collaboratore esperto che conosce il tuo contesto, il tuo tono e i tuoi obiettivi. Claude, l’assistente AI sviluppato da Anthropic, è oggi uno dei modelli linguistici più potenti al mondo, ma come ogni strumento potente rende al massimo solo quando sai come parlargli.
In questa guida completa vedremo tutto quello che serve per padroneggiare i prompt per Claude: dai principi fondamentali del prompt engineering fino alle tecniche avanzate, passando per i consigli condivisi pubblicamente da Boris Cherny, il creatore di Claude Code, durante un talk tecnico dedicato proprio all’uso pratico dello strumento. Troverai decine di esempi concreti, template pronti da copiare, errori da evitare e workflow professionali usati internamente ad Anthropic.
Che tu sia uno sviluppatore che vuole sfruttare Claude Code al massimo, un consulente SEO che genera contenuti, un imprenditore che automatizza processi o semplicemente un utente curioso, qui trovi tutto quello che ti serve. Preparati: è una guida lunga, ma alla fine saprai scrivere prompt per Claude meglio del 99% degli utenti.
Un prompt è, nella sua definizione più semplice, l’istruzione testuale che fornisci a un modello di intelligenza artificiale per ottenere una risposta. Nel caso di Claude, il prompt è il messaggio che scrivi nella chat di Claude.ai, nel terminale di Claude Code, o nel campo messages di una chiamata API.
Ma ridurre il prompt a “una domanda che fai all’AI” è riduttivo. Il prompt è, a tutti gli effetti, l’interfaccia di programmazione in linguaggio naturale tra te e il modello. È il modo in cui trasferisci a Claude tre cose fondamentali:
I modelli linguistici come Claude non leggono nel pensiero. Generano la risposta più probabile e utile dato ciò che hanno davanti. Se il prompt è vago, il modello deve “riempire i buchi” con assunzioni statistiche, e quelle assunzioni potrebbero non coincidere con le tue aspettative. Se il prompt è preciso, ricco di contesto e ben strutturato, la risposta sarà proporzionalmente più precisa, pertinente e utilizzabile.
C’è un principio che vale la pena fissare subito, perché è il filo conduttore di tutta questa guida: la qualità dell’output di Claude è quasi sempre un riflesso della qualità del prompt. Quando un utente dice “Claude non capisce cosa voglio”, nella grande maggioranza dei casi il problema è nel prompt, non nel modello. E la buona notizia è che scrivere prompt migliori è un’abilità che si impara in fretta, con poche regole e molta pratica.
Chi arriva a Claude dopo aver usato altri assistenti AI tende a riutilizzare le stesse abitudini di prompting. Funzionano, ma non sfruttano le caratteristiche specifiche di Claude. Ecco cosa rende Claude diverso dal punto di vista di chi scrive prompt:
Finestra di contesto molto ampia. Claude gestisce contesti di centinaia di migliaia di token. Questo significa che puoi incollare interi documenti, codebase, trascrizioni, contratti o report nel prompt e chiedere analisi approfondite. Un buon prompt per Claude sfrutta questa capacità: invece di riassumere tu il contesto, dai a Claude il materiale grezzo e lascia che sia lui a estrarne il valore.
Ottima aderenza alle istruzioni strutturate. Claude è stato addestrato per rispondere in modo eccellente a prompt organizzati con struttura esplicita, in particolare con tag XML (ne parleremo in dettaglio). Se separi chiaramente istruzioni, contesto, esempi e domanda, Claude segue la struttura con grande fedeltà.
Capacità agentiche native. Con Claude Code e con gli strumenti (tool use) via API, Claude non si limita a rispondere: esplora file, esegue comandi, cerca sul web, itera sui risultati. Questo cambia radicalmente il modo di promptare: non descrivi più solo l’output desiderato, ma anche il processo e gli strumenti che Claude può usare per arrivarci.
Attenzione alla sicurezza e ai vincoli. Claude tende a rispettare con precisione i vincoli espliciti (“non superare le 200 parole”, “rispondi solo in JSON”, “non inventare fonti”). Usare vincoli chiari è uno dei modi più efficaci per controllare l’output.
Prima di entrare nella parte tecnica, vale la pena inquadrare il perché economico. Per un professionista — sviluppatore, consulente, marketer — la differenza tra un prompt mediocre e un prompt eccellente si misura in ore. Un prompt vago genera un output che devi correggere, riscrivere, reimpostare, con tre o quattro iterazioni di andata e ritorno. Un prompt eccellente genera un output utilizzabile all’80-95% al primo colpo.
Su scala, questo si traduce in numeri concreti. Anthropic ha raccontato che, internamente, l’onboarding tecnico dei nuovi assunti — che prima richiedeva due o tre settimane — oggi richiede due o tre giorni, perché i nuovi ingegneri usano Claude Code per fare domande sul codebase invece di interrompere continuamente i colleghi. Non è magia: è l’effetto composto di uno strumento potente usato con prompt giusti nel workflow giusto.
Se gestisci progetti per clienti, come agenzia o freelance, saper scrivere prompt per Claude è ormai una competenza fatturabile: automazione di contenuti, analisi di dati, generazione di codice, audit tecnici, reportistica. Ogni singolo caso d’uso passa dalla stessa porta: il prompt.
La fonte principale di questa guida, oltre alla documentazione ufficiale di Anthropic e all’esperienza diretta, è un talk tecnico tenuto da Boris Cherny, membro del technical staff di Anthropic e creatore di Claude Code. Il talk è dichiaratamente pratico: niente teoria, niente storia dei modelli linguistici, solo consigli operativi su come ottenere di più da Claude.
Anche se il talk è centrato su Claude Code (lo strumento da terminale per lo sviluppo software agentico), i principi di prompting che emergono valgono per qualsiasi interazione con Claude. Vediamo i concetti chiave uno per uno, perché costituiscono la spina dorsale di un approccio professionale al prompting.
Il primo consiglio di Cherny per chi si avvicina a Claude Code è controintuitivo: non iniziare chiedendo a Claude di scrivere o modificare codice. Inizia facendo domande.
Ad Anthropic, i nuovi assunti tecnici imparano Claude Code il primo giorno di onboarding, e la prima cosa che fanno è interrogare il codebase: “come funziona questa classe?”, “dove viene istanziato questo oggetto?”, “perché questa funzione ha quindici parametri con nomi strani?”. Claude non si limita a una ricerca testuale: esplora il codice in profondità, cerca esempi d’uso reali, ricostruisce il contesto e restituisce risposte paragonabili a una documentazione interna ben scritta.
Perché questo è una lezione di prompting? Perché fare domande è il modo più rapido e sicuro per imparare i confini del modello: cosa riesce a fare al primo colpo, cosa richiede due o tre tentativi, cosa richiede supervisione interattiva. Cherny lo dice esplicitamente: il Q&A insegna alle persone come promptare. Prima di automatizzare, prima di delegare compiti complessi, costruisci un modello mentale delle capacità di Claude interrogandolo.
Questa lezione si traduce in una regola generale, valida ben oltre il codice: quando affronti un dominio nuovo con Claude, dedica le prime sessioni all’esplorazione conversazionale. Chiedi analisi, chiedi spiegazioni, chiedi “cosa faresti tu”. Capirai in fretta come formulare le richieste operative successive.
Un dettaglio interessante emerso nel talk: Claude Code non indicizza il codice, non lo carica su database remoti e non lo usa per addestrare modelli generativi. Il codice resta locale, e non c’è alcun setup di indicizzazione: si installa e si usa subito. Per chi lavora con codice di clienti sotto NDA, è un punto rilevante.
Questo è probabilmente il consiglio singolo più prezioso di tutto il talk, e merita di essere interiorizzato da chiunque usi Claude per compiti complessi.
Cherny descrive un errore che vede spesso: l’utente chiede a Claude di implementare una feature enorme, da migliaia di righe, in un colpo solo. A volte funziona. Ma a volte Claude costruisce qualcosa che non è affatto ciò che l’utente aveva in mente — non perché il modello sia incapace, ma perché il prompt non conteneva abbastanza informazioni per disambiguare l’intento.
La soluzione è disarmante nella sua semplicità: chiedi a Claude di pensare prima di agire. Nel prompt, aggiungi istruzioni come:
“Prima di scrivere codice, esplora il progetto, fai brainstorming sulle possibili soluzioni, prepara un piano dettagliato e sottoponimelo per approvazione. Solo dopo il mio ok, procedi con l’implementazione.”
Non servono strumenti speciali né modalità particolari: basta chiederlo nel prompt, e Claude sa cosa fare. Questo pattern — esplora, pianifica, conferma, esegui — trasforma un’interazione rischiosa (un grande output monolitico potenzialmente sbagliato) in un processo controllato con un checkpoint umano nel punto giusto: prima che il lavoro grosso venga fatto.
Il principio generale, applicabile a qualsiasi prompt per Claude: per compiti complessi, separa la fase di pianificazione dalla fase di esecuzione. Vale per il codice, ma anche per un piano editoriale, una strategia SEO, un business plan, un report di analisi. Il costo di un checkpoint è un messaggio in più; il beneficio è evitare di buttare via un output da tremila righe (o tremila parole) costruito sulla premessa sbagliata.
Un altro momento illuminante del talk riguarda un’abitudine di Cherny: dopo una sessione di lavoro, scrive semplicemente qualcosa come “commit push” e Claude fa tutto — crea il commit rispettando le convenzioni del repository (che deduce da solo leggendo la cronologia Git), crea il branch, pusha e apre la pull request su GitHub. Nessuna istruzione dettagliata, nessun prompt di sistema che spieghi la procedura: il modello è abbastanza capace da interpretare l’intento e ricostruire i passaggi.
Lo stesso vale per la cronologia Git: se chiedi “guarda nella cronologia Git e spiegami perché questa funzione è fatta così”, Claude sa usare Git, cercare i commit rilevanti, seguire i riferimenti alle issue e sintetizzare la storia. Cherny sottolinea che non c’è nulla nel system prompt di Claude Code che gli insegni a farlo: è capacità nativa del modello.
La lezione per il prompting è duplice e apparentemente contraddittoria, ma in realtà complementare:
Saper distinguere quando essere prescrittivi e quando essere sintetici è forse la competenza più raffinata del prompt engineering moderno. La regola pratica: specifica il risultato e i vincoli, lascia libertà sul processo — a meno che il processo non sia esso stesso un requisito.
Questo è il consiglio che, secondo Cherny, produce il salto di qualità più grande nei risultati: fornire a Claude uno strumento di feedback con cui controllare e iterare sul proprio output.
L’esempio del talk: se dai a Claude un mockup grafico e gli chiedi di costruire l’interfaccia web corrispondente, il risultato al primo tentativo sarà “abbastanza buono”. Ma se gli dai anche uno strumento per fare screenshot della pagina renderizzata (ad esempio un server Puppeteer), Claude confronterà da solo il risultato con il mockup, individuerà le differenze e itererà due o tre volte fino ad arrivare a un risultato quasi perfetto — senza che tu debba intervenire a ogni passaggio.
Il principio è generale e potentissimo: un agente AI con un ciclo di feedback chiuso (genera → verifica → correggi) supera enormemente lo stesso agente senza verifica. Le forme di verifica dipendono dal dominio:
Nel prompting quotidiano, anche senza strumenti esterni, puoi simulare questo pattern chiedendo esplicitamente l’auto-verifica: “Al termine, rileggi l’output e controlla che rispetti tutti i vincoli elencati; se qualcosa non è conforme, correggilo prima di consegnare la risposta”. È un’istruzione che costa una riga e migliora sensibilmente l’affidabilità.
Cherny dedica una parte consistente del talk a un tema che i prompt engineer esperti conoscono bene: più contesto pertinente dai a Claude, migliori sono le sue decisioni. Un ingegnere che lavora su un codebase ha in testa una quantità enorme di contesto — architettura, convenzioni, storia, strumenti — e il modo per rendere Claude altrettanto efficace è trasferirgli quel contesto.
Lo strumento principale in Claude Code è il file CLAUDE.md: un file di testo che, se posizionato nella directory di lavoro, viene letto automaticamente all’inizio di ogni sessione ed entra a far parte del primo messaggio. Cosa metterci:
Due raccomandazioni cruciali dal talk:
Il sistema è gerarchico: CLAUDE.md nella root del progetto (caricato sempre), CLAUDE.md in sottodirectory (caricati su richiesta quando Claude lavora in quelle directory), memoria utente globale valida per tutti i progetti, e policy enterprise distribuite a tutta l’azienda. La stessa gerarchia vale per slash commands, permessi sui comandi (allowlist e blocklist) e configurazione dei server MCP condivisi nel repository.
La lezione trascende Claude Code: il prompt non è solo il messaggio che scrivi, è tutto il contesto che il modello riceve. In Claude.ai l’equivalente sono i Progetti con le loro istruzioni personalizzate e i documenti caricati; via API è il system prompt. Investire tempo nella cura del contesto persistente è l’ottimizzazione con il miglior rapporto sforzo/risultato che esista: la scrivi una volta, la sfrutti in ogni conversazione.
Alcuni consigli “minori” del talk che rivelano molto sulla filosofia del prompting efficace:
Dettare i prompt a voce. Cherny racconta di usare spesso la dettatura vocale del sistema operativo per i propri prompt, perché parlare consente di essere molto più specifici e dettagliati senza la fatica di digitare. È un consiglio sottovalutato: la specificità è la valuta del prompting, e la voce abbassa il costo della specificità. Prova a dettare un prompt come lo spiegheresti a un collega: verrà naturalmente più ricco di contesto.
Interrompere e correggere presto. In Claude Code, il tasto Escape ferma Claude in qualsiasi momento senza corrompere la sessione. Cherny lo usa per correzioni chirurgiche: se Claude propone una modifica di venti righe di cui diciannove perfette, ferma tutto, indica la riga da cambiare e fa rifare solo quella. Il principio generale: non lasciare che un output vada avanti nella direzione sbagliata per educazione o inerzia. Interrompi, correggi la rotta, riparti. Ogni messaggio di correzione precoce risparmia molti messaggi di correzione tardiva.
Memorizzare le correzioni. Con il simbolo cancelletto (#), Claude Code memorizza un’istruzione in modo permanente nel CLAUDE.md. Se Claude usa male uno strumento, glielo dici una volta e vale per sempre. Equivalente universale: quando ti accorgi che stai ripetendo la stessa correzione in più conversazioni, quella correzione appartiene al contesto persistente (istruzioni del Progetto, system prompt), non al singolo prompt.
Per gli utenti avanzati, il talk presenta la modalità programmatica di Claude Code: con il flag -p puoi passare un prompt da riga di comando, specificare gli strumenti consentiti e ottenere output in JSON (anche in streaming). Claude diventa così una pedina componibile nelle pipeline: puoi fare pipe di un log gigantesco dentro Claude e chiedergli cosa c’è di interessante, incanalare l’output di git status e fargli selezionare informazioni, integrarlo nella CI, nella risposta agli incidenti, in qualsiasi automazione.
Cherny la definisce una “utility Unix super-intelligente”, e ammette che le possibilità sono appena state esplorate in superficie. Per chi scrive prompt, questo apre una categoria nuova: i prompt non interattivi, dove non c’è possibilità di chiarimento successivo e quindi il prompt deve essere autosufficiente — contesto completo, formato di output rigidamente specificato (JSON con schema), gestione esplicita dei casi limite. Ne parleremo nella sezione sulle tecniche avanzate.
Ultimo livello di maturità descritto nel talk: i power user non usano una sessione di Claude alla volta. Tengono più checkout dello stesso repository (o Git worktrees) e fanno lavorare più istanze di Claude in parallelo su task diversi, spesso via tmux o SSH. Il collo di bottiglia non è più il modello, ma la capacità umana di supervisionare più flussi di lavoro contemporaneamente.
Per il prompting, la conseguenza è interessante: quando deleghi in parallelo, ogni prompt deve essere un brief completo e autonomo, come il brief che daresti a un collaboratore che lavorerà da solo per un’ora. Contesto, obiettivo, vincoli, criteri di successo, cosa fare in caso di dubbio. È il livello più alto di maturità nella scrittura di prompt: prompt che non hanno bisogno di te.
Assorbiti gli insegnamenti del creatore di Claude Code, sistematizziamoli in principi operativi validi per ogni interazione con Claude — in chat, in Claude Code o via API. Questi sette principi coprono, da soli, la stragrande maggioranza dei miglioramenti che puoi ottenere.
La causa numero uno di output deludenti è la vaghezza. Confronta:
❌ Prompt vago: “Scrivimi un articolo sul marketing digitale.”
✅ Prompt specifico: “Scrivi un articolo di 1.500 parole per il blog di un’agenzia web italiana che si rivolge a PMI siciliane. Argomento: perché una PMI dovrebbe investire in SEO locale nel 2026. Tono professionale ma diretto, senza anglicismi inutili. Struttura: introduzione con un dato concreto, 4 sezioni H2, conclusione con call to action verso una consulenza gratuita. Evita frasi fatte come ‘nell’era digitale’.”
Il secondo prompt richiede trenta secondi in più e restituisce un output dieci volte più vicino al risultato finale. Ogni elemento specificato — lunghezza, pubblico, tono, struttura, esclusioni — è una decisione che altrimenti Claude avrebbe preso al posto tuo, statisticamente, e non necessariamente come volevi tu.
Regola pratica: se rileggendo il tuo prompt un collaboratore umano competente potrebbe interpretarlo in due modi diversi, Claude potrà farlo anche lui. Disambigua.
Claude ha una finestra di contesto enorme: usala. Incolla il documento intero invece del riassunto. Includi il testo della pagina da ottimizzare, non solo l’URL descritto a parole. Allega i dati grezzi, le email precedenti, il brief del cliente, gli esempi di lavori passati.
Il contesto utile per un prompt per Claude include tipicamente:
Attenzione però alla lezione del CLAUDE.md: contesto pertinente, non contesto qualsiasi. Diecimila parole di materiale irrilevante diluiscono il segnale. La domanda guida è: “un consulente esterno bravissimo, per fare questo lavoro, di quali informazioni avrebbe bisogno?”. Quelle, tutte quelle, e solo quelle.
Claude risponde in modo particolarmente affidabile ai prompt strutturati, e la struttura raccomandata dalla stessa Anthropic si basa sui tag XML: delimitatori espliciti che separano le diverse parti del prompt. Esempio:
Sei un consulente SEO senior specializzato in e-commerce italiani.
<contesto>
Il cliente gestisce un e-commerce WooCommerce di articoli da giardinaggio.
Traffico organico attuale: 8.000 sessioni/mese. Obiettivo: +50% in 6 mesi.
</contesto>
<dati>
[qui incolli l'export delle query da Google Search Console]
</dati>
<compito>
Analizza le query e identifica le 10 opportunità con miglior rapporto
tra volume potenziale e difficoltà, considerando che il sito ha
autorità di dominio media.
</compito>
<formato_output>
Tabella con: query, intento di ricerca, pagina target consigliata,
azione da fare, priorità (alta/media/bassa).
</formato_output>
I vantaggi della struttura con tag: Claude non confonde mai le istruzioni con i dati (fondamentale quando incolli testi lunghi), puoi riferirti alle sezioni per nome (“rispondi usando solo le informazioni in “), e il prompt diventa un template riutilizzabile in cui cambi solo il contenuto delle sezioni. I nomi dei tag sono liberi: usa nomi descrittivi e coerenti.
Nessuna descrizione dello stile che vuoi sarà mai efficace quanto un esempio dello stile che vuoi. Questa tecnica si chiama few-shot prompting: includi nel prompt uno o più esempi input→output del risultato desiderato.
Riscrivi le descrizioni prodotto seguendo lo stile di questo esempio.
<esempio>
Input: Tosaerba elettrico 1800W, larghezza taglio 42cm, cesto 50L
Output: Prato perfetto senza fatica: il tosaerba elettrico da 1800W
taglia una fascia di 42 cm a ogni passata e raccoglie tutto nel
capiente cesto da 50 litri. Meno svuotamenti, più tempo per goderti
il giardino.
</esempio>
<da_riscrivere>
[le tue descrizioni grezze]
</da_riscrivere>
Con 2-3 esempi ben scelti, Claude estrae autonomamente il pattern: lunghezza, tono, struttura sintattica, presenza della “promessa di beneficio” prima dei dati tecnici. Gli esempi sono particolarmente potenti per: formati di output ripetitivi, classificazioni, stili di scrittura, convenzioni di codice, trasformazioni di dati.
Un accorgimento: scegli esempi rappresentativi anche dei casi limite. Se nel tuo dataset ci sono input strani, includi un esempio di come gestirli.
Iniziare il prompt definendo chi deve “essere” Claude orienta tutto l’output: registro, profondità, priorità, persino gli errori che eviterà. “Sei un avvocato specializzato in diritto del lavoro italiano” produce risposte diverse da “sei un HR manager” a parità di domanda — e la differenza è esattamente quella che vuoi controllare.
Il ruolo funziona meglio quando è specifico e include il punto di vista: “Sei un revisore severo che deve trovare problemi in questo contratto prima della firma” attiva un comportamento diverso da “spiegami questo contratto”. Per lavori professionali, specifica anche il livello: “senior”, “con 20 anni di esperienza”, “abituato a lavorare con PMI italiane”.
Ogni volta che l’output ha una destinazione precisa — un documento, un foglio di calcolo, un CMS, un altro programma — specifica il formato in modo esplicito: lunghezza, struttura, sintassi, cosa includere e cosa escludere.
Esempi di vincoli di formato efficaci:
I vincoli negativi (“senza”, “evita”, “non includere”) funzionano, ma quando possibile esprimi il vincolo in positivo: invece di “non essere prolisso”, scrivi “massimo 150 parole”. Il vincolo misurabile è sempre più affidabile del vincolo qualitativo.
È la lezione 2 del talk di Cherny generalizzata: per compiti complessi, chiedi esplicitamente a Claude di ragionare passo passo prima di produrre la risposta finale, oppure di produrre prima un piano da approvare.
Formulazioni utili:
Il ragionamento esplicito migliora l’accuratezza su problemi matematici, logici, di analisi e di pianificazione, e ha un beneficio collaterale prezioso: rende visibili le assunzioni di Claude, così puoi correggerle prima che inquinino l’output finale.
Padroneggiati i sette principi, entriamo nelle tecniche che distinguono un utente esperto. Non servono in ogni prompt: servono quando la posta in gioco è alta — automazioni, prompt riutilizzabili, integrazioni via API, task ad alto rischio di errore.
Abbiamo già visto il “ragiona passo passo”. La versione avanzata è guidare la catena di ragionamento definendo tu le tappe:
Analizza questo bilancio seguendo esattamente questi passaggi:
1. Identifica i movimenti anomali rispetto alla media mensile
2. Per ogni anomalia, verifica se esiste una controparte nello stesso periodo
3. Classifica le anomalie residue per rischio (basso/medio/alto)
4. Solo alla fine, scrivi la sintesi esecutiva
Mostra il lavoro di ogni passaggio in una sezione separata.
Definire i passaggi serve a due scopi: impedisce a Claude di saltare fasi che per te sono critiche, e rende l’output auditabile — puoi verificare dove il ragionamento ha eventualmente deviato.
Via API, puoi “mettere in bocca” a Claude l’inizio della risposta (prefill dell’assistant turn). Se il prefill è {, Claude proseguirà con JSON puro senza preamboli. In chat ottieni un effetto simile con istruzioni ferree: “La tua risposta deve iniziare direttamente con il carattere { e finire con }”. Per pipeline automatizzate — come quelle costruite con la modalità SDK di Claude Code vista sopra — l’output vincolato è vitale: un preambolo discorsivo romperebbe il parser a valle.
Consiglio operativo per il JSON: fornisci sempre lo schema con un esempio compilato, non solo la descrizione dei campi. E specifica come gestire i valori mancanti (“se il dato non è presente, usa null, non inventare”).
Per lavori grandi, un solo mega-prompt è spesso inferiore a una catena di prompt specializzati, dove l’output di uno diventa l’input del successivo:
Vantaggi: ogni fase ha un prompt corto e mirato, puoi verificare e correggere i risultati intermedi, e riutilizzi le fasi come moduli. È lo stesso pattern esplora→pianifica→esegui del talk di Cherny, industrializzato.
Quando incolli documenti molto lunghi, tre accorgimenti migliorano nettamente i risultati:
Se lavori via API o con i Progetti di Claude.ai, distingui i due livelli: nel system prompt (o nelle istruzioni del Progetto) metti tutto ciò che è stabile — ruolo, tono, regole, formato ricorrente, glossario aziendale; nel messaggio utente metti solo ciò che cambia — il task del giorno e i suoi dati. È l’equivalente del CLAUDE.md: scrivi una volta, benefici sempre, e i singoli prompt diventano corti e veloci da scrivere.
Generalizzando la lezione 4 del talk (dai a Claude un modo di verificare il proprio lavoro), puoi incorporare la verifica direttamente nel prompt sotto forma di rubrica:
Dopo aver scritto il testo, valutalo rispetto a questa rubrica e
correggi ciò che non raggiunge il punteggio massimo:
- Keyword principale presente in H1, primo paragrafo e almeno 2 H2?
- Nessuna frase sopra le 30 parole?
- Ogni sezione contiene almeno un dato concreto o esempio?
- CTA finale presente e coerente con l'obiettivo?
Mostra la checklist compilata alla fine.
La rubrica trasforma criteri di qualità impliciti in un ciclo di feedback esplicito. È il “Puppeteer dei contenuti”: Claude confronta l’output con un riferimento e itera.
Passiamo alla pratica pura: template di prompt per Claude, organizzati per caso d’uso, che puoi copiare e adattare. Ognuno applica i principi visti finora — nota la struttura ricorrente: ruolo, contesto, compito, formato, verifica.
Analisi dell’intento di ricerca:
Sei un SEO specialist senior per il mercato italiano.
<keyword>prompt per claude</keyword>
Analizza l'intento di ricerca di questa keyword: cosa vuole davvero
trovare chi la digita? È intento informativo, commerciale o misto?
Che formato di contenuto domina probabilmente la SERP (guida, lista,
tool, comparazione)? Quali sotto-domande implicite deve coprire un
contenuto per soddisfare pienamente l'intento? Concludi con la
struttura H2/H3 ideale per posizionarsi.
Brief editoriale completo:
Sei il content strategist di un'agenzia SEO italiana.
<contesto>Sito: blog di un'agenzia web per PMI. Obiettivo del post:
generare lead per il servizio di audit SEO.</contesto>
<keyword_principale>audit seo</keyword_principale>
Crea un brief editoriale completo: titolo SEO (max 60 caratteri),
meta description (max 155), scaletta H2/H3 con l'angolo di ogni
sezione, keyword secondarie da includere, domande per la sezione FAQ,
link interni suggeriti, e 3 indicazioni di tono. Prima di scrivere
il brief, elenca le 3 assunzioni principali che stai facendo.
Ottimizzazione di un testo esistente:
<testo>[incolla il testo]</testo>
<keyword>ricambi tosaerba</keyword>
Ottimizza questo testo per la keyword indicata senza stravolgerne il
tono. Regole: keyword nel primo paragrafo in modo naturale, aggiungi
2 H2 con varianti semantiche, spezza i paragrafi sopra le 4 righe,
riscrivi le frasi passive in attive. Alla fine mostra una tabella
"prima/dopo" delle modifiche principali con la motivazione di ciascuna.
Ecco i pattern più utili emersi dal talk, tradotti in prompt riutilizzabili.
Onboarding su un codebase nuovo (la lezione 1 di Cherny):
Sto lavorando per la prima volta su questo progetto. Prima di
qualsiasi modifica, aiutami a capirlo: qual è l'architettura
generale? Quali sono i 5 file più importanti da conoscere? Che
convenzioni di stile e naming vengono usate? Come si eseguono
build e test? Guarda anche la cronologia Git recente per capire
su cosa sta lavorando il team.
Feature con piano preventivo (la lezione 2):
Devo aggiungere [descrizione della feature]. Prima di scrivere
qualsiasi riga di codice: esplora le parti del progetto coinvolte,
proponi 2-3 approcci alternativi con pro e contro, scegli il
migliore motivando la scelta, e presentami un piano di
implementazione dettagliato file per file. Aspetta la mia
approvazione prima di procedere.
Bugfix con ciclo di verifica (la lezione 4):
C'è un bug: [descrizione + come riprodurlo]. Procedi così:
1) scrivi prima un test che riproduce il bug e verifica che fallisca;
2) individua la causa guardando anche la cronologia Git del file
per capire se il comportamento era intenzionale;
3) correggi;
4) esegui tutti i test e itera finché non passano;
5) riassumi causa e soluzione in 3 righe per il commit message.
Refactoring sicuro:
Refactoring del file [X]: obiettivo leggibilità, zero cambi di
comportamento. Vincoli: non modificare le firme pubbliche, non
aggiungere dipendenze, mantieni lo stile del progetto (deducilo
dai file vicini). Dopo il refactoring esegui i test esistenti;
se non esistono test per questo file, scrivili prima di toccare
il codice.
Esempio di CLAUDE.md ben fatto (la lezione 5):
# CLAUDE.md
## Comandi
- Test: npm run test (mai npm test, usa la config sbagliata)
- Build: npm run build && npm run typecheck
- Deploy: solo via CI, mai manuale
## Convenzioni
- Componenti React: funzionali, un file per componente, PascalCase
- Stato globale: solo Zustand, niente Redux
- Commenti in italiano, nomi variabili in inglese
## Architettura
- /src/api: tutte le chiamate esterne, mai fetch diretti nei componenti
- /src/lib: utility pure, sempre testate
## Note
- Il modulo pagamenti è legacy: non toccarlo senza chiedere
Nota la brevità: niente prosa, solo le informazioni che evitano errori ricorrenti. Questo è il “tuning del contesto” raccomandato nel talk.
Analisi di dati grezzi:
Sei un analista finanziario meticoloso.
<dati>[incolla estratto conto / export CSV]</dati>
Compito: categorizza i movimenti, evidenzia le anomalie (importi
fuori scala, duplicati, controparti ricorrenti insolite) e produci
una sintesi. Regole: non inventare mai categorie per movimenti
ambigui — marcali come "DA VERIFICARE" con il motivo del dubbio.
Formato: tabella + sintesi di 10 righe. Alla fine dichiara quanti
movimenti hai marcato come dubbi e perché.
Email delicata:
Devo scrivere a un cliente che è in ritardo di 60 giorni con un
pagamento di 1.800€, ma con cui voglio mantenere il rapporto.
<storia>Terzo sollecito. I primi due, gentili, sono stati ignorati.
Il cliente in passato ha sempre pagato, anche se in ritardo.</storia>
Scrivi 2 versioni dell'email: una ferma ma cordiale, una che
introduce conseguenze concrete (sospensione servizi). Massimo 120
parole ciascuna, tono professionale, niente giri di parole nel
primo paragrafo: il motivo dell'email deve essere chiaro subito.
Decisione strategica:
Sei un advisor che ha il compito di trovare i punti deboli, non di
assecondarmi.
<situazione>[descrivi la decisione da prendere con numeri e vincoli]</situazione>
Prima elenca le domande a cui dovrei saper rispondere prima di
decidere e che non ho affrontato. Poi analizza l'opzione che
preferisco cercando attivamente i rischi che sto sottovalutando.
Solo alla fine dammi la tua raccomandazione, con il livello di
confidenza e cosa la farebbe cambiare.
Vediamo ora il rovescio della medaglia: gli anti-pattern che vediamo più spesso e la loro correzione.
1. Il prompt-titolo. “Articolo su intelligenza artificiale.” Non è un prompt, è un argomento. Correzione: applica il principio 1 — pubblico, obiettivo, lunghezza, tono, struttura, esclusioni.
2. Il mega-task monolitico. Chiedere in un solo messaggio analisi + strategia + esecuzione + revisione. È esattamente il caso della “feature da 3.000 righe” del talk: a volte funziona, spesso produce qualcosa di diverso da ciò che volevi. Correzione: piano prima, esecuzione poi; oppure prompt chaining.
3. Il contesto negato. “Scrivi la pagina servizi per il mio sito” senza dire cosa vendi, a chi, a che prezzo, con che differenziazione. Claude scriverà una pagina servizi generica perfettamente inutile. Correzione: la regola del consulente esterno — cosa dovrebbe sapere per fare un buon lavoro?
4. Le istruzioni in conflitto. “Sii sintetico ma copri ogni aspetto in dettaglio, con tono formale ma amichevole e frizzante.” Quando due vincoli confliggono, Claude sceglie un compromesso che potrebbe non piacerti. Correzione: gerarchizza (“la priorità è la sintesi; il dettaglio solo dove indicato”).
5. Correggere ripetendo lo stesso prompt. Se l’output non va, riscrivere lo stesso prompt sperando in un esito diverso è inefficiente. Correzione: di’ a Claude cosa non va dell’output precedente, in modo specifico (“il tono è troppo istituzionale, guarda l’esempio in e riallineati”). E se la stessa correzione ricorre in più conversazioni, spostala nel contesto persistente — istruzioni di Progetto o CLAUDE.md — come insegna il pattern del cancelletto in Claude Code.
6. Non interrompere in tempo. In un processo lungo, aspettare la fine per dire che la direzione era sbagliata costa il doppio. Correzione: chiedi checkpoint intermedi (“mostrami la scaletta prima”, “fammi vedere il primo capitolo prima di continuare”) e usa la correzione precoce.
7. Fidarsi dei fatti senza chiedere le fonti. Per contenuti con dati, date, numeri e citazioni, non dare per scontato che tutto sia verificato. Correzione: “per ogni dato numerico indica la fonte; se non sei sicuro di un’informazione, segnalala come da verificare”. Ancora meglio: usa la ricerca web quando disponibile e chiedi le fonti dei claim.
8. Ignorare il formato di destinazione. Ricevere un output perfetto ma nel formato sbagliato (prosa quando serviva una tabella, testo quando serviva JSON) è tempo perso. Correzione: principio 6, sempre, anche quando sembra ovvio.
Finora abbiamo parlato del singolo prompt. Ma il vero salto di produttività, come emerge chiaramente dal talk del creatore di Claude Code, avviene quando il prompting diventa infrastruttura condivisa: asset che il team scrive una volta e usa per sempre.
Ogni azienda che usa Claude seriamente dovrebbe mantenere una libreria di prompt versionata, esattamente come mantiene la documentazione. Struttura consigliata:
Il parallelo con Claude Code è diretto: il CLAUDE.md condiviso nel repository, gli slash command versionati in .claude/commands, la configurazione MCP nel progetto. Cherny descrive questo come un effetto rete: una persona investe un’ora nella configurazione, e ogni membro del team la sfrutta a ogni sessione. La stessa logica vale per marketing, amministrazione, vendite.
In Claude Code, gli slash command sono prompt salvati come file che puoi richiamare con /nomecomando. L’esempio citato nel talk è eloquente: nel repository di Claude Code esiste un comando che etichetta automaticamente le issue di GitHub, ed è eseguito da una GitHub Action — un prompt che lavora da solo, in automazione, risparmiando ore di lavoro umano ripetitivo.
Il concetto da portare a casa: ogni compito che descrivi a Claude più di due volte merita di diventare un prompt salvato. In Claude Code sarà uno slash command; in Claude.ai un Progetto o un messaggio template; via API un endpoint della tua automazione.
Il talk tocca anche un tema che le aziende sottovalutano: la governance dell’uso di Claude. In Claude Code, gli amministratori possono distribuire policy enterprise che pre-approvano i comandi sicuri usati da tutti (eliminando attriti) e bloccano in modo non aggirabile comandi o URL vietati (proteggendo il codebase). Cherny rivela che la sicurezza dei comandi bash è stata una delle parti più difficili da progettare: comandi in sola lettura identificati automaticamente, analisi statica delle combinazioni di comandi, e un sistema di permessi a livelli.
La traduzione per qualsiasi team: definisci regole d’uso esplicite — quali dati si possono incollare nei prompt, come trattare le informazioni dei clienti, quali output richiedono revisione umana prima della pubblicazione. Il prompt engineering aziendale maturo include sempre un livello di policy.
Quando Claude lavora dentro un’automazione — una pipeline SDK, una GitHub Action, un cron che genera report — il prompt deve rispettare requisiti più severi, perché nessun umano potrà chiarire i dubbi a metà strada:
Chi usa Claude dall’interfaccia web o dall’app ha a disposizione funzionalità che cambiano il modo di scrivere i prompt. Vediamole in ottica di prompting.
I Progetti di Claude.ai sono l’equivalente consumer del CLAUDE.md: uno spazio con istruzioni personalizzate e documenti caricati che ogni conversazione del progetto eredita automaticamente. L’approccio corretto è identico a quello raccomandato nel talk: istruzioni brevi, curate e specifiche. Un progetto “Contenuti Blog” conterrà tono di voce, pubblico, struttura standard degli articoli e due o tre esempi dei tuoi pezzi migliori; un progetto “Assistenza Clienti” conterrà le policy di risposta, il glossario dei prodotti e i template delle email. Il risultato: i tuoi prompt quotidiani si accorciano dell’80%, perché il contesto stabile è già lì.
Errore comune: caricare nel progetto decine di documenti “perché non si sa mai”. Vale la regola del contesto curato — ogni documento caricato deve rispondere alla domanda “servirà nella maggior parte delle conversazioni di questo progetto?”. Per il materiale occasionale, meglio allegarlo al singolo messaggio.
Quando Claude ha accesso alla ricerca web, il prompting cambia in due modi. Primo, puoi (e devi) chiedere informazioni aggiornate esplicitamente: “cerca i dati più recenti su X prima di rispondere”. Secondo, puoi imporre standard giornalistici: “cita la fonte di ogni dato numerico”, “privilegia fonti primarie e ufficiali”, “se le fonti sono in disaccordo, segnalalo invece di scegliere arbitrariamente”. Per i contenuti SEO questo è oro: un articolo con dati aggiornati e fonti reali è qualitativamente superiore — per i lettori e per i motori di ricerca — a uno costruito solo sulla conoscenza statica del modello.
Quando chiedi a Claude output lunghi o strutturati (articoli, codice, tabelle, presentazioni), specificare la destinazione finale nel prompt migliora il risultato: “preparalo come documento pronto da incollare in WordPress, con i sottotitoli in H2 e H3”, “genera un file Markdown scaricabile”, “crea una pagina HTML autonoma che posso aprire nel browser”. Claude adatterà formato, struttura e persino le scelte tecniche alla destinazione dichiarata. È il principio 6 applicato all’ecosistema: il formato non è solo sintassi, è il contesto d’uso dell’output.
Mettiamo insieme tutto con un esempio realistico: produrre un articolo SEO di qualità con Claude, applicando i principi di questa guida.
Sette passaggi, quattro lezioni del creatore di Claude Code applicate fuori dal codice. È questo il senso profondo della guida: i pattern del prompting agentico professionale sono trasferibili a qualunque lavoro della conoscenza.
Non esiste una lunghezza ideale: esiste la lunghezza necessaria. Un prompt efficace è lungo quanto serve per trasferire intento, contesto e vincoli — né più né meno. Per una domanda semplice bastano dieci parole; per un brief di lavoro complesso possono servire diverse centinaia di parole più i documenti allegati. L’errore non è mai la lunghezza in sé, ma la vaghezza (prompt troppo corto per il compito) o il rumore (contesto irrilevante che diluisce il segnale). Ricorda la regola del CLAUDE.md: contesto curato, non contesto abbondante.
Claude comprende e produce un italiano eccellente, e per output destinati a un pubblico italiano conviene promptare in italiano: il modello calibra meglio registro, idiomi e riferimenti culturali. L’inglese può dare un piccolo vantaggio su task tecnici molto specialistici (terminologia di programmazione, documentazione di librerie), ma la differenza per la maggior parte degli usi è trascurabile. La scelta pragmatica: prompta nella lingua dell’output desiderato, e specifica sempre esplicitamente la lingua se prompt e output devono differire.
In gran parte sì: i principi (specificità, contesto, esempi, struttura, formato) sono universali. Ma alcuni pattern rendono particolarmente bene su Claude: i tag XML per la struttura, l’uso di contesti molto lunghi, le istruzioni di auto-verifica e i workflow agentici con piano preventivo. Se ottimizzi seriamente un prompt per la produzione, testalo sul modello specifico che userai: le differenze si vedono soprattutto sui casi limite.
Tre leve in ordine di potenza: (1) mostra un esempio completo del formato desiderato (few-shot); (2) descrivi il formato con vincoli misurabili, non qualitativi; (3) chiedi l’auto-verifica finale contro una checklist del formato. Via API aggiungi la quarta leva: il prefill della risposta. Se Claude continua a deviare, quasi sempre c’è un’ambiguità o un conflitto nelle istruzioni: rileggile come le leggerebbe un estraneo.
I principi sono gli stessi, ma Claude Code aggiunge la dimensione agentica: Claude non solo risponde, ma agisce — legge file, esegue comandi, itera. Il prompt quindi non descrive solo l’output, ma il processo: cosa esplorare, quando pianificare, come verificarsi, quando fermarsi a chiedere. In più, Claude Code ha il contesto persistente del CLAUDE.md e strumenti come slash command e memoria, che spostano parte del “prompting” dalla conversazione alla configurazione. La progressione consigliata dal creatore dello strumento: prima Q&A sul codice, poi modifiche guidate, poi integrazione degli strumenti del team, infine automazione e parallelizzazione.
Sì, ed è una delle tecniche meta più efficaci: incolla il tuo prompt e chiedi “analizza questo prompt e riscrivilo per renderlo più efficace: segnala ambiguità, informazioni mancanti e vincoli non misurabili”. Lo stesso talk di Cherny suggerisce di passare il contesto (come il CLAUDE.md) attraverso un prompt improver. Puoi anche chiedere a Claude, dopo un output deludente, “cosa avresti avuto bisogno di sapere per fare meglio?”: la risposta è, di fatto, la lista di ciò che mancava al tuo prompt.
Per molte persone sì, e il motivo è pratico: parlando, il costo di essere dettagliati crolla. Il creatore di Claude Code racconta di dettare i propri prompt con la dettatura di sistema proprio perché la specificità aiuta molto e a voce viene naturale spiegare il contesto come si farebbe con un collega. Il rischio della dettatura è la disorganizzazione: per compiti complessi, meglio dettare il contesto e poi rifinire per iscritto struttura e vincoli.
Prima di inviare un prompt importante, passa questa checklist:
Se c’è un messaggio che attraversa tutto il talk del creatore di Claude Code, è questo: non esistono formule magiche, esiste un metodo. Fai domande per capire i confini dello strumento. Chiedi un piano prima dell’esecuzione. Dai al modello un modo per verificare il proprio lavoro. Cura il contesto come cureresti la documentazione. Trasforma ciò che ripeti in asset riutilizzabili. E man mano che cresci, delega di più e in parallelo.
Sono principi che valgono per un ingegnere che lavora su un codebase da milioni di righe come per un consulente che scrive contenuti, analizza dati o automatizza processi per i clienti. Il modello sottostante migliora di mese in mese — e proprio per questo la competenza che mantiene il suo valore nel tempo non è conoscere il trucco del momento, ma saper comunicare intento, contesto e vincoli con chiarezza. Che poi è, da sempre, la definizione di un buon brief.
Inizia oggi: prendi l’ultimo prompt che ti ha deluso, passalo attraverso la checklist qui sopra, e riprova. La differenza si vede al primo tentativo.
Vuoi integrare Claude nei processi della tua azienda — dalla generazione di contenuti SEO all’automazione dei workflow? Contattami per una consulenza: analizziamo insieme i casi d’uso a maggior ritorno per il tuo business.