Grok 4.7 Prompt-Sammlung: 5 Szenarien zum direkten Kopieren

TL;DR: 5 Szenarien, alle mit grok-4.7 in der HiAPI-Produktionsumgebung tatsächlich ausgeführt, Ausgaben im Originalwortlaut. Kosten pro Aufruf: $0,007–0,021, alle 5 zusammen etwa $0,06. Die Links unter jedem Prompt füllen beim Klick denselben Prompt automatisch in die Modellseite ein – senden und reproduzieren. Grok 4.7 ist auf HiAPI verfügbar, Modellseite öffnen und direkt ausprobieren; neue Nutzer erhalten bei der Registrierung 200 Credits.

Szenario 1: Hängende Nebenläufigkeit diagnostizieren

Die Grundursache ist, dass das Response-Objekt nicht freigegeben wird und die Verbindung dauerhaft einen Slot im Connector-Pool belegt.

Das von session.get() zurückgegebene ClientResponse gibt die Verbindung erst an den TCPConnector zurück, wenn release() / close() aufgerufen wird (oder der asynchrone Kontextmanager verlassen wird). Die aktuelle Schreibweise hat weder async with noch ein explizites release(). Das Auslesen des Bodys gibt die Verbindung nicht zurück; zwischen Response und Connection besteht zudem eine zirkuläre Referenz, sodass die Freigabe erst beim __del__ der zyklischen GC erfolgt.

Standardmäßig beträgt das Verbindungslimit pro ClientSession 100. 20 Worker halten je eine Session und senden seriell Anfragen, jeder Worker verarbeitet etwa 250 URLs. Wenn Verbindungen nicht zurückgegeben werden:

1. Belegte Verbindungen werden durch das Idle-Timeout des Servers oder das Verbindungslimit per RST zurückgesetzt; aiohttp wirft auf Protokollebene ConnectionResetError (nicht unbedingt aus deinem await, daher kann except sie weder abfangen noch bereinigen).
2. Der Slot bleibt belegt. Nach 100 blockiert der nächste session.get() in connector.acquire(), und dieses Warten unterliegt oft keinem Timeout.
3. Alle Worker hängen in acquire, rufen weder queue.get() noch task_done() auf. Auf dem Event-Loop gibt es keine neuen Allokationen, die zyklische GC läuft nicht mehr, __del__ kann die Verbindungen nicht einsammeln – es entsteht ein Deadlock. Auch queue.join() wartet ewig.

except Exception: pass schluckt nur Ausnahmen in der Nutzer-Coroutine, gibt aber keine Verbindungen frei, daher treten „Fehler“ und „Hänger“ gemeinsam auf.

Minimale Änderung:

async def fetch(url, session):
    async with session.get(url) as r:
        return await r.json()

async with durchläuft auf beiden Pfaden – normaler Rückgabe und Ausnahme – __aexit__ → release():

• Die Verbindung geht sofort in den Pool zurück, Slots sammeln sich nicht bis 100 an, session.get() blockiert nicht mehr dauerhaft in acquire, Worker können die Queue weiter konsumieren. Das behebt den Hänger.
• Verbindungen belegen nicht mehr lange und warten auf ein RST des Servers, der ConnectionResetError auf Protokollebene verschwindet ebenfalls; selbst wenn beim Lesen des Bodys tatsächlich die Verbindung abbricht, gibt der Kontextmanager diese Verbindung zurück/schließt sie – ein Fehlschlag legt den Pool nicht lahm. Das behebt den Fehler und stellt sicher, dass die Queue nach dem Fehler weiterläuft.

Vollständiger Prompt:

Der folgende Python-Code zeigt bei etwas höherer Nebenläufigkeit zufällig ConnectionResetError, danach hängt der gesamte Worker und konsumiert die Queue nicht mehr. Bitte finde die Grundursache, gib eine Reparatur mit minimaler Änderung an und erkläre, warum deine Reparatur sowohl das „Fehler“- als auch das „Hänger“-Problem gleichzeitig löst.

```python
import asyncio, aiohttp

async def fetch(url, session):
    r = await session.get(url)
    return await r.json()

async def worker(queue):
    session = aiohttp.ClientSession()
    while True:
        url = await queue.get()
        try:
            data = await fetch(url, session)
            print(data)
        except Exception:
            pass
        queue.task_done()

async def main():
    queue = asyncio.Queue()
    for i in range(5000):
        queue.put_nowait(f"https://api.example.com/item/{i}")
    workers = [asyncio.create_task(worker(queue)) for _ in range(20)]
    await queue.join()

asyncio.run(main())
```

