Pour utiliser Kimi K3.1 Pro, choisissez un mode d’accès, démarrez une nouvelle conversation avec le modèle, puis confiez-lui une tâche précise, avec le matériel dont il a besoin. Vous pouvez accéder au modèle via les produits de Kimi et via l’API. Kimi K3.1 Pro est aussi disponible dans iWeaver, qui propose un essai gratuit du modèle.
La tâche la plus utile à faire en premier doit produire un résultat que vous pouvez vérifier : comparer deux documents, expliquer un passage difficile, ou corriger un problème de codage reproductible. Ce guide vous accompagne dans ces tâches et vous montre comment affiner le résultat, sans recommencer à chaque fois.
Choisissez où utiliser Kimi K3.1 Pro
Avant de commencer, pour connaître les détails de la mise à jour, lisez ce qui est nouveau dans Kimi K3.1 Pro.
L’annonce de la version de Kimi indique un accès via son site web, ses applications, Kimi Work, Kimi Code et son API. Choisissez le mode correspondant à la tâche que vous souhaitez accomplir.
| Votre tâche | Un point de départ pratique |
|---|---|
| Poser des questions ou explorer une idée | Une interface de chat avec K3.1 Pro sélectionné |
| Comprendre et organiser des documents sources | Le flux documentaire d’iWeaver |
| Modifier des fichiers dans un projet logiciel | Kimi Code |
| Connecter le modèle à votre propre application | Kimi API |
Ces modes ont des exigences de compte, des quotas d’utilisation et des contrôles distincts. L’accès à un modèle via un service ne définit pas les conditions d’un autre.
Pour une première tentative, évitez de configurer une API, sauf si votre objectif est une intégration. Commencez par une tâche que vous pouvez mener à bien et revoir dans un chat ou via un flux documentaire.
Étape 1 : définissez le résultat avant d’ajouter du matériel
Notez ce que vous voulez obtenir. « Analysez ces fichiers » laisse trop de place à l’interprétation. « Comparez le plan de lancement proposé avec les notes d’entretien et identifiez les hypothèses non étayées » donne au modèle une tâche plus claire.
Une description de tâche utile comporte quatre éléments :
- La question à laquelle vous avez besoin d’une réponse.
- Les sources que la réponse doit utiliser.
- La forme du résultat final.
- Les détails qui nécessitent une attention particulière.
Par exemple :
Comparez le plan de lancement avec les notes d’entretien client. Produisez un tableau des fonctionnalités proposées, des éléments probants issus des entretiens et des questions en suspens. Utilisez uniquement le matériel joint. Distinguez vos suggestions des faits énoncés dans les documents.
Gardez la première attribution étroite. Vous pourrez l’élargir après avoir vérifié que le modèle comprend bien les sources.
Étape 2 : démarrez une session distincte et sélectionnez le modèle
Si vous hésitez entre les deux variantes, consultez K3.1 Pro vs. Highspeed.
Choisissez Kimi K3.1 Pro dans les contrôles du modèle disponibles dans votre service. Dans Kimi Code CLI, le sélecteur de modèle officiel est /model. Sa documentation recommande une session distincte lors du passage au nouveau modèle.
Si le modèle manque, vérifiez votre éligibilité de compte et la liste actuelle des modèles. Dans un client Kimi officiel, redémarrer ou se reconnecter peut mettre à jour la disponibilité, comme décrit dans la documentation. Un service tiers peut suivre son propre processus de déploiement.
Évitez de poursuivre une longue conversation qui contient des hypothèses issues d’une tâche différente. Une session distincte facilite la fourniture du bon contexte et l’évaluation de la réponse.
Étape 3 : fournissez les sources dans un ordre exploitable
Nommez vos fichiers clairement et expliquez leur relation. Une politique actuelle et une politique plus ancienne doivent être étiquetées comme telles. Les notes d’entretien doivent conserver les noms des intervenants ou des identifiants lorsque l’attribution est importante.
Demandez au modèle de vérifier l’ensemble des sources avant de rédiger une réponse longue :
Lisez la liste des documents que vous pouvez utiliser, leurs dates apparentes, et la question que chacun aide à traiter. Signalez tout fichier que vous ne pouvez pas lire ou toute information manquante qui empêche la comparaison.
Ce point de contrôle permet de repérer tôt une pièce jointe illisible ou une discordance de version. Il vous donne aussi une occasion de corriger le périmètre avant que le modèle ne construise un argument à partir de ces éléments.
Kimi met en avant une grande fenêtre de contexte, mais votre quota disponible dépend du mode d’accès et du plan. Ne partez pas du principe qu’un seul téléversement peut contenir tous les fichiers d’un projet. Vérifiez les limites réelles du service.
Étape 4 : demandez des preuves avant un rapport bien présenté
Pour le travail sur des documents, commencez par un tableau des preuves. Dans iWeaver, vous pouvez utiliser l’AI Document Summarizer pour vous orienter dans le contenu avant de demander à K3.1 Pro une comparaison ciblée.
Essayez cette consigne :
Extraire les preuves nécessaires pour répondre à la question de recherche. Pour chaque point, indiquez le nom de la source, un passage ou un emplacement que je peux vérifier, ainsi que toute qualification qui modifie sa signification. Listez séparément les contradictions. Ne rédigez pas encore le rapport final.
Inspectez le tableau. Chaque passage étaye-t-il l’affirmation ? Une déclaration concernant un seul client devient-elle une déclaration à propos de tous les clients ? Un scénario a-t-il été traité comme un résultat observé ?
Quand les preuves sont solides, demandez le livrable :
Transformez les preuves examinées en une note d’environ 600 mots. Commencez par la décision qu’elles appuient, expliquez les preuves les plus solides, puis terminez par les questions en suspens. Conservez l’incertitude présente dans le matériel source.
Le processus en deux étapes vous donne l’occasion de corriger le raisonnement avant qu’il ne devienne une prose bien rédigée.
Étape 5 : utilisez des relances ciblées
Quand une réponse rate sa cible, identifiez précisément le problème. « Recommencez » donne peu d’indications.
Si la réponse est trop générale, demandez-lui de traiter une décision précise. Si elle mélange preuves et opinions, demandez des sections séparées. Si elle fournit une conclusion non étayée, demandez quelle source établit cette conclusion et quel libellé plus prudent serait justifié.
Par exemple :
Révisez la recommandation du troisième paragraphe. Les notes d’entretien démontrent un intérêt, mais elles n’établissent pas la volonté de payer. Gardez cette distinction explicite et expliquez quelles preuves permettraient de la trancher.
Pour une vue d’ensemble visuelle d’un PDF, le flux de travail PDF to Mind Map peut aider à organiser le sujet. Vérifiez à nouveau la source avant de vous fier à une étiquette de branche comme à une affirmation détaillée.
Utiliser K3.1 Pro pour coder
Si vous évaluez un autre modèle pour le même travail, utilisez les critères de tâche dans Kimi K3.1 Pro vs. Claude Opus 5.5.
Donnez à une tâche de codage un point de départ reproductible et une sortie observable. Incluez l’erreur, le comportement attendu et les contraintes pertinentes du projet.
Reproduisez le test date-parser qui échoue. Identifiez la cause, apportez le changement minimal justifié, puis exécutez les vérifications pertinentes. Expliquez tout comportement que le correctif modifie et tout cas que vous n’avez pas pu vérifier.
Passez en revue les fichiers modifiés et les résultats des tests. Une explication convaincante n’est utile que si l’implémentation la soutient.
Pour les intégrations, copiez l’identifiant exact du modèle et l’endpoint depuis la documentation pour votre canal d’accès. Kimi Code et l’API générale utilisent des conventions de nommage propres au canal. Ne remplacez pas le nom affiché depuis un menu de chat dans une requête API.
Dépannage de votre première exécution
| Problème | À vérifier |
|---|---|
| La réponse ignore un document | Demandez quelles sources étaient disponibles et réclamez une réponse spécifique à un passage |
| Deux documents sont mélangés | Étiquetez les versions et demandez une extraction séparée avant la comparaison |
| La réponse invente des détails manquants | Exigez une catégorie explicite « non indiqué dans les sources » |
| Un résultat de codage semble finalisé mais échoue | Reproduisez le problème et examinez les tests et les changements pertinents |
| Une demande Kimi Code est rejetée : raisonnement désactivé | Gardez le raisonnement activé, comme l’exige la documentation de son modèle |
Utilisez une tâche menée à bien pour décider de la suite. Si K3.1 Pro produit un tableau de preuves solide mais un rapport sans orientation, affinez les instructions d’écriture. S’il manque des détails de source, améliorez d’abord l’organisation des sources et les points de contrôle. Augmentez la charge de travail après que la tâche plus petite aura produit un résultat que vous pouvez vérifier.