Concatenare prompt complessi per prestazioni migliori

While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.

Quando si lavora con attività complesse, Claude può talvolta perdere il filo se si cerca di gestire tutto in un singolo prompt. Il prompt a catena di pensiero (Chain of Thought, CoT) è ottimo, ma cosa succede se l’attività ha più fasi distinte che richiedono ciascuna un pensiero approfondito?

Entra in gioco la concatenazione dei prompt: scomporre attività complesse in sotto-attività più piccole e gestibili.

Perché concatenare i prompt?

Accuratezza: Ogni sotto-attività riceve la piena attenzione di Claude, riducendo gli errori.
Chiarezza: Sotto-attività più semplici significano istruzioni e output più chiari.
Tracciabilità: Individuare e correggere facilmente i problemi nella catena di prompt.

Quando concatenare i prompt

Usa la concatenazione dei prompt per attività multi-fase come la sintesi della ricerca, l’analisi dei documenti o la creazione iterativa di contenuti. Quando un’attività coinvolge trasformazioni multiple, citazioni o istruzioni, la concatenazione impedisce a Claude di saltare o gestire male i passaggi.

Ricorda: Ogni anello della catena riceve la piena attenzione di Claude!

Suggerimento per il debug: Se Claude salta un passaggio o ha prestazioni scarse, isola quel passaggio nel suo prompt dedicato. Questo ti permette di perfezionare i passaggi problematici senza rifare l’intera attività.

Come concatenare i prompt

Identifica le sotto-attività: Suddividi l’attività in fasi distinte e sequenziali.
Struttura con XML per passaggi chiari: Usa tag XML per passare gli output tra i prompt.
Abbi un obiettivo singolo: Ogni sotto-attività dovrebbe avere un obiettivo singolo e chiaro.
Itera: Perfeziona le sotto-attività in base alle prestazioni di Claude.

Esempi di flussi di lavoro concatenati:

Analisi multi-fase: Vedi gli esempi legali e aziendali qui sotto.
Pipeline di creazione contenuti: Ricerca → Schema → Bozza → Modifica → Formattazione.
Elaborazione dati: Estrai → Trasforma → Analizza → Visualizza.
Processo decisionale: Raccogli info → Elenca opzioni → Analizza ciascuna → Raccomanda.
Cicli di verifica: Genera contenuto → Revisiona → Perfeziona → Ri-revisiona.

Suggerimento per l’ottimizzazione: Per attività con sotto-attività indipendenti (come l’analisi di più documenti), crea prompt separati ed eseguili in parallelo per velocità.

Avanzato: Catene di auto-correzione

Puoi concatenare i prompt per far revisionare a Claude il proprio lavoro! Questo intercetta errori e perfeziona gli output, specialmente per attività ad alto rischio.

Prompt 1

Ruolo	Contenuto
User	Riassumi questo articolo di ricerca medica. <paper>{{RESEARCH_PAPER}}</paper> Concentrati su metodologia, risultati e implicazioni cliniche.
Assistant {{SUMMARY}}	Metodologia: RCT in doppio cieco con 500 pazienti con diabete di Tipo 2. Gruppo A (n=250) ha ricevuto nuovo agonista duale GLP-1/GIP; Gruppo B (n=250) ha ricevuto agonista GLP-1 standard. Studio di 24 settimane, endpoint primario: riduzione HbA1c. Risultati: - Gruppo A: riduzione media HbA1c dell’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 5,2kg - Gruppo B: perdita di peso media 3,1kg Sicurezza: Profili di eventi avversi simili, nessun evento serio attribuito al trattamento. Implicazioni Cliniche: L’agonista duale mostra un controllo glicemico e una perdita di peso superiori rispetto alla terapia standard. Potrebbe essere rivoluzionario, specialmente per i diabetici obesi.

Ruolo

Contenuto

User

Riassumi questo articolo di ricerca medica.

<paper>{{RESEARCH_PAPER}}</paper>

Concentrati su metodologia, risultati e implicazioni cliniche.

Assistant
{{SUMMARY}}

Metodologia: RCT in doppio cieco con 500 pazienti con diabete di Tipo 2. Gruppo A (n=250) ha ricevuto nuovo agonista duale GLP-1/GIP; Gruppo B (n=250) ha ricevuto agonista GLP-1 standard. Studio di 24 settimane, endpoint primario: riduzione HbA1c.

Risultati:
- Gruppo A: riduzione media HbA1c dell’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 5,2kg
- Gruppo B: perdita di peso media 3,1kg

Sicurezza: Profili di eventi avversi simili, nessun evento serio attribuito al trattamento.

Implicazioni Cliniche: L’agonista duale mostra un controllo glicemico e una perdita di peso superiori rispetto alla terapia standard. Potrebbe essere rivoluzionario, specialmente per i diabetici obesi.