Mit diesem Prompt generieren →

grok-4.7, standardmäßig high-Reasoning-Stufe, max_tokens auf 6000 begrenzt, tatsächliche Laufzeit 107,7 s, Eingabe 3.572 / Ausgabe 7.301 Tokens, ca. $0,021.

Wenn du Symptome, Code und die Vorgabe „beide Probleme müssen zugleich erklärt werden“ auf einmal vollständig angibst, lokalisiert das Modell die Grundursache auf Ebene des Verbindungspools, statt oberflächlich try-catch zu ändern.

Szenario 2: Code-Review mit JSON-Ausgabe

{"issues":[{"severity":"high","line":8,"problem":"Guthabenprüfung und Abbuchung sind getrennt, es gibt eine TOCTOU-Race-Condition: nebenläufige Anfragen können gleichzeitig die Guthabenprüfung bestehen und dann doppelt abbuchen, was zu Überziehung oder Double-Spending führt","fix":"Auf eine einzelne bedingte Aktualisierung umstellen (z. B. $inc nur wenn balance>=amount) oder Prüfung und Abbuchung innerhalb einer Transaktion mit Zeilensperre/optimistischer Sperre atomar durchführen"},{"severity":"high","line":9,"problem":"Abbuchung und Gutschrift sind zwei unabhängige Schreiboperationen ohne Transaktion; wenn der erste Schritt erfolgreich ist und der zweite fehlschlägt, verschwindet das Geld von from und kann nicht zurückgerollt werden","fix":"Beide Updates in dieselbe Datenbanktransaktion legen, bei einem Fehlschlag wird alles zurückgerollt, und vor dem Commit prüfen, ob das Zielkonto to existiert"}

,"summary":"Diese Transfer-Schnittstelle entbehrt atomarer Transaktionen, Authentifizierung und Eingabevalidierung; unter Nebenläufigkeit kommt es zu Double-Spending oder Geldverlust, und Ausnahmepfade lassen Anfragen hängen."}

(Auszug: Die Originalausgabe ist ein einzeiliges JSON; die ersten beiden high-Probleme und die summary sind beibehalten, der Rest ist ausgelassen)

Vollständiger Prompt:

Bitte prüfe den folgenden Node.js-Routencode und finde alle Probleme, die zu Produktionsvorfällen führen können (Sicherheit, Nebenläufigkeit, Ressourcenlecks zählen alle), sortiert nach Schweregrad. Gib strikt JSON aus, Format: {"issues": [{"severity": "high|medium|low", "line": Zeilennummer, "problem": "Problem", "fix": "Lösung"}], "summary": "Ein-Satz-Zusammenfassung"}.

```js
const express = require('express');
const db = require('./db');
const router = express.Router();

router.post('/transfer', async (req, res) => {
  const { from, to, amount } = req.body;
  const fromAccount = await db.findOne({ id: from });
  if (fromAccount.balance >= amount) {
    await db.update({ id: from }, { $inc: { balance: -amount } });
    await db.update({ id: to }, { $inc: { balance: amount } });
    res.json({ ok: true });
  } else {
    res.status(400).json({ ok: false });
  }
});

module.exports = router;
```

Mit diesem Prompt generieren →

grok-4.7, standardmäßig high-Reasoning-Stufe, max_tokens auf 4000 begrenzt, tatsächliche Laufzeit 40,1 s, Eingabe 3.576 / Ausgabe 2.734 Tokens, ca. $0,010.

Wenn du im Prompt direkt das gewünschte JSON-Gerüst vorgibst (Feldnamen, Sortierregeln), gibt grok-4.7 strikt das Format aus – direkt in die Pipeline übernehmbar.

Szenario 3: Technische Lösungsalternativen vergleichen

Empfohlen wird „Aktivitäts-Heartbeat + Redis TTL + bedarfsgesteuertes kurzes Polling“, nicht WebSocket/SSE für flächendeckendes Online-Push. Das Ausgrauen nach 5 Minuten braucht kein sekundengenaues Push; bei 100k DAU hält Polling problemlos stand und passt besser zu Next.js.

Lösungsvergleich

	Polling	SSE	WebSocket
Richtung	Client zieht	Server pusht unidirektional	Bidirektional
Passung zu „nach 5 Minuten Inaktivität ausgrauen“	Hoch. Aktualisierung alle 30–60 s reicht für den grünen Punkt	Mittel. Push ist schneller, aber das Ausgrauen bei Timeout muss man selbst berechnen	Niedrig bis mittel. Verbunden ≠ aktiv
Next.js-Eignung	Am besten. Normaler Route Handler	Schlecht. Langverbindungen sind mit Serverless/Multi-Instanz unfreundlich	Am schlechtesten. Braucht eigenen WS-Prozess, Sticky Sessions oder Drittanbieter
Verbindungskosten	Keine Langverbindungen	1 pro online Nutzer	1 pro online Nutzer, plus Heartbeat zur Lebendhaltung
Skalierung	Zustandslos, horizontale Skalierung einfach	Verbindungsabbrüche, Reconnects, Fan-out über mehrere Instanzen müssen verwaltet werden	Wie links, aber aufwendiger
Fehlermodus	Eine Anfrage schlägt fehl, nächster Abruf folgt	Nach Verbindungsabbruch bleibt der Status stehen, Nachladen nötig	Wie links, Gateway komplexer
Lohnt sich bei 100k DAU	Ja, als Standardlösung	Nur wenn bereits ein Push-Kanal existiert	Nur wenn bereits ein Chat-/Kollaborations-Gateway existiert

Grobe Peak-Schätzung: 100k täglich aktive Nutzer, gleichzeitig online geschätzt 5 %–15 %, also etwa 5.000–15.000. Heartbeat alle 45 s ergibt ca. 100–300 Schreibvorgänge/s; jeder ruft alle 30 s den Status der sichtbaren Nutzer ab, auch die Lesevorgänge liegen im komfortablen Bereich von Redis. Der Engpass liegt nicht beim „grünen Punkt“.

Empfehlung und Begründung

Redis als Online-Wahrheit, PostgreSQL nur für das kalte last_seen, der Client pollt nur die aktuell auf dem Bildschirm sichtbaren Nutzer.

1. Die Produktsemantik lautet „5 Minuten ohne Aktivität“, nicht „TCP ist noch verbunden“. Eine Seite, die offen steht und nicht bewegt wird, soll ausgrauen; selbst mit WS braucht man daher einen separaten Aktivitäts-Heartbeat. Die Verbindung allein löst die Anforderung nicht.
2. Der grüne Punkt erlaubt Fehler von einigen Dutzend Sekunden. Ein Polling-Intervall von 30–60 s ist relativ zum 5-Minuten-Fenster ausreichend.
3. Next.js (besonders Vercel / Serverless) eignet sich nicht zum Tragen von Langverbindungen. WS/SSE zieht dich in einen separaten Echtzeitdienst, Sticky Routing und Reconnect-Kompensation hinein, bei geringem Nutzen.
4. Wer wessen Status sehen soll, ist meist lokal (Freunde, Konversationsliste, Avatare der aktuellen Seite), kein siteweites Broadcasting. Batch-Abfrage per id in Redis ist eine Größenordnung einfacher als das Pflegen von Abonnement-Beziehungen.
5. Der Ablauf von Redis-Keys drückt „Timeout offline“ natürlich aus; man braucht keine Keyspace-Notifications oder Tabellenscans.

Benutzerbezogene Anwesenheit als Online (empfohlene Hauptlösung):

```text
presence:u:{userId}   STRING  Wert = Server-Unix-Millisekunden
                      TTL = 300 Sekunden
                      Beim Heartbeat SET key value EX 300
                      Online = Key existiert
```

Keine Client-Zeit verwenden. Die TTL muss nicht 2–3 Mal größer als das Heartbeat-Intervall sein; hier Heartbeat 45–60 s, TTL 300 s – zwei bis drei verlorene Heartbeats gelten noch als online, passend zu „5 Minuten ohne Aktivität“.

(Auszug: Empfehlung und die ersten 5 Begründungen, benutzerbezogene Hauptlösung im Redis-Key-Design)

Vollständiger Prompt:

Ich möchte einer Web-App mit 100k täglich aktiven Nutzern eine „Echtzeit-Online-Status“-Funktion hinzufügen (grüner Punkt neben dem Nutzeravatar, nach 5 Minuten ohne Aktivität grau). Der Technologie-Stack ist Next.js + PostgreSQL + Redis. Bitte gib zuerst einen Lösungsvergleich (WebSocket / SSE / Polling), erkläre, welche du empfiehlst und warum, und liste dann die Implementierungsschritte und das Redis-Key-Design auf. Keinen vollständigen Code schreiben, Schlüsselfragmente dürfen eingefügt werden.

Mit diesem Prompt generieren →

grok-4.7, standardmäßig high-Reasoning-Stufe, max_tokens auf 6000 begrenzt, tatsächliche Laufzeit 69,8 s, Eingabe 3.429 / Ausgabe 4.247 Tokens, ca. $0,014.

Erst Stack und Geschäftsvolumen festlegen, dann „erst vergleichen, dann empfehlen“ verlangen – die Ausgabe ist ein prüfungsfähiger Lösungsvorschlag statt neutraler Aufklärung.

Szenario 4: Konzept erklären

Zuerst das Szenario klären. Angenommen, du baust eine Bestellung: Die Bestellung muss in die Datenbank geschrieben werden, und gleichzeitig muss eine Nachricht in die Message Queue, damit Lager, Punkte und Benachrichtigungen als Downstream arbeiten. Diese beiden Aktionen liegen nicht in derselben „Transaktion“; schlägt irgendein Schritt dazwischen fehl, entsteht im System ein Riss, bei dem „eine Seite erfolgreich ist, die andere nicht stattgefunden hat“.

Warum zuerst Datenbank, dann Nachricht senden zu Nachrichtenverlust führt

Der Datenbank-Commit war erfolgreich, die Bestellung ist gespeichert. Gleich danach muss der Prozess die Nachricht senden; dabei kann:

• das Netz kurz stocken und das Senden scheitern;
• die Message Queue vorübergehend nicht verfügbar sein;
• häufiger noch: der Prozess stürzt nach dem Datenbank-Commit und vor dem Nachrichtensenden ab (Neustart, OOM, Rolling-Deploy).

Die Bestellung liegt in der Datenbank, die Nachricht wurde nie gesendet. Downstream weiß nichts von dieser Bestellung, Lager wird nicht abgebucht, Benachrichtigung nicht gesendet. Auch späteres Wiederholen hilft nicht – der abgestürzte Prozess ist weg; ohne separate zuverlässige Kompensation geht diese Nachricht verloren. Für jemanden, der nur Monolithen geschrieben hat, ist das so: Du trägst „Zahlung erhalten“ im Hauptbuch ein, gehst dann zur Post, um den Benachrichtigungsbrief zu verschicken, der Brief geht unterwegs verloren, aber das Hauptbuch ist bereits geändert – beide Seiten passen nicht zusammen.

(Auszug: Der Verlustmechanismus bei „erst DB schreiben, dann Nachricht senden“ und die zentrale Metapher)

Vollständiger Prompt:

Erkläre in einer Sprache, die ein Backend-Entwickler mit 3 Jahren Erfahrung, aber ohne jeglichen Kontakt zu verteilten Systemen versteht, warum „zuerst die Datenbank schreiben, dann die Message Queue“ zu Nachrichtenverlust führen kann und „zuerst die Message Queue senden, dann die Datenbank schreiben“ ebenfalls nicht funktioniert. Gib an, für welche Szenarien die beiden in der Branche üblichen korrekten Vorgehensweisen (lokale Nachrichtentabelle / Transaktionsnachricht) jeweils geeignet sind.

Mit diesem Prompt generieren →

grok-4.7, standardmäßig high-Reasoning-Stufe, max_tokens auf 4000 begrenzt, tatsächliche Laufzeit 41,3 s, Eingabe 3.410 / Ausgabe 2.478 Tokens, ca. $0,009.

Statt „erklär es verständlich“ lieber „erklär es einer Person mit konkretem Profil“ – dann wählt das Modell selbst die richtige Granularität; die Metapher von Hauptbuch und Post stammt genau daher.

Szenario 5: Datenanalyse-Skript

```python
import pandas as pd
import numpy as np

# Beispieldaten (durch deinen echten df ersetzbar)
np.random.seed(42)
n = 500
df = pd.DataFrame({
    "order_id": range(1, n + 1),
    "user_id": np.random.randint(1, 80, n),
    "amount": np.round(np.random.uniform(20, 500, n), 2),
    "created_at": pd.date_range("2023-01-01", periods=n, freq="D").astype(str),  # simulierte String-Daten
    "status": np.random.choice(["paid", "paid", "paid", "cancelled"], n),
})

# ---------- 0. Datumsverarbeitung: String zu datetime ----------
df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
df = df.dropna(subset=["created_at", "amount", "user_id"])

# Optional: nur gültige Bestellungen zählen (status-Werte je nach Geschäft anpassen)
df_valid = df[df["status"] == "paid"].copy()

# ---------- 1. GMV und Bestellanzahl pro Monat ----------
df_valid["month"] = df_valid["created_at"].dt.to_period("M")
monthly = (
    df_valid.groupby("month", as_index=False)
    .agg(GMV=("amount", "sum"), order_count=("order_id", "count"))
    .sort_values("month")
)
monthly["month"] = monthly["month"].astype(str)
print("=== GMV und Bestellanzahl pro Monat ===")
print(monthly)
```

(Auszug: vordere Hälfte des Codes (Datumsverarbeitung + monatlicher GMV); die hintere Hälfte mit Nutzer-Ranking und Trend der Erstbestellungen ist ausgelassen)

Vollständiger Prompt:

Ich analysiere mit pandas einen E-Commerce-Bestelldatensatz; der DataFrame df hat die Spalten: order_id, user_id, amount, created_at, status. Bitte gib mir vollständig lauffähigen Python-Code, der berechnet: 1) GMV und Bestellanzahl pro Monat; 2) Ranking der kumulierten Ausgaben pro Nutzer (nur Top 20); 3) monatlichen Trend des durchschnittlichen Betrags der Erstbestellung neuer Nutzer. Berücksichtige, dass created_at ein String sein kann, und kommentiere die Schlüsselschritte.

