Compétence skill-image-qwen

Générez ou éditez des images avec Qwen-Image-3.0. Le modèle prend en charge à la fois la génération texte-à-image (T2I) et l'édition image-à-image (I2I) : créez directement à partir d'une description textuelle ou modifiez avec précision 1 à 3 images de référence en combinant instructions d'édition. L'objectif principal est de passer du « joli » à « l'utile » : l'image générée doit pouvoir être un livrable directement utilisable. Principe fondamental : exploiter les invites pour maximiser les capacités du modèle ; placer la « clarification des besoins », la « validation et optimisation des invites » et la « confirmation avant génération » au premier plan.

Mise à jour majeure V3 : chaîne de jetons en trois étapes (sécurisée par le code, seule méthode 100 % fiable)

La V2 était en deux phases (prepare/generate), ce qui permettait théoriquement de passer directement à prepare sans optimisation des invites. La V3 ajoute une étape de « validation et optimisation des invites » comme barrière de contrôle au niveau du code, formant une chaîne de jetons en trois étapes :

Phase 1 optimize : le modèle effectue la validation et l'optimisation selon le modèle officiel (paradigme en 6 étapes) et enregistre le résultat – obligatoirement avec « comparaison avant/après optimisation + explication des modifications » (pour éviter le travail bâclé). Le code génère un jeton A (lié à l'empreinte sha256 du contenu de l'invite optimisée) et enregistre l'historique. N'appelle jamais l'API réelle.
Phase 2 prepare : le code vérifie le jeton A (pas de jeton A -> refus, message : « Vous devez d'abord effectuer la validation et l'optimisation des invites ») ; si réussi, il présente tel quel à l'utilisateur « besoin initial -> invite optimisée -> explication des modifications » pour confirmation ; génère un jeton B, détruit le jeton A (utilisé puis immédiatement supprimé). N'appelle jamais l'API réelle.
Phase 3 generate : le code vérifie le jeton B (pas de jeton B / non correspondant / contenu modifié -> refus) ; si réussi, il exécute l'appel API, détruit le jeton B après succès (utilisé puis immédiatement supprimé).

Relais de jetons : optimize ->(jeton A)-> prepare ->(jeton B)-> generate, sans un ticket la porte ne s'ouvre pas ; le modèle ne peut pas passer du besoin initial directement à la génération, il sera bloqué à prepare ou generate.

Les jetons sont des sous-produits du flux, pas des mots de passe codés en dur : générés dynamiquement par le code comme empreinte de contenu (sha256(invite)), même en lisant le code source le modèle ne peut pas les falsifier ; seule une exécution correcte de chaque étape donne accès à la clé.

Les jetons sont liés au contenu : chaque demande a un jeton différent ; si le contenu soumis ne correspond pas à la version enregistrée/confirmée, refus – empêche « montrer une chose, en générer une autre ».

Portée des jetons : l'empreinte ne couvre que le contenu de l'invite ; les paramètres techniques (taille, format, etc.) sont récupérés depuis l'enregistrement et non inclus dans l'empreinte – la porte verrouille le fait essentiel « l'utilisateur a confirmé le contenu », les paramètres techniques sont flexibles pour éviter de refaire tout le processus pour un simple changement de taille.

Utilisé puis immédiatement supprimé : prepare consomme et détruit le jeton A, generate détruit le jeton B après succès – empêche la réutilisation d'anciens jetons pour sauter des étapes et exécuter à nouveau.

Messages de refus comme guide pédagogique : les textes d'erreur sont des guides de procédure ; bloqué, le modèle peut s'auto-corriger et revenir au bon flux.

Mécanisme anti-bâclé : l'enregistrement optimize exige obligatoirement « comparaison avant/après + explication des modifications », prepare présente tel quel à l'utilisateur pour confirmation ; pour faire semblant, il faudrait inventer une justification de modification sur le moment, ce qui augmente le coût de la tricherie ; l'utilisateur peut vérifier la justification et détecter si la direction est erronée (par exemple, style « réaliste » changé en « cartoon »). Un seul document sert à la fois de « devoir anti-bâclé » et de « base de confirmation utilisateur », sans ajouter d'étape supplémentaire.

