Zum Hauptinhalt springen

Was sind Playbooks?

Playbooks sind einfach zu teilende, wiederverwendbare Prompts für wiederkehrende Aufgaben

Ein Playbook ist wie ein benutzerdefinierter System-Prompt für eine wiederkehrende Aufgabe. Wenn du zum Beispiel viele verschiedene Devin-Sitzungen brauchst, in denen jeweils dieselbe Bibliothek eines Drittanbieters integriert wird – aber in unterschiedlichen Teilen deiner Anwendung –, möchtest du möglicherweise ein Playbook verwenden. Playbooks sind außerdem leicht zu teilen und wiederzuverwenden. Sobald jemand mit Devin Erfolg hat, können andere diesen Erfolg viel einfacher reproduzieren.
Die meisten Best Practices, Styleguides oder anderen projektspezifischen Anweisungen sollten über Knowledge mit Devin geteilt werden. Wir empfehlen, die Dokumentation zu Knowledge zu lesen, bevor du Playbooks erstellst, um zu verstehen, welche Methode besser zu deinen Anforderungen passt.
Devin
Wir empfehlen den Einsatz von Playbooks, wenn:
  • Du oder deine Teammitglieder den Prompt in mehreren Sitzungen wiederverwenden werdet.
  • Du feststellst, dass du Devin dieselben Hinweise immer wieder gibst.
  • Der Anwendungsfall für andere relevant sein könnte – in deinem Unternehmen oder in der Devin-Community.

Erste Schritte mit Playbooks

Playbooks können Devins Fähigkeiten in vielen Bereichen sofort nutzbar machen, erfordern heute jedoch noch einiges an Können beim Schreiben. Ähnlich wie beim Prompt-Engineering erfordert das Schreiben von Playbooks Ausprobieren und Iteration. Das Ergebnis dieser Arbeit ist jedoch ein Dokument, das Devin in die Lage versetzt, komplexe Aufgaben eigenständig zu übernehmen – vom Einlesen von Daten in Redshift und der Durchführung von Datenbankmigrationen bis hin zur Nutzung unterschiedlichster Software und APIs, z. B. Together, Plaid, Stripe, Modal, Springboot, Odoo und Storybook.
Überlege dir für dein erstes Playbook eine einfache, mehrstufige Aufgabe, die Devin für dich übernehmen soll.
  1. Erstelle ein Dokument, das Folgendes beschreibt:
    1. Das Ergebnis, das Devin erreichen soll
    2. Die dafür nötigen Schritte
  2. Optional: Füge Abschnitte wie Procedure, Specifications, Advice, Forbidden Actions oder Required from User hinzu
    1. Procedure: Skizziere den gesamten Umfang der Aufgabe. Füge mindestens einen Schritt für das Setup, die eigentliche Aufgabe und die Auslieferung hinzu.
    2. Specifications: Beschreibe die Postconditions – was soll wahr sein, nachdem Devin fertig ist?
    3. Advice: Füge Hinweise hinzu, um Devins Vorannahmen zu korrigieren
    4. Forbidden Actions: Nenne alle Aktionen, die Devin auf keinen Fall ausführen darf
    5. Required from User: Beschreibe alle Eingaben oder Informationen, die von dir benötigt werden
  3. Erstelle das Playbook direkt in der Web-App, indem du auf „Create a new Playbook“ klickst. Alternativ kannst du eine Datei mit der Dateiendung .devin.md speichern und sie beim Start einer Devin-Session per Drag-and-drop in die Web-App ziehen.
Devin
Du hast ein Playbook erfolgreich mit einer Session verknüpft, wenn ein blaues Pill-Element erscheint und zusätzlich eine Inline-Komponente zum Bearbeiten des Playbooks angezeigt wird, bevor du deine Session startest.
Devin

Ein großartiges Playbook schreiben

Vorgehen

Der Abschnitt „Vorgehen“ sollte …
  • einen Schritt pro Zeile haben, jeder Schritt im Imperativ formuliert
  • den gesamten Umfang der Aufgabe abdecken
  • mindestens einen Schritt für Setup, die eigentliche Aufgabe und die Übergabe/Ergebnisse enthalten
  • darauf abzielen, die Schritte gegenseitig ausschließend und vollständig abdeckend zu gestalten
  • Zusätzliche Tipps
    • Vorgehensbeschreibungen sollten dir helfen, die Reihenfolge von Devins Aktionen zu definieren – ähnlich wie if/else/Schleifen/goto im Code
    • Mach Aufgaben nicht zu spezifisch, es sei denn, es ist wirklich nötig; das kann Devins Fähigkeit zur Problemlösung einschränken
    • Jeder Schritt im Vorgehen sollte ein Tätigkeitsverb enthalten – z. B. Schreiben, Navigiere zu etc.

Ratschläge und Hinweise

