Kimi K3.1 Pro Prompt-Sammlung: 5 Szenarien zum direkten Kopieren und Verwenden

Kimi K3.1 Pro ist jetzt auf HiAPI verfügbar; neue Nutzer erhalten bei der Registrierung 200 Credits gratis. Im Folgenden findest du 5 praxiserprobte Prompts für Fehlerbehebung, Code-Review, Lösungsvergleich, Analyse langer Dokumente und Datenverarbeitung. Jeder Prompt lässt sich direkt kopieren; per Link werden die Felder automatisch ausgefüllt.

1. System-Fehlerbehebung: Aus Fehlerprotokollen die Ursache lokalisieren

Gib dem Modell die Fehlerprotokolle und lass es die Kette Ebene für Ebene durchgehen, um Ursache und Behebungsschritte auszugeben – statt vager Ratschläge wie „Netzwerkverbindung prüfen“.

Beispielausgabe zur Orientierung: Das Modell listet die Prüfkette auf (z. B. Nginx-Reverse-Proxy-Konfiguration → Zustand des Backend-Dienstes → Datenbank-Verbindungspool), gibt für jede Ebene Prüfbefehle, erwartete Ergebnisse und auffälliges Verhalten an, benennt schließlich die Ursache (z. B. „Der PostgreSQL-Verbindungspool ist erschöpft, wodurch neue Anfragen mit Timeout in der Warteschlange hängen“) und liefert einen zweistufigen Behebungsplan.

Du bist ein Backend-Fehlerbehebungsingenieur. Nachfolgend ein Fehlerprotokoll aus der Produktionsumgebung. Bitte untersuche es nach folgenden Schritten:

1. Interpretiere Zeile für Zeile die entscheidenden Zeitpunkte und Fehlercodes im Protokoll
2. Analysiere entlang der Aufrufkette (Eingang → Middleware → Dienst → Datenbank) Ebene für Ebene mögliche Ursachen
3. Nenne die wahrscheinlichsten Ursachen (höchstens 3)
4. Gib zu jeder Ursache einen Prüfbefehl und Behebungsschritte an

Ausgabeformat:
## Protokollinterpretation
## Ebenweise Untersuchung
## Ursachenanalyse
## Behebungsschritte

Protokoll:
[Füge hier dein Fehlerprotokoll ein]

Mit diesem Prompt Fehler beheben →

kimi-k3.1-pro, reasoning_effort: high. Referenz: ca. $0.03 (Eingabe ca. 3000 Token + Ausgabe ca. 2000 Token).

Wichtige Punkte: Im Prompt sind Ausgabestruktur und Prüfkette definiert; das Modell überspringt keine Schritte und gibt keine nutzlosen Ratschläge wie „einfach neu starten“. Bei Fehlerbehebungsaufgaben ist reasoning_effort auf high oder max sinnvoller – bei low werden mitunter Zwischenebenen übersprungen und direkt Schlussfolgerungen geraten.

2. Code-Review: strukturierte JSON-Ausgabe

Lass das Modell den Code prüfen und JSON ausgeben, das sich direkt in eine CI-Prüfung integrieren lässt. Der json_schema-Modus von K3.1 Pro stellt sicher, dass Ausgabefelder, Typen und Enum-Werte exakt deiner Definition entsprechen.

Beispielausgabe zur Orientierung: Das Modell gibt ein JSON-Objekt zurück, das ein issues-Array (jeder Eintrag mit file, line, severity, category, description, suggestion), ein summary-Objekt (mit Zählungen je Schweregrad) sowie overall_score (0-100) enthält. Die Schweregrade werden strikt in die vier Stufen critical / major / minor / style eingeteilt.

Du sollst den folgenden Code prüfen. Bitte gib das Prüfergebnis streng nach JSON-Schema aus und gib außerhalb des JSON keinerlei Text aus.

Prüfdimensionen:
- Logikfehler und Randbedingungen
- Performance-Probleme (N+1-Abfragen, unnötige Schleifen)
- Sicherheitsrisiken (SQL-Injection, XSS, unvalidierte Eingaben)
- Codestil und Lesbarkeit

Ausgabe-JSON-Schema:
{
  "issues": [
    {
      "file": "string",
      "line": "number",
      "severity": "critical | major | minor | style",
      "category": "logic | performance | security | style",
      "description": "string",
      "suggestion": "string"
    }
  ],
  "summary": {
    "critical": "number",
    "major": "number",
    "minor": "number",
    "style": "number"
  },
  "overall_score": "number (0-100)"
}

Code:
[Füge hier deinen Code ein]

Mit diesem Prompt Code prüfen →

kimi-k3.1-pro, response_format: json_schema. Referenz: ca. $0.04 (Eingabe ca. 4000 Token + Ausgabe ca. 2500 Token).

