Komplexe Prompts verketten für bessere Leistung

Bei komplexen Aufgaben kann Claude manchmal den Überblick verlieren, wenn Sie versuchen, alles in einem einzigen Prompt zu behandeln. Chain of Thought (CoT) Prompting ist großartig, aber was ist, wenn Ihre Aufgabe mehrere verschiedene Schritte hat, die jeweils tiefgehendes Nachdenken erfordern?

Hier kommt Prompt-Verkettung ins Spiel: Das Aufteilen komplexer Aufgaben in kleinere, handhabbare Teilaufgaben.

Warum Prompts verketten?

Genauigkeit: Jede Teilaufgabe erhält Claudes volle Aufmerksamkeit und reduziert Fehler.
Klarheit: Einfachere Teilaufgaben bedeuten klarere Anweisungen und Ausgaben.
Nachverfolgbarkeit: Probleme in Ihrer Prompt-Kette können leicht lokalisiert und behoben werden.

Wann Prompts verketten

Verwenden Sie Prompt-Verkettung für mehrstufige Aufgaben wie Forschungssynthese, Dokumentenanalyse oder iterative Inhaltserstellung. Wenn eine Aufgabe mehrere Transformationen, Zitate oder Anweisungen beinhaltet, verhindert die Verkettung, dass Claude Schritte auslässt oder falsch handhabt.

Denken Sie daran: Jedes Glied in der Kette erhält Claudes volle Aufmerksamkeit!

Debugging-Tipp: Wenn Claude einen Schritt verpasst oder schlecht ausführt, isolieren Sie diesen Schritt in seinem eigenen Prompt. So können Sie problematische Schritte optimieren, ohne die gesamte Aufgabe neu zu machen.

Wie man Prompts verkettet

Teilaufgaben identifizieren: Unterteilen Sie Ihre Aufgabe in verschiedene, aufeinanderfolgende Schritte.
Mit XML für klare Übergaben strukturieren: Verwenden Sie XML-Tags, um Ausgaben zwischen Prompts weiterzugeben.
Ein Einzelaufgabenziel haben: Jede Teilaufgabe sollte ein einzelnes, klares Ziel haben.
Iterieren: Verfeinern Sie Teilaufgaben basierend auf Claudes Leistung.

Beispiele für verkettete Workflows:

Mehrstufige Analyse: Siehe die rechtlichen und geschäftlichen Beispiele unten.
Content-Erstellungs-Pipelines: Recherche → Gliederung → Entwurf → Bearbeitung → Formatierung.
Datenverarbeitung: Extrahieren → Transformieren → Analysieren → Visualisieren.
Entscheidungsfindung: Informationen sammeln → Optionen auflisten → Jede analysieren → Empfehlen.
Verifizierungsschleifen: Inhalt generieren → Überprüfen → Verfeinern → Erneut überprüfen.

Optimierungstipp: Bei Aufgaben mit unabhängigen Teilaufgaben (wie der Analyse mehrerer Dokumente) erstellen Sie separate Prompts und führen Sie diese parallel aus, um Zeit zu sparen.

Fortgeschritten: Selbstkorrektur-Ketten

Sie können Prompts verketten, damit Claude seine eigene Arbeit überprüft! Dies fängt Fehler ab und verfeinert Ausgaben, besonders bei wichtigen Aufgaben.

Prompt 1

Rolle	Inhalt
User	Fassen Sie dieses medizinische Forschungspapier zusammen. <paper>{{RESEARCH_PAPER}}</paper> Konzentrieren Sie sich auf Methodik, Ergebnisse und klinische Implikationen.
Assistant {{SUMMARY}}	Methodik: Doppelblinde RCT mit 500 Typ-2-Diabetes-Patienten. Gruppe A (n=250) erhielt neuartigen GLP-1/GIP-Dualagonisten; Gruppe B (n=250) erhielt Standard-GLP-1-Agonisten. 24-wöchige Studie, primärer Endpunkt: HbA1c-Reduktion. Ergebnisse: - Gruppe A: 1,8% mittlere HbA1c-Reduktion - Gruppe B: 1,1% mittlere HbA1c-Reduktion - 68% der Gruppe A vs. 52% der Gruppe B erreichten HbA1c <7% - Gruppe A: 5,2kg mittlerer Gewichtsverlust - Gruppe B: 3,1kg mittlerer Gewichtsverlust Sicherheit: Ähnliche Nebenwirkungsprofile, keine schwerwiegenden Ereignisse der Behandlung zugeschrieben. Klinische Implikationen: Dualagonist zeigt überlegene Blutzuckerkontrolle und Gewichtsverlust im Vergleich zur Standardtherapie. Könnte bahnbrechend sein, besonders für übergewichtige Diabetiker.

Rolle

Inhalt

User

Fassen Sie dieses medizinische Forschungspapier zusammen.

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

Konzentrieren Sie sich auf Methodik, Ergebnisse und klinische Implikationen.

Assistant
{{SUMMARY}}

Methodik: Doppelblinde RCT mit 500 Typ-2-Diabetes-Patienten. Gruppe A (n=250) erhielt neuartigen GLP-1/GIP-Dualagonisten; Gruppe B (n=250) erhielt Standard-GLP-1-Agonisten. 24-wöchige Studie, primärer Endpunkt: HbA1c-Reduktion.

Ergebnisse:
- Gruppe A: 1,8% mittlere HbA1c-Reduktion
- Gruppe B: 1,1% mittlere HbA1c-Reduktion
- 68% der Gruppe A vs. 52% der Gruppe B erreichten HbA1c <7%
- Gruppe A: 5,2kg mittlerer Gewichtsverlust
- Gruppe B: 3,1kg mittlerer Gewichtsverlust

Sicherheit: Ähnliche Nebenwirkungsprofile, keine schwerwiegenden Ereignisse der Behandlung zugeschrieben.

Klinische Implikationen: Dualagonist zeigt überlegene Blutzuckerkontrolle und Gewichtsverlust im Vergleich zur Standardtherapie. Könnte bahnbrechend sein, besonders für übergewichtige Diabetiker.

