Vous avez créé une fonctionnalité avec un outil de programmation IA. La liste apparaît, les filtres fonctionnent et une autre consigne change le résultat. Puis quelqu’un demande pourquoi un élément a disparu ou si une petite règle affectera les autres filtres. Il faut redemander à l’IA.

Essayez avec un petit filtre JavaScript. Notez les éléments qu’il gardera, changez le seuil de stock à la main, puis comparez le résultat à votre prédiction.

Choisir un comportement prévisible

« Apprends-moi toute cette app » est une vaste tâche. Choisissez plutôt un résultat précis : quels éléments restent quand catégorie, texte recherché et filtre de disponibilité sont combinés ?

Posez trois questions avant de modifier :

  1. Quels identifiants cette entrée doit-elle renvoyer ?
  2. Quelle condition inclut ou exclut chaque élément ?
  3. Quels résultats doivent rester identiques si la règle de disponibilité change ?

Si la syntaxe vous est encore inconnue, avancez expression par expression. Ici, filter garde les éléments dont le rappel renvoie true, && exige toutes les conditions et || accepte l’un ou l’autre côté. Entrée et sortie sont assez petites pour un calcul sur papier.

Téléchargez l’atelier de filtrage. Le code et les quatre enregistrements ont été créés pour cette leçon ; ce ne sont ni une réponse IA capturée ni le source d’une vraie application. Décompressez et ouvrez filter-learning-lab. Il faut Node.js 22 ou ultérieur, un éditeur et un terminal. Aucune dépendance à installer, aucun appel de modèle ni requête réseau.

Écrire trois prédictions avant d’exécuter le code

Lisez catalog.mjs et filter.mjs. Le catalogue contient ces enregistrements :

ID Libellé Catégorie Stock
folded-stars Folded stars paper 1
paper-kites Paper kites paper 3
clay-moons Clay moons clay 0
clay-bells Clay bells clay 2

La règle initiale inclut un élément dès qu’il possède une unité. La recherche porte sur le libellé, ignore la casse et retire les espaces autour de la requête. Catégorie, recherche et disponibilité doivent toutes correspondre. La catégorie all accepte toute catégorie ; une recherche vide accepte tout libellé.

Ouvrez blank-note.md et notez les identifiants attendus pour ces entrées. Relisez la fonction au besoin, mais attendez avant de lancer l’observateur ou de demander la réponse.

Cas Catégorie Recherche availableOnly À expliquer
A paper vide true Pourquoi un stock de 1 suffit
B all CLAY false Pourquoi l’élément sans stock peut apparaître
C clay bells true Comment les trois conditions se combinent

Lancez ensuite ces commandes depuis le dossier extrait :

node observe.mjs
node --test baseline.test.mjs
Comparer vos prédictions aux résultats originaux
Cas Identifiants originaux Raison
A folded-stars, paper-kites Les deux sont en paper et ont au moins une unité en stock.
B clay-moons, clay-bells La recherche de libellé sans casse et sans espaces périphériques trouve les deux. Le filtre de disponibilité est désactivé.
C clay-bells La catégorie et le libellé correspondent, et le stock vaut 2.

Si votre prédiction diffère, marquez la première condition mal comprise. Pour B, « l’élément est en stock » serait faux : clay-moons a un stock nul. Il reste parce que availableOnly est false, donc cette condition ne l’exclut pas.

Expliquer la règle sans emprunter une réponse

Fermez la note complétée si vous l’avez ouverte. Écrivez deux ou trois phrases expliquant B à quelqu’un qui regarde le catalogue. Incluez l’entrée réelle et la condition qui autorise le stock nul.

Distinguez les quelques fichiers et leurs rôles :

Fichier Rôle dans l’exercice
catalog.mjs Fournit les quatre enregistrements.
filter.mjs Décide quels enregistrements correspondent aux conditions fournies.
observe.mjs Fournit trois jeux de conditions et affiche les identifiants et stocks retenus.
baseline.test.mjs Vérifie le comportement de filtrage original.