Wichtige Punkte: Um das Ausgabeformat festzulegen, muss response_format: {"type": "json_schema", "json_schema": {...}} übergeben werden. Das Schema zusätzlich im Prompt zu wiederholen, ist eine doppelte Absicherung – selbst wenn json_schema nicht greift, gibt das Modell das Format ein. severity verwendet Enum-Werte statt natürlicher Sprache, damit nachgelagerte Systeme direkt Verzweigungen vornehmen können.

3. Vergleich technischer Lösungen: mehrdimensionale Bewertungstabelle

Wenn zwei technische Lösungen nicht zu entscheiden sind, ist es fairer, das Modell nach mehreren Dimensionen bewerten und die Gesamtpunktzahl berechnen zu lassen, als Kollegen aus dem Bauch heraus entscheiden zu lassen.

Beispielausgabe zur Orientierung: Das Modell erstellt eine Vergleichstabelle mit 5-6 Dimensionen wie Performance, Wartbarkeit, Reife des Ökosystems, Lernaufwand und Passung zum Team; für jede Dimension vergibt es 1-10 Punkte und eine Begründung in einem Satz, berechnet anschließend gewichtet die Gesamtpunktzahl und gibt eine Empfehlung.

Ich muss zwischen zwei technischen Lösungen wählen: Lösung A und Lösung B. Bitte vergleiche sie entlang der folgenden 6 Dimensionen, bewerte jede Dimension (1-10) und schreibe eine Begründung in einem Satz; berechne am Ende gewichtet die Gesamtpunktzahl und gib eine Empfehlung ab.

Vergleichsdimensionen und Gewichtung:
- Performance (Gewichtung 25 %)
- Wartbarkeit (Gewichtung 20 %)
- Reife des Ökosystems (Gewichtung 20 %)
- Lernaufwand (Gewichtung 15 %)
- Passung zum bestehenden Tech-Stack des Teams (Gewichtung 15 %)
- Community-Aktivität (Gewichtung 5 %)

Ausgabeformat:
| Dimension | Lösung A Punkte | Lösung B Punkte | Begründung |
|---|---|---|---|
| Performance | | | |
| ... | | | |
| **Gewichtete Gesamtpunktzahl** | | | |

Letzter Abschnitt: Begründung der Empfehlung (höchstens 3 Sätze)

Lösung A: [Beschreibe Lösung A, z. B. Tech-Stack, Architektur, zentrale Abhängigkeiten]
Lösung B: [Beschreibe Lösung B, z. B. Tech-Stack, Architektur, zentrale Abhängigkeiten]
Kontext: [optional: Teamgröße, bestehender Tech-Stack, Geschäftsszenario]

Mit diesem Prompt Lösungen vergleichen →

kimi-k3.1-pro, reasoning_effort: high. Referenz: ca. $0.04 (Eingabe ca. 3000 Token + Ausgabe ca. 3000 Token).

Wichtige Punkte: Passe die Gewichtungen an deine tatsächliche Situation an. Wenn das Team bereits eine Präferenz hat, schreibe die Gewichtung direkt in den Prompt – das Modell berücksichtigt sie bei der Punktevergabe. Gib nicht nur die Namen der Lösungen an – beschreibe die wichtigsten Technologieentscheidungen, Abhängigkeiten und die Teamsituation jeder Lösung, damit das Modell fundierte Punkte vergeben kann.

4. Analyse langer Dokumente: Kerninformationen aus einem ganzen Handbuch extrahieren

Wirf Dutzende Seiten technischer Dokumentation, Meeting-Protokolle oder Nutzerfeedback hinein und lass das Modell genau die Punkte extrahieren, die dich wirklich interessieren. Der Kontext von 1M Token bei K3.1 Pro reicht aus, um ein ganzes Handbuch zu verarbeiten.

Beispielausgabe zur Orientierung: Das Modell fasst zunächst Thema und Struktur des Dokuments zusammen, beantwortet dann die einzelnen Kernfragen Punkt für Punkt und listet schließlich leicht übersehene Randfälle und Widersprüche auf.

Nachfolgend ein vollständiges technisches Dokument. Bitte extrahiere die Kerninformationen nach folgender Struktur:

1. Überblick über Thema und Struktur des Dokuments (ein Absatz)
2. Beantworte die folgenden konkreten Fragen:
   - [Frage 1]
   - [Frage 2]
   - [Frage 3]
3. Alle im Dokument genannten Einschränkungen und Vorannahmen (Punkt für Punkt auflisten)
4. Leicht zu übersehende Randfälle (mindestens 3)
5. Widersprüchliche oder unklare Stellen im Dokument (falls vorhanden)

Dokument:
[Füge hier den vollständigen Dokumenttext ein]

Mit diesem Prompt Dokumente analysieren →

