Erste Schritte
Modelle & Preise
Funktionen erkunden
Über Claude erfahren
- Mit Claude entwickeln
- Anwendungsfälle
- Kontextfenster
- Glossar
- Prompt-Engineering
- Überblick
- Claude 4 Best Practices
- Prompt-Generator
- Prompt-Vorlagen verwenden
- Prompt-Verbesserer
- Sei klar und direkt
- Beispiele verwenden (Multishot-Prompting) um Claudes Verhalten zu steuern
- Claude denken lassen (CoT)
- XML-Tags verwenden
- Claude eine Rolle zuweisen (System-Prompts)
- Claudes Antwort vorfüllen
- Komplexe Prompts verketten
- Tipps für langen Kontext
- Tipps für erweitertes Denken
Testen & evaluieren
- Erfolgskriterien definieren
- Testfälle entwickeln
- Schutzmechanismen verstärken
- Verwendung des Evaluierungstools
Rechtliches Zentrum
Agent-Komponenten
- Werkzeuge
- Model Context Protocol (MCP)
- Computernutzung (Beta)
- Google Sheets Add-on
Komplexe Prompts für bessere Leistung verketten
While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.
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 Chaining 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 Chaining für mehrstufige Aufgaben wie Forschungssynthese, Dokumentenanalyse oder iterative Inhaltserstellung. Wenn eine Aufgabe mehrere Transformationen, Zitate oder Anweisungen beinhaltet, verhindert Verkettung, dass Claude Schritte auslässt oder falsch handhabt.
Denken Sie daran: Jedes Glied in der Kette erhält Claudes volle Aufmerksamkeit!
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 Einzelaufgaben-Ziel 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-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.
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 Gewichtsabnahme 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 Forschungspapier-Zusammenfassung 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 fehlende schwerwiegende 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. Erste Verwendung ausschreiben empfohlen. 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+ Akronyme definieren, Gruppen-Baseline-Statistiken erwähnen, sekundäre Ergebnisse notieren und kurz auf den Bedarf an Langzeitstudien eingehen. |
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. Der primäre Endpunkt der 24-wöchigen Studie war 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 bei beiden Behandlungen. Klinische Implikationen: Der GLP-1/GIP-Dualagonist zeigt überlegene Blutzuckerkontrolle und Gewichtsabnahme 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 Langzeitstudien erforderlich, um die anhaltende Wirksamkeit und Sicherheit zu bestätigen sowie mögliche Vorteile auf 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 Dienstleistungserbringung 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. |
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 Dienstleistungserbringung. 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. |
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 Mandant reduziert Konflikte, unterstützt hohes Wachstum. + Microservices ermöglichen unabhängige Skalierung von Komponenten. - Gemeinsame App-Server könnten bei extremer Last zum Engpass werden. - Keine Erwähnung von Auto-Scaling oder Load Balancing für App-Tier. 2. Sicherheit: + Mandanten-Datenisolierung durch Sharding mindert Datenlecks. + JWT mit kurzer Gültigkeit und Refresh-Tokens ist Branchenstandard. - Keine Erwähnung von Verschlüsselung (ruhend, in Transit) oder Schlüsselverwaltung. - IAM-Strategie mangelt an 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 Skalierung erhöhen vs. optimierte Multi-Tenant-DB. - Keine Diskussion von reservierten Instanzen oder Spot-Instanzen für Kosteneinsparung. |
Prompt 2
Rolle | Inhalt |
---|---|
User | Erstellen Sie ein Strategieüberprüfungsdokument für die technische Leitung 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-Skalierung, mangelt aber an robuster App-Tier-Skalierung und fortgeschrittenen Sicherheitsmaßnahmen. Kostenoptimierungen sind vorhanden, könnten aber bei hoher Skalierung versagen. 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 exzellent. Es minimiert Query-Latenz, unterstützt hohes Datenwachstum und ermöglicht nahtlose Pro-Mandant-Skalierung. - Microservices-Architektur erlaubt Skalierung einzelner Komponenten basierend auf Bedarf, entscheidend für diverse Enterprise-Workloads. Schwächen: - Gemeinsame Applikationsserver riskieren, zum Engpass zu werden. Mit wachsender Mandantenzahl und Traffic könnte die Performance aller Mandanten leiden. - 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 Mandanten-Datenisolierung, mindern Risiken von Datenlecks oder unberechtigtem Zugriff zwischen Mandanten. - 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 Transit (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 mangelt an Tiefe. Wir benötigen RBAC mit wohldefinierten 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-Mandant-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 reservierte Instanzen für vorhersehbare Workloads oder Spot-Instanzen 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 Verfügbarkeitszonen mit CDN für statische Assets. 2. Sicherheitshärtung: a. Verschlüsseln Sie Daten in Ruhe (AES-256) und Transit (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 spaltenorientierte Multi-Tenant-DB (z.B. Snowflake) vs. Sharding bei Skalierung. b. Nutzen Sie reservierte Instanzen für App-Server, Spot-Instanzen 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 Hochskalierungs-Simulation 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 Sicherheitsaudit durch Dritte durch, fokussiert auf Datenisolierung und Zugriffskontrolle. Mit diesen Verbesserungen wird unsere Multi-Tenancy-Strategie Enterprise-Grade sein: skalierbar, sicher und kosteneffektiv. Der PoC wird unsere Design-Entscheidungen validieren und Vertrauen bei unseren Enterprise-Kunden schaffen. |
Prompt 3
Rolle | Inhalt |
---|---|
User | Bewerten Sie dieses Strategieüberprüfungsdokument hinsichtlich Klarheit, Umsetzbarkeit und Ausrichtung auf Enterprise-Prioritäten. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
Assistant | 1. Klarheit: A + Klare Struktur mit Executive Summary, Detaillierter Analyse und Empfehlungen. + Analyse verwendet Notensystem (B+, B-) für schnelles Erfassen von Stärken/Schwächen. + Technische Begriffe (RBAC, ABAC, TLS) werden erklärt oder kontextualisiert, unterstützt nicht-technische Führungskräfte. + Visuelle Hilfen (Aufzählungspunkte, Einrückung) verbessern Lesbarkeit. 2. Umsetzbarkeit: A- + Empfehlungen sind spezifisch und technisch (z.B. “Implementieren Sie Auto-Scaling mit Kubernetes”). + PoC-Plan mit klaren Zielen bietet Fahrplan. - Fehlend: Zeitpläne, Ressourcenanforderungen oder Team-Zuweisungen für jede Empfehlung. + Vorschlag: Fügen Sie einen “Nächste Schritte” Abschnitt mit unmittelbaren Aktionen, Rollen und grober Zeitplanung hinzu. 3. Enterprise-Ausrichtung: A+ + Adressiert Enterprise-Prioritäten direkt: - Skalierbarkeit: Diskutiert Handhabung von Enterprise-Level Traffic-Spitzen. - Sicherheit: Fokussiert auf Datenisolierung, Verschlüsselung und Enterprise IAM. - Kosten: Strategien entsprechen Enterprise FinOps (reservierte Instanzen, Right-Sizing). + PoC mit “Hochskalierungs-Simulation” und Sicherheitsaudit zeigt Engagement für Enterprise-Grade Qualität. + Sprache resoniert mit Enterprise-Bedenken: “inakzeptables Risiko”, “Enterprise-Grade”, “Vertrauen schaffen”. Insgesamt überzeugt das Dokument in Klarheit und Enterprise-Ausrichtung. Die Umsetzbarkeit ist stark, könnte aber mit einem “Nächste Schritte” Abschnitt auf A+ gehoben werden. Die technische Tiefe, gepaart mit klaren Erklärungen, macht es hocheffektiv für technische und nicht-technische Führungskräfte. Hervorragende Arbeit! |
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.
Was this page helpful?