Delegare con le Istruzioni Giuste

C'è un divario di competenze che la maggior parte delle persone incontra la prima volta che prova a delegare un compito reale a Claude. Scrivono un prompt, ricevono qualcosa che manca il segno, e concludono una di due cose: o Claude non è abbastanza capace, oppure non si sono spiegati bene, quindi riscrivono tutto da zero e riprovano.

Nessuna delle due conclusioni è del tutto corretta. Il divario è quasi sempre un divario di prompting — specificamente, il divario tra il prompting da chat e il prompting da delega. Sembrano simili in superficie, ma richiedono una mentalità diversa.

Il prompting da chat è conversazionale. Chiedi, ricevi una risposta, reagisci, continui. L'andirivieni è il mezzo. Il prompting da delega è più come scrivere un buon brief: descrivi come appare il lavoro finito, fornisci a Claude ciò di cui ha bisogno per lavorare, e lascialo fare il lavoro. L'obiettivo è scrivere un prompt che potrebbe essere consegnato a una persona di fiducia e capace — un tirocinante intelligente, un collaboratore capace — ed eseguito senza alcuna domanda di follow-up.

Quel test della singola domanda è in realtà il miglior strumento di calibrazione che hai. Rileggi il tuo prompt e chiediti: se qualcuno di cui mi fido ricevesse questo, cosa dovrebbe indovinare? Qualsiasi cosa dovrebbe indovinare è ciò che manca al tuo prompt.

L'input di un compito Cowork che mostra un prompt di delega dettagliato che specifica il risultato, il materiale di partenza, il formato e la destinazione di salvataggio
Scrivere il brief in Cowork: risultato, materiale di partenza, formato e dove salvare il risultato.

I Quattro Ingredienti

I prompt di delega efficaci hanno quattro ingredienti. Non come lista di controllo da seguire meccanicamente, ma come modo di pensare a ciò che stai effettivamente comunicando.

Il primo è il risultato. Come appare il lavoro finito? Questo è diverso dal descrivere cosa vuoi che Claude faccia. "Riassumi i report" descrive un'azione. "Produce un riassunto esecutivo di una pagina che un direttore non tecnico potrebbe leggere in due minuti e capire le nostre prestazioni Q2 rispetto agli obiettivi" descrive un risultato. La differenza conta. Quando specifichi il risultato, dai a Claude la capacità di prendere decisioni su come farlo. Quando specifichi solo l'azione, lasci lo scopo ambiguo.

Il secondo è il materiale di partenza. Dove dovrebbe guardare Claude? Se stai chiedendo a Claude di lavorare con dei file, nominali esplicitamente. "Usa le risposte del sondaggio nella mia cartella /Ricerca" è molto più utile di "usa i dati che ho menzionato." Claude non indovina dal contesto quali file intendi, cosa contengono, o quali hanno la precedenza se ci sono più versioni. Essere espliciti qui non è pedante — è la differenza tra ottenere ciò che ti aspettavi e ottenere qualcosa che Claude ha inventato per colmare un vuoto.

Il terzo è il formato e la destinazione dell'output. Che tipo di file, e dove deve andare? Sembra ovvio, ma è uno degli ingredienti più comunemente saltati. "Salva come file .xlsx nella mia cartella /Finanza/Q2" dà a Claude una zona di atterraggio chiara. Senza di essa, potresti ottenere output nel formato sbagliato, incollato nella conversazione invece di salvato da qualche parte, o salvato in una posizione che ha senso per Claude ma non per te.

Il quarto sono i vincoli e le preferenze. Questo è il catch-all per tutto ciò che modella come l'output dovrebbe sembrare, per chi è, o cosa dovrebbe evitare. Tono, lunghezza, struttura, pubblico, cose da escludere. Non tutto ha bisogno di un vincolo, ma quando hai una preferenza forte — il report deve corrispondere al nostro stile aziendale, l'analisi è per un cliente che non conosce la nostra terminologia interna — dillo qui. I vincoli non sono limitazioni per Claude; sono informazioni che lo aiutano a fornire esattamente ciò di cui hai bisogno.

Prima e Dopo

Ecco come appare il divario tra un prompt debole e uno forte nella pratica.

Immagina di essere un responsabile marketing che prepara un briefing competitivo prima del lancio di un prodotto. Hai raccolto articoli recenti, note di analisti e un foglio di confronto dei concorrenti. Ti serve un documento che il tuo team di prodotto possa leggere prima di una riunione di giovedì.

Il prompt debole:

"Puoi mettere insieme un briefing competitivo basato sulla ricerca che ho?"

È una richiesta che suona ragionevole. È anche quasi interamente ambigua. Quale ricerca? Che formato dovrebbe avere il briefing? Quanto lungo? Chi lo legge? Quali decisioni deve supportare? Una persona capace che riceve questo prompt dovrebbe fare almeno quattro domande di follow-up prima di iniziare. Claude riempirà quei vuoti con ipotesi — e le ipotesi potrebbero non corrispondere a ciò che avevi in mente.

Il 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 team di prodotto
in vista della revisione del lancio di giovedì. Il briefing dovrebbe essere di
due o tre pagine. Strutturalo con un paragrafo di riepilogo della situazione in
cima, poi una sezione per ciascuno dei nostri tre principali concorrenti che
copra le loro mosse recenti e il posizionamento dei prezzi. Chiudi con una
sezione chiamata 'Implicazioni per il Lancio' che metta in evidenza le due o
tre cose di cui il nostro team deve maggiormente tenere conto. Il pubblico sono
i nostri responsabili di prodotto, che conoscono bene il nostro prodotto ma
potrebbero non aver seguito da vicino le notizie sui concorrenti. Salva come
file .docx in /Marketing/Briefing."