Prompt 2

Rolle	Inhalt
User	Ihre Aufgabe ist es, Feedback zu einer Forschungspapierzusammenfassung zu geben. Hier ist eine Zusammenfassung eines medizinischen Forschungspapiers: <summary> {{SUMMARY}} </summary> Hier ist das Forschungspapier: <paper> {{RESEARCH_PAPER}} </paper> Überprüfen Sie diese Zusammenfassung auf Genauigkeit, Klarheit und Vollständigkeit auf einer Notenskala von A-F.
Assistant {{FEEDBACK}}	1. Genauigkeit: A - Korrekt berichtete Hauptstatistiken: HbA1c-Reduktionen, Gewichtsverlust. - Sicherheitsprofil und Fehlen schwerwiegender Nebenwirkungen präzise notiert. - Behauptung “bahnbrechend” ist durch signifikant bessere Ergebnisse gerechtfertigt. 2. Klarheit: A- - Prägnant und gut strukturiert mit klaren Abschnitten. - Gute Verwendung vergleichender Sprache (z.B. “um 3% höher als Q1”) für Kontext. - Kleines Problem: Akronyme wie “RCT”, “GLP-1” und “GIP” nicht definiert. Erwägen Sie Ausschreibung bei erster Verwendung. 3. Vollständigkeit: B+ - Deckt alle angeforderten Bereiche ab: Methodik, Ergebnisse, klinische Implikationen. - Fehlend: Baseline-Charakteristika der Gruppen (waren sie gut abgestimmt?). - Fehlend: Sekundäre Endpunkte (z.B. Blutdruck, Lipide). - Zu erwägen: Langzeitimplikationen oder Bedarf an weiterer Forschung. Insgesamt ist die Zusammenfassung genau und klar und bietet wichtige Einblicke für ein schnelles Verständnis der Studie. Für A+ definieren Sie Akronyme, erwähnen Sie Gruppen-Baseline-Statistiken, notieren Sie sekundäre Outcomes und erwähnen Sie kurz den Bedarf an Langzeitstudien.

Rolle

Inhalt

User

Ihre Aufgabe ist es, Feedback zu einer Forschungspapierzusammenfassung zu geben. Hier ist eine Zusammenfassung eines medizinischen Forschungspapiers:
<summary>
{{SUMMARY}}
</summary>

Hier ist das Forschungspapier:
<paper>
{{RESEARCH_PAPER}}
</paper>

Überprüfen Sie diese Zusammenfassung auf Genauigkeit, Klarheit und Vollständigkeit auf einer Notenskala von A-F.

Assistant
{{FEEDBACK}}

1. Genauigkeit: A
- Korrekt berichtete Hauptstatistiken: HbA1c-Reduktionen, Gewichtsverlust.
- Sicherheitsprofil und Fehlen schwerwiegender Nebenwirkungen präzise notiert.
- Behauptung “bahnbrechend” ist durch signifikant bessere Ergebnisse gerechtfertigt.

2. Klarheit: A-
- Prägnant und gut strukturiert mit klaren Abschnitten.
- Gute Verwendung vergleichender Sprache (z.B. “um 3% höher als Q1”) für Kontext.
- Kleines Problem: Akronyme wie “RCT”, “GLP-1” und “GIP” nicht definiert. Erwägen Sie Ausschreibung bei erster Verwendung.

3. Vollständigkeit: B+
- Deckt alle angeforderten Bereiche ab: Methodik, Ergebnisse, klinische Implikationen.
- Fehlend: Baseline-Charakteristika der Gruppen (waren sie gut abgestimmt?).
- Fehlend: Sekundäre Endpunkte (z.B. Blutdruck, Lipide).
- Zu erwägen: Langzeitimplikationen oder Bedarf an weiterer Forschung.

Insgesamt ist die Zusammenfassung genau und klar und bietet wichtige Einblicke für ein schnelles Verständnis der Studie. Für A+ definieren Sie Akronyme, erwähnen Sie Gruppen-Baseline-Statistiken, notieren Sie sekundäre Outcomes und erwähnen Sie kurz den Bedarf an Langzeitstudien.

Prompt 3

Rolle	Inhalt
User	Ihre Aufgabe ist es, eine Papierzusammenfassung basierend auf Feedback zu verbessern. Hier ist der erste Entwurf eines medizinischen Forschungspapiers: <summary> {{SUMMARY}} </summary> Hier ist das Forschungspapier: <paper> {{RESEARCH_PAPER}} </paper> Hier ist das Feedback: <feedback> {{FEEDBACK}} </feedback> Aktualisieren Sie die Zusammenfassung basierend auf dem Feedback.
Assistant	Methodik: Doppelblinde randomisierte kontrollierte Studie (RCT) mit 500 Typ-2-Diabetes-Patienten. Gruppe A (n=250) erhielt einen neuartigen Glucagon-like Peptide-1/Glucose-dependent Insulinotropic Polypeptide (GLP-1/GIP) Dualagonisten; Gruppe B (n=250) erhielt einen Standard-GLP-1-Agonisten. Die 24-wöchige Studie hatte als primären Endpunkt die HbA1c-Reduktion. Die Gruppen waren gut abgestimmt hinsichtlich Alter, BMI und Ausgangs-HbA1c. Ergebnisse: - Gruppe A: 1,8% mittlere HbA1c-Reduktion - Gruppe B: 1,1% mittlere HbA1c-Reduktion - 68% der Gruppe A vs. 52% der Gruppe B erreichten HbA1c <7% - Gruppe A: 5,2kg mittlerer Gewichtsverlust - Gruppe B: 3,1kg mittlerer Gewichtsverlust Sekundäre Endpunkte zeigten Verbesserungen bei Blutdruck und Lipidprofilen in beiden Gruppen, wobei Gruppe A etwas bessere Ergebnisse zeigte. Sicherheit: Ähnliche Nebenwirkungsprofile, ohne schwerwiegende Ereignisse, die einer der beiden Behandlungen zugeschrieben wurden. Klinische Implikationen: Der GLP-1/GIP-Dualagonist demonstriert überlegene Blutzuckerkontrolle und Gewichtsverlust im Vergleich zur Standard-GLP-1-Therapie. Diese Ergebnisse deuten darauf hin, dass es ein bedeutender Fortschritt sein könnte, besonders für übergewichtige Diabetiker. Allerdings sind längerfristige Studien erforderlich, um die anhaltende Wirksamkeit und Sicherheit zu bestätigen sowie mögliche Vorteile für kardiovaskuläre Outcomes zu untersuchen.

