Kimi K3 dans un grand dépôt : organiser le contexte
Une fenêtre étendue ne remplace ni carte du projet, ni critères d’acceptation, ni trace durable des décisions prises pendant la tâche.
La documentation de Kimi K3 annonce une fenêtre de contexte d’un million de tokens. C’est une capacité déclarée, pas la preuve que tout dépôt sera correctement compris lorsqu’il est envoyé en entier. L’utilité du contexte dépend aussi de la pertinence et de l’organisation des informations.
Dans un grand projet, le problème est rarement le manque de texte. On trouve des instructions anciennes, des modules aux noms proches, des tests qui ne représentent plus la production et des décisions jamais écrites. Davantage d’espace permet d’ajouter du contenu sans nécessairement résoudre ses contradictions.
Commencer par une carte utile aux décisions
Identifiez le point d’entrée, le composant chargé de la règle examinée et les tests associés. Expliquez le comportement incorrect et sa reproduction. Au lieu de demander de comprendre tout le monorepo, demandez de suivre une opération précise en citant les fichiers qui justifient l’explication.
La première réponse doit être vérifiable. Si l’agent affirme qu’une validation se fait sur le serveur, il doit montrer le code correspondant. Découvrir que le contrôle existe seulement dans l’interface change la correction nécessaire. La carte doit réduire le champ de recherche, plutôt que décrire toutes les arborescences de manière générale.
Choisir le contexte autour de la question
Pour corriger une règle de livraison, le calcul, l’origine des données, les contrats d’entrée et les tests sont généralement pertinents. L’historique complet des campagnes commerciales peut ne pas l’être. Lorsqu’une dépendance devient utile, ajoutez le contenu nécessaire et expliquez pourquoi elle entre dans l’investigation.
Cette sélection facilite aussi la révision. Une demande centrée sur dix fichiers pertinents se reconstitue mieux qu’une conversation réunissant de nombreux sujets sans relation expliquée. Il n’existe pas de nombre idéal de fichiers pour chaque tâche ; chaque ensemble doit avoir une raison d’être. Retirez les hypothèses dépassées lorsque les éléments nouveaux modifient le plan.
Une longue session doit laisser une trace hors du chat
La documentation des sessions Kimi Code décrit leur conservation et leur reprise. Même avec cette fonction, gardez une note de travail dans le projet : objectif, décisions confirmées, fichiers modifiés, vérifications effectuées et prochain point à valider.
Imaginons une migration interrompue après l’adaptation des requêtes, mais avant l’examen des permissions. La simple mention « migration presque terminée » peut conduire une autre session à s’arrêter trop tôt. Préciser la vérification manquante conserve la différence entre implémentation partielle et comportement démontré. La note doit être intelligible sans avoir suivi la conversation initiale.
Réviser des modifications compréhensibles
Découpez les changements par comportement, en précisant leurs dépendances. Une étape peut préparer une interface interne, une autre modifier ses utilisateurs et une dernière retirer l’ancienne compatibilité après les tests. Ce n’est pas une recette universelle, mais une façon de rendre la révision possible sans imposer une lecture énorme en une fois.
À la fin, confrontez l’explication de l’agent aux changements réels et exécutez les cas pertinents. Consommer beaucoup de contexte ne prouve rien sur la correction. Le guide de travail avec Kimi Code traite de l’exécution ; la comparaison entre modèles explique comment documenter l’essai. Organiser le travail reste une partie de la solution dans un grand dépôt.
À propos de l’auteur
Tiago F SantiagoCommentaires
Aucun commentaire pour le moment
Partagez une question ou une expérience en lien avec cet article.
Articles sur le même sujet