L’observateur est un appelant de terminal, pas une capture de navigateur. Dans votre app, un bouton ou formulaire peut fournir des valeurs similaires ; lisez cet appelant avant de supposer ce qu’envoie l’interface.

Le lecteur local de Yenpo permet de garder données, filtre et appelant ouverts. Les recherches de fichiers et de texte n’exigent pas de modèle. Si vous utilisez l’AI Reader avec votre fournisseur, interrogez la condition précise qui vous bloque, puis revenez au source environnant et rédigez votre explication. Lancez vous-même les commandes dans Terminal ; l’exercice n’a besoin d’aucune réponse de modèle.

Modifier une règle à la main

Changez maintenant l’exigence : lorsque le filtre de disponibilité est actif, n’affichez que les matériaux avec assez de stock pour deux personnes, une unité chacune. Gardez inchangés le filtre de catégorie, la normalisation de recherche et le comportement du filtre désactivé.

La règle initiale « au moins un » était correcte pour l’exigence initiale. C’est une petite évolution fonctionnelle, pas une correction de bug cachée.

Avant de modifier, écrivez une nouvelle prédiction. A doit perdre folded-stars. B doit toujours inclure l’élément sans stock puisque le filtre est désactivé. C doit garder clay-bells, dont le stock vaut exactement 2.

Lancez une fois les vérifications de la nouvelle exigence contre le code original :

node --test exercise/pair-policy.check.mjs

Cette commande doit échouer avant la modification : la fonction téléchargée accepte encore un stock de 1. Lisez l’assertion échouée pour identifier le comportement non implémenté. Une erreur de syntaxe ou un fichier absent serait un autre échec.

Dans filter.mjs, changez seulement le seuil de stock de >= 1 à >= 2. Gardez la condition availableOnly autour. Puis lancez :

node observe.mjs
node --test exercise/pair-policy.check.mjs
Cas Identifiants après modification Ce qui est vérifié
A paper-kites Une unité ne suffit plus pour la règle à deux personnes.
B clay-moons, clay-bells Désactiver la disponibilité contourne toujours le stock ; la recherche retire encore les espaces et ignore la casse.
C clay-bells Exactement deux unités suffisent ; > 2 serait incorrect.

La suite initiale décrit la règle d’une unité. Ses assertions concernées échoueront après ce changement volontaire. Utilisez les vérifications séparées pour deux personnes ; n’effacez pas une assertion pour masquer un échec. L’archive conserve le source original pour recommencer l’exercice.

Réexpliquer le changement, y compris ce qui reste identique

Mettez l’exemple complété de côté et terminez votre note avec vos propres mots. Elle doit préciser :

  • Les seuils de stock initial et nouveau, et l’emplacement exact modifié.
  • Pourquoi A perd un élément alors que B reste inchangé.
  • Pourquoi un stock d’exactement 2 doit toujours convenir dans C.
  • Les commandes exécutées et ce que montraient leurs sorties.
  • Ce qui n’a pas été vérifié, comme les entrées de formulaire, le serveur ou la persistance d’une vraie app.

Une explication finale utile est précise : « Avec la disponibilité active, tous les filtres doivent correspondre et le stock doit désormais être d’au moins deux. Sinon, le stock n’affecte pas la sélection. Le seuil retire folded-stars de A, tandis que B et C gardent les mêmes identifiants. » Fermez la page et essayez de le dire à partir du code, sans mémoriser cette formulation.

Essayez maintenant une autre entrée. Prédisez le résultat avant l’exécution, puis expliquez quelles conditions ont gardé ou exclu chaque élément.

Appliquer le même cycle à une fonctionnalité de votre projet

Choisissez un petit comportement avec des entrées visibles et une sortie reproductible. Notez la version du source, faites une copie ou utilisez votre contrôle de version habituel, et limitez la première modification. Écrivez la prédiction avant l’exécution. Si le résultat diffère, lisez la condition et l’appelant avant de demander un autre correctif généré.

Si vous ne localisez pas encore le comportement, commencez par trouver une entrée dans du code inconnu. Pour juger une explication IA, utilisez l’exercice de vérification d’explication. Pour une modification proposée, le parcours du cache de promesses examine un correctif concret et son échec.