Prompt per delegare bene
La prima volta che provano ad affidare a Claude un lavoro vero, molte persone incontrano lo stesso ostacolo. Scrivono un prompt, ricevono un risultato che non è quello che si aspettavano e arrivano a una di due conclusioni: o Claude non è abbastanza bravo, oppure loro non si sono spiegati bene. A quel punto riscrivono tutto da capo e riprovano.
Di solito il problema non è esattamente nessuna delle due cose. Il punto è che un prompt da chat e un prompt pensato per far svolgere un lavoro non sono la stessa cosa. Da fuori si somigliano, ma richiedono un approccio diverso.
In chat il prompt serve a iniziare una conversazione: chiedi, ricevi una risposta, reagisci, continui. L'andirivieni fa parte del processo. Con Cowork, invece, il prompt assomiglia di più a un brief ben scritto: descrivi il risultato finale, dai a Claude i materiali che gli servono e gli lasci fare il lavoro. L'obiettivo è scrivere un prompt che potresti dare a una persona capace, per esempio uno stagista sveglio o un collaboratore affidabile, senza che debba tornare da te con una lista di domande.
Questo è anche il miglior controllo che puoi fare prima di inviare il prompt. Rileggilo e chiediti: se lo ricevessi io, senza sapere altro, cosa dovrei indovinare? Tutto ciò che andrebbe indovinato è qualcosa che manca dal prompt.
I quattro elementi
Un buon prompt per Cowork contiene quattro elementi. Non sono una checklist da compilare in modo meccanico: sono un modo per capire se stai davvero dicendo a Claude ciò che gli serve sapere.
Il primo è il risultato. Che cosa deve esistere alla fine? Non è la stessa cosa che descrivere l'azione da fare. "Riassumi i report" descrive un'azione. "Prepara un executive summary di una pagina, leggibile in due minuti da un direttore non tecnico, che faccia capire come sono andate le performance del Q2 rispetto agli obiettivi" descrive un risultato. La differenza conta. Se specifichi il risultato, Claude può scegliere il modo migliore per arrivarci. Se specifichi solo l'azione, lo scopo resta ambiguo.
Il secondo sono i materiali di partenza. Dove deve guardare Claude? Se vuoi che lavori su dei file, indica quali sono. "Usa le risposte al sondaggio nella cartella /Ricerca" è molto più utile di "usa i dati di cui parlavo prima". Claude non può sapere dal contesto quali file intendi, cosa contengono o quale versione usare se ce ne sono più di una. Essere espliciti qui non è pignoleria: è la differenza tra ottenere ciò che ti aspettavi e ricevere un output basato su ipotesi.
Il terzo è il formato dell'output e dove salvarlo. Che tipo di file vuoi, e dove deve finire? Sembra ovvio, ma è una delle cose che si dimenticano più spesso. "Salvalo come file .xlsx nella cartella /Finanza/Q2" dà a Claude una destinazione chiara. Senza questa indicazione, potresti ritrovarti con il formato sbagliato, con il risultato incollato nella conversazione invece che salvato, o con un file messo in una posizione che per Claude ha senso ma per te no.
Il quarto sono vincoli e preferenze. Qui rientra tutto ciò che influenza il modo in cui l'output deve essere scritto o costruito: tono, lunghezza, struttura, pubblico, cose da escludere. Non sempre servono vincoli particolari, ma se hai una preferenza forte, scrivila. Se il report deve seguire lo stile aziendale, o se l'analisi è destinata a un cliente che non conosce il vostro gergo interno, dillo. I vincoli non servono a limitare Claude: servono a dargli informazioni utili per produrre esattamente ciò che ti serve.
Prima e dopo
Ecco come cambia, nella pratica, un prompt troppo vago rispetto a un brief utilizzabile.
Immagina di lavorare nel marketing e di dover preparare un briefing competitivo prima del lancio di un prodotto. Hai raccolto articoli recenti, note di analisti e un foglio di confronto tra concorrenti. Ti serve un documento che il product team possa leggere prima della riunione di giovedì.
Il prompt debole:
"Puoi mettere insieme un briefing competitivo basato sulla ricerca che ho?"
Sembra una richiesta ragionevole. In realtà è quasi tutta da interpretare. Quale ricerca? Che formato deve avere il briefing? Quanto deve essere lungo? Chi lo leggerà? Quale decisione deve aiutare a prendere? Una persona capace, prima di iniziare, avrebbe almeno quattro domande da farti. Claude proverà a riempire quei vuoti con delle ipotesi, ma non è detto che siano le stesse che avevi in mente tu.
Un prompt efficace:
"Utilizzando i file nella mia cartella /Marketing/Competitivo — inclusi i tre articoli di notizie, la nota degli analisti di maggio e il foglio di confronto dei concorrenti — scrivi un briefing competitivo per il nostro product team in vista della review del lancio di giovedì. Il briefing deve essere di due o tre pagine. Apri con un paragrafo di sintesi della situazione, poi dedica una sezione a ciascuno dei nostri tre principali concorrenti, includendo mosse recenti e posizionamento sui prezzi. Chiudi con una sezione intitolata 'Implicazioni per il lancio', con le due o tre cose di cui il team deve tenere conto. Il pubblico sono i nostri product lead: conoscono bene il prodotto, ma potrebbero non aver seguito da vicino le notizie sui concorrenti. Salva il file in formato .docx nella cartella /Marketing/Briefing."
Il lavoro è lo stesso. Il brief no. La seconda versione specifica il risultato, indica i materiali di partenza, dà una struttura senza dettare ogni frase, chiarisce il pubblico e dice dove salvare il file. Uno stagista sveglio potrebbe eseguirlo senza chiedere altro.
La trappola del troppo dettaglio
Esiste anche l'errore opposto, e le persone attente ai dettagli ci cascano spesso: scrivere un prompt che somiglia a un manuale di istruzioni.
Per esempio:
"Prima, apri il foglio di confronto dei concorrenti. Guarda le colonne da B a F. Per ogni concorrente, nota il prezzo nella colonna C. Poi guarda gli articoli nella cartella. Trova le menzioni dei prezzi. Confronta quelle menzioni con il foglio. Poi scrivi un paragrafo per ogni concorrente. Inizia con il loro nome. Poi descrivi i loro prezzi. Poi descrivi le notizie recenti. Usa tre frasi per concorrente..."
È peggio, non meglio, di una descrizione chiara del risultato. Se specifichi ogni passaggio, togli a Claude la possibilità di scegliere l'approccio più sensato. Rendi anche il prompt fragile: se il foglio ha una struttura diversa da quella che ti aspettavi, o se gli articoli non parlano esplicitamente di prezzi, le istruzioni passo passo si rompono. Una buona descrizione del risultato lascia a Claude lo spazio per gestire le variazioni. Uno script passo passo no.
Il livello giusto è questo: abbastanza dettaglio perché sia chiaro quando il lavoro è finito, ma non così tanto da controllare ogni passaggio.
Iterare senza ricominciare da capo
Il primo output spesso è vicino al risultato giusto, ma non ci arriva del tutto. L'istinto di molte persone è riscrivere il prompt da zero e riprovare. Quasi sempre è una perdita di tempo.
Quando riparti da capo, butti via tutto ciò che Claude ha già capito dal primo prompt e dal suo stesso output. Inoltre diventa più difficile capire che cosa andava davvero corretto. Di solito conviene trattare l'output come una bozza e dare feedback su quella.
Guarda la differenza tra queste due risposte a un output che non è ancora abbastanza buono:
Opzione uno — ripartire da capo: "Proviamo di nuovo. Mi serve un briefing competitivo più conciso e focalizzato sulla strategia di prezzo. Il pubblico sono i nostri product lead. Per favore usa i file nella cartella /Marketing/Competitivo..." Opzione due — lavorare sull'output già prodotto: "La struttura è giusta e le sezioni dei concorrenti funzionano bene. L'Executive summary è troppo lungo: riducilo a tre frasi al massimo. La sezione 'Implicazioni per il lancio' deve essere più concreta; adesso è troppo generica per essere utile. Puoi rivedere solo quelle due sezioni?"
La seconda opzione è più veloce ed efficace. Dai a Claude un feedback preciso su ciò che ha già prodotto, invece di chiedergli di ricostruire tutto da nuove istruzioni. È lo stesso approccio che useresti con una persona: non restituisci una bozza dicendo "rifalla da capo, ma con più giudizio". Indichi che cosa va cambiato e perché.
L'eccezione è quando l'output mostra che il prompt iniziale portava proprio nella direzione sbagliata. Se Claude ha risolto un problema diverso da quello che volevi, allora ha senso riscrivere il prompt. Ma se l'output è impostato bene e ha solo bisogno di essere rifinito, lavora su quello. Arriverai alla versione finale più in fretta.
Il test dello stagista
Prendi un prompt che hai scritto, o che stai per scrivere. Leggilo come se fossi una persona capace che lo riceve per la prima volta come incarico di lavoro. Sai usare gli strumenti. Hai voglia di fare bene. Però non hai mai incontrato chi ha scritto il brief, e non hai altro contesto oltre a quello che c'è sulla pagina.
Cosa dovresti indovinare?
Se la risposta è "nulla", il prompt probabilmente funziona: il risultato è chiaro, i materiali di partenza sono indicati, il formato è definito e i vincoli si capiscono. Se dovresti indovinare una o due cose, hai trovato le lacune da colmare. Se dovresti indovinarne quattro o cinque, il prompt va riscritto prima di inviarlo.
Non si tratta di seguire un template. Si tratta di sviluppare un occhio per ciò che il prompt comunica davvero, invece di ciò che pensi comunichi perché tu conosci già il contesto. La maggior parte degli errori nasce proprio lì: tra ciò che hai in testa e ciò che hai effettivamente scritto.
Un'abitudine utile: scrivi il prompt, poi mettiti per trenta secondi nei panni di chi lo riceve. Quella pausa, da sola, fa emergere quasi tutte le lacune.
Pensa a un lavoro reale che fai regolarmente e che richiede di mettere insieme informazioni da più fonti: un report settimanale, un riassunto di riunione, un aggiornamento di progetto, una raccolta di ricerche. Scegli qualcosa che hai già fatto più volte e che conosci bene.
Scrivi un prompt usando i quattro elementi: risultato, materiali di partenza, formato e destinazione dell'output, più eventuali vincoli o preferenze. Poi applica il test dello stagista: rileggi il prompt come se non avessi nessun contesto e individua tutto ciò che dovresti indovinare. Modificalo finché la risposta a "che cosa dovrei indovinare?" non è davvero "nulla".
Quando ci sei, esegui il compito. Quando arriva l'output, resisti alla tentazione di valutarlo come riuscito o fallito. Individua invece le due o tre modifiche più precise che lo renderebbero migliore, e scrivi quel feedback a Claude come follow-up. Osserva quanto più rapidamente la seconda versione si avvicina al risultato finale.