Modèles et versions

Version	ID du modèle	Positionnement	Prix unitaire génération
Standard (par défaut)	`qwen-image-3.0`	Équilibre qualité-vitesse, pratique pour la création quotidienne	1K/2K 0,18 yuan/pièce
Pro (optionnel)	`qwen-image-3.0-pro`	Mise en page dense, détails extrêmes, connaissances approfondies	1K 0,25 yuan/pièce, 2K 0,50 yuan/pièce

Compétences fondamentales du modèle (officielles « trois réalités ») :

Capacité	Description	Indicateur clé
Contenu riche	Peut contenir une page entière : examens, journaux, atlas, infographies en une génération	Longueur d'instruction jusqu'à 4,5K tokens
Détails réalistes	Résiste à l'agrandissement : textures proches des matériaux réels	Caractères de 10 px lisibles, pores et cheveux visibles en détail
Connaissances approfondies	Comprend tout : multilingue, interdisciplinaire	Couvre 12 langues, 100+ styles artistiques et plusieurs interfaces UI

Par défaut, utiliser la version standard. Passage à Pro uniquement quand l'utilisateur a explicitement besoin des capacités Pro (mise en page dense avec images dans l'image, détails réalistes comme micro-expressions/pores/cheveux) ou en fait la demande.
Prix d'entrée identique pour les deux versions (0,02 yuan/pièce). Voir references/pricing_and_models.md.
Limites du modèle et recommandations de sélection dans references/pricing_and_models.md.

Flux de travail (à respecter impérativement)

① Identification et clarification des besoins -> ② Sélection de la version -> ③ Construction de l'invite puis optimisation avec optimize -> ④ Affichage et confirmation -> ⑤ prepare confirmation -> ⑥ generate et itération -> ⑦ Retour des coûts.

Étape 1 : Identification et clarification des besoins (primordiale, ne pas sauter)

En tant qu'expert en génération d'images IA, évaluez si la demande de l'utilisateur est suffisamment claire et détaillée. Les demandes initiales des utilisateurs sont souvent vagues, cette étape est cruciale pour la qualité de l'image : elle nécessite des échanges répétés avec l'utilisateur.

Analyser l'intention : en combinant la question texte de l'utilisateur + les pièces jointes (images de référence, croquis, captures), déterminer :
- Type de tâche : création à partir de rien (T2I) ? Édition d'image existante (I2I) ?
- Cela implique-t-il une personne réelle, une marque ou un objet nécessitant une fidélité ?
- Nombre d'images de référence et rôle de chacune (cible d'édition / référence de style / source du sujet).
Affiner sur plusieurs dimensions (en cas de flou, confirmer point par point, utiliser request_user_input pour questions groupées ou naturelles ; si déjà détaillé, une confirmation légère suffit) :
1. Contenu principal 2. Style 3. Composition et angle 4. Ambiance et lumière 5. Format et proportions 6. Quantité 7. Usage 8. Images de référence 9. Exigence de fidélité
Personnes réelles : demander et enregistrer les caractéristiques distinctives de chaque personne (coiffure/couleur de cheveux/lunettes/teint/forme du visage/vêtements/morphologie/âge) comme points d'ancrage dans l'invite.
Résumer en un « cahier des charges image » et le présenter à l'utilisateur pour confirmation.

Principe d'efficacité : si la demande est déjà claire, faire une confirmation légère (reformuler + demander « c'est correct, des ajustements ? ») sans parcourir mécaniquement toute la liste ; approfondir uniquement sur les dimensions floues ou à haut risque (fidélité, rôle des images de référence).

Étape 2 : Sélection de la version

En fonction des besoins clarifiés à l'étape 1, choisir la version selon les recommandations (voir references/pricing_and_models.md) :