kimi-k3.1-pro, reasoning_effort: max, max_tokens: 8000. Referenz: ca. $0.07 (Eingabe ca. 15000 Token + Ausgabe ca. 3000 Token). Bei langen Dokumenten richtet sich die Zahl der Eingabe-Token nach der tatsächlichen Dokumentlänge; hier wird von etwa 10.000 chinesischen Schriftzeichen als vorsichtiger Schätzung ausgegangen.

Wichtige Punkte: Ersetze die Fragen 2 und 3 durch das, was du wirklich aus dem Dokument erfahren möchtest, und lass nicht die [Frage 1]-Platzhalter stehen. Bei sehr langen Dokumenten setze reasoning_effort auf max – bei langem Kontext werden mit low leicht Informationen übersehen. Wenn du dasselbe lange Dokument mehrfach analysierst, kostet das Lesen aus dem Cache ab dem zweiten Mal nur $0.2156/M Token (1/10 des Eingabepreises).

5. Datenanalyse: Aus Rohdaten einen Insight-Bericht erstellen

Gib CSV- oder JSON-Daten ein und lass das Modell automatisch Statistiken erstellen, Trends erkennen, Anomalien finden und direkt einen Bericht ausgeben, den du in den Wochenbericht einfügen kannst.

Beispielausgabe zur Orientierung: Das Modell erstellt zunächst einen Datenüberblick (Zeilenanzahl, Felder, Zeitraum), gibt dann Statistiken zu wichtigen Kennzahlen, Trendbeschreibungen und Markierungen anormaler Datenpunkte aus und liefert abschließend 2-3 umsetzbare Empfehlungen.

Du bist ein Datenanalyst. Nachfolgend findest du Rohdaten. Bitte führe die folgende Analyse durch und gib einen Bericht aus:

1. Datenüberblick: Zeilenanzahl, Feldliste, Zeitraum, Datenvollständigkeit (Fehlquote)
2. Statistiken zu wichtigen Kennzahlen: Wähle je nach Feldtyp automatisch passende statistische Kennzahlen
   - Numerische Felder: Mittelwert, Median, Maximum, Minimum, Standardabweichung
   - Kategoriale Felder: Top-5-Kategorien und Anteile
3. Trendanalyse: Wenn ein Zeitfeld vorhanden ist, aggregiere die wichtigsten Kennzahlen nach Woche/Monat und beschreibe den Trend
4. Anomalieerkennung: Markiere Datenpunkte, die mehr als 2 Standardabweichungen vom Mittelwert abweichen
5. Schlussfolgerungen und Empfehlungen: 2-3 umsetzbare Empfehlungen

Ausgabeformat: Markdown-Bericht, Abschnittsüberschriften, wichtige Zahlen fett.

Daten:
[Füge hier deine CSV- oder JSON-Daten ein]

Mit diesem Prompt Daten analysieren →

kimi-k3.1-pro, reasoning_effort: high. Referenz: ca. $0.03 (Eingabe ca. 2000 Token + Ausgabe ca. 2000 Token). Bei größeren Datenmengen steigt die Zahl der Eingabe-Token entsprechend.

Wichtige Punkte: In den Daten sollten keine sensiblen Informationen enthalten sein (echte Nutzer-IDs, Telefonnummern, Schlüssel). Wenn die Daten viele Zeilen haben, reichen die ersten 200 Zeilen aus, damit das Modell Trends und Anomalien erkennt – K3.1 Pro kann auch ohne vollständige Daten genaue statistische Schlussfolgerungen liefern.

Allgemeine Formulierung von Prompts

K3.1 Pro ist ein Reasoning-Modell; der Prompt muss keine Universalpräfixe wie „Du bist ein professioneller XX“ enthalten. Drei wichtige Punkte:

1. Struktur vorgeben statt Gedankengang: Definiere das Ausgabeformat und die abzudeckenden Dimensionen und lass das Modell selbst überlegen, wie es sie füllt – das funktioniert besser, als Schritt für Schritt vorzugeben.
2. Konkrete Fragen stellen: „Analysiere dieses Protokoll“ ist schwächer als „Finde in diesen 500 Zeilen die früheste Anomalie, ihren aufrufenden Vorgänger und welche Konfigurationen für die Behebung geändert werden müssen“.
3. reasoning_effort je nach Szenario wählen: Für Fehlerbehebung und lange Dokumente high oder max, für einfache Fragen und Formatkonvertierung low – die Kosten können sich um ein Vielfaches unterscheiden.

Öffne die Modellseite von Kimi K3.1 Pro, wähle ein Szenario, kopiere den Prompt und starte die Generierung.

Artikelreihe zu Kimi K3.1 Pro

• Modellseite
• Wie verwende ich die API? In 5 Minuten zum ersten Aufruf
• Preisvergleich
• Kimi K3.1 Pro vs Claude Opus 5.5