Prompt 2

Ruolo	Contenuto
User	Il tuo compito è fornire feedback su un riassunto di un 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 da A a F.
Assistant {{FEEDBACK}}	1. Accuratezza: A - Riportate correttamente le statistiche chiave: riduzioni HbA1c, perdita di peso. - Notato accuratamente il profilo di sicurezza e l’assenza di eventi avversi seri. - L’affermazione “rivoluzionario” è giustificata dai risultati significativamente migliori. 2. Chiarezza: A- - Conciso e ben strutturato con sezioni chiare. - Buon uso del linguaggio comparativo (es. “su del 3% dal Q1”) per contesto. - Problema minore: Acronimi come “RCT,” “GLP-1,” e “GIP” non definiti. Considerare di scriverli per esteso al primo uso. 3. Completezza: B+ - Copre tutte le aree richieste: metodologia, risultati, implicazioni cliniche. - Mancante: Caratteristiche di base dei gruppi (erano ben bilanciati?). - Mancante: Eventuali endpoint secondari (es. pressione sanguigna, lipidi). - Considerare: Implicazioni a lungo termine o necessità di ulteriori ricerche. Nel complesso, il riassunto è accurato e chiaro, fornendo informazioni chiave per una rapida comprensione dello studio. Per elevarlo ad A+, definire gli acronimi, menzionare le statistiche di base dei gruppi, notare eventuali risultati secondari e accennare brevemente alla necessità di studi a lungo termine.

Ruolo

Contenuto

User

Il tuo compito è fornire feedback su un riassunto di un 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 da A a F.

Assistant
{{FEEDBACK}}

1. Accuratezza: A
- Riportate correttamente le statistiche chiave: riduzioni HbA1c, perdita di peso.
- Notato accuratamente il profilo di sicurezza e l’assenza di eventi avversi seri.
- L’affermazione “rivoluzionario” è giustificata dai risultati significativamente migliori.

2. Chiarezza: A-
- Conciso e ben strutturato con sezioni chiare.
- Buon uso del linguaggio comparativo (es. “su del 3% dal Q1”) per contesto.
- Problema minore: Acronimi come “RCT,” “GLP-1,” e “GIP” non definiti. Considerare di scriverli per esteso al primo uso.

3. Completezza: B+
- Copre tutte le aree richieste: metodologia, risultati, implicazioni cliniche.
- Mancante: Caratteristiche di base dei gruppi (erano ben bilanciati?).
- Mancante: Eventuali endpoint secondari (es. pressione sanguigna, lipidi).
- Considerare: Implicazioni a lungo termine o necessità di ulteriori ricerche.

Nel complesso, il riassunto è accurato e chiaro, fornendo informazioni chiave per una rapida comprensione dello studio. Per elevarlo ad A+, definire gli acronimi, menzionare le statistiche di base dei gruppi, notare eventuali risultati secondari e accennare brevemente alla necessità di studi a lungo termine.

Prompt 3

Ruolo	Contenuto
User	Il tuo compito è migliorare un riassunto di un 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.
Assistant	Metodologia: Studio randomizzato controllato (RCT) in doppio cieco con 500 pazienti con diabete di Tipo 2. Gruppo A (n=250) ha ricevuto un nuovo agonista duale peptide-1 glucagone-simile/polipeptide insulinotropico glucosio-dipendente (GLP-1/GIP); Gruppo B (n=250) ha ricevuto un agonista GLP-1 standard. Lo studio di 24 settimane aveva come endpoint primario la riduzione dell’HbA1c. I gruppi erano ben bilanciati per età, BMI e HbA1c basale. Risultati: - Gruppo A: riduzione media HbA1c dell’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 5,2kg - Gruppo B: perdita di peso media 3,1kg Gli endpoint secondari hanno mostrato miglioramenti nella pressione sanguigna e nei profili lipidici per entrambi i gruppi, con il Gruppo A che ha mostrato risultati leggermente migliori. Sicurezza: Profili di eventi avversi simili, senza eventi seri attribuiti a nessuno dei trattamenti. Implicazioni Cliniche: L’agonista duale GLP-1/GIP dimostra un controllo glicemico e una perdita di peso superiori rispetto alla terapia GLP-1 standard. Questi risultati suggeriscono che potrebbe essere un avanzamento significativo, particolarmente per i diabetici obesi. Tuttavia, sono necessari studi a più lungo termine per confermare l’efficacia e la sicurezza sostenute, così come per investigare potenziali benefici sugli outcome cardiovascolari.

Ruolo

Contenuto

User

Il tuo compito è migliorare un riassunto di un 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.

Assistant