Scénario	Version recommandée
Affiches quotidiennes, illustrations, visuels réseaux sociaux, maquettes UI, génération en lot	Standard (par défaut)
Sortie haute résolution 2K sans exigence de détails extrêmes	Standard (2K au même prix, plus économique)
Composition d'image produit e-commerce dans un décor (I2I multi-images)	Standard suffit ; Pro si texture extrême souhaitée
Mise en page journal, examen, storyboard, menu, infographie (composition dense)	Pro
Portrait photo, gros plan produit (micro-expressions/pores/cheveux réalistes)	Pro
Atlas illustré, infographie pédagogique historique (multi-modules + multilingue)	Pro

Par défaut standard ; en cas de besoin Pro, informer clairement l'utilisateur de la différence de coût (Pro 178 % plus cher en 2K).
Si l'utilisateur ne spécifie pas de version, utiliser la standard par défaut et l'indiquer dans le plan de génération.

Étape 3 : Construction de l'invite et appel à optimize (validation et enregistrement, jamais d'appel API)

En fonction de l'intention et des spécifications de l'étape 1, valider et optimiser l'invite en respectant les meilleures pratiques et la bibliothèque de cas, puis sélectionner le mode et appeler optimize (au lieu de générer directement). C'est l'étape centrale pour maximiser les capacités du modèle : les besoins initiaux sont généralement courts et flous, il faut les développer selon le paradigme officiel en 6 étapes pour obtenir une invite riche en détails visuels, et enregistrer « comparaison avant/après + explication des modifications ».

3.1 Consulter les meilleures pratiques et la bibliothèque de cas

Consultez d'abord references/best_practices.md et references/case_library.md pour trouver des cas officiels similaires, apprendre la structure et les techniques clés des invites, identifier les pièges courants et les éviter.

Référence rapide scénario à cas :

Scénario utilisateur	Cas de référence	Axe de l'invite
Mise en page examen/document/rapport	Cas 1 (examen de chinois)	Description zone par zone en scan + texte écrit caractère par caractère
Photographie macro/gros plan produit	Cas 2 (macro broderie)	Fibre du matériau + instant d'action + faible profondeur de champ
Notes manuscrites/formules mathématiques	Cas 3 (notes de maths)	Annotations trois couleurs + formule caractère par caractère + figures géométriques
Composition image produit e-commerce dans décor	Cas 4 (composition I2I)	Règles d'édition (extraire/ignorer/conserver/générer)
Design de personnage/cohérence multi-angle	Cas 5 (fiche personnage)	Description très détaillée d'un personnage + division en zones multi-angle
Carte dessinée à la main/infographie	Cas 6 (carte gastronomique)	Description zone par zone + points numérotés + système de légendes
Menu/tableau des prix	Cas 7 (menu Chaoshan)	Rubriques + liste des plats + photos intégrées
Atlas illustré/affiche éducative	Cas 8 (atlas ruqun)	Description modulaire + personnage principal visuel + modules auxiliaires
Infographie vectorielle/guide de randonnée	Cas 9 (guide de randonnée)	Style vectoriel anglais + palette de couleurs + points de passage
Enseignement historique/infographie multilingue	Cas 10 (rébellion An Lushan)	Mode bilingue + format large horizontal + contraintes négatives
Portrait photo commercial	Cas 11 (portrait de rue italien)	Narration arrière-plan multicouche + personnage très détaillé + rendu argentique
Portrait photo avec jeu d'ombres et lumières	Cas 12 (portrait chapeau de paille)	Cause et emplacement des ombres + paramètres photo + contraintes négatives

Analyse complète de la structure des invites des 12 cas officiels et techniques clés dans references/case_library.md ; texte complet des invites originales dans Qwen-Image-3.0官方最佳实践案例与完整提示词手册.md.