Rolle

Inhalt

User

Ihre Aufgabe ist es, eine Papierzusammenfassung basierend auf Feedback zu verbessern. Hier ist der erste Entwurf eines medizinischen Forschungspapiers:
<summary>
{{SUMMARY}}
</summary>

Hier ist das Forschungspapier:
<paper>
{{RESEARCH_PAPER}}
</paper>

Hier ist das Feedback:
<feedback>
{{FEEDBACK}}
</feedback>

Aktualisieren Sie die Zusammenfassung basierend auf dem Feedback.

Assistant

Methodik: Doppelblinde randomisierte kontrollierte Studie (RCT) mit 500 Typ-2-Diabetes-Patienten. Gruppe A (n=250) erhielt einen neuartigen Glucagon-like Peptide-1/Glucose-dependent Insulinotropic Polypeptide (GLP-1/GIP) Dualagonisten; Gruppe B (n=250) erhielt einen Standard-GLP-1-Agonisten. Die 24-wöchige Studie hatte als primären Endpunkt die HbA1c-Reduktion. Die Gruppen waren gut abgestimmt hinsichtlich Alter, BMI und Ausgangs-HbA1c.

Ergebnisse:
- Gruppe A: 1,8% mittlere HbA1c-Reduktion
- Gruppe B: 1,1% mittlere HbA1c-Reduktion
- 68% der Gruppe A vs. 52% der Gruppe B erreichten HbA1c <7%
- Gruppe A: 5,2kg mittlerer Gewichtsverlust
- Gruppe B: 3,1kg mittlerer Gewichtsverlust

Sekundäre Endpunkte zeigten Verbesserungen bei Blutdruck und Lipidprofilen in beiden Gruppen, wobei Gruppe A etwas bessere Ergebnisse zeigte.

Sicherheit: Ähnliche Nebenwirkungsprofile, ohne schwerwiegende Ereignisse, die einer der beiden Behandlungen zugeschrieben wurden.

Klinische Implikationen: Der GLP-1/GIP-Dualagonist demonstriert überlegene Blutzuckerkontrolle und Gewichtsverlust im Vergleich zur Standard-GLP-1-Therapie. Diese Ergebnisse deuten darauf hin, dass es ein bedeutender Fortschritt sein könnte, besonders für übergewichtige Diabetiker. Allerdings sind längerfristige Studien erforderlich, um die anhaltende Wirksamkeit und Sicherheit zu bestätigen sowie mögliche Vorteile für kardiovaskuläre Outcomes zu untersuchen.

Beispiele

Beachten Sie, dass Claude die Anweisung verpasst, vorgeschlagene Änderungen in seinem E-Mail-Entwurf anzugeben.

Rolle	Inhalt
User	Sie sind unser Chief Legal Officer. Überprüfen Sie diesen SaaS-Vertrag auf Risiken, mit Fokus auf Datenschutz, SLAs und Haftungsobergrenzen. <contract> {{CONTRACT}} </contract> Verfassen Sie dann eine E-Mail an den Anbieter mit Ihren Bedenken und vorgeschlagenen Änderungen.
Assistant	Nach Überprüfung des SaaS-Vertrags habe ich mehrere Bedenken identifiziert: 1. Datenschutz (Abschnitt 7): - Problem: Anbieter hat weitreichende Rechte zur Nutzung von Kundendaten für “Serviceverbesserung”. - Risiko: Könnte zu unerlaubter Datenweitergabe oder Monetarisierung führen. 2. SLAs (Abschnitt 5): - Problem: 99,5% Verfügbarkeitsgarantie liegt unter Branchenstandard. - Risiko: Übermäßige Ausfallzeiten könnten unseren Betrieb beeinträchtigen. 3. Haftung (Abschnitt 9): - Problem: Obergrenze bei 3 Monatsgebühren festgelegt. - Risiko: Unzureichend für potenzielle Datenschutzverletzungen oder Serviceausfälle. E-Mail-Entwurf: Sehr geehrte/r {{VENDOR}}, nach Überprüfung der SaaS-Vereinbarung haben wir folgende Bedenken: 1. Datenschutz: Wir verlangen, dass unsere Daten nur für die direkte Servicebereitstellung verwendet werden, nicht für eine breite “Serviceverbesserung”. Bitte ändern Sie Abschnitt 7. 2. SLAs: 99,5% Verfügbarkeit ist unzureichend. Wir benötigen 99,99% mit klar definierten Strafen. Bitte überarbeiten Sie Abschnitt 5. 3. Haftung: Die aktuelle Obergrenze von 3 Monatsgebühren ist unzureichend. Wir schlagen eine Obergrenze von 12 Monatsgebühren vor, ohne Obergrenze für Datenschutzverletzungen oder vorsätzliches Fehlverhalten. Wir schätzen unsere potenzielle Partnerschaft und glauben, dass diese Änderungen uns auf Erfolg ausrichten werden. Bitte senden Sie eine überarbeitete Vereinbarung. Mit freundlichen Grüßen {{CLO_NAME}}

Rolle

Inhalt

User

Sie sind unser Chief Legal Officer. Überprüfen Sie diesen SaaS-Vertrag auf Risiken, mit Fokus auf Datenschutz, SLAs und Haftungsobergrenzen.

<contract>
{{CONTRACT}}
</contract>

