Warum ein Prompt-Enhancer mehr ist als "Text umformulieren"

Ein Prompt-Enhancer klingt nach einem kleinen Komfort-Feature: ein bisschen Text rein, ein bisschen bessere Formulierung raus. In der Praxis ist das aber derselbe Fehler wie beim „Bild verbessern“-Button: außen wirkt es trivial, innen ist es eine Kette aus Sicherheits- und Produktentscheidungen. Und sobald wir echte Nutzer drauflassen, wird aus „nice to have“ sehr schnell ein Kosten-, Abuse- und UX-Thema.

In diesem Artikel zeige ich dir, warum wir den Prompt-Enhancer wie ein Produktfeature bauen (mit klaren Grenzen) – und warum wir dabei ganz bewusst konkrete Modelle wie OpenAI gpt-4o-mini einsetzen, aber sie trotzdem austauschbar halten.

Hook: „Mach den Prompt besser“ ist keine harmlose Bitte

Der typische Start ist unschuldig: „Kannst du das bitte klarer formulieren?“ Oder: „Mach daraus einen Prompt, der wirklich gute Ergebnisse liefert.“

Was dabei oft übersehen wird: Sobald wir so einen Enhancer öffentlich anbieten, sind wir plötzlich verantwortlich für Dinge, die sonst im Schatten passieren:

• Kostenkontrolle: jeder Request ist ein bezahlter LLM-Call.

• Abuse-Prevention: eine offene Textbox ist ein Magnet für Spam, Prompt-Injection, „Free LLM“-Missbrauch.

• Sicherheit: Prompts können PII enthalten – und Logs sind sonst plötzlich ein Datenleck.

Ein Prompt-Enhancer ist damit weniger „Text-Tool“ und mehr „Mini-Produkt“: mit klarer API, Limits und Fehlerformen.

Kontext: Warum wir überhaupt einen Enhancer brauchen

Die meisten Prompt-Probleme sind keine „AI-Probleme“. Sie sind Kommunikationsprobleme: Ziel unklar, Constraints fehlen, Output-Format ist nicht definiert, Beispiele fehlen.

Wenn wir Nutzer damit allein lassen, sehen wir immer dieselben Symptome:

• „Die AI versteht mich nicht“ (eigentlich: Prompt ist zu vage).

• „Die Antwort ist zu lang/zu kurz“ (eigentlich: Output-Format/Scope fehlt).

• „Mal klappt’s, mal nicht“ (eigentlich: keine Constraints, keine Beispiele, keine Struktur).

Ein Enhancer soll nicht „magisch“ sein. Er soll den Nutzer zwingen, expliziter zu werden – und das Ergebnis so strukturieren, dass es verlässlich mit modernen Modellen funktioniert.

Optionen: Von „schnell“ zu „robust“

Option 1: Client-only (direkt gegen OpenAI im Browser)

Das klingt nach maximaler Geschwindigkeit: Frontend ruft OpenAI direkt auf, fertig.

Aber das scheitert sofort an zwei Dingen:

• Secrets: Ein API-Key gehört nicht in den Client.

• Kosten/Abuse: Ohne serverseitige Limits ist das ein offener Kostenhahn.

Option 2: Dünner Proxy (einfach weiterleiten)

Ein einzelner Endpoint nimmt Text an und leitet ihn blind an OpenAI weiter. Das löst das Key-Problem, aber nicht die Produktprobleme.

Du bekommst dann schnell Wildwuchs: jedes neue Feature (Attachments, Vision, PDF) klebt neue Sonderlogik an die Route – und Limits/Fehlerformen driften auseinander.

Option 3: Service-Layer mit klaren Guardrails (unsere Wahl)

Wir behandeln den Prompt-Enhancer wie die anderen Tools: zentraler Service, klare Eingabevalidierung, Rate-Limits, Quoten, konsistente Error-Shapes und redacted Logging.

Entscheidung: Wir nennen die Modelle – aber wir binden uns nicht daran fest

Konkretheit hilft. Deshalb ist es sinnvoll, dass wir im Betrieb klar sagen können: Wir nutzen aktuell OpenAI gpt-4o-mini als Default – getrennt für Text und Vision. Aber: Wir bauen die Schnittstelle so, dass wir Modellnamen per Env tauschen können, ohne das Frontend neu zu erfinden.

• Textmodell via PROMPT_TEXT_MODEL (Default: gpt-4o-mini)

• Visionmodell via PROMPT_VISION_MODEL (Default: gpt-4o-mini)

Implementierung (high level): Was im Backend wirklich passiert

Der Prompt-Enhancer hängt bei uns nicht am UI, sondern am Backend-Service. Der Einstieg ist ein API-Endpoint, der Form-Data (für Files) oder JSON akzeptiert.

1) Validierung & Limits vor dem ersten Token

Bevor wir OpenAI überhaupt aufrufen, validieren wir den Input strikt (Zod). Dazu gehören auch Upload-Regeln (max. Anzahl/Größe/Typen).

Dann kommt der Teil, der in vielen Projekten fehlt: Rate-Limits + Quoten. Der Endpoint ist rate-limited (15/min) und wir tracken Usage serverseitig (Guest/User), damit aus einem Demo-Feature kein Kostenproblem wird.

