Prompt-Engineering
Verketten Sie komplexe Prompts für eine stärkere Leistung
Prompt-Engineering
Verketten Sie komplexe Prompts für eine stärkere Leistung
Bei der Arbeit mit komplexen Aufgaben kann Claude manchmal den Ball fallen lassen, wenn Sie versuchen, alles in einem einzigen Prompt zu erledigen. Chain of Thought (CoT) Prompting ist großartig, aber was ist, wenn Ihre Aufgabe mehrere unterschiedliche Schritte erfordert, die jeweils ein tiefgehendes Nachdenken erfordern?
Hier kommt das Prompt-Chaining ins Spiel: die Aufteilung komplexer Aufgaben in kleinere, überschaubare Teilaufgaben.
Warum Prompts verketten?
- Genauigkeit: Jede Teilaufgabe erhält Claudes volle Aufmerksamkeit, was Fehler reduziert.
- Klarheit: Einfachere Teilaufgaben bedeuten klarere Anweisungen und Ergebnisse.
- Nachvollziehbarkeit: Probleme in Ihrer Prompt-Kette können leicht identifiziert und behoben werden.
Wann sollte man Prompts verketten?
Verwenden Sie Prompt-Chaining 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 auslässt oder schlecht ausführt, isolieren Sie diesen Schritt in einem eigenen Prompt. So können Sie problematische Schritte optimieren, ohne die gesamte Aufgabe neu zu machen.
Wie man Prompts verkettet
- Teilaufgaben identifizieren: Zerlegen Sie Ihre Aufgabe in einzelne, aufeinanderfolgende Schritte.
- Mit XML für klare Übergaben strukturieren: Verwenden Sie XML-Tags, um Ausgaben zwischen Prompts zu übergeben.
- Ein Einzelaufgabenziel haben: Jede Teilaufgabe sollte ein einziges, klares Ziel haben.
- Iterieren: Verfeinern Sie Teilaufgaben basierend auf Claudes Leistung.
Beispiele für verkettete Workflows:
- Mehrstufige Analyse: Siehe die Rechts- und Geschäftsbeispiele unten.
- Content-Creation-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: Für Aufgaben mit unabhängigen Teilaufgaben (wie die Analyse mehrerer Dokumente) erstellen Sie separate Prompts und führen Sie sie parallel aus, um Zeit zu sparen.
Fortgeschritten: Selbstkorrekturketten
Sie können Prompts verketten, damit Claude seine eigene Arbeit überprüft! Dies fängt Fehler ab und verfeinert die Ergebnisse, insbesondere bei Aufgaben mit hohem Einsatz.
Prompt 1
| Rolle | Inhalt |
|---|---|
| Benutzer | Fassen Sie dieses medizinische Forschungspapier zusammen. <paper>{{RESEARCH_PAPER}}</paper> Konzentrieren Sie sich auf Methodik, Ergebnisse und klinische Implikationen. |
| Assistent {{SUMMARY}} | Methodik: Doppelblinde RCT mit 500 Typ-2-Diabetes-Patienten. Gruppe A (n=250) erhielt neuartigen GLP-1/GIP-Doppelagonisten; 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, die auf die Behandlung zurückzuführen waren. Klinische Implikationen: Der Doppelagonist zeigt eine überlegene glykämische Kontrolle und Gewichtsabnahme im Vergleich zur Standardtherapie. Könnte ein Durchbruch sein, insbesondere für adipöse Diabetiker. |
Prompt 2
| Rolle | Inhalt |
|---|---|
| Benutzer | Ihre Aufgabe ist es, Feedback zu einer Zusammenfassung eines Forschungspapiers 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 Skala von A bis F. |
| Assistent {{FEEDBACK}} | 1. Genauigkeit: A - Korrekte Angabe der wichtigsten Statistiken: HbA1c-Reduktionen, Gewichtsverlust. - Genaue Angabe des Sicherheitsprofils und des Fehlens schwerwiegender Nebenwirkungen. - Die Behauptung “Durchbruch” ist durch signifikant bessere Ergebnisse gerechtfertigt. 2. Klarheit: A- - Prägnant und gut strukturiert mit klaren Abschnitten. - Gute Verwendung von Vergleichssprache (z.B. “um 3% höher als in Q1”) für den Kontext. - Kleines Problem: Abkürzungen wie “RCT”, “GLP-1” und “GIP” nicht definiert. Erwägen Sie, bei der ersten Verwendung auszuschreiben. 3. Vollständigkeit: B+ - Deckt alle geforderten Bereiche ab: Methodik, Ergebnisse, klinische Implikationen. - Fehlend: Baseline-Charakteristika der Gruppen (waren sie gut abgestimmt?). - Fehlend: Sekundäre Endpunkte (z.B. Blutdruck, Lipide). - Zu bedenken: Langfristige Implikationen oder Notwendigkeit weiterer Forschung. Insgesamt ist die Zusammenfassung genau und klar und bietet wichtige Erkenntnisse für ein schnelles Verständnis der Studie. Um auf A+ zu kommen, definieren Sie Abkürzungen, erwähnen Sie die Baseline-Statistiken der Gruppen, vermerken Sie sekundäre Ergebnisse und gehen Sie kurz auf die Notwendigkeit von Langzeitstudien ein. |
Prompt 3
| Rolle | Inhalt |
|---|---|
| Benutzer | Ihre Aufgabe ist es, eine Zusammenfassung eines Papiers anhand von Feedback zu verbessern. Hier ist der erste Entwurf einer Zusammenfassung 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. |
| Assistent | 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) Doppelagonisten; Gruppe B (n=250) erhielt einen Standard-GLP-1-Agonisten. Der primäre Endpunkt der 24-wöchigen Studie war die HbA1c-Reduktion. Die Gruppen waren hinsichtlich Alter, BMI und Ausgangs-HbA1c gut abgestimmt. 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 des Blutdrucks und der Lipidprofile für beide Gruppen, wobei Gruppe A etwas bessere Ergebnisse zeigte. Sicherheit: Ähnliche Nebenwirkungsprofile, wobei keine schwerwiegenden Ereignisse einer der beiden Behandlungen zugeschrieben wurden. Klinische Implikationen: Der GLP-1/GIP-Doppelagonist zeigt eine überlegene glykämische Kontrolle und Gewichtsabnahme im Vergleich zur Standard-GLP-1-Therapie. Diese Ergebnisse deuten darauf hin, dass es ein bedeutender Fortschritt sein könnte, insbesondere für adipöse Diabetiker. Es sind jedoch längerfristige Studien erforderlich, um die anhaltende Wirksamkeit und Sicherheit zu bestätigen sowie potenzielle Vorteile für kardiovaskuläre Ergebnisse zu untersuchen. |
Beispiele
Beachten Sie, dass Claude in seinem E-Mail-Entwurf die Anweisung übersieht, Änderungsvorschläge zu machen.
| Rolle | Inhalt |
|---|---|
| Benutzer | Sie sind unser Chief Legal Officer. Überprüfen Sie diesen SaaS-Vertrag auf Risiken, wobei Sie sich auf Datenschutz, SLAs und Haftungsbeschränkungen konzentrieren. <contract> {{CONTRACT}} </contract> Verfassen Sie dann eine E-Mail an den Anbieter mit Ihren Bedenken und Änderungsvorschlägen. |
| Assistent | Nach Durchsicht des SaaS-Vertrags habe ich mehrere Bedenken identifiziert: 1. Datenschutz (Abschnitt 7): - Problem: Der Anbieter hat weitreichende Rechte zur Nutzung von Kundendaten zur “Serviceverbesserung”. - Risiko: Könnte zu unbefugter Datenweitergabe oder Monetarisierung führen. 2. SLAs (Abschnitt 5): - Problem: 99,5% Verfügbarkeitsgarantie liegt unter dem Branchenstandard. - Risiko: Übermäßige Ausfallzeiten könnten unseren Betrieb beeinträchtigen. 3. Haftung (Abschnitt 9): - Problem: Begrenzung auf 3 Monatsgebühren. - Risiko: Unzureichend für potenzielle Datenschutzverletzungen oder Serviceausfälle. Entwurf der E-Mail: Sehr geehrte Damen und Herren von {{VENDOR}}, Nach Durchsicht 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 derzeitige Begrenzung auf 3 Monatsgebühren ist unzureichend. Wir schlagen eine Begrenzung auf 12 Monatsgebühren vor, ohne Begrenzung für Datenschutzverletzungen oder vorsätzliches Fehlverhalten. Wir schätzen unsere potenzielle Partnerschaft und glauben, dass diese Änderungen uns auf Erfolgskurs bringen werden. Bitte senden Sie uns eine überarbeitete Vereinbarung. Mit freundlichen Grüßen, {{CLO_NAME}} |
Prompt 1
| Rolle | Inhalt |
|---|---|
| Benutzer | Sie sind unser Chief Legal Officer. Überprüfen Sie diesen SaaS-Vertrag auf Risiken, wobei Sie sich auf Datenschutz, SLAs und Haftungsbeschränkungen konzentrieren.. <contract> {{CONTRACT}} </contract> Geben Sie Ihre Ergebnisse in <risks>-Tags aus. |
| Assistent {{CONCERNS}} | 1. Datenschutz (Abschnitt 7): - Problem: Der Anbieter hat weitreichende Rechte zur Nutzung von Kundendaten zur “Serviceverbesserung”. - Risiko: Könnte zu unbefugter Datenweitergabe oder Monetarisierung von Kundendaten führen. - Auswirkung: Potenzieller Vertrauensbruch bei Kunden, Bußgelder durch Aufsichtsbehörden (DSGVO, CCPA). 2. SLAs (Abschnitt 5): - Problem: 99,5% Verfügbarkeitsgarantie liegt unter dem Branchenstandard (typischerweise 99,99%). - Risiko: Bis zu 43,8 Stunden Ausfallzeit pro Jahr gegenüber 52,6 Minuten bei 99,99%. - Auswirkung: Betriebsunterbrechungen, Umsatzverluste, Kundenunzufriedenheit. 3. Haftung (Abschnitt 9): - Problem: Haftungsbegrenzung auf 3 Monatsgebühren. - 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önnen, wie Sammelklagen oder Bußgelder. |
Prompt 2
| Rolle | Inhalt |
|---|---|
| Benutzer | Verfassen Sie eine E-Mail an einen SaaS-Produktanbieter, in der Sie die folgenden Bedenken darlegen und Änderungen vorschlagen. Hier sind die Bedenken: <concerns> {{CONCERNS}} </concerns> |
| Assistent {{EMAIL}} | Sehr geehrte Damen und Herren von {{VENDOR}}, Nach gründlicher Prüfung der vorgeschlagenen SaaS-Vereinbarung hat unser Rechtsteam mehrere vorrangige Bedenken festgestellt, die ausgeräumt werden müssen, bevor wir fortfahren können: 1. Datenschutz (Abschnitt 7): - Aktuell: Weitreichende Rechte zur Nutzung von Kundendaten zur “Serviceverbesserung”. - Bedenken: Mögliche unbefugte Datenweitergabe oder Monetarisierung. - Änderungsvorschlag: Beschränkung der Datennutzung auf die direkte Servicebereitstellung. Jede Nutzung zur Verbesserung, Analyse oder Vermarktung muss auf Opt-in-Basis erfolgen, 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. - Änderungsvorschlag: 99,99% Verfügbarkeit mit gestaffelten Service-Gutschriften. Z.B. 10% Gutschrift für <99,99%, 25% für <99,9%, 50% für <99,5%. 3. Haftung (Abschnitt 9): - Aktuell: Begrenzung auf 3 Monatsgebühren. - Bedenken: Völlig unzureichend für Datenschutzverletzungen, IP-Diebstahl oder längere Ausfälle. - Änderungsvorschlag: 12 Monatsgebühren für allgemeine Haftung. Unbegrenzt für Datenschutzverletzungen, vorsätzliches Fehlverhalten, IP-Verletzungen. Diese Änderungen sind für uns nicht verhandelbar. Sie entsprechen den Branchenstandards und unserem Engagement für Datensicherheit, operative Exzellenz und Sorgfaltspflicht. Wir schätzen das Potenzial unserer Partnerschaft, und die Berücksichtigung dieser Punkte wird eine starke Grundlage schaffen. Bitte lassen Sie Ihr Rechtsteam dies überprüfen und die Änderungen einarbeiten. Wir diskutieren gerne weiter, um gegenseitiges Verständnis und Einvernehmen sicherzustellen. Mit freundlichen Grüßen, {{CLO_NAME}} |
Prompt 3
| Rolle | Inhalt |
|---|---|
| Benutzer | 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 Tonfall, Klarheit und Professionalität. |
| Assistent | 1. Tonfall: - Professionell und bestimmt, ohne konfrontativ zu sein. - Die Verwendung von “nicht verhandelbar” ist stark, aber angesichts der Kritikalität der Themen gerechtfertigt. - Kooperative Sprache (“wir schätzen”, “gerne diskutieren”) gleicht die Bestimmtheit aus und wahrt einen konstruktiven Ton. 2. Klarheit: - Hervorragende Strukturierung: Aktueller Stand, Bedenken und Änderungsvorschlag für jedes Thema. - Fachbegriffe (z.B. “EBITDA”, “gestaffelte Service-Gutschriften”) sind für einen B2B-SaaS-Kontext angemessen. - Handlungspunkte sind klar: Rechtsteam des Anbieters soll überprüfen und Änderungen einarbeiten. 3. Professionalität: - Konzentriert sich auf den gegenseitigen Nutzen und die Branchenstandards, nicht nur auf unsere Forderungen. - Erwähnt breitere Verantwortlichkeiten (Datensicherheit, operative Exzellenz, Sorgfaltspflicht), was die Diskussion auf eine höhere Ebene hebt. - Bietet weitere Diskussionen an und zeigt Engagement für Verständnis und Lösung der Probleme. Insgesamt findet die E-Mail die richtige Balance zwischen Bestimmtheit und Zusammenarbeit. Sie artikuliert klar unsere Bedenken, schlägt konkrete Lösungen vor und wahrt einen professionellen, partnerschaftsorientierten Ton. Keine Überarbeitungen nötig; Versand kann erfolgen. |
Prompt 1
| Rolle | Inhalt |
|---|---|
| Benutzer | 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. |
| Assistent {{ANALYSIS}} | 1. Skalierbarkeit: + Datenbank-Sharding nach Mandant 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 Lastverteilung für die App-Ebene. 2. Sicherheit: + Mandantendaten-Isolierung durch Sharding mindert Datenlecks. + JWT mit kurzer Gültigkeit und Refresh-Tokens entspricht Best Practices der Branche. - Keine Erwähnung von Verschlüsselung (ruhend, in Transit) oder Schlüsselverwaltung. - IAM-Strategie enthält keine Details zu Rollen, Berechtigungen oder RBAC. 3. Kosteneffizienz: + Gemeinsame App-Server reduzieren Kosten für ungenutzte Ressourcen. + Serverless-Funktionen für seltene Aufgaben optimieren Kosten. - Pro-Mandant-DB könnte Kosten bei großem Umfang im Vergleich zu optimierter Multi-Tenant-DB erhöhen. - Keine Diskussion über reservierte Instanzen oder Spot-Instanzen zur Kosteneinsparung. |
Prompt 2
| Rolle | Inhalt |
|---|---|
| Benutzer | Erstellen Sie ein Strategieüberprüfungsdokument für die Führungskräfte im Ingenieurwesen auf der Grundlage dieser Analyse einer Multitenancy-Strategie. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Fügen Sie eine Zusammenfassung, eine detaillierte Analyse und Empfehlungen hinzu. |
| Assistent {{STRATEGY_DOC}} | # Überprüfung der Multitenancy-Strategie: SaaS Enterprise-Produkt ## Zusammenfassung Die vorgeschlagene Strategie demonstriert ein solides Fundament in den Prinzipien der Skalierbarkeit und Sicherheit, weist aber Lücken in den Implementierungsdetails auf. Sie überzeugt durch Datenisolierung und Skalierung auf Komponentenebene, aber es fehlt eine robuste Skalierung auf App-Ebene und fortschrittliche Sicherheitsmaßnahmen. Kostenoptimierungen sind vorhanden, können aber bei hoher Skalierung ins Stocken geraten. Mit gezielten Verbesserungen kann diese Strategie unsere Enterprise-SaaS-Ambitionen effektiv unterstützen. ## Detaillierte Analyse ### 1. Skalierbarkeit: B+ Stärken: - Datenbank-Sharding nach Mandant ist hervorragend. Es minimiert die Abfragelatenz, unterstützt hohes Datenwachstum und erleichtert nahtlose mandantenspezifische Skalierung. - Microservices-Architektur ermöglicht die Skalierung einzelner Komponenten je nach Bedarf, was für die Bewältigung verschiedener Enterprise-Workloads entscheidend ist. Schwächen: - Gemeinsame Anwendungsserver riskieren, zum Engpass zu werden. Mit zunehmender Mandantenzahl und zunehmendem Traffic könnte dies die Leistung für alle Mandanten beeinträchtigen. - Das Fehlen von Auto-Scaling und Lastverteilung für die App-Ebene ist ein kritisches Versäumnis. Diese sind unerlässlich, um Verkehrsspitzen ohne Überbereitstellung zu bewältigen. ### 2. Sicherheit: B- Stärken: - Sharding-Datenbanken bieten eine starke Isolierung der Mandantendaten und mindern das Risiko von Datenlecks oder unbefugtem Zugriff zwischen Mandanten. - JWT mit kurzer Gültigkeit und Refresh-Tokens entsprechen den OWASP-Best-Practices und reduzieren die Zeitfenster für Token-Schwachstellen. Schwächen: - Keine Erwähnung von Datenverschlüsselung im Ruhezustand oder in Transit (TLS 1.3). Dies ist für Enterprise-Daten nicht verhandelbar. - Schlüsselverwaltungsstrategie fehlt. Wie werden Verschlüsselungsschlüssel, JWT-Geheimnisse und DB-Anmeldeinformationen verwaltet und rotiert? - IAM mangelt es an Tiefe. Wir brauchen RBAC mit klar definierten Rollen, attributbasierte Zugriffskontrolle (ABAC) für feingranulare Berechtigungen und Integration mit Enterprise-Identitätsanbietern (SAML, OIDC). ### 3. Kosteneffizienz: B Stärken: - Gemeinsame App-Server reduzieren Kosten für ungenutzte Kapazitäten, gut für gleichmäßigen Traffic. - Serverless für seltene Aufgaben (z.B. Reporting) ist klug; Bezahlung nur bei Nutzung dieser Ressourcen. Schwächen: - Pro-Mandanten-Datenbanken sind möglicherweise nicht kosteneffizient bei großem Umfang im Vergleich zu einer gut konzipierten Multi-Tenant-Datenbank mit robuster Datenpartitionierung. - Keine Erwähnung von Kosteneinsparungsmaßnahmen wie reservierten Instanzen für vorhersehbare Workloads oder Spot-Instanzen für fehlertolerante Aufgaben. - Fehlende Auto-Skalierung auf App-Ebene könnte zu Überbereitstellung und damit zu höheren Kosten führen. ## Empfehlungen 1. App-Tier-Resilienz: Implementieren Sie Auto-Scaling mit Kubernetes oder Cloud-nativen Diensten (EKS, GKE). Bereitstellung über Verfügbarkeitszonen mit CDN für statische Assets. 2. Sicherheitsoptimierung: a. Verschlüsselung ruhender Daten (AES-256) und Daten in Transit (TLS 1.3). b. Verwenden Sie einen verwalteten KMS (AWS KMS, GCP KMS) für die Schlüsselverwaltung. c. Verbessern Sie IAM mit RBAC, ABAC und SAML/OIDC für Enterprise-SSO. 3. Kostenoptimierung: a. Bewerten Sie eine spal tenorientierte Multi-Tenant-DB (z.B. Snowflake) vs. Sharding bei großem Umfang. b. Verwenden Sie reservierte Instanzen für App-Server, Spot-Instanzen für unkritische Workloads. c. Implementieren Sie proaktives Monitoring und Rightsizing, um Überbereitstellung zu vermeiden. 4. Proof of Concept (PoC): Führen Sie vor der vollständigen Implementierung einen PoC mit einer Simulation im großen Maßstab durch: a. Testen Sie Sharding-DB vs. optimierte Multi-Tenant-DB auf Kosten und Leistung. b. Belastungstest der App-Ebene mit simulierten Enterprise-Verkehrsspitzen. c. Durchführung eines externen Sicherheitsaudits mit Schwerpunkt auf Datenisolierung und Zugriffskontrolle. Mit diesen Verbesserungen wird unsere Multi-Tenancy-Strategie Enterprise-tauglich sein: skalierbar, sicher und kosteneffizient. Der PoC wird unsere Designentscheidungen validieren und unseren Enterprise-Kunden Vertrauen einflößen. |
Prompt 3
| Rolle | Inhalt |
|---|---|
| Benutzer | Bewerten Sie dieses Strategieüberprüfungsdokument hinsichtlich Klarheit, Umsetzbarkeit und Ausrichtung an den Prioritäten des Unternehmens. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistent | 1. Klarheit: A + Klare Struktur mit Zusammenfassung, detaillierter Analyse und Empfehlungen. + Analyse verwendet ein Bewertungssystem (B+, B-) für schnelles Erfassen von Stärken/Schwächen. + Technische Begriffe (RBAC, ABAC, TLS) werden erklärt oder in einen Kontext gestellt, was nicht-technischen Führungskräften hilft. + Visuelle Hilfsmittel (Aufzählungspunkte, Einrückungen) verbessern die Lesbarkeit. 2. Umsetzbarkeit: A- + Empfehlungen sind spezifisch und technisch (z.B. “Implementieren Sie Auto-Scaling mit Kubernetes”). + PoC-Plan mit klaren Zielen bietet einen Fahrplan. + Fehlend: Zeitpläne, Ressourcenanforderungen oder Teamzuweisungen für jede Empfehlung. + Zu erwägen: Fügen Sie einen Abschnitt “Nächste Schritte” mit sofortigen Maßnahmen, Rollen und einem groben Zeitplan hinzu. 3. Ausrichtung an Unternehmenszielen: A+ + Geht direkt auf die Prioritäten des Unternehmens ein: - Skalierbarkeit: Diskutiert die Bewältigung von Enterprise-Verkehrsspitzen. - Sicherheit: Konzentriert sich auf Datenisolierung, Verschlüsselung und Enterprise-IAM. - Kosten: Strategien entsprechen Enterprise-FinOps (reservierte Instanzen, Rightsizing). + PoC mit “Simulation im großen Maßstab” und Sicherheitsaudit zeigt Engagement für Enterprise-Qualität. + Sprache spricht Enterprise-Anliegen an: “inakzeptables Risiko”, “Enterprise-tauglich”, “Vertrauen einflößen”. Insgesamt überzeugt das Dokument durch Klarheit und Ausrichtung auf das Unternehmen. Die Umsetzbarkeit ist stark, könnte aber mit einem Abschnitt “Nächste Schritte” auf A+ angehoben werden. Die technische Tiefe, gepaart mit klaren Erklärungen, macht es sowohl für technische als auch für nicht-technische Führungskräfte sehr effektiv. Gute Arbeit! |
Prompt-Bibliothek
Lassen Sie sich von einer kuratierten Auswahl an Prompts für verschiedene Aufgaben und Anwendungsfälle inspirieren.
GitHub Prompting Tutorial
Ein Beispiel-gefülltes Tutorial, das die Prompt-Engineering-Konzepte aus unserer Dokumentation abdeckt.
Google Sheets Prompting Tutorial
Eine leichtgewichtigere Version unseres Prompt-Engineering-Tutorials über ein interaktives Spreadsheet.