Verfassen Sie dann eine E-Mail an den Anbieter mit Ihren Bedenken und vorgeschlagenen Änderungen.

Assistant

Nach Überprüfung des SaaS-Vertrags habe ich mehrere Bedenken identifiziert:

1. Datenschutz (Abschnitt 7):
- Problem: Anbieter hat weitreichende Rechte zur Nutzung von Kundendaten für “Serviceverbesserung”.
- Risiko: Könnte zu unerlaubter Datenweitergabe oder Monetarisierung führen.

2. SLAs (Abschnitt 5):
- Problem: 99,5% Verfügbarkeitsgarantie liegt unter Branchenstandard.
- Risiko: Übermäßige Ausfallzeiten könnten unseren Betrieb beeinträchtigen.

3. Haftung (Abschnitt 9):
- Problem: Obergrenze bei 3 Monatsgebühren festgelegt.
- Risiko: Unzureichend für potenzielle Datenschutzverletzungen oder Serviceausfälle.

E-Mail-Entwurf:

Sehr geehrte/r {{VENDOR}},

nach Überprüfung der SaaS-Vereinbarung haben wir folgende Bedenken:

1. Datenschutz: Wir verlangen, dass unsere Daten nur für die direkte Servicebereitstellung verwendet werden, nicht für eine breite “Serviceverbesserung”. Bitte ändern Sie Abschnitt 7.

2. SLAs: 99,5% Verfügbarkeit ist unzureichend. Wir benötigen 99,99% mit klar definierten Strafen. Bitte überarbeiten Sie Abschnitt 5.

3. Haftung: Die aktuelle Obergrenze von 3 Monatsgebühren ist unzureichend. Wir schlagen eine Obergrenze von 12 Monatsgebühren vor, ohne Obergrenze für Datenschutzverletzungen oder vorsätzliches Fehlverhalten.

Wir schätzen unsere potenzielle Partnerschaft und glauben, dass diese Änderungen uns auf Erfolg ausrichten werden. Bitte senden Sie eine überarbeitete Vereinbarung.

Mit freundlichen Grüßen
{{CLO_NAME}}

Prompt 1

Rolle	Inhalt
User	Sie sind unser Chief Legal Officer. Überprüfen Sie diesen SaaS-Vertrag auf Risiken, mit Fokus auf Datenschutz, SLAs und Haftungsobergrenzen. <contract> {{CONTRACT}} </contract> Geben Sie Ihre Erkenntnisse in <risks> Tags aus.
Assistant {{CONCERNS}}	1. Datenschutz (Abschnitt 7): - Problem: Anbieter hat weitreichende Rechte zur Nutzung von Kundendaten für “Serviceverbesserung”. - Risiko: Könnte zu unerlaubter Datenweitergabe oder Monetarisierung von Kundendaten führen. - Auswirkung: Mögliche Verletzung des Kundenvertrauens, regulatorische Strafen (DSGVO, CCPA). 2. SLAs (Abschnitt 5): - Problem: 99,5% Verfügbarkeitsgarantie liegt unter Branchenstandard (typischerweise 99,99%). - Risiko: Bis zu 43,8 Stunden Ausfallzeit pro Jahr vs. 52,6 Minuten bei 99,99%. - Auswirkung: Betriebsunterbrechungen, Umsatzverlust, Kundenunzufriedenheit. 3. Haftung (Abschnitt 9): - Problem: Haftungsobergrenze bei 3 Monatsgebühren festgelegt. - Risiko: Unzureichend für potenzielle Datenschutzverletzungen, IP-Diebstahl oder längere Serviceausfälle. - Auswirkung: Unzureichende Entschädigung für Schäden, die die Obergrenze weit übersteigen könnten, wie Sammelklagen oder regulatorische Strafen.

Rolle

Inhalt

User

Assistant
{{CONCERNS}}

1. Datenschutz (Abschnitt 7):
- Problem: Anbieter hat weitreichende Rechte zur Nutzung von Kundendaten für “Serviceverbesserung”.
- Risiko: Könnte zu unerlaubter Datenweitergabe oder Monetarisierung von Kundendaten führen.
- Auswirkung: Mögliche Verletzung des Kundenvertrauens, regulatorische Strafen (DSGVO, CCPA).

2. SLAs (Abschnitt 5):
- Problem: 99,5% Verfügbarkeitsgarantie liegt unter Branchenstandard (typischerweise 99,99%).
- Risiko: Bis zu 43,8 Stunden Ausfallzeit pro Jahr vs. 52,6 Minuten bei 99,99%.
- Auswirkung: Betriebsunterbrechungen, Umsatzverlust, Kundenunzufriedenheit.

3. Haftung (Abschnitt 9):
- Problem: Haftungsobergrenze bei 3 Monatsgebühren festgelegt.
- Risiko: Unzureichend für potenzielle Datenschutzverletzungen, IP-Diebstahl oder längere Serviceausfälle.
- Auswirkung: Unzureichende Entschädigung für Schäden, die die Obergrenze weit übersteigen könnten, wie Sammelklagen oder regulatorische Strafen.

Prompt 2

