ymh3753201/dst-skills

Que fait dst-skills ?

Transformez n'importe quel matériel produit en un ensemble professionnel d'images e-commerce qui aident réellement à la décision d'achat. Codex doit jouer simultanément les rôles de directeur de la stratégie visuelle e-commerce, de directeur de la photographie commerciale, de rédacteur de contenu produit et de réviseur d'identité produit : d'abord lire les images de manière multimodale et concevoir une stratégie visuelle complète ; après une seule confirmation de l'utilisateur, puis laisser le modèle d'image actuel générer chaque image finale, les réviser et les retravailler.

Règles absolues

1. Le produit, la scène, le texte, les icônes et les annotations dans les images finales destinées aux consommateurs sont générés par le modèle d'image ; le script se contente d'enregistrer, de vérifier le contrat et d'accepter la planche contact.
2. En cas d'erreur de texte, de dérive du produit, d'informations pauvres ou de mise en page non professionnelle, continuez l'édition d'image ou régénérez ; ne livrez pas d'image de substitution ou de « suggestion de post-production manuelle ».
3. Les images principales de recherche sans texte additionnel imposé par la plateforme restent sans texte ; les autres pages ne doivent pas dégénérer en « nature morte du produit + deux lignes de gros texte » en raison d'un manque de paramètres.
4. L'IA peut générer de nouveaux angles, personnages et scènes basés sur des images de référence, mais ne peut pas écrire les paramètres inférés, les matériaux, les fonctions, les accessoires ou les services comme des faits sur le produit.
5. Ne prétendez pas que la plateforme a approuvé la publication, sauf si le téléchargement réel et la vérification en retour ont été effectués.

1. Diagnostic multimodal des actifs

Examinez toutes les photos produit, emballages, logos, paramètres, détails, SKU, mannequins et références de style. Enregistrez individuellement role / proves / limitations, puis décrivez le verrouillage de l'identité produit, les problèmes des images d'origine et les opportunités de conception. Le verrouillage de l'identité doit être spécifique au contour, au nombre et à la position des composants, aux divisions structurelles, au logo/aux interfaces, aux coutures, à la couleur et aux proportions, et ne doit pas se contenter d'écrire « rester cohérent ».

2. Plateforme et emplacements d'images

Une plateforme n'est pas une taille unique. Après avoir consulté la plateforme actuelle, établissez placement pour l'image principale de recherche, la galerie carrée, l'image principale 3:4, le SKU, les modules de description et les images de campagne, en enregistrant un par un l'utilisation, la quantité, les proportions, les pixels sélectionnés, la justification et les research_ids. Lorsque les informations publiques ne fournissent pas les pixels exacts, marquez-les comme « suggestion de conception », ne prétendez pas connaître les règles strictes du backend.

Choisissez des dimensions précises et directement générables pour Image 2 ; si les pixels réels ne sont pas conformes, le modèle doit les refaire avec des spécifications exécutables, ne passez pas par le script pour recadrer, redimensionner ou ajouter des bordures afin de simuler l'achèvement.

3. Texte factuel et texte commercial sécurisé

L'absence de paramètres ne signifie pas l'absence de texte. Divisez le texte en deux couches :

• Texte factuel : product_fact / visual_fact / platform_fact. Les paramètres, fonctions, matériaux, compatibilité, accessoires et services doivent être liés à des fact_ids approuvés.
• Texte commercial sécurisé : safe_commercial / scenario_narrative / category_education / buyer_guidance. Peut être complété sur la base du langage de conception visible, des avantages esthétiques, des émotions liées au style de vie, de la connaissance de la catégorie et des conseils à l'acheteur, mais ne doit pas suggérer des performances non prouvées.

Chaque copy de page utilise la structure headline / subheadline / supporting_points / microcopy. Sauf pour l'image principale sans texte, il faut généralement un titre principal, un sous-titre d'avantage et au moins deux points d'appui ; n'utilisez pas le nom de la page comme copie de vente. Voir prompting.md pour plus de détails.

Le texte commercial sécurisé reste principalement axé sur la compréhension positive du produit et les avantages esthétiques. Les déclarations de risque sont placées dans microcopy ; sans besoin explicite de l'utilisateur ou de la plateforme, l'ensemble des images ne doit pas contenir plus d'une page dédiée à la vérification pré-achat ou à la liste des risques, et ne doit pas utiliser plusieurs pages d'avertissements pour remplacer la valeur du produit.

4. Classification des lacunes, ne plus tout bloquer

L'absence de quelque chose ne signifie pas que c'est hors de portée. out_of_scope ne peut être utilisé que pour le contenu explicitement exclu par l'utilisateur ou qui n'est effectivement pas nécessaire pour l'emplacement. Pour les blocking, ajoutez blocking_scope :

• project : L'identité du produit n'est pas claire, les informations réglementées ne sont pas sécurisées, etc. Le projet reste en draft et bloque toute génération d'images.
• claim : Ne bloque que le paramètre ou la fonction de texte correspondant ; utilisez safe_fallback pour générer une page de preuves sécurisée.
• acceptance : Peut générer un ensemble d'images sécurisées, mais ne peut pas prétendre à l'exhaustivité des preuves commerciales.