Metodologia: Studio randomizzato controllato (RCT) in doppio cieco con 500 pazienti con diabete di Tipo 2. Gruppo A (n=250) ha ricevuto un nuovo agonista duale peptide-1 glucagone-simile/polipeptide insulinotropico glucosio-dipendente (GLP-1/GIP); Gruppo B (n=250) ha ricevuto un agonista GLP-1 standard. Lo studio di 24 settimane aveva come endpoint primario la riduzione dell’HbA1c. I gruppi erano ben bilanciati per età, BMI e HbA1c basale.

Risultati:
- Gruppo A: riduzione media HbA1c dell’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 5,2kg
- Gruppo B: perdita di peso media 3,1kg

Gli endpoint secondari hanno mostrato miglioramenti nella pressione sanguigna e nei profili lipidici per entrambi i gruppi, con il Gruppo A che ha mostrato risultati leggermente migliori.

Sicurezza: Profili di eventi avversi simili, senza eventi seri attribuiti a nessuno dei trattamenti.

Implicazioni Cliniche: L’agonista duale GLP-1/GIP dimostra un controllo glicemico e una perdita di peso superiori rispetto alla terapia GLP-1 standard. Questi risultati suggeriscono che potrebbe essere un avanzamento significativo, particolarmente per i diabetici obesi. Tuttavia, sono necessari studi a più lungo termine per confermare l’efficacia e la sicurezza sostenute, così come per investigare potenziali benefici sugli outcome cardiovascolari.

Esempi

Nota che Claude manca l’istruzione di fornire modifiche proposte nella sua bozza di email.

Ruolo	Contenuto
User	Sei il nostro Direttore Legale. Rivedi questo contratto SaaS per i 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.
Assistant	Dopo aver rivisto il contratto SaaS, ho identificato diverse preoccupazioni: 1. Privacy dei Dati (Sezione 7): - Problema: Il fornitore ha ampi diritti di utilizzo dei dati del cliente per “miglioramento del servizio.” - Rischio: Potrebbe portare a condivisione o monetizzazione non autorizzata dei dati. 2. SLA (Sezione 5): - Problema: Garanzia di uptime del 99,5% è sotto lo standard di settore. - Rischio: Eccessivo downtime potrebbe impattare le nostre operazioni. 3. Responsabilità (Sezione 9): - Problema: Limite fissato a 3 mesi di canoni. - Rischio: Inadeguato per potenziali violazioni dei dati o guasti del servizio. Bozza email: Gentile {{VENDOR}}, Dopo aver rivisto l’accordo SaaS, abbiamo delle preoccupazioni: 1. Privacy dei Dati: Richiediamo che i nostri dati siano usati solo per la fornitura diretta del servizio, non per un generico “miglioramento del servizio.” Si prega di modificare la Sezione 7. 2. SLA: Il 99,5% di uptime è insufficiente. Necessitiamo del 99,99% con penali chiaramente definite. Si prega di rivedere la Sezione 5. 3. Responsabilità: L’attuale limite di 3 mesi di canoni è inadeguato. Proponiamo un limite di 12 mesi di canoni, senza limite per violazioni dei dati o condotta dolosa. Apprezziamo la nostra potenziale partnership e crediamo che queste modifiche ci metteranno sulla strada del successo. Si prega di inviare un accordo rivisto. Cordiali saluti, {{CLO_NAME}}

Ruolo

Contenuto

User

Sei il nostro Direttore Legale. Rivedi questo contratto SaaS per i 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.

Assistant

Dopo aver rivisto il contratto SaaS, ho identificato diverse preoccupazioni:

1. Privacy dei Dati (Sezione 7):
- Problema: Il fornitore ha ampi diritti di utilizzo dei dati del cliente per “miglioramento del servizio.”
- Rischio: Potrebbe portare a condivisione o monetizzazione non autorizzata dei dati.

2. SLA (Sezione 5):
- Problema: Garanzia di uptime del 99,5% è sotto lo standard di settore.
- Rischio: Eccessivo downtime potrebbe impattare le nostre operazioni.

3. Responsabilità (Sezione 9):
- Problema: Limite fissato a 3 mesi di canoni.
- Rischio: Inadeguato per potenziali violazioni dei dati o guasti del servizio.

Bozza email:

Gentile {{VENDOR}},

Dopo aver rivisto l’accordo SaaS, abbiamo delle preoccupazioni:

1. Privacy dei Dati: Richiediamo che i nostri dati siano usati solo per la fornitura diretta del servizio, non per un generico “miglioramento del servizio.” Si prega di modificare la Sezione 7.

2. SLA: Il 99,5% di uptime è insufficiente. Necessitiamo del 99,99% con penali chiaramente definite. Si prega di rivedere la Sezione 5.