Rolle	Inhalt
User	Verfassen Sie eine E-Mail an einen SaaS-Produktanbieter, die die folgenden Bedenken aufführt und Änderungen vorschlägt. Hier sind die Bedenken: <concerns> {{CONCERNS}} </concerns>
Assistant {{EMAIL}}	Sehr geehrte/r {{VENDOR}}, nach einer gründlichen Überprüfung der vorgeschlagenen SaaS-Vereinbarung hat unser Rechtsteam mehrere hochprioritäre Bedenken identifiziert, die vor unserem Fortfahren adressiert werden müssen: 1. Datenschutz (Abschnitt 7): - Aktuell: Weitreichende Rechte zur Nutzung von Kundendaten für “Serviceverbesserung”. - Bedenken: Mögliche unerlaubte Datenweitergabe oder Monetarisierung. - Vorgeschlagene Änderung: Beschränkung der Datennutzung auf direkte Servicebereitstellung. Jegliche Nutzung für Verbesserung, Analytik oder Marketing muss opt-in, widerrufbar und anonymisiert sein. 2. SLAs (Abschnitt 5): - Aktuell: 99,5% Verfügbarkeitsgarantie. - Bedenken: Bis zu 43,8 Stunden Ausfallzeit pro Jahr, Risiko von Betriebsunterbrechungen. - Vorgeschlagene Änderung: 99,99% Verfügbarkeit mit gestaffelten Service-Credits. Z.B. 10% Gutschrift für <99,99%, 25% für <99,9%, 50% für <99,5%. 3. Haftung (Abschnitt 9): - Aktuell: Obergrenze bei 3 Monatsgebühren. - Bedenken: Völlig unzureichend für Datenschutzverletzungen, IP-Diebstahl oder längere Ausfälle. - Vorgeschlagene Änderung: 12 Monatsgebühren für allgemeine Haftung. Keine Obergrenze für Datenschutzverletzungen, vorsätzliches Fehlverhalten, IP-Verletzungen. Diese Änderungen sind für uns nicht verhandelbar. Sie entsprechen Branchenstandards und unserem Engagement für Datensicherheit, betriebliche Exzellenz und treuhänderische Verantwortung. Wir schätzen das Potenzial unserer Partnerschaft, und die Adressierung dieser Punkte wird eine starke Grundlage schaffen. Bitte lassen Sie Ihr Rechtsteam diese Änderungen prüfen und einarbeiten. Wir stehen gerne für weitere Gespräche zur Verfügung, um gegenseitiges Verständnis und Einigung sicherzustellen. Mit freundlichen Grüßen {{CLO_NAME}}

Rolle

Inhalt

User

Verfassen Sie eine E-Mail an einen SaaS-Produktanbieter, die die folgenden Bedenken aufführt und Änderungen vorschlägt. Hier sind die Bedenken:
<concerns>
{{CONCERNS}}
</concerns>

Assistant
{{EMAIL}}

Sehr geehrte/r {{VENDOR}},

nach einer gründlichen Überprüfung der vorgeschlagenen SaaS-Vereinbarung hat unser Rechtsteam mehrere hochprioritäre Bedenken identifiziert, die vor unserem Fortfahren adressiert werden müssen:

1. Datenschutz (Abschnitt 7):
- Aktuell: Weitreichende Rechte zur Nutzung von Kundendaten für “Serviceverbesserung”.
- Bedenken: Mögliche unerlaubte Datenweitergabe oder Monetarisierung.
- Vorgeschlagene Änderung: Beschränkung der Datennutzung auf direkte Servicebereitstellung. Jegliche Nutzung für Verbesserung, Analytik oder Marketing muss opt-in, widerrufbar und anonymisiert sein.

2. SLAs (Abschnitt 5):
- Aktuell: 99,5% Verfügbarkeitsgarantie.
- Bedenken: Bis zu 43,8 Stunden Ausfallzeit pro Jahr, Risiko von Betriebsunterbrechungen.
- Vorgeschlagene Änderung: 99,99% Verfügbarkeit mit gestaffelten Service-Credits. Z.B. 10% Gutschrift für <99,99%, 25% für <99,9%, 50% für <99,5%.

3. Haftung (Abschnitt 9):
- Aktuell: Obergrenze bei 3 Monatsgebühren.
- Bedenken: Völlig unzureichend für Datenschutzverletzungen, IP-Diebstahl oder längere Ausfälle.
- Vorgeschlagene Änderung: 12 Monatsgebühren für allgemeine Haftung. Keine Obergrenze für Datenschutzverletzungen, vorsätzliches Fehlverhalten, IP-Verletzungen.

Diese Änderungen sind für uns nicht verhandelbar. Sie entsprechen Branchenstandards und unserem Engagement für Datensicherheit, betriebliche Exzellenz und treuhänderische Verantwortung. Wir schätzen das Potenzial unserer Partnerschaft, und die Adressierung dieser Punkte wird eine starke Grundlage schaffen.

Bitte lassen Sie Ihr Rechtsteam diese Änderungen prüfen und einarbeiten. Wir stehen gerne für weitere Gespräche zur Verfügung, um gegenseitiges Verständnis und Einigung sicherzustellen.

Mit freundlichen Grüßen
{{CLO_NAME}}

Prompt 3

Rolle	Inhalt
User	Ihre Aufgabe ist es, eine E-Mail zu überprüfen und Feedback zu geben. Hier ist die E-Mail: <email> {{EMAIL}} </email> Geben Sie Feedback zu Ton, Klarheit und Professionalität.
Assistant	1. Ton: - Professionell und bestimmt ohne konfrontativ zu sein. - Verwendung von “nicht verhandelbar” ist stark, aber angesichts der Kritikalität der Probleme gerechtfertigt. - Kooperative Sprache (“wir schätzen”, “stehen gerne zur Verfügung”) balanciert die Bestimmtheit und behält einen konstruktiven Ton bei. 2. Klarheit: - Ausgezeichnete Strukturierung: Aktueller Stand, Bedenken und vorgeschlagene Änderung für jedes Problem. - Technische Begriffe (z.B. “EBITDA”, “gestaffelte Service-Credits”) sind angemessen für einen B2B-SaaS-Kontext. - Handlungspunkte sind klar: Rechtsteam des Anbieters soll prüfen und Änderungen einarbeiten. 3. Professionalität: - Fokussiert auf gegenseitigen Nutzen und Branchenstandards, nicht nur auf unsere Forderungen. - Erwähnt breitere Verantwortlichkeiten (Datensicherheit, betriebliche Exzellenz, treuhänderische Pflicht), hebt die Diskussion auf eine höhere Ebene. - Bietet weitere Diskussion an, zeigt Engagement für Verständnis und Problemlösung. Insgesamt trifft die E-Mail die richtige Balance zwischen Bestimmtheit und Kooperation. Sie artikuliert unsere Bedenken klar, schlägt spezifische Lösungen vor und behält einen professionellen, partnerschaftsorientierten Ton bei. Keine Überarbeitungen nötig; kann so versendet werden.

