Dikaya Pro 2 : une revue de code bornée et testable

Exemple API minimal

Code Python illustratif, pas une réponse exécutée. La clé vient de l’environnement et les relances automatiques sont désactivées. Une coupure peut laisser le résultat et le coût inconnus : ne relancez pas à l’aveugle.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro-2",
    max_tokens=512,
    messages=[{"role": "user", "content": "Crée une liste de vérification pour ma tâche. Sépare les faits des hypothèses."}],
)
print(response.choices[0].message.content)

Choisir une unité de revue qui tient dans une décision

Au lieu de demander de corriger tout un dépôt, isolez une fonction et son appelant, par exemple la conversion d'une date saisie en échéance affichée. Décrivez le défaut observé et le résultat attendu avec une entrée concrète. Joignez la version du langage et les dépendances nécessaires à la compréhension. Un diagnostic sans contexte d'exécution peut confondre une règle métier avec une erreur technique.

Ajoutez un périmètre négatif : ne pas changer le stockage, ne pas renommer les champs publics, conserver les dates déjà valides. Ces contraintes permettent de juger une proposition autrement qu'à sa seule élégance. Demandez que les hypothèses sur les modules absents restent explicites et que le modèle signale la pièce manquante avant de proposer une réécriture qui dépendrait de cette pièce.

Décrire un test qui reproduit réellement le défaut

Commencez par le cas qui échoue aujourd'hui : une date vide, une valeur hors plage ou un changement de fuseau horaire. Le test doit invoquer le comportement de production concerné et exprimer une attente observable. Un exemple qui vérifie seulement qu'une fonction existe peut passer tout en laissant le défaut intact. Fournissez le message d'échec réel si vous l'avez, sans le remplacer par une supposition.

Demandez ensuite deux cas de non-régression choisis pour une raison précise : une entrée déjà acceptée et une frontière qui ne doit pas bouger. Une longue liste de tests superficiels n'est pas une meilleure couverture. Exigez une phrase expliquant quel changement incorrect chaque test détecterait ; si la phrase reste vague, l'assertion a probablement besoin d'être rapprochée du comportement attendu.

Examiner une correction minimale avec ses conséquences

La correction proposée doit répondre au test défaillant sans déplacer silencieusement les responsabilités. Pour une validation de date, regardez où se trouvent normalisation, contrôle et message utilisateur. Demandez un diff limité et une explication des branches modifiées. Si le modèle crée un utilitaire, vérifiez qu'il n'existe pas déjà dans le projet et que son contrat correspond aux autres appelants.

Relisez aussi les suppressions : une ligne retirée peut contenir une compatibilité historique invisible dans l'extrait. Conservez les cas inconnus dans une rubrique à vérifier plutôt que les déclarer résolus. Ce guide propose un protocole de revue avec Pro 2, pas une mesure comparative de qualité ni une preuve qu'une correction générée compile dans votre dépôt réel.

Utiliser la démonstration pour un petit cas complet

La démo actuelle prend Pro 2 comme modèle textuel par défaut, avec au plus trois requêtes pour les nouveaux comptes admissibles. Les conditions antérieures restent attachées à leurs instantanés. Le contexte de démo est limité à 6000 octets et la sortie Pro 2 à 8192 jetons, raisonnement compris. Préférez donc une petite fonction complète à plusieurs fichiers tronqués au milieu d'une définition.

Le réglage de démonstration reasoning_effort=none ne garantit pas une absence de jetons de raisonnement ni un texte final non vide. Les anciennes demandes Flash conservent leur compatibilité et leur plafond propre de 512, sans nouvelle attribution de quota. Ni le grand contexte annoncé de Pro 2 ni le passage en payant ne réécrivent les essais déjà consommés ou l'historique de votre compte.

Séparer proposition, exécution locale et résultat observé

Copiez le changement dans un espace de travail maîtrisé, lancez le test de reproduction, puis les vérifications pertinentes du projet. Rapportez les sorties exactes : commande, statut et assertion en échec. Le navigateur affiche du code mais ne lance pas vos commandes. Les outils éventuels d'un client IDE appartiennent à ce client, avec leur propre validation ; ils ne sont pas une faculté native de cette conversation.

En intégration, un plafond de sortie explicite borne la demande, tandis que max_retries=0 évite les répétitions implicites du SDK Python. La documentation du SDK étaye cette mécanique seulement. Un échec réseau n'établit pas une absence de coût ; différenciez-le d'un rejet HTTP connu. N'inventez pas de clé d'idempotence publique pour justifier un nouvel appel dont l'issue précédente reste inconnue.

Fermer la revue avec une preuve et les points ouverts

Le compte rendu final peut tenir en quatre rubriques : défaut reproduit, modification retenue, tests exécutés et risques non vérifiés. Écrivez « non exécuté » si vous n'avez pas lancé une commande. Cela évite de transformer une suggestion convaincante en faux résultat. Pour une suite de travail, fournissez le nouveau diff réel et les nouveaux échecs plutôt que demander au modèle de se souvenir d'un état implicite.

Vérifiez seller-pro-2 dans le sélecteur avant tout envoi ; un brouillon enregistré peut prévaloir sur celui transféré depuis l'article. Le transfert ne lance rien. Les images utilisent un pont textuel payant séparé, pas une vision native Pro 2 ; la démo reste textuelle. Les niveaux low, high et max des autres entrées ne doivent pas être appliqués ici par simple analogie.

Questions et réponses

Pro 2 est-il exactement seller-glm-5-3 ?

Non : Pro 2 est la version modifiée fondée sur GLM-5.3 commercialisée sous seller-pro-2. seller-glm-5-3 est une autre identité publique. Utilisez le sélecteur et les paramètres de l'entrée exacte ; une origine apparentée ne prouve ni des réponses identiques ni des conditions de démonstration communes.

Quel extrait préparer pour une première revue en démo ?

Choisissez une fonction courte, son contrat et un cas défaillant que vous pouvez reproduire. Gardez les imports ou types indispensables, mais retirez les données inutiles. Le dossier doit tenir dans les limites de la démo ; une architecture entière coupée arbitrairement donne moins de prise à la vérification qu'un petit comportement complet.

Les tests générés prouvent-ils que la correction fonctionne ?

Pas avant exécution dans votre projet. Examinez les assertions, lancez le cas qui échouait et vérifiez les comportements voisins. Le modèle peut proposer du code plausible utilisant une API inexistante ou une mauvaise hypothèse. Conservez les erreurs de compilation et les résultats observés comme preuves, sans les remplacer par son commentaire.

Pro 2 peut-il ouvrir une capture de mon erreur ?

En mode payant, les images passent par une étape de description textuelle distincte et facturée ; Pro 2 n'a pas de vision native. Pour une erreur de compilation, le texte copié du terminal est souvent plus vérifiable. La démonstration demeure textuelle et n'offre pas les fichiers ou outils des accès payants.

Sources

Contenu préparé avec l’aide de l’IA. Les exemples sont illustratifs, pas des réponses réelles ni des tests comparatifs. Les sources externes ne remplacent pas les conditions du service.

• Documentation Dikaya : requêtes et limites
  dikaya.cc
• Catalogue Dikaya : identités et modalités
  dikaya.cc
• Tarifs Dikaya : conditions de calcul
  dikaya.cc
• SDK Python OpenAI : politique de nouvelles tentatives
  github.com
• MDN : réponses HTTP, erreurs réseau et Fetch
  developer.mozilla.org