Stesso compito. Brief completamente diverso. La seconda versione specifica il risultato, nomina il materiale di partenza, fornisce indicazioni strutturali senza dettare ogni frase, identifica il pubblico e fornisce una destinazione. Un tirocinante intelligente potrebbe eseguirlo senza chiedere nulla.

La Trappola della Iper-specificazione

C'è un modo di fallire opposto che vale la pena nominare, perché le persone intelligenti e attente ai dettagli ci cadono spesso. L'iper-specificazione: scrivere un prompt che è essenzialmente un manuale d'istruzioni.

Sembra così:

"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 pulita del risultato. Quando specifichi ogni passo, sovrascrivi il giudizio di Claude sull'approccio più efficace. Rendi anche il prompt fragile — se il foglio ha una struttura diversa da quella che ti aspettavi, o se gli articoli non menzionano esplicitamente i prezzi, le istruzioni passo-passo si rompono. Una buona descrizione del risultato dà a Claude la libertà di gestire intelligentemente le variazioni. Un script passo-passo non lo fa.

Il giusto livello di specificità è: abbastanza che "fatto" sia inequivocabile, non così tanto da microgestire il metodo.

Iterare Senza Ricominciare da Capo

Il primo output è spesso vicino ma non del tutto giusto. L'istinto che la maggior parte delle persone ha è di riscrivere l'intero prompt e riprovare. Quell'istinto è quasi sempre sbagliato.

Quando riscrivi da zero, scardi tutto ciò che Claude ha imparato dal tuo primo prompt e dal suo stesso output. Rendi anche più difficile isolare cosa aveva effettivamente bisogno di cambiare. La mossa migliore è trattare l'output come una bozza e dargli feedback direttamente su di essa.

Considera la differenza tra queste due risposte a un output che non ha centrato il bersaglio:

Opzione uno — ricominciare da capo:
"Proviamo di nuovo. Ho bisogno di un briefing competitivo più conciso e
focalizzato sulla strategia dei prezzi. Il pubblico sono i nostri responsabili
di prodotto. Per favore usa i file nella cartella /Marketing/Competitivo..."

Opzione due — iterare sull'output:
"La struttura è giusta e le sezioni dei concorrenti funzionano bene. Il riassunto
esecutivo è troppo lungo — riducilo a tre frasi al massimo. La sezione
'Implicazioni per il Lancio' dovrebbe essere più specifica; in questo momento è
troppo generica per essere praticabile. Puoi rivedere solo quelle due sezioni?"

L'opzione due è più veloce ed efficace. Stai dando a Claude feedback preciso e mirato su ciò che esiste, invece di chiedergli di ricostruire il compito da nuove istruzioni. È lo stesso approccio che useresti con qualsiasi collaboratore: non restituisci una bozza dicendo "ricomincia da capo con più giudizio." Segni cosa deve cambiare e perché.

L'eccezione è quando l'output rivela che il tuo prompt originale era fondamentalmente fuorviante. Se Claude ha risolto il problema sbagliato del tutto, un prompt rivisto ha senso. Ma se l'output è direzionalmente giusto e ha bisogno di rifinitura, itera su di esso. Arriverai alla versione finale più velocemente.

Il Test del Tirocinante in Azione

Prendi qualsiasi prompt che hai scritto o che stai per scrivere. Leggilo come se fossi una persona intelligente e capace che l'ha appena ricevuto come assegnazione di lavoro. Conosci gli strumenti. Sei disposto a lavorare sodo. Ma non hai mai incontrato la persona che ha scritto il brief, e non hai nessun contesto oltre a quello che c'è sulla pagina.

Cosa dovresti indovinare?

Se la risposta è nulla — hai un output chiaro in mente, sai dove vive il materiale di partenza, sai quale formato consegnare e capisci i vincoli — il prompt funzionerà. Se la risposta è una o due cose, quelle sono le lacune da colmare. Se la risposta è quattro o cinque cose, il prompt ha bisogno di una revisione sostanziale prima di inviarlo.

Non si tratta di seguire un template. Si tratta di sviluppare un senso per ciò che un prompt sta effettivamente comunicando rispetto a ciò che supponi comunichi perché conosci già il contesto. Quel divario tra ciò che sai e ciò che hai scritto è dove vivono la maggior parte dei fallimenti di delega.

Un'abitudine utile: scrivi il prompt, poi mettiti nei panni del lettore per trenta secondi prima di inviarlo. Quella pausa da sola coglierà la maggior parte delle lacune.

Prova Questo

Pensa a un compito reale che fai regolarmente e che implica raccogliere informazioni da più fonti — un rapporto di stato settimanale, un riassunto di riunione, un aggiornamento di progetto, una raccolta di ricerche. Qualcosa che hai fatto almeno qualche volta e che conosci bene.

Scrivi un prompt di delega usando i quattro ingredienti: risultato, materiale di partenza, formato e destinazione dell'output, e qualsiasi vincolo o preferenza. Poi applica il test del tirocinante: leggi il tuo prompt come se non avessi nessun contesto precedente e identifica tutto ciò che dovresti indovinare. Rivedi il prompt per colmare quei vuoti. Il tuo obiettivo è un prompt in cui la risposta a "cosa dovrei indovinare?" sia genuinamente nulla.

Una volta che l'hai, esegui il compito. Quando l'output torna, resisti all'impulso di valutarlo come superato o non superato. Invece, identifica le due o tre cose più specifiche che lo renderebbero migliore, e scrivi quel feedback direttamente a Claude come follow-up. Nota quanto più velocemente la seconda versione arriva al risultato finale.