Rolle

Inhalt

User

Ihre Aufgabe ist es, eine E-Mail zu überprüfen und Feedback zu geben. Hier ist die E-Mail:
<email>
{{EMAIL}}
</email>

Geben Sie Feedback zu Ton, Klarheit und Professionalität.

Assistant

1. Ton:
- Professionell und bestimmt ohne konfrontativ zu sein.
- Verwendung von “nicht verhandelbar” ist stark, aber angesichts der Kritikalität der Probleme gerechtfertigt.
- Kooperative Sprache (“wir schätzen”, “stehen gerne zur Verfügung”) balanciert die Bestimmtheit und behält einen konstruktiven Ton bei.

2. Klarheit:
- Ausgezeichnete Strukturierung: Aktueller Stand, Bedenken und vorgeschlagene Änderung für jedes Problem.
- Technische Begriffe (z.B. “EBITDA”, “gestaffelte Service-Credits”) sind angemessen für einen B2B-SaaS-Kontext.
- Handlungspunkte sind klar: Rechtsteam des Anbieters soll prüfen und Änderungen einarbeiten.

3. Professionalität:
- Fokussiert auf gegenseitigen Nutzen und Branchenstandards, nicht nur auf unsere Forderungen.
- Erwähnt breitere Verantwortlichkeiten (Datensicherheit, betriebliche Exzellenz, treuhänderische Pflicht), hebt die Diskussion auf eine höhere Ebene.
- Bietet weitere Diskussion an, zeigt Engagement für Verständnis und Problemlösung.

Insgesamt trifft die E-Mail die richtige Balance zwischen Bestimmtheit und Kooperation. Sie artikuliert unsere Bedenken klar, schlägt spezifische Lösungen vor und behält einen professionellen, partnerschaftsorientierten Ton bei. Keine Überarbeitungen nötig; kann so versendet werden.

Prompt 1

Rolle	Inhalt
User	Als Senior Solutions Architect überprüfen und analysieren Sie diese Multitenancy-Strategie für unser neues Enterprise-SaaS-Produkt. <strategy> {{STRATEGY}} </strategy> Konzentrieren Sie sich auf Skalierbarkeit, Sicherheit und Kosteneffizienz.
Assistant {{ANALYSIS}}	1. Skalierbarkeit: + Datenbank-Sharding nach Tenant reduziert Konflikte, unterstützt hohes Wachstum. + Microservices ermöglichen unabhängige Skalierung von Komponenten. - Gemeinsame App-Server könnten unter extremer Last zum Engpass werden. - Keine Erwähnung von Auto-Scaling oder Load Balancing für App-Tier. 2. Sicherheit: + Tenant-Datenisolierung durch Sharding mindert Datenlecks. + JWT mit kurzer Gültigkeit und Refresh-Tokens ist Branchenstandard. - Keine Erwähnung von Verschlüsselung (in Ruhe, während der Übertragung) oder Schlüsselverwaltung. - IAM-Strategie fehlt Details zu Rollen, Berechtigungen oder RBAC. 3. Kosteneffizienz: + Gemeinsame App-Server reduzieren Leerlauf-Ressourcenkosten. + Serverless-Funktionen für seltene Aufgaben optimieren Kosten. - Pro-Tenant-DB könnte Kosten im Vergleich zu optimierter Multi-Tenant-DB bei Skalierung erhöhen. - Keine Diskussion von Reserved Instances oder Spot Instances für Kosteneinsparung.

Rolle

Inhalt

User

Als Senior Solutions Architect überprüfen und analysieren Sie diese Multitenancy-Strategie für unser neues Enterprise-SaaS-Produkt.

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

Konzentrieren Sie sich auf Skalierbarkeit, Sicherheit und Kosteneffizienz.

Assistant
{{ANALYSIS}}

1. Skalierbarkeit:
+ Datenbank-Sharding nach Tenant reduziert Konflikte, unterstützt hohes Wachstum.
+ Microservices ermöglichen unabhängige Skalierung von Komponenten.
- Gemeinsame App-Server könnten unter extremer Last zum Engpass werden.
- Keine Erwähnung von Auto-Scaling oder Load Balancing für App-Tier.

2. Sicherheit:
+ Tenant-Datenisolierung durch Sharding mindert Datenlecks.
+ JWT mit kurzer Gültigkeit und Refresh-Tokens ist Branchenstandard.
- Keine Erwähnung von Verschlüsselung (in Ruhe, während der Übertragung) oder Schlüsselverwaltung.
- IAM-Strategie fehlt Details zu Rollen, Berechtigungen oder RBAC.

3. Kosteneffizienz:
+ Gemeinsame App-Server reduzieren Leerlauf-Ressourcenkosten.
+ Serverless-Funktionen für seltene Aufgaben optimieren Kosten.
- Pro-Tenant-DB könnte Kosten im Vergleich zu optimierter Multi-Tenant-DB bei Skalierung erhöhen.
- Keine Diskussion von Reserved Instances oder Spot Instances für Kosteneinsparung.

Prompt 2