3. Responsabilità: L’attuale limite di 3 mesi di canoni è inadeguato. Proponiamo un limite di 12 mesi di canoni, senza limite per violazioni dei dati o condotta dolosa.

Apprezziamo la nostra potenziale partnership e crediamo che queste modifiche ci metteranno sulla strada del successo. Si prega di inviare un accordo rivisto.

Cordiali saluti,
{{CLO_NAME}}

Prompt 1

Ruolo	Contenuto
User	Sei il nostro Direttore Legale. Rivedi questo contratto SaaS per i rischi, concentrandoti su privacy dei dati, SLA e limiti di responsabilità. <contract> {{CONTRACT}} </contract> Inserisci i tuoi risultati nei tag <risks>.
Assistant {{CONCERNS}}	1. Privacy dei Dati (Sezione 7): - Problema: Il fornitore ha ampi diritti di utilizzo dei dati del cliente per “miglioramento del servizio.” - Rischio: Potrebbe portare a condivisione o monetizzazione non autorizzata 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 di settore (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 canoni. - Rischio: Inadeguato per potenziali violazioni dei dati, furto di IP o guasti prolungati del servizio. - Impatto: Compensazione insufficiente per danni che potrebbero superare di gran lunga il limite, come class-action o multe normative.

Ruolo

Contenuto

User

Assistant
{{CONCERNS}}

1. Privacy dei Dati (Sezione 7):
- Problema: Il fornitore ha ampi diritti di utilizzo dei dati del cliente per “miglioramento del servizio.”
- Rischio: Potrebbe portare a condivisione o monetizzazione non autorizzata 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 di settore (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 canoni.
- Rischio: Inadeguato per potenziali violazioni dei dati, furto di IP o guasti prolungati del servizio.
- Impatto: Compensazione insufficiente per danni che potrebbero superare di gran lunga il limite, come class-action o multe normative.

Prompt 2

Ruolo	Contenuto
User	Redigi un’email a un fornitore di prodotti SaaS delineando le seguenti preoccupazioni e proponendo modifiche. Ecco le preoccupazioni: <concerns> {{CONCERNS}} </concerns>
Assistant {{EMAIL}}	Gentile {{VENDOR}}, Dopo un’attenta revisione dell’accordo SaaS proposto, il nostro team legale ha identificato diverse preoccupazioni ad alta priorità che devono essere affrontate prima di poter procedere: 1. Privacy dei Dati (Sezione 7): - Attuale: Ampi diritti di utilizzo dei dati del cliente per “miglioramento del servizio.” - Preoccupazione: Potenziale condivisione o monetizzazione non autorizzata dei dati. - 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: 99,99% di uptime con crediti di servizio a livelli. Es. 10% di credito per <99,99%, 25% per <99,9%, 50% per <99,5%. 3. Responsabilità (Sezione 9): - Attuale: Limite a 3 mesi di canoni. - Preoccupazione: Gravemente inadeguato per violazioni dei dati, furto di IP o interruzioni prolungate. - Modifica Proposta: 12 mesi di canoni per responsabilità generale. Nessun limite per violazioni dei dati, condotta dolosa, violazione di IP. Queste modifiche sono non negoziabili per noi. Si allineano agli standard di settore e al 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 solida base. Vi preghiamo di far rivedere e incorporare queste modifiche al vostro team legale. Siamo disponibili a discutere ulteriormente per assicurare una comprensione e un accordo reciproci. Cordiali saluti, {{CLO_NAME}}

Ruolo

Contenuto

User

Redigi un’email a un fornitore di prodotti SaaS delineando le seguenti preoccupazioni e proponendo modifiche. Ecco le preoccupazioni:
<concerns>
{{CONCERNS}}
</concerns>

Assistant
{{EMAIL}}

Gentile {{VENDOR}},

Dopo un’attenta revisione dell’accordo SaaS proposto, il nostro team legale ha identificato diverse preoccupazioni ad alta priorità che devono essere affrontate prima di poter procedere:

1. Privacy dei Dati (Sezione 7):
- Attuale: Ampi diritti di utilizzo dei dati del cliente per “miglioramento del servizio.”
- Preoccupazione: Potenziale condivisione o monetizzazione non autorizzata dei dati.
- 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: 99,99% di uptime con crediti di servizio a livelli. Es. 10% di credito per <99,99%, 25% per <99,9%, 50% per <99,5%.

3. Responsabilità (Sezione 9):
- Attuale: Limite a 3 mesi di canoni.
- Preoccupazione: Gravemente inadeguato per violazioni dei dati, furto di IP o interruzioni prolungate.
- Modifica Proposta: 12 mesi di canoni per responsabilità generale. Nessun limite per violazioni dei dati, condotta dolosa, violazione di IP.

Queste modifiche sono non negoziabili per noi. Si allineano agli standard di settore e al 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 solida base.

Vi preghiamo di far rivedere e incorporare queste modifiche al vostro team legale. Siamo disponibili a discutere ulteriormente per assicurare una comprensione e un accordo reciproci.

Cordiali saluti,
{{CLO_NAME}}

Prompt 3

Ruolo	Contenuto
User	Il tuo compito è rivedere un’email e fornire feedback. Ecco l’email: <email> {{EMAIL}} </email> Dai feedback su tono, chiarezza e professionalità.
Assistant	1. Tono: - Professionale e assertivo senza essere conflittuale. - L’uso di “non negoziabili” è forte ma giustificato data la criticità dei problemi. - Il linguaggio collaborativo (“apprezziamo,” “disponibili a discutere”) bilancia la fermezza, mantenendo un tono costruttivo. 2. Chiarezza: - Eccellente strutturazione: 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. - Le azioni richieste sono chiare: il team legale del fornitore deve rivedere e incorporare le modifiche. 3. Professionalità: - Si concentra sul beneficio reciproco e gli standard di settore, 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 la comprensione e risoluzione dei problemi. Nel complesso, l’email raggiunge il giusto equilibrio tra assertività e collaborazione. Articola chiaramente le nostre preoccupazioni, propone soluzioni specifiche e mantiene un tono professionale orientato alla partnership. Non sono necessarie revisioni; procedere con l’invio.

Ruolo

Contenuto

User

Il tuo compito è rivedere un’email e fornire feedback. Ecco l’email:
<email>
{{EMAIL}}
</email>

Dai feedback su tono, chiarezza e professionalità.

Assistant

1. Tono:
- Professionale e assertivo senza essere conflittuale.
- L’uso di “non negoziabili” è forte ma giustificato data la criticità dei problemi.
- Il linguaggio collaborativo (“apprezziamo,” “disponibili a discutere”) bilancia la fermezza, mantenendo un tono costruttivo.

2. Chiarezza:
- Eccellente strutturazione: 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.
- Le azioni richieste sono chiare: il team legale del fornitore deve rivedere e incorporare le modifiche.

3. Professionalità:
- Si concentra sul beneficio reciproco e gli standard di settore, 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 la comprensione e risoluzione dei problemi.

Nel complesso, l’email raggiunge il giusto equilibrio tra assertività e collaborazione. Articola chiaramente le nostre preoccupazioni, propone soluzioni specifiche e mantiene un tono professionale orientato alla partnership. Non sono necessarie revisioni; procedere con l’invio.

Prompt 1

Ruolo	Contenuto
User	Come architetto di soluzioni senior, rivedi e analizza questa strategia multi-tenant per il nostro nuovo prodotto SaaS enterprise. <strategy> {{STRATEGY}} </strategy> Concentrati su scalabilità, sicurezza ed efficienza dei costi.
Assistant {{ANALYSIS}}	1. Scalabilità: + Lo sharding del database per tenant riduce la contesa, supporta alta crescita. + I microservizi permettono scaling indipendente dei componenti. - I server applicativi condivisi potrebbero diventare un collo di bottiglia sotto carico estremo. - Nessuna menzione di auto-scaling o bilanciamento del carico per il livello applicativo. 2. Sicurezza: + L’isolamento dei dati dei tenant via sharding mitiga le fughe di dati. + JWT con scadenza breve e token di refresh è best practice del settore. - Nessuna menzione di crittografia (a riposo, in transito) o gestione delle chiavi. - La strategia IAM manca di dettagli su ruoli, permessi o RBAC. 3. Efficienza dei costi: + I server applicativi condivisi riducono i costi delle risorse inattive. + Le funzioni serverless per task infrequenti ottimizzano i costi. - DB per tenant potrebbe aumentare i costi a scala vs DB multi-tenant ottimizzato. - Nessuna discussione su istanze riservate o spot per risparmio costi.

Ruolo

Contenuto

User

Come architetto di soluzioni senior, rivedi e analizza questa strategia multi-tenant per il nostro nuovo prodotto SaaS enterprise.

<strategy>
{{STRATEGY}}
</strategy>

Concentrati su scalabilità, sicurezza ed efficienza dei costi.

Assistant
{{ANALYSIS}}

1. Scalabilità:
+ Lo sharding del database per tenant riduce la contesa, supporta alta crescita.
+ I microservizi permettono scaling indipendente dei componenti.
- I server applicativi condivisi potrebbero diventare un collo di bottiglia sotto carico estremo.
- Nessuna menzione di auto-scaling o bilanciamento del carico per il livello applicativo.

2. Sicurezza:
+ L’isolamento dei dati dei tenant via sharding mitiga le fughe di dati.
+ JWT con scadenza breve e token di refresh è best practice del settore.
- Nessuna menzione di crittografia (a riposo, in transito) o gestione delle chiavi.
- La strategia IAM manca di dettagli su ruoli, permessi o RBAC.

3. Efficienza dei costi:
+ I server applicativi condivisi riducono i costi delle risorse inattive.
+ Le funzioni serverless per task infrequenti ottimizzano i costi.
- DB per tenant potrebbe aumentare i costi a scala vs DB multi-tenant ottimizzato.
- Nessuna discussione su istanze riservate o spot per risparmio costi.

Prompt 2

Ruolo	Contenuto
User	Redigi un documento di revisione strategica per la leadership ingegneristica basato su questa analisi di una strategia multi-tenant. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Includi un sommario esecutivo, analisi dettagliata e raccomandazioni.
Assistant {{STRATEGY_DOC}}	# Revisione Strategia Multi-tenant: Prodotto SaaS Enterprise ## Sommario Esecutivo La strategia proposta dimostra una solida base nei principi di scalabilità e sicurezza ma ha lacune nei dettagli implementativi. Eccelle nell’isolamento dei dati e nello scaling a livello di componenti ma manca di scaling robusto del livello applicativo e misure di sicurezza avanzate. Le ottimizzazioni dei costi sono presenti ma potrebbero vacillare ad alta scala. Con mi glioramenti mirati, 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 senza soluzione di continuità per tenant. - L’architettura a microservizi permette lo scaling di componenti individuali basato sulla domanda, cruciale per gestire carichi di lavoro enterprise diversi. Debolezze: - I server applicativi condivisi rischiano di diventare un collo di bottiglia. Con la crescita del numero di tenant e del traffico, questi potrebbero degradare le prestazioni per tutti i tenant. - L’assenza di auto-scaling e bilanciamento del carico per il livello applicativo è una svista critica. Questi sono essenziali per gestire picchi di traffico senza sovra-provisioning. ### 2. Sicurezza: B- Punti di forza: - I database shardati forniscono forte isolamento dei dati dei tenant, mitigando rischi di fughe di dati o accesso non autorizzato tra tenant. - JWT con scadenza breve e token di refresh si allineano alle 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. - Manca la strategia di gestione delle chiavi. Come sono gestite e ruotate le chiavi di crittografia, i segreti JWT e le credenziali DB? - IAM manca di profondità. Necessitiamo di RBAC con ruoli ben definiti, controllo accessi basato su attributi (ABAC) per permessi granulari e integrazione con provider di identità enterprise (SAML, OIDC). ### 3. Efficienza dei costi: B Punti di forza: - I server applicativi condivisi riducono i costi di capacità inattiva, buono per traffico stabile. - Serverless per task infrequenti (es. reporting) è intelligente; si paga solo quando queste risorse sono usate. Debolezze: - Database per tenant potrebbero non essere economicamente efficienti a scala rispetto a un database multi-tenant ben progettato con robusta partizione dei dati. - Nessuna menzione di misure di risparmio costi come istanze riservate per carichi di lavoro prevedibili o istanze spot per task fault-tolerant. - La mancanza di auto-scaling del livello applicativo potrebbe portare a sovra-provisioning, aumentando i costi. ## Raccomandazioni 1. Resilienza Livello Applicativo: Implementare auto-scaling con Kubernetes o servizi cloud-native (EKS, GKE). Distribuire attraverso zone di disponibilità con CDN per asset statici. 2. Rafforzamento Sicurezza: a. Crittografare dati a riposo (AES-256) e in transito (TLS 1.3). b. Usare un KMS gestito (AWS KMS, GCP KMS) per gestione chiavi. c. Migliorare IAM con RBAC, ABAC e SAML/OIDC per SSO enterprise. 3. Ottimizzazione Costi: a. Valutare DB multi-tenant colonnare (es. Snowflake) vs sharding a scala. b. Usare istanze riservate per server applicativi, istanze spot per carichi non critici. c. Implementare monitoraggio proattivo e right-sizing per evitare sovra-provisioning. 4. Proof of Concept (PoC): Prima dell’implementazione completa, condurre un PoC con simulazione ad alta scala: a. Testare DB shardato vs DB multi-tenant ottimizzato per costi e prestazioni. b. Stress-test del livello applicativo con picchi di traffico simulati a livello enterprise. c. Condurre audit di sicurezza di terze parti, focalizzandosi su isolamento dati e controlli accessi. Con questi miglioramenti, la nostra strategia multi-tenant sarà di livello enterprise: scalabile, sicura ed economicamente efficiente. Il PoC validerà le nostre scelte di design e infonderà fiducia nei nostri clienti enterprise.

Ruolo

Contenuto

User

Redigi un documento di revisione strategica per la leadership ingegneristica basato su questa analisi di una strategia multi-tenant.

<strategy>
{{STRATEGY}}
</strategy>

<analysis>
{{ANALYSIS}}
</analysis>

Includi un sommario esecutivo, analisi dettagliata e raccomandazioni.

Assistant
{{STRATEGY_DOC}}

# Revisione Strategia Multi-tenant: Prodotto SaaS Enterprise

## Sommario Esecutivo
La strategia proposta dimostra una solida base nei principi di scalabilità e sicurezza ma ha lacune nei dettagli implementativi. Eccelle nell’isolamento dei dati e nello scaling a livello di componenti ma manca di scaling robusto del livello applicativo e misure di sicurezza avanzate. Le ottimizzazioni dei costi sono presenti ma potrebbero vacillare ad alta scala. Con mi glioramenti mirati, 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 senza soluzione di continuità per tenant.
- L’architettura a microservizi permette lo scaling di componenti individuali basato sulla domanda, cruciale per gestire carichi di lavoro enterprise diversi.

Debolezze:
- I server applicativi condivisi rischiano di diventare un collo di bottiglia. Con la crescita del numero di tenant e del traffico, questi potrebbero degradare le prestazioni per tutti i tenant.
- L’assenza di auto-scaling e bilanciamento del carico per il livello applicativo è una svista critica. Questi sono essenziali per gestire picchi di traffico senza sovra-provisioning.

### 2. Sicurezza: B-

Punti di forza:
- I database shardati forniscono forte isolamento dei dati dei tenant, mitigando rischi di fughe di dati o accesso non autorizzato tra tenant.
- JWT con scadenza breve e token di refresh si allineano alle 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.
- Manca la strategia di gestione delle chiavi. Come sono gestite e ruotate le chiavi di crittografia, i segreti JWT e le credenziali DB?
- IAM manca di profondità. Necessitiamo di RBAC con ruoli ben definiti, controllo accessi basato su attributi (ABAC) per permessi granulari e integrazione con provider di identità enterprise (SAML, OIDC).

### 3. Efficienza dei costi: B

Punti di forza:
- I server applicativi condivisi riducono i costi di capacità inattiva, buono per traffico stabile.
- Serverless per task infrequenti (es. reporting) è intelligente; si paga solo quando queste risorse sono usate.

Debolezze:
- Database per tenant potrebbero non essere economicamente efficienti a scala rispetto a un database multi-tenant ben progettato con robusta partizione dei dati.
- Nessuna menzione di misure di risparmio costi come istanze riservate per carichi di lavoro prevedibili o istanze spot per task fault-tolerant.
- La mancanza di auto-scaling del livello applicativo potrebbe portare a sovra-provisioning, aumentando i costi.

## Raccomandazioni

1. Resilienza Livello Applicativo: Implementare auto-scaling con Kubernetes o servizi cloud-native (EKS, GKE). Distribuire attraverso zone di disponibilità con CDN per asset statici.

2. Rafforzamento Sicurezza:
a. Crittografare dati a riposo (AES-256) e in transito (TLS 1.3).
b. Usare un KMS gestito (AWS KMS, GCP KMS) per gestione chiavi.
c. Migliorare IAM con RBAC, ABAC e SAML/OIDC per SSO enterprise.

3. Ottimizzazione Costi:
a. Valutare DB multi-tenant colonnare (es. Snowflake) vs sharding a scala.
b. Usare istanze riservate per server applicativi, istanze spot per carichi non critici.
c. Implementare monitoraggio proattivo e right-sizing per evitare sovra-provisioning.

4. Proof of Concept (PoC): Prima dell’implementazione completa, condurre un PoC con simulazione ad alta scala:
a. Testare DB shardato vs DB multi-tenant ottimizzato per costi e prestazioni.
b. Stress-test del livello applicativo con picchi di traffico simulati a livello enterprise.
c. Condurre audit di sicurezza di terze parti, focalizzandosi su isolamento dati e controlli accessi.

Con questi miglioramenti, la nostra strategia multi-tenant sarà di livello enterprise: scalabile, sicura ed economicamente efficiente. Il PoC validerà le nostre scelte di design e infonderà fiducia nei nostri clienti enterprise.

Prompt 3

Ruolo	Contenuto
User	Valuta questo documento di revisione strategica per chiarezza, azionabilità e allineamento con le priorità enterprise. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc>
Assistant	1. Chiarezza: A + Struttura chiara con Sommario Esecutivo, Analisi Dettagliata e Raccomandazioni. + L’analisi usa un sistema di valutazione (B+, B-) per rapida comprensione di punti di forza/debolezza. + I termini tecnici (RBAC, ABAC, TLS) sono spiegati o contestualizzati, aiutando la leadership non tecnica. + Gli aiuti visivi (punti elenco, rientri) migliorano la leggibilità. 2. Azionabilità: A- + Le raccomandazioni sono specifiche e tecniche (es. “Implementare auto-scaling con Kubernetes”). + Il piano PoC con obiettivi chiari fornisce una roadmap. + Mancante: Timeline, requisiti di risorse o assegnazioni team per ogni raccomandazione. + Considerare: Aggiungere una sezione “Prossimi Passi” con azioni immediate, ruoli e timeline di alto livello. 3. Allineamento Enterprise: A+ + Affronta direttamente le priorità enterprise: - Scalabilità: Discute la gestione di picchi di traffico a livello enterprise. - Sicurezza: Si concentra su isolamento dati, crittografia e IAM enterprise. - Costi: 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à di livello enterprise. + Il linguaggio risuona con le preoccupazioni enterprise: “rischio inaccettabile,” “livello enterprise,” “infondere 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, lo rende altamente efficace sia per leadership tecnica che non tecnica. Ottimo lavoro!

Ruolo

Contenuto

User

Valuta questo documento di revisione strategica per chiarezza, azionabilità e allineamento con le priorità enterprise.

<priorities>
{{PRIORITIES}}
</priorities>

<strategy_doc>
{{STRATEGY_DOC}}
</strategy_doc>

Assistant

1. Chiarezza: A
+ Struttura chiara con Sommario Esecutivo, Analisi Dettagliata e Raccomandazioni.
+ L’analisi usa un sistema di valutazione (B+, B-) per rapida comprensione di punti di forza/debolezza.
+ I termini tecnici (RBAC, ABAC, TLS) sono spiegati o contestualizzati, aiutando la leadership non tecnica.
+ Gli aiuti visivi (punti elenco, rientri) migliorano la leggibilità.

2. Azionabilità: A-
+ Le raccomandazioni sono specifiche e tecniche (es. “Implementare auto-scaling con Kubernetes”).
+ Il piano PoC con obiettivi chiari fornisce una roadmap.
+ Mancante: Timeline, requisiti di risorse o assegnazioni team per ogni raccomandazione.
+ Considerare: Aggiungere una sezione “Prossimi Passi” con azioni immediate, ruoli e timeline di alto livello.

3. Allineamento Enterprise: A+
+ Affronta direttamente le priorità enterprise:
- Scalabilità: Discute la gestione di picchi di traffico a livello enterprise.
- Sicurezza: Si concentra su isolamento dati, crittografia e IAM enterprise.
- Costi: 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à di livello enterprise.
+ Il linguaggio risuona con le preoccupazioni enterprise: “rischio inaccettabile,” “livello enterprise,” “infondere 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, lo rende altamente efficace sia per leadership tecnica che non tecnica. Ottimo lavoro!

Libreria di prompt

Lasciati ispirare da una selezione curata di prompt per varie attività e casi d’uso.

Tutorial di prompting GitHub

Un tutorial ricco di esempi che copre i concetti di prompt engineering trovati nella nostra documentazione.

Tutorial di prompting Google Sheets

Una versione più leggera del nostro tutorial di prompt engineering tramite un foglio di calcolo interattivo.

Inizia

Agenti e strumenti

Scopri Claude

Sviluppa con Claude

Amministrazione

Test e valutazione

Risorse

Centro legale

Concatenare prompt complessi per prestazioni migliori

Perché concatenare i prompt?

Quando concatenare i prompt

Come concatenare i prompt

Esempi di flussi di lavoro concatenati:

Avanzato: Catene di auto-correzione

Prompt 1

Prompt 2

Prompt 3

Esempi

Prompt 1

Prompt 2

Prompt 3

Prompt 1

Prompt 2

Prompt 3

Libreria di prompt

Tutorial di prompting GitHub

Tutorial di prompting Google Sheets

Inizia

Agenti e strumenti

Scopri Claude

Sviluppa con Claude

Amministrazione

Test e valutazione

Risorse

Centro legale

​Perché concatenare i prompt?

​Quando concatenare i prompt

​Come concatenare i prompt

​Esempi di flussi di lavoro concatenati:

​Avanzato: Catene di auto-correzione

Prompt 1

Prompt 2

Prompt 3

​Esempi

Prompt 1

Prompt 2

Prompt 3

Prompt 1

Prompt 2

Prompt 3

Libreria di prompt

Tutorial di prompting GitHub

Tutorial di prompting Google Sheets

Perché concatenare i prompt?

Quando concatenare i prompt

Come concatenare i prompt

Esempi di flussi di lavoro concatenati:

Avanzato: Catene di auto-correzione

Esempi