3.2 Choisir la méthode (selon l'objectif)

Objectif	Méthode	Appel
Création à partir de rien, sans image de référence	Texte-à-image T2I	Invite uniquement, pas de `--image`
Conserver/étendre un personnage ou contenu d'une image existante	Image-à-image I2I	Invite + 1 à 3 `--image`

3.3 Écrire l'invite (paradigme officiel en 6 étapes)

Organisez le contenu selon la structure d'invite issue des 12 cas officiels (détaillée dans references/best_practices.md chapitre 3) :

Ouverture et cadrage : une phrase pour décrire le type d'image, l'orientation, le style global et l'ambiance. Ex. : « Il s'agit d'une affiche verticale…, le fond général est… »
Parcours spatial : décrivez strictement dans l'ordre spatial (du haut vers le bas, de gauche à droite, du sujet vers le fond) chaque zone, en précisant les positions relatives des éléments.
Texte écrit caractère par caractère : tout texte à rendre (titre/corps/légende/prix/pied de page) doit être écrit entre guillemets dans l'invite, en spécifiant police/taille/couleur/position.
Cinq éléments de détail : couleur avec nom précis, matériau avec terme de texture, lumière avec direction et dureté, police avec style, composition avec niveaux.
Contraintes de fin : listez les contraintes négatives avec « éviter… » (caractères illisibles/décalage/distorsion/surexposition/filigrane, etc.), utilisable aussi avec le paramètre --negative-prompt.
Format et paramètres photo : pour les styles réalistes/portraits, vous pouvez ajouter le rapport d'aspect, la focale, l'ouverture, etc. (ex. « vertical 3:4, 85 mm, f/2 »).

3 astuces officielles :

Les instructions peuvent être « longues » : 4,5K tokens pour des mises en page complexes, décrivez chaque zone, chaque texte, chaque position relative en détail.
Les petits caractères doivent être « nommés » : écrivez le texte exact directement dans l'instruction, entre guillemets, en spécifiant police/taille/couleur/position.
Le style doit être « complet » : pour un style photo, décrivez la lumière, l'objectif, l'ambiance (focale/ouverture/exposition/grain argentique) ; pour un style illustration, décrivez la matière, la palette, le coup de pinceau.

Points particuliers pour l'édition/référence (I2I) : écrivez clairement « conserver X, modifier uniquement Y », réitérez les invariants lors des itérations pour éviter la dérive. Pour les compositions multi-images, l'accent est mis sur les règles d'édition (extraire quoi/ignorer quoi/conserver quoi/générer quoi), utilisez des termes forts comme « doit » « ne doit pas » pour garantir l'utilisation complète des images de référence.

3.4 Appeler optimize (enregistrer comparaison + explication des modifications, retourner le jeton A, jamais d'appel API)

Une fois la validation et l'optimisation de l'invite terminées, appelez la phase optimize (au lieu de générer directement). optimize vérifie l'anti-bâclé (original/optimisé/explication des modifications complètes et substantielles), valide les paramètres, calcule l'empreinte de l'invite optimisée, enregistre l'historique et retourne le jeton A, sans jamais appeler l'API réelle, sans coût :

optimize T2I : python scripts/generate_image.py optimize --original-prompt "besoin initial" --optimized-prompt "invite optimisée" --change-explanation "explication des modifications" --size 1024*1024
optimize I2I : python scripts/generate_image.py optimize --original-prompt "besoin initial" --optimized-prompt "invite optimisée" --change-explanation "explication des modifications" --image ref.png --model qwen-image-3.0-pro
optimize multi-images : python scripts/generate_image.py optimize --original-prompt "..." --optimized-prompt "..." --change-explanation "..." --n 4

Paramètres obligatoires pour optimize : --original-prompt (besoin initial), --optimized-prompt (invite optimisée), --change-explanation (explication des modifications : ce qui a été optimisé et pourquoi – anti-bâclé, également base de la confirmation utilisateur). Paramètres courants : --model (par défaut qwen-image-3.0), --image (1 à 3 images de référence), --size largeur*hauteur, --n (1-6), --negative-prompt, --seed, --watermark, --no-prompt-extend, --prompt-extend-mode direct|agent, -o chemin de sortie. Tous les paramètres sont verrouillés dans l'enregistrement lors d'optimize, les phases suivantes ne peuvent pas les modifier (seul -o de generate peut surcharger le chemin de sortie).

Syntaxe @fichier pour les paramètres de type invite : si la valeur commence par @, elle est lue depuis le fichier au chemin spécifié (pour les invites très longues, contourne la limite de longueur de ligne de commande), ex. --optimized-prompt @optimized.txt.

Sortie d'optimize : besoin initial, invite optimisée, explication des modifications, plan de génération (mode/modèle/taille/quantité/mode de réécriture/coût estimé), jeton de validation (jeton A). Transférez ces informations complètes à l'étape 4.

Étape 4 : Affichage et confirmation (attente obligatoire de la confirmation utilisateur)

Affichez intégralement à l'utilisateur le « besoin initial -> invite optimisée -> explication des modifications » + plan de génération + jeton A retourné par optimize, et attendez une confirmation explicite :

Utilisateur confirme -> passez à l'étape 5, utilisez le jeton A pour appeler prepare.
Utilisateur demande des modifications -> retournez à l'étape 3 pour une nouvelle validation et optimisation, puis réexécutez optimize (produisant un nouveau jeton A, l'ancien devient invalide/nettoyé), puis réaffichez et confirmez.
⚠️ N'appelez pas prepare/generate avant la confirmation utilisateur. Bien que le code ne vérifie pas explicitement « l'utilisateur a-t-il vraiment vu », prepare doit dépendre d'un jeton A valide d'optimize ; l'affichage et la confirmation conformes sont un point de contrôle crucial pour la qualité et le coût. Lors de la confirmation, l'utilisateur peut comparer l'explication des modifications pour détecter si la direction est erronée (par exemple, style « réaliste » changé en « cartoon »).

Étape 5 : Confirmation prepare (consomme le jeton A, retourne le jeton B, pas d'appel API)

Après confirmation utilisateur, appelez prepare avec le jeton A + l'invite optimisée exactement identique à celle enregistrée lors d'optimize :

prepare : python scripts/generate_image.py prepare --token <jeton A> --optimized-prompt "<invite optimisée enregistrée lors d'optimize>"

Le script effectue trois vérifications (existence de l'enregistrement de validation / correspondance du jeton A / correspondance de l'invite optimisée avec la version enregistrée). En cas de succès, il présente tel quel « besoin initial -> invite optimisée (version confirmée) -> explication des modifications » + plan de génération, retourne le jeton de confirmation (jeton B), et détruit le jeton A (utilisé puis immédiatement supprimé).
Les paramètres techniques (images/taille/quantité, etc.) sont récupérés depuis l'enregistrement d'optimize et verrouillés, ne peuvent pas être modifiés à l'étape prepare.
Pas de jeton A ou contenu non correspondant -> refus (le message d'erreur sert de guide de procédure).

Étape 6 : generate et itération ponctuelle

Appelez generate avec le jeton B + l'invite exactement identique à celle confirmée lors de prepare :

generate : python scripts/generate_image.py generate --token <jeton B> --prompt "<invite version confirmée>" [-o chemin_sortie]

Le script effectue trois vérifications (existence de l'enregistrement de confirmation / correspondance du jeton B / correspondance de l'invite avec la version confirmée) avant d'appeler l'API ; les autres paramètres sont récupérés depuis l'enregistrement et verrouillés, ne peuvent pas être modifiés à l'étape generate.
En cas de succès, affiche automatiquement la taille réelle, l'utilisation, le coût, et détruit le jeton B (jeton unique, non réutilisable).
Affiche le chemin absolu de l'image.
Itération : ne modifiez qu'un seul élément à la fois -> réexécutez optimize (nouveau jeton A) -> affichage et confirmation -> prepare (nouveau jeton B) -> generate. Si le résultat n'est pas satisfaisant, privilégiez l'ajustement du « style/ambiance » ou de la « composition », ou revenez à l'étape 3 pour changer de stratégie.

Étape 7 : Retour des coûts

Après la génération, le script affiche automatiquement l'utilisation et le coût (version, paliers entrée/sortie, nombre d'images, prix unitaire, total). Résumez pour l'utilisateur :

Version et méthode utilisées (T2I/I2I), ID du modèle.
Taille de sortie, nombre généré, palier de facturation (1K/2K).
Coût d'entrée, coût de sortie, coût total (en yuans).
ID de la requête (pour traçabilité).

Règles de calcul des coûts et exemples dans references/pricing_and_models.md.

Mécanisme des jetons et de l'historique (chaîne en trois étapes, détails de sécurité par le code)

Format du jeton : sha256(invite)-nonce8 (empreinte liée au contenu de l'invite, nonce garantit que plusieurs enregistrements de la même invite ne se chevauchent pas). Les jetons A et B ont le même contenu et la même empreinte mais des nonces différents, ce sont deux jetons distincts.
Relais de jetons : optimize produit le jeton A -> prepare consomme le jeton A et produit le jeton B (détruit A) -> generate consomme le jeton B (détruit après succès). Une étape manquante = rejet.
Stockage de l'historique : deux répertoires dans le répertoire temporaire système – skill_image_qwen_optimize/<tokenA>.json (jeton A, contient original_prompt/optimized_prompt/change_explanation/params), skill_image_qwen_pending/<tokenB>.json (jeton B, contient la version confirmée et les paramètres récupérés). optimize stocke uniquement le chemin/URL de l'image, ne lit pas le contenu de l'image, l'historique reste léger.
Portée des jetons : l'empreinte ne couvre que le contenu de l'invite (sha256(invite)), les paramètres techniques (taille, format, etc.) sont récupérés depuis l'historique et non inclus dans l'empreinte – changer la taille ne nécessite pas de refaire tout le processus (sauf si la taille/filigrane est en soi un élément de conformité à confirmer par l'utilisateur).
Anti-bâclé : l'enregistrement optimize exige obligatoirement « comparaison avant/après + explication des modifications », l'explication doit atteindre un nombre minimum de caractères ; prepare présente tel quel à l'utilisateur pour confirmation.
Cycle de vie : prepare détruit immédiatement le jeton A après succès ; generate détruit immédiatement le jeton B après succès (jeton unique, anti-réutilisation) ; en cas d'échec de l'appel API, le jeton B est conservé pour permettre une nouvelle tentative avec le même jeton (pas besoin de reconfirmation) ; l'historique expire après 2 heures et est automatiquement nettoyé.
Verrouillage des paramètres : images/taille/quantité/mode de réécriture etc. sont verrouillés dans l'historique lors d'optimize, les phases suivantes les récupèrent et les utilisent, ne peuvent pas être modifiés ; generate ne peut surcharger que le chemin de sortie avec -o.
Les fichiers image doivent encore exister au moment de generate : optimize vérifie seulement l'existence et enregistre le chemin ; generate lit le disque pour le convertir en URI de données.

Règles de construction des invites

Paradigme en 6 étapes : ouverture et cadrage -> parcours spatial -> texte écrit caractère par caractère -> cinq éléments de détail -> contraintes de fin -> format et paramètres photo (voir references/best_practices.md).
Caractéristiques de Qwen : préfère les descriptions longues, détaillées et visuelles (jusqu'à 4,5K tokens) ; prompt_extend activé par défaut peut améliorer les invites courtes.
Texte dans l'image : marquez le contenu entre guillemets, spécifiez police/taille/couleur/position, exigez un rendu caractère par caractère.
Édition/référence : écrivez clairement « conserver X, modifier uniquement Y », réitérez les invariants lors des itérations pour éviter la dérive.
Taille : utilisez largeur*hauteur (séparé par un astérisque, ex. 1920*1080) ; si non spécifié, le modèle recommande automatiquement.
Consultez les meilleures pratiques complètes et la FAQ dans references/best_practices.md ; l'analyse de la structure des 12 cas officiels dans references/case_library.md ; les paramètres de l'API dans references/api_reference.md.

Index des fichiers de référence

Fichier	Contenu
`references/best_practices.md`	Aperçu des trois réalités, 3 astuces officielles, paradigme en 6 étapes, FAQ, paliers de taille, suggestions d'itération
`references/case_library.md`	Index catégorisé des 12 cas officiels, analyse de la structure des invites, techniques clés, référence rapide scénario à mode
`references/api_reference.md`	Point de terminaison API, structure du corps de la requête, description des paramètres, corps de la réponse, champ usage, codes d'erreur
`references/pricing_and_models.md`	Comparaison des modèles, tableau des prix, calcul des coûts, recommandations de sélection
`Qwen-Image-3.0官方最佳实践案例与完整提示词手册.md`	Texte officiel original : invites complètes des 12 cas, astuces d'utilisation, prix de l'API
`scripts/generate_image.py`	Script de génération en trois phases (optimize/prepare/generate, T2I/I2I, bibliothèque standard pure, chaîne de jetons en trois étapes avec validation obligatoire + confirmation, anti-bâclé, facturation automatique)

Contraintes importantes

Sécurité de la clé : lisez uniquement depuis la variable d'environnement DASHSCOPE_API_KEY, ne l'écrivez jamais dans le fichier de compétence, ne demandez jamais la clé en texte clair dans le chat. Si non définie, donnez des instructions pour la configurer et attendez.
Ne pas contourner les trois phases : pas de jeton A d'optimize -> prepare refusé ; pas de jeton B de prepare -> generate refusé ; optimize/prepare n'appellent pas l'API, aucun coût. Le modèle ne peut pas passer du besoin initial directement à la génération.
Anti-bâclé obligatoire : optimize doit enregistrer « comparaison avant/après + explication des modifications », l'explication doit être substantielle ; prepare présente tel quel à l'utilisateur pour confirmation.
Affichage et confirmation obligatoires : après optimize, affichez « besoin initial -> invite optimisée -> explication des modifications » + plan à l'utilisateur pour confirmation, n'appelez pas prepare/generate avant.
Clarifier avant de générer : ne lancez aucun script avant d'avoir terminé l'étape 1 (identification et clarification des besoins).
Emplacement de sortie : par défaut, enregistrez dans le répertoire output/ du répertoire de travail courant ; si l'image est destinée au projet en cours, déplacez-la à un emplacement approprié après génération.
Ne pas écraser : sauf demande explicite de l'utilisateur, utilisez des noms de fichiers avec numéro de version.
Validité des images : l'URL de l'image renvoyée par l'API est valide 24 heures, le script la télécharge automatiquement en local.

Préparation de l'environnement

Vous devez définir la variable d'environnement DASHSCOPE_API_KEY (clé API Alibaba Cloud Bailian).
Définition temporaire sous PowerShell (saisie masquée, la clé n'entre pas dans l'historique des commandes) : $env:DASHSCOPE_API_KEY = Read-Host -Prompt 'DASHSCOPE_API_KEY'
Définition permanente : via l'interface des variables d'environnement système, écrire DASHSCOPE_API_KEY, ou utiliser setx puis redémarrer le terminal. Ne stockez jamais la valeur réelle dans un fichier du dépôt.
Optionnel DASHSCOPE_BASE_URL : remplace le point de terminaison par défaut https://dashscope.aliyuncs.com (par exemple pour utiliser un nom de domaine propre à un espace de travail).
Obtention de la clé API : https://help.aliyun.com/zh/model-studio/get-api-key

skill-image-qwen

Qu'est-ce que skill-image-qwen ?

Demander à votre IA préférée

Documentation