2) OpenAI Call: Chat Completions vs. Responses API (file_search)

Wir nutzen OpenAI nicht „einfach so“, sondern wählen den Pfad abhängig von Attachments:

• Ohne PDFs: Chat Completions (und optional Vision über image_url).

• Mit PDFs (ohne Images): Responses API + tools=file_search. PDFs werden hochgeladen und als attachments referenziert.

3) Parameter: bewusst klein, bewusst vorhersehbar

Wir fahren konservative Defaults, die man in der Produktion erklären kann:

• max output tokens: PROMPT_OUTPUT_TOKENS_MAX=400

• temperature: PROMPT_TEMPERATURE=0.2

• top_p: PROMPT_TOP_P=0.9

4) Fehlerformen: nicht „irgendwas ging schief“, sondern nachvollziehbar

Provider-Fehler mappen wir auf unsere Standards (validation_error / forbidden / server_error). Das ist wichtig, weil ein Prompt-Tool ohne gute Fehlertexte nur frustriert: der Nutzer lernt nichts.

Beispiel: Aus Rohtext wird ein Agent Prompt (Role / Objective / Constraints / Steps)

Ein gutes Beispiel zeigt schneller als tausend Prinzipien, was der Enhancer tatsächlich tut. Stell dir vor, ein Nutzer schreibt (Rohtext):

„Mach mir bitte einen Prompt, damit ein Assistent unsere Website analysiert und konkrete SEO-Verbesserungen vorschlägt. Fokus: Performance und interne Links. Bitte als klare Schritt-für-Schritt Anleitung.“

Nach dem Enhancer kommt daraus eine Agent-Spezifikation, die ein Modell viel stabiler ausführen kann (vereinfacht dargestellt):

Role

Du bist ein senior SEO- und Performance-Analyst. Du lieferst konkrete, priorisierte Empfehlungen mit Begründung und klaren Umsetzungsschritten.

Objective

Analysiere die Website (Input: URL), identifiziere die wichtigsten Performance- und Internal-Linking-Probleme und liefere einen umsetzbaren Plan mit Quick Wins und strukturellen Maßnahmen.

Constraints

• Keine erfundenen Messwerte oder Lighthouse-Scores, wenn keine Daten vorhanden sind.

• Empfehlungen müssen priorisiert sein (Impact/Arbeitsaufwand).

• Fokus auf Performance (LCP/CLS/TBT) und interne Verlinkung; keine Off-Topic SEO-Debatten.

Steps

1. Frage nach der Ziel-URL und dem bevorzugten Device-Fokus (Mobile/Desktop), falls nicht angegeben.

2. Analysiere typische Performance-Treiber: Bildgrößen, Render-Blocking, Caching, JS-Bundle, Third-Party Scripts.

3. Prüfe Internal-Linking Muster: Navigation, Footer, Related Content, Orphan Pages, Link-Texte.

4. Gib eine priorisierte Liste von Maßnahmen aus (Quick Wins → größere Umbauten) inkl. kurzer Begründung.

Das ist der Kern: Wir verwandeln „Wunschtext“ in ausführbare Spezifikation. Das Modell wird dadurch nicht klüger – aber die Aufgabe wird klarer, testbarer und weniger zufällig.

Warum ich hier Replicate erwähne (und was wir davon lernen)

Replicate ist für uns ein gutes Gegenbeispiel, weil es zeigt, wie unterschiedlich „Modell-Strategie“ sein kann:

• Im AI Image Enhancer allowlisten wir Modelle und pinnen teils exakte Versionen, z. B. nightmareai/real-esrgan:42fed1c4974146d4d2414e2be2c5277c7fcf05fcc3a73abf41610695738c1d7b oder tencentarc/gfpgan:0fbacf7afc6c144e5be9767cff80f25aff23e52b0708f17e20f9879b2f21516c.

• Für einmalige Generierung/Assets nutzen wir bewusst latest, z. B. black-forest-labs/flux-1.1-pro, weil Aktualität wichtiger ist als 100% Reproduzierbarkeit.

Genau diese Entscheidung (pin vs latest) ist auch bei OpenAI relevant: Wenn wir Modellnamen hart in Code zementieren, verlieren wir Beweglichkeit. Wenn wir alles offen lassen, verlieren wir Kontrolle. Env-getrieben ist der Mittelweg.

Learnings: Prompt-Qualität ist UX – Guardrails sind der Preis für Stabilität

• Ein Prompt-Enhancer ist kein „Textfilter“. Er ist ein System, das Erwartungen managt (Format, Constraints, Beispiele).

• Ohne Rate-Limits/Quoten ist jedes AI-Feature kurzfristig – weil es irgendwann zu teuer wird.

• Modelle darf man nennen (wir nutzen aktuell gpt-4o-mini), aber die Architektur sollte nicht am Modell kleben.

Ausblick: Was als nächstes kommt

Der Prompt-Enhancer ist für uns der nächste Baustein in der AI-Story: dieselben Prinzipien (Validierung, Limits, klare Fehlerformen, austauschbare Provider) tauchen überall wieder auf – bei Webscraper, Web-Eval, Video und Voice.

Als nächstes können wir optional ein Hero Image für A2 generieren (analog zu A1/B1) – und danach geht’s weiter mit C1 (Webscraper).