Lorsqu'il y a des lacunes claim / acceptance, utilisez evidence_safe pour delivery_scope et evidence_safe_limited pour commercial_completeness.

Ne collectez que les lacunes critiques qui modifieraient l'identité du produit, le placement sur la plateforme, le champ factuel ou la conclusion d'acceptation, et interrogez l'utilisateur une seule fois ; le reste est complété par l'expression commerciale sécurisée.

5. Décision d'achat et charte visuelle

Établissez d'abord une carte des décisions de l'acheteur, listant 5 à 10 questions d'acheteur couvrant cinq dimensions décisionnelles clés : identification du produit, utilisation/compatibilité, preuves, choix de spécifications, risque/confiance. Déterminez ensuite le profil de l'acheteur cible, la motivation d'achat, les freins à l'achat, le positionnement principal, le concept créatif, la hiérarchie de l'information, les couleurs, les polices, la lumière et la grammaire de la mise en page.

Un ensemble d'images professionnel complet comprend par défaut au moins 8 images, avec au moins quatre composition_type, et les pages de scène et de récapitulation ne doivent pas dépasser la moitié. Pour chaque page, écrivez primary_decision, la preuve unique de la page unique_evidence et la valeur d'achat qui ne peut être remplacée par une autre page ; un même objectif décisionnel principal est limité à deux pages maximum. Lorsque les faits sont insuffisants, ne comblez pas le nombre avec plus d'images de scène. Le plan complet doit être écrit dans plan.md.

6. Rédiger les pages comme des plans exécutables

Chaque visual_brief de page n'est plus un slogan de style comme « haut de gamme, minimaliste », mais un plan de mise en page : product_scale, product_multiplicity, focal_zone, copy_zone, hierarchy, graphic_devices, lighting, depth, information_density, composition_rationale et content_modules. product_multiplicity doit indiquer combien d'ensembles de produits vendus apparaissent sur cette page, et si les vues répétées sous différents angles/étapes représentent le même produit, afin d'éviter que le modèle ne génère deux produits distincts à partir d'une vue ouverte/fermée.

detail / diagram / process / comparison / package / trust doivent authentiquement inclure des preuves locales, des annotations, des schémas, des processus, des comparaisons, des listes ou des preuves de confiance ; ne marquez pas une nature morte de scène comme detail pour contourner la vérification.

7. Pré-validation professionnelle et compilation des prompts avant confirmation

Après avoir terminé le plan structuré, exécutez :

python3 scripts/compile_prompts.py path/to/project.json --write
python3 scripts/validate_project.py path/to/project.json --schema-only

Le prompt final doit contenir six parties : 【页面任务】 【商品身份】 【构图蓝图】 【文案系统】 【视觉执行】 【负面约束】. Le prompt doit d'abord fournir suffisamment de relations créatives et informationnelles positives, puis lister les interdictions vraiment importantes.

8. Confirmation unique et pas de réécriture après coup

La quantité, la tâche de page, les faits, le texte principal, l'identité du produit et le placement confirmés sont la base de la génération d'images. Lors de la confirmation, enregistrez plan_sha256 et execution_manifest_sha256. Les enregistrements de génération doivent inclure attempt, generated_at, prompt_sha256 et le même plan_sha256 ; l'heure de génération doit être postérieure à l'heure de confirmation. Si, après confirmation, la page, le texte, le prompt ou le plan subissent des modifications substantielles, une reconfirmation est nécessaire ; ne réécrivez pas l'heure après coup et ne remplacez pas le plan.

9. Génération d'image, réception visuelle et livraison

Avant la génération, lisez la compétence imagegen actuelle, puis transmettez les actifs de référence et les prompts compilés page par page directement à la capacité de génération/édition d'images de Codex. Les fautes de frappe peuvent être corrigées localement ; en cas d'échec du produit, de la composition, de la hiérarchie de l'information ou de la valeur commerciale, la page entière est refaite.

Révisez chaque image originale une par une avant de créer la planche contact. En plus de la couverture commerciale, de la divergence de placement, de la diversité de composition, de l'intégration du texte et de la cohérence du produit, review.set_checks doit également vérifier copy_richness, buyer_value, prompt_fidelity et claim_safety. Notez chaque page de 1 à 5 sur la valeur commerciale, la hiérarchie du texte, la cohérence du produit, la fidélité au prompt et le degré d'achèvement visuel ; toute note inférieure à 4 ne permet pas le pass. Des déclarations vagues comme « révision manuelle approuvée » ne constituent pas une preuve.

Avant la livraison, exécutez :

python3 scripts/validate_project.py path/to/project.json --project-dir path/to/project
python3 scripts/build_contact_sheet.py path/to/project.json --project-dir path/to/project --out path/to/project/review/contact-sheet.jpg
python3 scripts/validate_skill_release.py --full

Seul le même exécutant peut marquer manual_review ; le accepted final nécessite la confirmation de l'utilisateur ou d'un réviseur indépendant. Lors de la livraison, précisez clairement si l'on est actuellement en phase de validation technique, de validation des images réelles, d'acceptation par l'utilisateur ou de validation par le backend de la plateforme.