Rolle	Inhalt
User	Erstellen Sie ein Strategie-Review-Dokument für die Entwicklungsleitung basierend auf dieser Analyse einer Multitenancy-Strategie. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Fügen Sie eine Executive Summary, detaillierte Analyse und Empfehlungen ein.
Assistant {{STRATEGY_DOC}}	# Multitenancy-Strategie-Review: SaaS Enterprise-Produkt ## Executive Summary Die vorgeschlagene Strategie zeigt eine solide Grundlage in Skalierbarkeits- und Sicherheitsprinzipien, hat aber Lücken in Implementierungsdetails. Sie überzeugt bei Datenisolierung und Komponenten-Level-Skalierung, mangelt aber an robuster App-Tier-Skalierung und fortgeschrittenen Sicherheitsmaßnahmen. Kostenoptimierungen sind vorhanden, könnten aber bei hoher Skalierung scheitern. Mit gezielten Verbesserungen kann diese Strategie unsere Enterprise-SaaS-Ambitionen effektiv unterstützen. ## Detaillierte Analyse ### 1. Skalierbarkeit: B+ Stärken: - Datenbank-Sharding nach Tenant ist exzellent. Es minimiert Query-Latenz, unterstützt hohes Datenwachstum und ermöglicht nahtlose Pro-Tenant-Skalierung. - Microservices-Architektur ermöglicht Skalierung einzelner Komponenten basierend auf Bedarf, entscheidend für die Handhabung diverser Enterprise-Workloads. Schwächen: - Gemeinsame Applikationsserver riskieren, zum Engpass zu werden. Mit wachsender Tenant-Anzahl und Traffic könnte sich die Performance über alle Tenants hinweg verschlechtern. - Fehlen von Auto-Scaling und Load Balancing für die App-Tier ist ein kritisches Versäumnis. Diese sind essentiell für die Handhabung von Traffic-Spitzen ohne Überbereitstellung. ### 2. Sicherheit: B- Stärken: - Sharded Datenbanken bieten starke Tenant-Datenisolierung, mindern Risiken von Datenlecks oder unberechtigtem Zugriff zwischen Tenants. - JWT mit kurzer Gültigkeit und Refresh-Tokens entsprechen OWASP Best Practices, reduzieren Token-Verwundbarkeitsperioden. Schwächen: - Keine Erwähnung von Datenverschlüsselung in Ruhe oder während der Übertragung (TLS 1.3). Dies ist nicht verhandelbar für Enterprise-Daten. - Schlüsselverwaltungsstrategie fehlt. Wie werden Verschlüsselungsschlüssel, JWT-Secrets und DB-Zugangsdaten verwaltet und rotiert? - IAM fehlt Tiefe. Wir benötigen RBAC mit gut definierten Rollen, attributbasierte Zugriffskontrolle (ABAC) für feingranulare Berechtigungen und Integration mit Enterprise-Identitätsprovidern (SAML, OIDC). ### 3. Kosteneffizienz: B Stärken: - Gemeinsame App-Server reduzieren Leerlaufkapazitätskosten, gut für gleichmäßigen Traffic. - Serverless für seltene Aufgaben (z.B. Reporting) ist klug; Zahlung nur bei Nutzung dieser Ressourcen. Schwächen: - Pro-Tenant-Datenbanken könnten bei Skalierung nicht kosteneffektiv sein im Vergleich zu einer gut designten Multi-Tenant-Datenbank mit robuster Datenpartitionierung. - Keine Erwähnung von Kostensparmaßnahmen wie Reserved Instances für vorhersehbare Workloads oder Spot Instances für fehlertolerante Aufgaben. - Fehlen von App-Tier-Auto-Scaling könnte zu Überbereitstellung führen, erhöht Kosten. ## Empfehlungen 1. App-Tier-Resilienz: Implementieren Sie Auto-Scaling mit Kubernetes oder Cloud-nativen Services (EKS, GKE). Deployment über Availability Zones mit CDN für statische Assets. 2. Sicherheitshärtung: a. Verschlüsseln Sie Daten in Ruhe (AES-256) und während der Übertragung (TLS 1.3). b. Nutzen Sie verwaltetes KMS (AWS KMS, GCP KMS) für Schlüsselverwaltung. c. Verbessern Sie IAM mit RBAC, ABAC und SAML/OIDC für Enterprise SSO. 3. Kostenoptimierung: a. Evaluieren Sie spaltenbasierte Multi-Tenant-DB (z.B. Snowflake) vs. Sharding bei Skalierung. b. Nutzen Sie Reserved Instances für App-Server, Spot Instances für unkritische Workloads. c. Implementieren Sie proaktives Monitoring und Right-Sizing zur Vermeidung von Überbereitstellung. 4. Proof of Concept (PoC): Vor vollständiger Implementierung führen Sie einen PoC mit Hochskalensimulation durch: a. Testen Sie Sharded DB vs. optimierte Multi-Tenant-DB für Kosten und Performance. b. Stress-Test der App-Tier mit simulierten Enterprise-Level-Traffic-Spitzen. c. Führen Sie Drittanbieter-Sicherheitsaudit durch, fokussiert auf Datenisolierung und Zugriffskontrolle. Mit diesen Verbesserungen wird unsere Multi-Tenancy-Strategie Enterprise-Grade sein: skalierbar, s

Rolle

Inhalt

User

Erstellen Sie ein Strategie-Review-Dokument für die Entwicklungsleitung basierend auf dieser Analyse einer Multitenancy-Strategie.

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

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

Fügen Sie eine Executive Summary, detaillierte Analyse und Empfehlungen ein.

Assistant
{{STRATEGY_DOC}}

# Multitenancy-Strategie-Review: SaaS Enterprise-Produkt

## Executive Summary
Die vorgeschlagene Strategie zeigt eine solide Grundlage in Skalierbarkeits- und Sicherheitsprinzipien, hat aber Lücken in Implementierungsdetails. Sie überzeugt bei Datenisolierung und Komponenten-Level-Skalierung, mangelt aber an robuster App-Tier-Skalierung und fortgeschrittenen Sicherheitsmaßnahmen. Kostenoptimierungen sind vorhanden, könnten aber bei hoher Skalierung scheitern. Mit gezielten Verbesserungen kann diese Strategie unsere Enterprise-SaaS-Ambitionen effektiv unterstützen.

## Detaillierte Analyse

### 1. Skalierbarkeit: B+

Stärken:
- Datenbank-Sharding nach Tenant ist exzellent. Es minimiert Query-Latenz, unterstützt hohes Datenwachstum und ermöglicht nahtlose Pro-Tenant-Skalierung.
- Microservices-Architektur ermöglicht Skalierung einzelner Komponenten basierend auf Bedarf, entscheidend für die Handhabung diverser Enterprise-Workloads.

