Kimi K3.1 Pro : la grande bibliothèque de prompts — 5 scénarios à copier-coller pour obtenir un résultat

Kimi K3.1 Pro est désormais disponible sur HiAPI, et les nouveaux utilisateurs reçoivent 200 crédits à l'inscription. Voici 5 prompts réellement utilisables, couvrant le diagnostic d'incidents, la revue de code, la comparaison de solutions, l'analyse de longs documents et le traitement de données. Chaque prompt peut être copié tel quel ; le lien le préremplit automatiquement.

1. Diagnostic système : localiser la cause racine à partir des logs d'erreur

Confiez les logs d'erreur au modèle et demandez-lui de remonter la chaîne couche par couche, puis de fournir la cause racine et les étapes de correction, plutôt qu'un vague « vérifiez la connexion réseau ».

Exemple de sortie attendu : le modèle liste la chaîne de diagnostic (par exemple configuration du reverse proxy Nginx → état de santé du service backend → pool de connexions à la base de données), indique pour chaque couche la commande de vérification, le résultat attendu et le symptôme anormal, puis isole la cause racine (par exemple « l'épuisement du pool de connexions PostgreSQL provoque le timeout des nouvelles requêtes en file d'attente ») et propose un plan de correction en deux étapes.

Tu es un ingénieur backend spécialisé dans le diagnostic d'incidents. Voici un extrait de logs d'erreur d'un environnement de production. Procède au diagnostic selon les étapes suivantes :

1. Interprète ligne par ligne les horodatages clés et les codes d'erreur des logs
2. Analyse couche par couche les causes possibles selon la chaîne d'appel (entrée → middleware → service → base de données)
3. Indique les causes racines les plus probables (3 maximum)
4. Pour chaque cause racine, fournis une commande de vérification et les étapes de correction

Format de sortie :
## Interprétation des logs
## Diagnostic couche par couche
## Analyse des causes racines
## Étapes de correction

