Zugang anfragen

Anwendungsfall · Entwickler

Prompts im Review, wie der Rest deines Codes.

Wenn ein Prompt bestimmt, was dein Produkt sagt, braucht er einen Verlauf, einen Test und einen Verantwortlichen.

support-reply.promptv2 → v3
committed to main as v3

Ein Workflow, der sich vertraut anfühlt.

  1. Halte den Prompt aus dem Code heraus

    Speichere ihn in Prompt Verse mit {{Variablen}}. Dein Code fragt nach den gerenderten Nachrichten, nicht nach einem hineinkopierten String.

  2. Branche für ein Experiment

    Probier eine neue Formulierung auf einem Branch. Main liefert weiter die genutzte Version.

  3. Beweise es mit einem Eval

    Ein paar Dutzend Fälle, eine Bewertungsmethode und ein Schwellenwert. Eine Änderung, die die Bewertung senkt, wird nicht gemergt.

  4. Tagge, was ausgeliefert wird

    Tagge die Version, die bestanden hat. Dein Dienst ruft diesen Tag ab.

Was du konkret bekommst.

  • Commits mit Nachrichten

    Ein prüfbarer Verlauf statt „prompt_final_v7“.

  • Nachrichten und JSON als Ausgabe

    Als Chat-Nachrichten, JSON, YAML, XML oder Prompty rendern.

  • Eine Tür für deine Agenten

    Dein Coding-Assistent kann Prompts über MCP lesen und verbessern.

Sag klar, wo die Grenzen liegen.

  • Vor der Beta
    Abruf zur Laufzeit

    Eine HTTP-API und ein MCP-Server gibt es in der Pre-Beta. Prüf die Routen in der Referenz, bevor du dich darauf verlässt.

  • Nicht angeboten
    Noch kein SDK

    Es gibt keine Client-Bibliotheken. Du rufst die HTTP-API oder MCP direkt auf.

Stell deine Prompts unter Versionskontrolle.