Mit diesem Prompt generieren →

grok-4.7, standardmäßig high-Reasoning-Stufe, max_tokens auf 5000 begrenzt, tatsächliche Laufzeit 18,5 s, Eingabe 3.440 / Ausgabe 1.427 Tokens, ca. $0,007.

Spaltennamen, zu berechnende Kennzahlen und Randfälle (created_at ist ein String) Punkt für Punkt auflisten – der generierte Code läuft direkt, keine Nacharbeit nötig.

Wie man Prompts schreibt

1. Echten Code und echte Spaltennamen einfügen, nicht „es gibt etwas Code“ beschreiben – direkt einfügen.
2. Das Ausgabeformat in den Prompt schreiben: Wenn JSON gewünscht ist, ein JSON-Gerüst angeben; wenn Code, dann „vollständig lauffähig“ sagen.
3. Vorgaben so konkret wie möglich: Sortierregeln, nur Top 20, keinen vollständigen Code, nur Schlüsselfragmente einfügen.

Häufige Fragen

Kann ich diese Prompts direkt verwenden? Ja. Alle 5 sind Original-Prompts, die wir auf HiAPI tatsächlich ausgeführt haben; die Ausgaben sind echte Ergebnisse. Ein Klick auf „Mit diesem Prompt generieren“ unter jedem Eintrag füllt die Modellseite automatisch vor – ersetze einfach den Code oder die Daten durch deine eigenen und leg los.