Logs :
[colle ici tes logs d'erreur]

Diagnostiquer un incident avec ce prompt →

kimi-k3.1-pro, reasoning_effort: high. Référence : environ $0.03 (entrée ~3000 tokens + sortie ~2000 tokens).

Point clé : le prompt définit la structure de sortie et la chaîne de diagnostic ; le modèle ne saute pas d'étapes et ne propose pas de suggestions inutiles du type « redémarrez pour voir ». Pour les problèmes de diagnostic, il est plus utile de régler reasoning_effort sur high ou max — avec low, le modèle saute parfois les couches intermédiaires pour deviner directement la conclusion.

2. Revue de code : sortie JSON structurée

Demandez au modèle de relire le code et de produire du JSON, directement exploitable en base ou dans une vérification CI. Le mode json_schema de K3.1 Pro garantit que les champs, types et valeurs d'énumération de la sortie correspondent strictement à votre définition.

Exemple de sortie attendu : le modèle renvoie un objet JSON contenant un tableau issues (chaque élément avec file, line, severity, category, description, suggestion), un objet summary (avec le décompte par niveau de gravité) et overall_score (0-100). Les niveaux de gravité sont strictement classés en quatre catégories : critical / major / minor / style.

Tu dois relire le code ci-dessous. Produis le résultat de la revue strictement selon le JSON Schema, sans aucun texte en dehors du JSON.

Axes de revue :
- Erreurs de logique et cas limites
- Problèmes de performance (requêtes N+1, boucles inutiles)
- Risques de sécurité (injection SQL, XSS, entrées non validées)
- Style de code et lisibilité

JSON Schema de sortie :
{
  "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 :
[colle ici ton code]

Relire du code avec ce prompt →

kimi-k3.1-pro, response_format: json_schema. Référence : environ $0.04 (entrée ~4000 tokens + sortie ~2500 tokens).

Point clé : il faut passer response_format: {"type": "json_schema", "json_schema": {...}} pour verrouiller le format de sortie. Répéter le Schema dans le prompt est une double sécurité — même si json_schema ne s'applique pas, le modèle produira le format demandé. Utilisez des valeurs d'énumération pour severity plutôt que des descriptions en langage naturel, afin que les traitements en aval puissent faire des branchements directs.

3. Comparaison de solutions techniques : tableau de notation multidimensionnel

Quand deux solutions techniques sont difficiles à départager, faites noter le modèle sur plusieurs dimensions et calculer un score total : c'est plus équitable que laisser un collègue trancher à l'instinct.

Exemple de sortie attendu : le modèle génère un tableau comparatif couvrant 5 à 6 dimensions (performance, maintenabilité, maturité de l'écosystème, coût d'apprentissage, adéquation avec l'équipe, etc.), avec pour chacune une note de 1 à 10 et une justification en une phrase, puis calcule le score pondéré total et formule une recommandation.

Je dois choisir entre deux solutions techniques : solution A et solution B. Compare-les une à une sur les 6 dimensions suivantes, note chaque dimension (1-10) en justifiant en une phrase, puis calcule le score pondéré total et formule une recommandation.

Dimensions de comparaison et pondérations :
- Performance (pondération 25 %)
- Maintenabilité (pondération 20 %)
- Maturité de l'écosystème (pondération 20 %)
- Coût d'apprentissage (pondération 15 %)
- Adéquation avec la stack technique existante de l'équipe (pondération 15 %)
- Activité de la communauté (pondération 5 %)

Format de sortie :
| Dimension | Note solution A | Note solution B | Justification |
|---|---|---|---|
| Performance | | | |
| ... | | | |
| **Score pondéré total** | | | |

Dernier paragraphe : justification de la recommandation (3 phrases maximum)

Solution A : [décris la solution A, par exemple stack technique, architecture, dépendances clés]
Solution B : [décris la solution B, par exemple stack technique, architecture, dépendances clés]
Contexte : [facultatif : taille de l'équipe, stack technique existante, contexte métier]

Comparer deux solutions avec ce prompt →

kimi-k3.1-pro, reasoning_effort: high. Référence : environ $0.04 (entrée ~3000 tokens + sortie ~3000 tokens).

Point clé : ajustez les pondérations à votre situation réelle. Si l'équipe a déjà une préférence, écrivez directement les pondérations dans le prompt ; le modèle en tiendra compte dans le calcul. Ne vous contentez pas de donner le nom des solutions : décrivez clairement les choix techniques clés, les dépendances et le contexte de l'équipe pour chaque solution, afin que le modèle puisse attribuer des notes fondées.

4. Analyse de longs documents : extraire l'information clé de tout un manuel

Fournissez des dizaines de pages de documentation technique, de comptes rendus de réunion ou de retours utilisateurs et demandez au modèle d'extraire les quelques points qui vous intéressent vraiment. Le contexte de 1M tokens de K3.1 Pro est suffisant pour absorber tout un manuel.

Exemple de sortie attendu : le modèle résume d'abord le thème et la structure du document, puis répond point par point à chaque question clé, et liste enfin les cas limites et contradictions facilement omis.

Voici un document technique complet. Extrais les informations clés selon la structure suivante :

1. Aperçu du thème et de la structure du document (un paragraphe)
2. Réponds aux questions précises suivantes :
   - [question 1]
   - [question 2]
   - [question 3]
3. Toutes les contraintes et hypothèses préalables mentionnées dans le document (liste point par point)
4. Cas limites facilement omis (au moins 3)
5. Points contradictoires ou peu clairs dans le document (le cas échéant)

Document :
[colle ici le texte intégral du document]

Analyser un document avec ce prompt →

kimi-k3.1-pro, reasoning_effort: max, max_tokens: 8000. Référence : environ $0.07 (entrée ~15000 tokens + sortie ~3000 tokens). Les tokens d'entrée d'un long document dépendent de sa longueur réelle ; ici, estimation prudente d'environ 10 000 caractères chinois.

Point clé : remplacez les questions 2 et 3 par ce que vous voulez réellement savoir du document, ne laissez pas les [question 1] du modèle. Pour un document très long, réglez reasoning_effort sur max ; avec low, des informations sont facilement omises dans les contextes longs. En cas d'analyse répétée du même long document, la lecture depuis le cache ne coûte que $0.2156/M tokens à partir de la deuxième fois (1/10 du prix d'entrée).

5. Analyse de données : générer un rapport d'insights à partir de données brutes

Fournissez un jeu de données CSV ou JSON et demandez-lui de calculer automatiquement les statistiques, de dégager les tendances, de repérer les anomalies et de produire directement un rapport collable dans votre rapport hebdomadaire.

Exemple de sortie attendu : le modèle commence par un aperçu des données (nombre de lignes, champs, plage temporelle), puis produit les statistiques des indicateurs clés, une description des tendances, l'annotation des points de données anormaux et enfin 2 à 3 recommandations actionnables.

Tu es analyste de données. Voici un jeu de données brutes. Réalise l'analyse suivante et produis un rapport :

1. Aperçu des données : nombre de lignes, liste des champs, plage temporelle, complétude des données (taux de valeurs manquantes)
2. Statistiques des indicateurs clés : choisis automatiquement les mesures appropriées selon le type de champ
   - Champs numériques : moyenne, médiane, maximum, minimum, écart-type
   - Champs catégoriels : Top 5 des catégories et leur part
3. Analyse des tendances : s'il existe un champ temporel, agrège les principaux indicateurs par semaine/mois et décris la tendance
4. Détection d'anomalies : signale les points de données s'écartant de plus de 2 écarts-types de la moyenne
5. Conclusions et recommandations : 2 à 3 recommandations actionnables

Format de sortie : rapport Markdown, titres par section, chiffres clés en gras.

Données :
[colle ici tes données CSV ou JSON]

Analyser des données avec ce prompt →

kimi-k3.1-pro, reasoning_effort: high. Référence : environ $0.03 (entrée ~2000 tokens + sortie ~2000 tokens). Le nombre de tokens d'entrée augmente avec le volume de données.

Point clé : ne mettez pas d'informations sensibles dans les données (vrais ID utilisateur, numéros de téléphone, clés). Si le jeu de données comporte beaucoup de lignes, les 200 premières suffisent au modèle pour dégager tendances et anomalies — K3.1 Pro n'a pas besoin de l'intégralité des données pour produire des conclusions statistiques précises.

Rédaction générale des prompts

K3.1 Pro est un modèle de raisonnement ; inutile d'écrire des préfixes passe-partout du type « tu es un expert en XX ». Trois points essentiels :

1. Donnez la structure, pas le raisonnement : définissez le format de sortie et les dimensions à couvrir, et laissez le modèle raisonner sur la façon de les remplir ; c'est plus efficace que de lui dicter les étapes pas à pas.
2. Posez des questions précises : « analyse ces logs » est moins efficace que « trouve la première anomalie apparue dans ces 500 lignes de logs, son appelant en amont, et les configurations à modifier pour corriger ».
3. Choisissez reasoning_effort selon le scénario : high ou max pour le diagnostic et les longs documents, low pour les questions simples et les conversions de format ; le coût peut varier de plusieurs fois.

Ouvrez la page du modèle Kimi K3.1 Pro, choisissez un scénario, copiez le prompt et lancez la génération.

Série d'articles Kimi K3.1 Pro

• Page du modèle
• Comment utiliser l'API ? Réussir son premier appel en 5 minutes
• Comparaison des prix
• Kimi K3.1 Pro vs Claude Opus 5.5