Schwächen:
- Gemeinsame Applikationsserver riskieren, zum Engpass zu werden. Mit wachsender Tenant-Anzahl und Traffic könnte sich die Performance über alle Tenants hinweg verschlechtern.
- Fehlen von Auto-Scaling und Load Balancing für die App-Tier ist ein kritisches Versäumnis. Diese sind essentiell für die Handhabung von Traffic-Spitzen ohne Überbereitstellung.

### 2. Sicherheit: B-

Stärken:
- Sharded Datenbanken bieten starke Tenant-Datenisolierung, mindern Risiken von Datenlecks oder unberechtigtem Zugriff zwischen Tenants.
- JWT mit kurzer Gültigkeit und Refresh-Tokens entsprechen OWASP Best Practices, reduzieren Token-Verwundbarkeitsperioden.

Schwächen:
- Keine Erwähnung von Datenverschlüsselung in Ruhe oder während der Übertragung (TLS 1.3). Dies ist nicht verhandelbar für Enterprise-Daten.
- Schlüsselverwaltungsstrategie fehlt. Wie werden Verschlüsselungsschlüssel, JWT-Secrets und DB-Zugangsdaten verwaltet und rotiert?
- IAM fehlt Tiefe. Wir benötigen RBAC mit gut definierten Rollen, attributbasierte Zugriffskontrolle (ABAC) für feingranulare Berechtigungen und Integration mit Enterprise-Identitätsprovidern (SAML, OIDC).

### 3. Kosteneffizienz: B

Stärken:
- Gemeinsame App-Server reduzieren Leerlaufkapazitätskosten, gut für gleichmäßigen Traffic.
- Serverless für seltene Aufgaben (z.B. Reporting) ist klug; Zahlung nur bei Nutzung dieser Ressourcen.

Schwächen:
- Pro-Tenant-Datenbanken könnten bei Skalierung nicht kosteneffektiv sein im Vergleich zu einer gut designten Multi-Tenant-Datenbank mit robuster Datenpartitionierung.
- Keine Erwähnung von Kostensparmaßnahmen wie Reserved Instances für vorhersehbare Workloads oder Spot Instances für fehlertolerante Aufgaben.
- Fehlen von App-Tier-Auto-Scaling könnte zu Überbereitstellung führen, erhöht Kosten.

## Empfehlungen

1. App-Tier-Resilienz: Implementieren Sie Auto-Scaling mit Kubernetes oder Cloud-nativen Services (EKS, GKE). Deployment über Availability Zones mit CDN für statische Assets.

2. Sicherheitshärtung:
a. Verschlüsseln Sie Daten in Ruhe (AES-256) und während der Übertragung (TLS 1.3).
b. Nutzen Sie verwaltetes KMS (AWS KMS, GCP KMS) für Schlüsselverwaltung.
c. Verbessern Sie IAM mit RBAC, ABAC und SAML/OIDC für Enterprise SSO.

3. Kostenoptimierung:
a. Evaluieren Sie spaltenbasierte Multi-Tenant-DB (z.B. Snowflake) vs. Sharding bei Skalierung.
b. Nutzen Sie Reserved Instances für App-Server, Spot Instances für unkritische Workloads.
c. Implementieren Sie proaktives Monitoring und Right-Sizing zur Vermeidung von Überbereitstellung.

4. Proof of Concept (PoC): Vor vollständiger Implementierung führen Sie einen PoC mit Hochskalensimulation durch:
a. Testen Sie Sharded DB vs. optimierte Multi-Tenant-DB für Kosten und Performance.
b. Stress-Test der App-Tier mit simulierten Enterprise-Level-Traffic-Spitzen.
c. Führen Sie Drittanbieter-Sicherheitsaudit durch, fokussiert auf Datenisolierung und Zugriffskontrolle.

Mit diesen Verbesserungen wird unsere Multi-Tenancy-Strategie Enterprise-Grade sein: skalierbar, s

icher und kosteneffektiv. Der PoC wird unsere Design-Entscheidungen validieren und Vertrauen bei unseren Enterprise-Kunden schaffen. |

Prompt-Bibliothek

Lassen Sie sich von einer kuratierten Auswahl von Prompts für verschiedene Aufgaben und Anwendungsfälle inspirieren.

GitHub Prompting Tutorial

Ein beispielreiches Tutorial, das die Prompt-Engineering-Konzepte aus unserer Dokumentation behandelt.

Google Sheets Prompting Tutorial

Eine leichtgewichtigere Version unseres Prompt-Engineering-Tutorials über eine interaktive Tabelle.

Erste Schritte

Mit Claude entwickeln

Testen und auswerten

Erfahren Sie mehr über Claude

Verwaltung

Ressourcen

Rechtszentrum

Komplexe Prompts verketten für bessere Leistung

Warum Prompts verketten?

Wann Prompts verketten

Wie man Prompts verkettet

Beispiele für verkettete Workflows:

Fortgeschritten: Selbstkorrektur-Ketten

Prompt 1

Prompt 2

Prompt 3

Beispiele

Prompt 1

Prompt 2

Prompt 3

Prompt 1

Prompt 2

Prompt-Bibliothek

GitHub Prompting Tutorial

Google Sheets Prompting Tutorial

Erste Schritte

Mit Claude entwickeln

Testen und auswerten

Erfahren Sie mehr über Claude

Verwaltung

Ressourcen

Rechtszentrum

​Warum Prompts verketten?

​Wann Prompts verketten

​Wie man Prompts verkettet

​Beispiele für verkettete Workflows:

​Fortgeschritten: Selbstkorrektur-Ketten

Prompt 1

Prompt 2

Prompt 3

​Beispiele

Prompt 1

Prompt 2

Prompt 3

Prompt 1

Prompt 2

Prompt-Bibliothek

GitHub Prompting Tutorial

Google Sheets Prompting Tutorial

Warum Prompts verketten?

Wann Prompts verketten

Wie man Prompts verkettet

Beispiele für verkettete Workflows:

Fortgeschritten: Selbstkorrektur-Ketten

Beispiele