Wie gut ist grok-4.7 im Coden? xAI positioniert es für Coding und Wissensarbeit; offiziell meldet xAI für Terminal-Bench 4.0 einen Anstieg von 20,3 % bei grok-4.6 auf 38,0 % (offizielle Angabe). Die Grundursachenanalyse in Szenario 1 und die Prüfliste in Szenario 2 stammen aus unseren echten Läufen – urteile selbst.

Was kostet ein Aufruf ungefähr? Zu HiAPI-Plattformpreisen (Eingabe $0,84 / Ausgabe $2,52 pro 1M Tokens) kosten diese 5 zusammen etwa $0,06. Das günstigste Szenario 5 kostet nur ca. $0,007, das teuerste Szenario 1 ca. $0,021.

Wofür braucht man 500K Kontext? Du kannst die Dateien eines mittelgroßen Repositories oder Hunderte Seiten Logs in einer Anfrage zur Prüfung, Fehlersuche oder Umgestaltung einfügen, ohne selbst aufzuteilen. Kurze Alltagsprompts schöpfen das nicht aus und kosten nicht mehr – abgerechnet wird nach tatsächlichen Tokens.

Weiterlesen

• Was kostet die Grok 4.7 API? – drei Reasoning-Stufen, Preisgestaltung für lange Dokumente und Monatsbudget-Matrix
• Grok 4.7 vs Grok 4.6 – gleicher Preis, wann welches Modell
• Grok 4.7 API-Integrationsleitfaden – in 5 Minuten die erste Anfrage zum Laufen bringen
• Grok 4.6 Modellseite – vollständige Nutzung des vorherigen Flaggschiffs
• Grok 4.7 Modellseite – online ausprobieren, Parameter und Live-Preise