Avis sur Prompt Lab : une bonne méthode, un calculateur à corriger
Prompt Lab impose des cas communs et un barème déclaré pour comparer deux instructions. La lecture du code et de petits tests locaux révèlent des limites à corriger avant de décider à partir des scores.
Prompt Lab impose des cas communs et un barème déclaré pour comparer deux instructions. La lecture du code et de petits tests locaux révèlent des limites à corriger avant de décider à partir des scores.
Périmètre
Cet avis porte sur la version publique0.1.1, révision e7e5027c6e6522bf8e2b6dae9ff25744c9451f35, vérifiée le29 octobre2026. Ce plugin ZCode dispose d’un calculateur utilisant la bibliothèque standard Python et d’une licence MIT. J’ai lu README, skill et code, puis exécuté de petits cas synthétiques de calcul. Je n’ai lancé ni ZCode ni comparaison de modèles et n’ai mesuré aucun coût fournisseur. Le propriétaire a proposé le projet pour examen ; les conclusions sont indépendantes des liens de parrainage du site.
Une méthode utile
Les deux variantes reçoivent les mêmes cas avec un barème pondéré défini avant jugement. Le processus documenté demande un nouvel agent pour chaque cas/variante/répétition et conserve runs.json avec les sorties. Le barème et les propriétés attendues ne sont pas transmis à l’exécutant. Cela réduit les fuites entre variantes. Le calculateur ne crée toutefois pas d’agents et ne prouve pas leur isolation ; un journal consigne un récit d’exécution. Le README décrit l’installation marketplace et /prompt-lab avec deux chemins, les cas, le barème et les répétitions.
Deux tests numériques en échec
J’ai écrit OK dans A-run1.txt et FAIL dans A-run2.txt pour un critère contains-OK. Avec runs_per=2, le calculateur a lu OK deux fois et renvoyé1.0. Dans compute_scores, collect_outputs reçoit1 au lieu du numéro courant. Un autre test avec un premier cas réussi et un second échoué donne1.0 puis0.5 ; le second devrait valoir0.0 pour ce seul critère. Les compteurs got_w et total_w incluent les cas précédents. Ces essais portent sur les fichiers et le calcul, pas sur un modèle.
Jugement en attente et recherche littérale
Avec un critère objectif et un critère manuel non jugé, l’agrégation annonce un gagnant malgré pending_manual=1 pour les deux variantes. Le compteur est visible, mais la promesse du README de différer le verdict n’est pas imposée. La propriété no invented numbers vérifie seulement l’absence de l’expression invented numbers, sans détecter un nombre inventé. Contains et regex servent aux contraintes de format ; la vérité factuelle et l’effet causal d’une formulation exigent un jugement distinct.
Les corrections que je demanderais
Il faut lire le numéro exact de répétition, refuser un fichier absent et réinitialiser les compteurs à chaque cas et répétition. Bloquer le verdict tant que des jugements requis manquent, ou le signaler provisoire. Réserver les propriétés sémantiques au jugement manuel et vérifier le journal contre la matrice prévue. Les tests doivent couvrir des sorties différentes, une seconde sortie absente, l’ordre réussite/échec inversé et pending_manual. Ce sont des recommandations, pas des corrections appliquées au dépôt. En attendant, je lirais les sorties brutes et utiliserais la méthode comme liste de contrôle sans choisir une instruction sur ses scores actuels.