While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.
Perché concatenare i prompt?
- Precisione: Ogni sottocompito riceve la piena attenzione di Claude, riducendo gli errori.
- Chiarezza: Sottocompiti più semplici significano istruzioni e output più chiari.
- Tracciabilità: Identifica e risolvi facilmente i problemi nella tua catena di prompt.
Quando concatenare i prompt
Usa il concatenamento di prompt per compiti multi-step come la sintesi di ricerca, l’analisi di documenti o la creazione iterativa di contenuti. Quando un compito coinvolge multiple trasformazioni, citazioni o istruzioni, il concatenamento impedisce a Claude di perdere o gestire male i passaggi. Ricorda: Ogni anello della catena riceve la piena attenzione di Claude!Suggerimento per il debug: Se Claude perde un passaggio o performa male, isola quel passaggio nel suo proprio prompt. Questo ti permette di affinare i passaggi problematici senza rifare l’intero compito.
Come concatenare i prompt
- Identifica i sottocompiti: Suddividi il tuo compito in passaggi distinti e sequenziali.
- Struttura con XML per passaggi chiari: Usa tag XML per passare output tra prompt.
- Avere un obiettivo a singolo compito: Ogni sottocompito dovrebbe avere un obiettivo singolo e chiaro.
- Itera: Raffina i sottocompiti basandoti sulle prestazioni di Claude.
Esempi di flussi di lavoro concatenati:
- Analisi multi-step: Vedi gli esempi legali e aziendali qui sotto.
- Pipeline di creazione contenuti: Ricerca → Schema → Bozza → Modifica → Formato.
- Elaborazione dati: Estrai → Trasforma → Analizza → Visualizza.
- Presa di decisioni: Raccogli info → Elenca opzioni → Analizza ciascuna → Raccomanda.
- Loop di verifica: Genera contenuto → Rivedi → Raffina → Ri-rivedi.
Suggerimento di ottimizzazione: Per compiti con sottocompiti indipendenti (come analizzare più documenti), crea prompt separati ed eseguili in parallelo per velocità.
Avanzato: Catene di auto-correzione
Puoi concatenare prompt per far sì che Claude riveda il proprio lavoro! Questo cattura errori e raffina output, specialmente per compiti ad alto rischio.Esempio: Riassunto di ricerca auto-correttivo
Esempio: Riassunto di ricerca auto-correttivo
Prompt 1
| Ruolo | Contenuto |
|---|---|
| Utente | Riassumi questo articolo di ricerca medica. <paper>{{RESEARCH_PAPER}}</paper> Concentrati su metodologia, risultati e implicazioni cliniche. |
| Assistente {{SUMMARY}} | Metodologia: RCT in doppio cieco con 500 pazienti con diabete di tipo 2. Gruppo A (n=250) ha ricevuto un nuovo agonista duale GLP-1/GIP; Gruppo B (n=250) ha ricevuto un agonista GLP-1 standard. Studio di 24 settimane, endpoint primario: riduzione HbA1c. Risultati: - Gruppo A: riduzione media HbA1c del 1,8% - Gruppo B: riduzione media HbA1c dell’1,1% - 68% del Gruppo A vs. 52% del Gruppo B ha raggiunto HbA1c <7% - Gruppo A: perdita di peso media di 5,2kg - Gruppo B: perdita di peso media di 3,1kg Sicurezza: Profili di eventi avversi simili, nessun evento grave attribuito al trattamento. Implicazioni Cliniche: L’agonista duale mostra controllo glicemico e perdita di peso superiori rispetto alla terapia standard. Potrebbe essere rivoluzionario, specialmente per diabetici obesi. |
Prompt 2
| Ruolo | Contenuto |
|---|---|
| Utente | Il tuo compito è fornire feedback su un riassunto di articolo di ricerca. Ecco un riassunto di un articolo di ricerca medica: <summary> {{SUMMARY}} </summary> Ecco l’articolo di ricerca: <paper> {{RESEARCH_PAPER}} </paper> Rivedi questo riassunto per accuratezza, chiarezza e completezza su una scala graduata A-F. |
| Assistente {{FEEDBACK}} | 1. Accuratezza: A - Ha riportato correttamente le statistiche chiave: riduzioni HbA1c, perdita di peso. - Ha notato accuratamente il profilo di sicurezza e la mancanza di eventi avversi gravi. - L’affermazione di “rivoluzionario” è giustificata da risultati significativamente migliori. 2. Chiarezza: A- - Conciso e ben strutturato con sezioni chiare. - Buon uso di linguaggio comparativo (es. “aumento del 3% dal Q1”) per contesto. - Problema minore: Acronimi come “RCT,” “GLP-1,” e “GIP” non definiti. Considera di scrivere per esteso al primo uso. 3. Completezza: B+ - Copre tutte le aree richieste: metodologia, risultati, implicazioni cliniche. - Mancante: Caratteristiche basali dei gruppi (erano ben abbinati?). - Mancante: Eventuali endpoint secondari (es. pressione sanguigna, lipidi). - Considera: Implicazioni a lungo termine o necessità di ulteriori ricerche. Nel complesso, il riassunto è accurato e chiaro, fornendo intuizioni chiave per una comprensione rapida dello studio. Per elevare ad A+, definisci gli acronimi, menziona le statistiche basali dei gruppi, nota eventuali risultati secondari e tocca brevemente la necessità di studi a lungo termine. |
Prompt 3
| Ruolo | Contenuto |
|---|---|
| Utente | Il tuo compito è migliorare un riassunto di articolo dato il feedback. Ecco la prima bozza di un articolo di ricerca medica: <summary> {{SUMMARY}} </summary> Ecco l’articolo di ricerca: <paper> {{RESEARCH_PAPER}} </paper> Ecco il feedback: <feedback> {{FEEDBACK}} </feedback> Aggiorna il riassunto basandoti sul feedback. |
| Assistente | Metodologia: Studio controllato randomizzato (RCT) in doppio cieco con 500 pazienti con diabete di tipo 2. Gruppo A (n=250) ha ricevuto un nuovo agonista duale peptide-1 simile al glucagone/polipeptide insulinotropico glucosio-dipendente (GLP-1/GIP); Gruppo B (n=250) ha ricevuto un agonista GLP-1 standard. L’endpoint primario dello studio di 24 settimane era la riduzione HbA1c. I gruppi erano ben abbinati per età, BMI e HbA1c basale. Risultati: - Gruppo A: riduzione media HbA1c del 1,8% - Gruppo B: riduzione media HbA1c dell’1,1% - 68% del Gruppo A vs. 52% del Gruppo B ha raggiunto HbA1c <7% - Gruppo A: perdita di peso media di 5,2kg - Gruppo B: perdita di peso media di 3,1kg Gli endpoint secondari hanno mostrato miglioramenti nella pressione sanguigna e nei profili lipidici per entrambi i gruppi, con il Gruppo A che mostra risultati leggermente migliori. Sicurezza: Profili di eventi avversi simili, senza eventi gravi attribuiti a nessuno dei due trattamenti. Implicazioni Cliniche: L’agonista duale GLP-1/GIP dimostra controllo glicemico e perdita di peso superiori rispetto alla terapia GLP-1 standard. Questi risultati suggeriscono che potrebbe essere un progresso significativo, particolarmente per diabetici obesi. Tuttavia, sono necessari studi a lungo termine per confermare efficacia e sicurezza sostenute, così come per investigare potenziali benefici sui risultati cardiovascolari. |
Esempi
Esempio: Analizzare un contratto legale (senza concatenamento)
Esempio: Analizzare un contratto legale (senza concatenamento)
Nota che Claude perde l’istruzione di fornire modifiche proposte nella sua bozza di email.
| Ruolo | Contenuto |
|---|---|
| Utente | Sei il nostro Chief Legal Officer. Rivedi questo contratto SaaS per rischi, concentrandoti su privacy dei dati, SLA e limiti di responsabilità. <contract> {{CONTRACT}} </contract> Poi redigi un’email al fornitore con le tue preoccupazioni e modifiche proposte. |
| Assistente | Dopo aver rivisto il contratto SaaS, ho identificato diverse preoccupazioni: 1. Privacy dei Dati (Sezione 7): - Problema: Il fornitore ha ampi diritti di usare i dati del cliente per “miglioramento del servizio.” - Rischio: Potrebbe portare a condivisione non autorizzata di dati o monetizzazione. 2. SLA (Sezione 5): - Problema: Garanzia di uptime del 99,5% è sotto lo standard industriale. - Rischio: Downtime eccessivo potrebbe impattare le nostre operazioni. 3. Responsabilità (Sezione 9): - Problema: Limite fissato a 3 mesi di commissioni. - Rischio: Inadeguato per potenziali violazioni di dati o fallimenti del servizio. Bozza email: Gentile {{VENDOR}}, Dopo aver rivisto l’accordo SaaS, abbiamo preoccupazioni: 1. Privacy dei Dati: Richiediamo che i nostri dati siano usati solo per fornitura diretta del servizio, non per ampio “miglioramento del servizio.” Si prega di modificare la Sezione 7. 2. SLA: Uptime del 99,5% è insufficiente. Abbiamo bisogno del 99,99% con penali chiaramente definite. Si prega di rivedere la Sezione 5. 3. Responsabilità: Il limite attuale di 3 mesi di commissioni è inadeguato. Proponiamo un limite di 12 mesi di commissioni, senza limite per violazioni di dati o condotta dolosa. Apprezziamo la nostra potenziale partnership e crediamo che questi cambiamenti ci prepareranno per il successo. Si prega di inviare un accordo rivisto. Cordiali saluti, {{CLO_NAME}} |
Esempio: Analizzare un contratto legale (con concatenamento)
Esempio: Analizzare un contratto legale (con concatenamento)
Prompt 1
| Ruolo | Contenuto |
|---|---|
| Utente | Sei il nostro Chief Legal Officer. Rivedi questo contratto SaaS per rischi, concentrandoti su privacy dei dati, SLA e limiti di responsabilità. <contract> {{CONTRACT}} </contract> Fornisci i tuoi risultati in tag <risks>. |
| Assistente {{CONCERNS}} | 1. Privacy dei Dati (Sezione 7): - Problema: Il fornitore ha ampi diritti di usare i dati del cliente per “miglioramento del servizio.” - Rischio: Potrebbe portare a condivisione non autorizzata di dati o monetizzazione dei dati del cliente. - Impatto: Potenziale violazione della fiducia del cliente, multe normative (GDPR, CCPA). 2. SLA (Sezione 5): - Problema: Garanzia di uptime del 99,5% è sotto lo standard industriale (tipicamente 99,99%). - Rischio: Fino a 43,8 ore di downtime all’anno vs. 52,6 minuti al 99,99%. - Impatto: Interruzioni operative, perdita di ricavi, insoddisfazione del cliente. 3. Responsabilità (Sezione 9): - Problema: Limite di responsabilità fissato a 3 mesi di commissioni. - Rischio: Inadeguato per potenziali violazioni di dati, furto di IP o fallimenti prolungati del servizio. - Impatto: Compensazione insufficiente per danni che potrebbero superare di gran lunga il limite, come azioni legali collettive o multe normative. |
Prompt 2
| Ruolo | Contenuto |
|---|---|
| Utente | Redigi un’email a un fornitore di prodotti SaaS delineando le seguenti preoccupazioni e proponendo modifiche. Ecco le preoccupazioni: <concerns> {{CONCERNS}} </concerns> |
| Assistente {{EMAIL}} | Gentile {{VENDOR}}, Dopo una revisione approfondita dell’accordo SaaS proposto, il nostro team legale ha identificato diverse preoccupazioni ad alta priorità che devono essere affrontate prima che possiamo procedere: 1. Privacy dei Dati (Sezione 7): - Attuale: Ampi diritti di usare i dati del cliente per “miglioramento del servizio.” - Preoccupazione: Potenziale condivisione non autorizzata di dati o monetizzazione. - Modifica Proposta: Limitare l’uso dei dati alla fornitura diretta del servizio. Qualsiasi uso per miglioramento, analisi o marketing deve essere opt-in, revocabile e anonimizzato. 2. SLA (Sezione 5): - Attuale: Garanzia di uptime del 99,5%. - Preoccupazione: Fino a 43,8 ore di downtime all’anno, rischiando interruzioni operative. - Modifica Proposta: Uptime del 99,99% con crediti di servizio a livelli. Es., credito del 10% per <99,99%, 25% per <99,9%, 50% per <99,5%. 3. Responsabilità (Sezione 9): - Attuale: Limite a 3 mesi di commissioni. - Preoccupazione: Grossolanamente inadeguato per violazioni di dati, furto di IP o interruzioni prolungate. - Modifica Proposta: 12 mesi di commissioni per responsabilità generale. Senza limite per violazioni di dati, condotta dolosa, violazione di IP. Questi cambiamenti sono non negoziabili per noi. Si allineano con gli standard industriali e il nostro impegno per la sicurezza dei dati, l’eccellenza operativa e la responsabilità fiduciaria. Apprezziamo il potenziale della nostra partnership, e affrontare questi punti stabilirà una base solida. Si prega di far rivedere e incorporare questi cambiamenti al vostro team legale. Siamo felici di discutere ulteriormente per assicurare comprensione e accordo reciproci. Cordiali saluti, {{CLO_NAME}} |
Prompt 3
| Ruolo | Contenuto |
|---|---|
| Utente | Il tuo compito è rivedere un’email e fornire feedback. Ecco l’email: <email> {{EMAIL}} </email> Fornisci feedback su tono, chiarezza e professionalità. |
| Assistente | 1. Tono: - Professionale e assertivo senza essere conflittuale. - L’uso di “non negoziabile” è forte ma giustificato data la criticità dei problemi. - Il linguaggio collaborativo (“apprezziamo,” “felici di discutere”) bilancia la fermezza, mantenendo un tono costruttivo. 2. Chiarezza: - Strutturazione eccellente: Stato attuale, preoccupazione e modifica proposta per ogni problema. - I termini tecnici (es. “EBITDA,” “crediti di servizio a livelli”) sono appropriati per un contesto B2B SaaS. - Gli elementi d’azione sono chiari: il team legale del fornitore deve rivedere e incorporare i cambiamenti. 3. Professionalità: - Si concentra sul beneficio reciproco e gli standard industriali, non solo sulle nostre richieste. - Menziona responsabilità più ampie (sicurezza dei dati, eccellenza operativa, dovere fiduciario), elevando la discussione. - Offre ulteriore discussione, mostrando impegno per comprendere e risolvere i problemi. Nel complesso, l’email trova il giusto equilibrio tra assertività e collaborazione. Articola chiaramente le nostre preoccupazioni, propone soluzioni specifiche e mantiene un tono professionale orientato alla partnership. Nessuna revisione necessaria; procedi con l’invio. |
Esempio: Revisione strategia multitenancy
Esempio: Revisione strategia multitenancy
Prompt 1
| Ruolo | Contenuto |
|---|---|
| Utente | Come architetto senior delle soluzioni, rivedi e analizza questa strategia di multitenancy per il nostro nuovo prodotto SaaS enterprise. <strategy> {{STRATEGY}} </strategy> Concentrati su scalabilità, sicurezza ed efficacia dei costi. |
| Assistente {{ANALYSIS}} | 1. Scalabilità: + Lo sharding del database per tenant riduce la contesa, supporta alta crescita. + I microservizi permettono scaling indipendente dei componenti. - I server app condivisi potrebbero creare colli di bottiglia sotto carico estremo. - Nessuna menzione di auto-scaling o load balancing per il livello app. 2. Sicurezza: + L’isolamento dei dati tenant via sharding mitiga le perdite di dati. + JWT con scadenza breve e token di refresh è best practice industriale. - Nessuna menzione di crittografia (a riposo, in transito) o gestione chiavi. - La strategia IAM manca di dettagli su ruoli, permessi o RBAC. 3. Efficacia dei costi: + I server app condivisi riducono i costi delle risorse inattive. + Le funzioni serverless per compiti infrequenti ottimizzano i costi. - Il DB per tenant potrebbe aumentare i costi su scala vs. DB multi-tenant ottimizzato. - Nessuna discussione di istanze riservate o istanze spot per risparmio costi. |
Prompt 2
| Ruolo | Contenuto |
|---|---|
| Utente | Redigi un documento di revisione strategica per la leadership ingegneristica basato su questa analisi di una strategia di multitenancy. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Includi un riassunto esecutivo, analisi dettagliata e raccomandazioni. |
| Assistente {{STRATEGY_DOC}} | # Revisione Strategia Multitenancy: Prodotto SaaS Enterprise ## Riassunto Esecutivo La strategia proposta dimostra una base solida nei principi di scalabilità e sicurezza ma ha lacune nei dettagli di implementazione. Eccelle nell’isolamento dei dati e nello scaling a livello di componente ma manca di scaling robusto del livello app e misure di sicurezza avanzate. Le ottimizzazioni dei costi sono presenti ma potrebbero vacillare su alta scala. Con miglioramenti m irati, questa strategia può supportare efficacemente le nostre ambizioni SaaS enterprise. ## Analisi Dettagliata ### 1. Scalabilità: B+ Punti di forza: - Lo sharding del database per tenant è eccellente. Minimizza la latenza delle query, supporta alta crescita dei dati e facilita lo scaling seamless per tenant. - L’architettura microservizi permette di scalare componenti individuali basandosi sulla domanda, cruciale per gestire carichi di lavoro enterprise diversi. Debolezze: - I server applicazione condivisi rischiano di diventare un collo di bottiglia. Man mano che il numero di tenant e il traffico crescono, questi potrebbero degradare le prestazioni su tutti i tenant. - L’assenza di auto-scaling e load balancing per il livello app è una svista critica. Questi sono essenziali per gestire picchi di traffico senza over-provisioning. ### 2. Sicurezza: B- Punti di forza: - I database shardati forniscono forte isolamento dei dati tenant, mitigando i rischi di perdite di dati o accesso non autorizzato tra tenant. - JWT con scadenza breve e token di refresh si allineano con le best practice OWASP, riducendo le finestre di vulnerabilità dei token. Debolezze: - Nessuna menzione di crittografia dei dati a riposo o in transito (TLS 1.3). Questo è non negoziabile per dati enterprise. - La strategia di gestione chiavi è mancante. Come sono gestiti e ruotati le chiavi di crittografia, i segreti JWT e le credenziali DB? - IAM manca di profondità. Abbiamo bisogno di RBAC con ruoli ben definiti, controllo accesso basato su attributi (ABAC) per permessi granulari e integrazione con provider di identità enterprise (SAML, OIDC). ### 3. Efficacia dei costi: B Punti di forza: - I server app condivisi riducono i costi di capacità inattiva, buono per traffico steady-state. - Serverless per compiti infrequenti (es. reporting) è intelligente; paga solo quando queste risorse sono usate. Debolezze: - I database per tenant potrebbero non essere cost-effective su scala rispetto a un database multi-tenant ben progettato con partizionamento dati robusto. - Nessuna menzione di misure di risparmio costi come istanze riservate per carichi di lavoro prevedibili o istanze spot per compiti fault-tolerant. - La mancanza di auto-scaling del livello app potrebbe portare a over-provisioning, aumentando i costi. ## Raccomandazioni 1. Resilienza Livello App: Implementa auto-scaling con Kubernetes o servizi cloud-native (EKS, GKE). Distribuisci attraverso zone di disponibilità con CDN per asset statici. 2. Hardening Sicurezza: a. Critta dati a riposo (AES-256) e in transito (TLS 1.3). b. Usa un KMS gestito (AWS KMS, GCP KMS) per gestione chiavi. c. Migliora IAM con RBAC, ABAC e SAML/OIDC per SSO enterprise. 3. Ottimizzazione Costi: a. Valuta DB multi-tenant colonnare (es. Snowflake) vs. sharding su scala. b. Usa istanze riservate per server app, istanze spot per carichi di lavoro non critici. c. Implementa monitoraggio proattivo e right-sizing per evitare overprovisioning. 4. Proof of Concept (PoC): Prima dell’implementazione completa, conduci un PoC con simulazione ad alta scala: a. Testa DB shardato vs. DB multi-tenant ottimizzato per costo e prestazioni. b. Stress-test del livello app con picchi di traffico simulati a livello enterprise. c. Conduci audit di sicurezza di terze parti, concentrandosi su isolamento dati e controlli accesso. Con questi miglioramenti, la nostra strategia multi-tenancy sarà enterprise-grade: scalabile, sicura ed efficace nei costi. Il PoC validerà le nostre scelte di design e instillerà fiducia nei nostri clienti enterprise. |
Prompt 3
| Ruolo | Contenuto |
|---|---|
| Utente | Valuta questo documento di revisione strategica per chiarezza, azionabilità e allineamento con le priorità enterprise. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistente | 1. Chiarezza: A + Struttura chiara con Riassunto Esecutivo, Analisi Dettagliata e Raccomandazioni. + L’analisi usa un sistema di voti (B+, B-) per comprensione rapida di punti di forza/debolezze. + I termini tecnici (RBAC, ABAC, TLS) sono spiegati o contestualizzati, aiutando la leadership non tecnica. + Gli aiuti visivi (punti elenco, indentazione) migliorano la leggibilità. 2. Azionabilità: A- + Le raccomandazioni sono specifiche e tecniche (es. “Implementa auto-scaling con Kubernetes”). + Il piano PoC con obiettivi chiari fornisce una roadmap. + Mancante: Timeline, requisiti di risorse o assegnazioni team per ogni raccomandazione. + Considera: Aggiungi una sezione “Prossimi Passi” con azioni immediate, ruoli e timeline di alto livello. 3. Allineamento Enterprise: A+ + Affronta direttamente le priorità enterprise: - Scalabilità: Discute gestione picchi di traffico a livello enterprise. - Sicurezza: Si concentra su isolamento dati, crittografia e IAM enterprise. - Costo: Le strategie si allineano con FinOps enterprise (istanze riservate, right-sizing). + PoC con “simulazione ad alta scala” e audit di sicurezza mostra impegno per qualità enterprise-grade. + Il linguaggio risuona con preoccupazioni enterprise: “rischio inaccettabile,” “enterprise-grade,” “instillare fiducia.” Nel complesso, il documento eccelle in chiarezza e allineamento enterprise. L’azionabilità è forte ma potrebbe essere elevata ad A+ con una sezione “Prossimi Passi”. La profondità tecnica, accoppiata con spiegazioni chiare, rende questo altamente efficace sia per leadership tecnica che non tecnica. Ottimo lavoro! |
Libreria prompt
Lasciati ispirare da una selezione curata di prompt per vari compiti e casi d’uso.
Tutorial prompting GitHub
Un tutorial ricco di esempi che copre i concetti di prompt engineering trovati nella nostra documentazione.
Tutorial prompting Google Sheets
Una versione più leggera del nostro tutorial di prompt engineering tramite un foglio di calcolo interattivo.