Geben Sie Devin Ratschläge und Hinweise, wenn …
  • Sie eine bevorzugte Vorgehensweise zur Erledigung der Aufgaben haben
  • die Hinweise für die gesamte Aufgabe oder für mehrere Schritte gelten. Hinweise, die nur für einen Schritt gelten, sollten direkt bei diesem Schritt stehen (z. B. als Unterpunkt)
  • Sie Devins Vorannahmen korrigieren. Hinweise können wie Kommentare zu Pseudocode wirken, die dessen Ausführung beeinflussen.
Wenn sich ein Hinweis nur auf einen einzelnen Procedure-Schritt bezieht, schreiben Sie ihn unter diesen Schritt und verwenden Sie dafür verschachtelte Aufzählungspunkte

Spezifikationen

Der Abschnitt Spezifikationen kann hilfreich sein, um die Postconditions (Abschlussbedingungen) des Playbooks zu beschreiben — was soll gelten, wenn Devin fertig ist?

Was von Nutzerseite benötigt wird

Denken Sie an alles, was erforderlich ist, aber außerhalb von Devins Kontrolle liegt. Zum Beispiel, wenn Sie ein Token oder Informationen bereitstellen müssen, auf die Devin nicht öffentlich zugreifen kann.

Weitere Tipps + Taktiken

  • Führen Sie 2+ Devins parallel mit demselben Playbook aus, um mögliche Fehler schnell zu identifizieren.
  • Wenn Devin Hilfe braucht, chatten Sie mit ihm, um es zu unterstützen. Ergänzen Sie anschließend Ihr Playbook, damit Devin beim nächsten Mal ohne Eingriff erfolgreich ist.
Beschreiben Sie klar, was das Ergebnis sein soll und wie Devin kommunizieren soll, dass es fertig ist (z. B. welche Dateien angehängt oder welche Links geteilt werden sollen, falls zutreffend).
Erkunden Sie die verschiedenen Entscheidungen, die Devin treffen kann, und führen Sie Devin auf dem effizientesten Pfad durch das Playbook.
  • Sie können den Unterschied zwischen einem funktionierenden und einem fehlerhaften Playbook ausmachen.
  • Zum Beispiel kann Folgendes ein sehr wichtiges Detail sein, weil alloy und tts-1 vermutlich nicht die Optionen wären, die Devin von sich aus wählen würde – und dies lenkt Devin in eine Richtung, in der der Erfolg wahrscheinlicher ist!
3. Create request dict with model: "tts-1", voice: "alloy"

Beispiel-Playbook

Beispielsitzungen mit dem folgenden Playbook kannst du hier und hier ansehen.
R Data Science Tutorial
Playbook: R Data Science Tutorial

## Überblick
Erstelle ein Data-Science-Tutorial mit einem R-Markdown-Notebook.

## Vom Benutzer benötigte Informationen
- Link zu einem Datensatz (CSV-Dateianhang oder Kaggle-Link)
- Konkrete Aufgabe, für die ein Data-Science-Tutorial erstellt werden soll

## Vorgehen
1. Lade den vom Benutzer bereitgestellten Datensatz herunter.
-  Falls nötig, lade den Datensatz mit der Kaggle CLI herunter – du benötigst dafür keine Anmeldedaten.
2. Erstelle ein R-Markdown-Notebook mit dem Titel `data_science_tutorial.Rmd`.
3. Erstelle eine Datei `tmp.Rmd` zum Schreiben und Speichern von Zwischenständen des Codes.
4. Erstelle 5 Hauptabschnitte in der Datei `data_science_tutorial.Rmd` und füge Code aus der Datei `tmp.Rmd` hinzu, der Folgendes enthält:
- Datensatzstatistiken. Erzeuge eine statistische Zusammenfassung des Datensatzes.
- EDA (Exploratory Data Analysis). Erstelle ein Balkendiagramm und ein Streudiagramm für die bereitgestellten Daten.
- Train-Test-Split. Teile die Daten im Verhältnis 80:20 auf. Speichere die Trainings- und Testdaten.
- Training des Machine-Learning-Modells. Speichere das Modell nach dem Training.
- Inferenz mit dem gespeicherten Modell. Lade das gespeicherte Modell und bewerte seine Leistung auf dem Testdatensatz mit der vom Benutzer angegebenen Metrik.
5. Wenn der Code fertig ist, füge für jeden Abschnitt eine kurze Erklärung hinzu.
6. Konvertiere das R-Markdown-Notebook in das HTML-Format.
7. Sende das finale R-Markdown-Notebook, die HTML-Datei, das gespeicherte Modell und die Testdaten an den Benutzer.

## Spezifikationen
1. Sende das R-Markdown-Notebook und die HTML-Datei an den Benutzer.
2. Sende das gespeicherte Modell und die Testdaten an den Benutzer.

## Hinweise und Tipps
1. Installiere Pakete nicht erneut, wenn sie bereits installiert sind.
2. Eine Anmeldung bei RStudio ist nicht erforderlich, um diese Aufgabe abzuschließen.
3. Führe das gesamte Notebook aus, nachdem du für jeden Abschnitt den Code hinzugefügt hast.

## Verbotene Aktionen
1. Überschreibe die Datei `data_science_tutorial.Rmd` nicht.