← Tous les guides
Flux de développement

Déboguer un échec CI avec l’IA, en toute sécurité

Transformez un échec CI en petite correction vérifiable : isolez la première erreur, testez le diagnostic et gardez les secrets hors de l’invite.

Lire l’article

Commencer par les faits

Conservez la commande échouée, son code de sortie, la première erreur exploitable, les versions et le plus petit extrait utile. Retirez jetons, données clients, URL privées et archives complètes.

L’objectif est d’obtenir deux ou trois hypothèses testables, pas une réparation automatique du dépôt.

  • La commande exacte et son code de sortie
  • La première erreur exploitable avec son contexte minimal
  • Les versions du runtime, du gestionnaire de paquets et du framework
  • Un point d’arrêt : finissez la demande après le diagnostic, avant de demander un correctif
  1. Suivez le guide OpenCode lié, y compris le fichier de permissions et le test des actions refusées. Utilisez un dossier jetable et transmettez seulement les extraits approuvés.
  2. Collez l’instruction de diagnostic ci-dessous dans cette session. Remplacez les champs entre crochets par la commande, les versions et les extraits expurgés autorisés. Envoyez une fois et conservez les hypothèses.
  3. Dans le terminal du projet initial, examinez une vérification proposée, puis exécutez-la. Notez son résultat avant de demander une correction.

Demander un diagnostic limité

Demandez les hypothèses par ordre de probabilité, la ligne de journal qui les justifie et une vérification réversible pour chacune. Une requête courte vers l’inférence sans serveur suffit pour ce travail.

Invite de débogage prudenteApplication
Vous examinez un échec de compilation. Ne proposez aucune modification pour le moment.

1. Identifiez la cause racine probable la plus ancienne.
2. Citez la ligne exacte du journal qui soutient chaque hypothèse.
3. Proposez une vérification réversible pour les trois hypothèses les plus probables.
4. Indiquez les informations manquantes.

N’inventez aucun fichier, aucune version ni aucun résultat de commande.

Vérifier avant de corriger

Exécutez la vérification proposée : version résolue, installation propre ou option de configuration. Demandez ensuite, si nécessaire, un diff limité à un fichier et relancez la commande originale.

Un échec reproductible, puis sa correction

Dans un dossier jetable, créez app.cjs avec le contenu ci-dessous, puis exécutez node app.cjs vous-même. Node affiche ReferenceError: greeting is not defined. Copiez cette erreur dans la consigne de diagnostic. Vérifiez l'hypothèse en comparant le nom déclaré, greting, au nom lu, greeting. Corrigez uniquement le nom dans la déclaration et relancez la même commande. La sortie attendue est Hello.

app.cjs avant correctionContenu du fichier
const greting = "Hello";
console.log(greeting);
Exécuter avant et après la correctionTerminal local
node app.cjs

Conserver une limite claire

Le modèle est un second regard rapide. La personne qui connaît le dépôt doit choisir, relire et valider la correction. Ne transmettez jamais des données de production ni des identifiants.

Vérifier le résultat

Résultat attendu
Vous recevez un diagnostic court lié aux lignes fournies, pas un correctif spéculatif.
Arrêter si
Refusez une réponse sans preuve dans le journal, qui demande des secrets ou propose une réécriture large du dépôt.
Étape suivante
Exécutez la vérification réversible la plus probable avant d’accepter une modification de code.