Communitygithub.com

工作流 de réplication de vidéos virales artistiques v6.1

Banque de cas vectoriels de vidéos virales intégrée, supportant l'analyse de nouvelles vidéos, la double ASR, les prompts Seedance et un contrôle qualité hiérarchisé pour Codex.

Qu'est-ce que 工作流 de réplication de vidéos virales artistiques v6.1 ?

Ce skill pour Codex standardise la réplication de vidéos virales en neuf étapes, de l'analyse du référence à la validation avant publication. Il intègre une base de connaissances vectorielle locale (2048 dimensions) de cas viraux historiques, permettant la recherche sans appel à des services payants, et supporte l'analyse de nouvelles vidéos (découpage, double ASR avec Alibaba Cloud, extraction d'images clés). Le workflow impose des contraintes visuelles strictes (produit et style), une compétition créative avec au moins 5 concepts, un contrat de réplication au format JSON (schema v4), des prompts Seedance par segment, et une série de portes qualité automatisées (pre-generation, pre-stitch, pre-publish). Il est conçu pour les créateurs de contenu et les marketeurs souhaitant reproduire ou adapter formellement des formats viraux, avec des livrables structurés (analyse, script, storyboard, prompts).

Compatible avec✓Claude Code✓Codex CLI~Cursor
npx skills add 784697524-ux/yishufan-viral-video-replica-workflow

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Workflow de réplication de vidéos virales artistiques v6.1

Chemin du package portable

Considérez le répertoire contenant ce SKILL.md comme SKILL_DIR. Ce package intègre dans vendor/watch/ les backends d'analyse, de sous-titrage et d'ASR. Utilisez le chemin portable suivant dans les exemples de commandes :

SKILL_DIR="<chemin complet vers le répertoire contenant ce SKILL.md>"

Périmètre de livraison

Par défaut, livrez : preuves de référence, faits sur le produit, verrouillage visuel du produit et du style, contrat de réplication lisible par machine, script seconde par seconde, caractérisation des personnages, storyboard en planches indépendantes, plan de mouvement plan par plan, prompts Seedance découpés par durée de modèle et rapport de validation avant génération.

Sauf demande explicite de l'utilisateur, ne générez pas de vidéo, ne consommez pas de crédits, n'exportez pas de rendu final et ne publiez pas. Si l'utilisateur demande explicitement une production complète, franchissez d'abord la porte de pré-génération, puis lisez intégralement la branche de production complète VidMuse ; les contenus sans preuve réelle doivent être marqués comme "extrapolation créative".

Entrée minimale

  • Source de référence au choix : un chemin local complet ou une URL publique d'une vidéo de référence, ou bien "Référence intelligente à la bibliothèque de cas viraux historiques" explicite.
  • Capture d'écran ou documentation détaillée du produit ; pour un produit physique, des images claires suffisantes pour verrouiller l'apparence, les proportions, les couleurs, les matériaux, la structure et le logo sont obligatoires. En cas de simple page de coupon/avantage, n'inventez pas d'angles physiques non montrés.
  • Image de référence de style ou vidéo de référence pouvant servir de preuve de style ; en l'absence d'image de style indépendante, considérez explicitement la vidéo originale comme source de style, ne la comblez pas arbitrairement avec un "haut de gamme" générique.
  • Mode de réplication et densité de rythme ; si l'utilisateur ne spécifie pas et que différents choix modifient le résultat, ne demandez qu'une seule fois.

Spécifications par défaut : 9:16, mandarin standard, chaque segment généré de 1 à 15 secondes. Lors de la création d'une fiche IA, le total des pièces jointes (personnages, storyboard, audio et produit) ne doit pas dépasser 9. La réplication visuelle haute-fidélité suit par défaut la durée complète de la vidéo originale ; les deux autres modes, par défaut 30 secondes si l'utilisateur ne spécifie pas. Ne supprimez pas le rebondissement de la vidéo originale pour atteindre deux segments.

Banque de cas vectoriels viraux intégrée (mode référence intelligente)

knowledge_base/index.sqlite3 est la base de semences prête à l'emploi : elle ne contient que des cas de projets officiels, pas de conversations privées, de clés API, de cookies ou de vidéos originales. Elle utilise des vecteurs de hachage locaux fixes à 2048 dimensions pour les caractères chinois et les étiquettes de mécanismes, sans recourir à des services d'embedding payants.

Lorsque l'utilisateur ne fournit qu'un coupon/produit, ou demande explicitement une sélection intelligente de référence parmi les cas viraux historiques, vous devez d'abord interroger la base vectorielle locale, sans sélectionner de cas au hasard de mémoire. Après la première installation, interrogez directement, sans avoir à créer la base au préalable :

python3 "${SKILL_DIR}/scripts/viral_library.py" search \
  "<besoin créatif complet>" \
  --top-k 5 \
  --out "<répertoire projet>/00_historical_match.md"

Synthétisez une requête complète incluant le produit, la population cible, le scénario d'utilisation, l'univers visuel, les relations entre personnages, l'émotion visée, la densité de rythme et les avantages confirmés ; ne vous limitez pas au nom du produit. La recherche renvoie des identifiants de cas ; pour lire l'archive textuelle complète d'un cas dans la base, exécutez :

python3 "${SKILL_DIR}/scripts/viral_library.py" show "<case_id>" \
  --out "<répertoire projet>/00_historical_case.md"

Après avoir effectué l'analyse, le script, le storyboard ou le débriefing d'une nouvelle vidéo et placé les résultats dans le répertoire de travail outputs/, rafraîchissez l'index local de l'utilisateur. Cet index fusionne par défaut la base de semences intégrée, et la recherche l'utilise en priorité :

python3 "${SKILL_DIR}/scripts/viral_library.py" build \
  --workspace "<chemin complet du répertoire de travail des vidéos virales>"

Lors des recherches ultérieures, ajoutez --workspace "<chemin complet du répertoire de travail des vidéos virales>" pour interroger la base fusionnée "cas intégrés + nouveaux cas utilisateur".

Par défaut, n'indexez pas les conversations privées de Codex. N'ajoutez --include-chats que si l'utilisateur demande explicitement une base privée purement locale ; les bases de données contenant des conversations ne doivent pas être distribuées à l'extérieur.

Le rapport de recherche doit fournir : une référence principale, un modèle de production réutilisable, jusqu'à deux références candidates, le mécanisme identifié, les chemins traçables vers l'analyse/le script/les prompts/le storyboard, la disponibilité actuelle de la vidéo originale, et les leçons des échecs à impérativement tirer. Règles d'exécution :

  • Lorsque decision=insufficient_match, arrêtez de forcer le modèle de référence ; demandez plutôt une nouvelle vidéo de référence ou effectuez une simple extrapolation de mécanisme original.
  • Les cas avec quality_status=blocked ne doivent pas réutiliser leur script, prompts ou storyboard ; si une analyse fiable de la vidéo originale existe, ne réutilisez que reference_analysis_only, tout en lisant son debriefing QC comme barrière négative.
  • quality_status=unknown n'équivaut pas à un succès ; cela indique seulement que le matériel historique n'a pas de conclusion publiable. Ce cas doit encore passer toutes les portes qualité lors de la création en cours.
  • La base de semences ne contient pas de vidéos originales ni d'actifs machine originaux ; vous ne pouvez citer que les timecodes, hachages, analyses, scripts et leçons d'échec archivés dans la base, et ne pouvez pas prétendre avoir revu la vidéo originale pour ce tour.
  • Même si la base locale de l'utilisateur contient explicitement des conversations historiques, leur poids reste inférieur à celui des artefacts formels du répertoire de travail ; elles ne remplacent pas les preuves d'analyse.
  • La recherche ne sélectionne que les mécanismes et les actifs ; elle ne concatène pas directement d'anciens scripts. Vous devez encore entrer dans la phase 3 de compétition créative, de test de suppression du produit, de table reading par prise et de contrat narratif schema v4.

Lorsque l'utilisateur fournit une nouvelle vidéo de référence, vous pouvez utiliser cette base pour rechercher des cas similaires et des leçons d'échec à titre d'aide, mais l'identité de la référence principale, sa durée et son SHA-256 doivent être basés sur la nouvelle vidéo réellement lue.

Phase 0 : Verrouillage du mode, de l'univers visuel et de l'identité des actifs

Avant de générer un script ou un storyboard, produisez :

Mode actuel : Réplication visuelle haute-fidélité / Transfert de mécanisme viral / Réplication mixte commerciale
Densité de rythme : Suivi de la vidéo originale / Densité standard / Densité élevée avec rebondissements
Périmètre de production : Pack d'actifs / Livraison de fiche IA / Vidéo complète
Type de mouvement : Dominé par la référence / Performance narrative / Publicité en mouvement continu
Raisonnement :
Contraintes matérielles de l'univers visuel :

Lisez intégralement references/trois_modes_de_replication.md. Exécutez un seul mode. Le média, la direction IP ou l'univers visuel spécifiés explicitement par l'utilisateur sont des contraintes matérielles globales ; elles ne sont pas annulées par "permettre le remplacement de personnages/scènes". Par exemple, un CG artistique historique ne doit pas être transformé en romance réaliste moderne.

Avant d'exécuter les backends, relisez le chemin absolu ou l'URL fournis par l'utilisateur pour ce tour. Il est interdit de sélectionner d'autres actifs en se basant sur des noms de fichiers similaires.

Phase 1 : Exécution du backend de preuves

Le contrat du backend est décrit dans references/backend_contract.md. Vérifiez d'abord la configuration Alibaba Cloud :

python3 "${SKILL_DIR}/scripts/configure_asr.py" --check

Si la configuration manque, exécutez la commande suivante ; la clé est lue via une entrée masquée, ne la placez pas dans la ligne de commande, le fichier de skill ou le rapport :

python3 "${SKILL_DIR}/scripts/configure_asr.py" \
  --endpoint "<Endpoint compatible-mode/v1 de l'espace métier Alibaba Cloud>"

Préparez les preuves de référence :

python3 "${SKILL_DIR}/scripts/prepare_reference.py" "<vidéo de référence>" \
  --out-dir "<répertoire projet>"

Ce script doit accomplir :

  • Verrouillage du chemin absolu, nom de fichier, SHA-256, durée, format d'image et paramètres audio/vidéo de l'actif local.
  • Extraction des images clés de toute la vidéo et capture dense à 2fps sans déduplication des 3 premières secondes.
  • Génération supplémentaire d'une timeline à 0,5 seconde fixe pour toute la vidéo ; même si la scène est statique, ne dédupliquez pas.
  • Forcer l'utilisation de l'espace métier Alibaba Cloud, sans passer par le Groq par défaut.
  • Transcrire séparément avec paraformer-v2 et paraformer-v1 et générer les timecodes.
  • Lorsque les deux modèles présentent des incohérences textuelles, marquez "À vérifier" ; ne les traitez pas directement comme des dialogues de personnages.

Examinez d'abord frame par frame la timeline fixe à 0,5 seconde listée dans watch/timeline_0_5s/timeline_manifest.json, puis examinez les images clés des scènes. Vous devez enregistrer dans le contrat de réplication le nombre d'images examinées et le dernier timestamp ; ne regarder que les images clés des scènes risque de manquer les longues pauses, les performances statiques de fin et les fins cycliques. Si vous détectez des rebondissements consécutifs, des actions rapides ou des inversions spatiales, exécutez pour chaque cluster de rebondissements :

python3 "${SKILL_DIR}/vendor/watch/scripts/watch.py" "<vidéo de référence>" \
  --detail balanced --start <début> --end <fin> \
  --fps 2 --no-dedup --resolution 1024 --no-whisper \
  --out-dir "<répertoire projet>/watch/reversal_<numéro>"

Par "analyse image par image" de ce skill, on entend : examen de chaque image de la timeline fixe à 0,5 seconde, examen de chaque image clé de scène, examen dense des 3 premières secondes et des clusters de rebondissements. watch est limité à 2fps ; vous ne pouvez pas prétendre avoir visionné chaque image brute encodée de la vidéo. Si l'utilisateur demande explicitement un examen complet à 30fps, vous devez indiquer qu'un pipeline de vision par ordinateur dédié est nécessaire.

L'ASR prouve uniquement la reconnaissance de sons, pas l'identité du locuteur. Les dialogues doivent être vérifiés conjointement avec les résultats des deux modèles, les sous-titres visibles, le mouvement des lèvres et l'action visuelle ; les paroles de fond et les dialogues des personnages doivent être enregistrés dans des colonnes séparées.

La phase 1 doit produire :

  • 00_source_manifest.json et 00_reference_evidence.md.
  • Durée, format d'image, nombre d'images extraites, modèle de transcription et état de la transcription.
  • Tableau des dialogues avec timecodes ; chaque ligne marquée comme dialogue de personnage/parole/effet sonore/à vérifier.
  • Tableau des plans avec timecodes : échelle, personnage, action, expression, regard, relation spatiale, mouvement de caméra et son.
  • Preuve seconde par seconde des 3 premières secondes, variation seconde par seconde des clusters de rebondissements, première apparition de la marque et point de mémorisation final.

Si la musique, les bruits de rupture, les impacts, les sons d'arrêt ou les boucles sonores de la vidéo originale font partie d'un rebondissement, listez-les séparément avec leurs timecodes dans le tableau sonore. Si vous devez fournir l'audio original à un modèle vidéo, utilisez scripts/extract_reference_audio.py pour extraire la piste mixte unique de la vidéo originale ; vous devez préciser qu'elle peut contenir à la fois musique, dialogues et effets sonores, sans prétendre avoir séparé la musique pure.

Phase 2 : Extraction des mécanismes, table des faits et double verrouillage produit/style

Vous devez répondre : pourquoi la première seconde retient-elle l'attention, pourquoi continue-t-on à regarder, quelle est la première erreur d'interprétation, où se produit le changement de pouvoir/causalité/signification des accessoires/vérité spatiale, pourquoi le produit devient-il la réponse à l'intrigue, pourquoi les 3 dernières secondes méritent-elles d'être vues.

Les changements de plan, d'angle, les explosions répétées ou les cris continus ne sont pas considérés comme des rebondissements. La densité élevée de rebondissements ne s'applique qu'aux clusters de rebondissements identifiés ; dans un cluster, au moins une variable effective doit être ajoutée par seconde, le niveau doit augmenter toutes les 2 à 3 secondes, et chaque changement ultérieur doit être causé par le précédent.

La table des faits sur le produit doit au minimum inclure : nom du produit, prix, avantages, magasins applicables, période de vente, période d'utilisation, mode de validation, restrictions et conditions d'annulation. Chaque élément doit être marqué avec sa source de preuve et son état de confirmation. Ne transformez pas un coupon d'éligibilité en un produit gratuit, et n'ajoutez pas de prix, quantités, dates et restrictions qui ne sont pas visibles ou fournis.

Créez simultanément 02_visual_lock.md :

  • Verrouillage produit : listez le chemin relatif, le SHA-256 et l'utilisation de chaque actif de référence produit ; verrouillez point par point l'apparence, les proportions, la couleur, la matière, la structure et le logo. Pour les faces, dos, interfaces, textes d'emballage sans preuve, appliquez systématiquement do_not_invent.
  • Verrouillage style : à partir de la référence de style ou de la vidéo originale, extrayez la lumière, les couleurs, la composition, le langage visuel, les personnages, les décors et les textures, générez un lock_id unique et un prompt de style réutilisable ; chaque prompt Clip doit intégrer textuellement ce prompt et le lock_id.
  • La liste des éléments prohibés n'enregistre que les actifs de ce tour et les styles en conflit demandés explicitement par l'utilisateur. Si la vidéo originale est néon ou cyberpunk, n'appliquez pas de prohibitions génériques.

Cette phase ne fait que verrouiller les preuves, sans concevoir d'idée créative. Les actifs de référence produit doivent être copiés dans le répertoire projet et liés à leur hachage ; s'il existe plusieurs angles, marquez-les séparément avec leur utilisation, et ne présentez pas d'images générées par IA comme preuve originale du produit.

Phase 3 : Compétition créative en salle de rédaction et conditions d'accès à la table de lecture

Il est interdit d'écrire un script seconde par seconde directement après avoir regardé la vidéo de référence. Décomposez d'abord la vidéo de référence en ADN du mécanisme : accroche d'ouverture, question du public, première erreur d'interprétation, moteur de conflit, mécanisme de rebondissement, récompense émotionnelle et point de mémorisation final. N'héritez ici que du mécanisme de diffusion, ne copiez pas les dialogues de surface.

La session d'écriture doit d'abord produire au moins 5 concepts narratifs véritablement différents ; écrivez-en 10 lorsque l'utilisateur demande explicitement une "publicité dynamique à gros budget" ou motion_profile=continuous_motion_ad. Chaque concept doit modifier au moins deux des éléments suivants : relation entre personnages, source de conflit, choix des personnages, intervention du produit, mode de rebondissement ou retour final. Chaque concept doit inclure une phrase d'histoire, le conflit, le choix du personnage, les conséquences visibles, le rebondissement inattendu, les preuves préalables, le rôle dramatique du produit et la conclusion. Pour les publicités en mouvement continu, ajoutez en une ligne les 6 à 8 nœuds d'action continue : "lancement du personnage → intervention du produit → changement d'environnement → escalade de l'action → climax → conclusion produit". Il est interdit de simuler plusieurs options par simple changement de mots ou de costumes.

La session d'évaluation note chaque concept : accroche des 3 premières secondes 20, causalité 25, fraîcheur 20, causalité produit 15, héritage du mécanisme de référence 10, générabilité par IA 10. Pour les publicités en mouvement continu, comparez en outre l'intensité dynamique, l'impact visuel, la continuité du mouvement, la relation personnage-produit, la complétude narrative et la faisabilité du découpage, sans modifier le score principal de 100 points. Le concept sélectionné doit avoir un score total d'au moins 85 et aucune disqualification stricte ; les concepts non retenus doivent avoir leur raison d'élimination. La session d'évaluation peut rejeter tous les concepts et demander une réécriture. Les disqualifications strictes incluent : personnage sans motivation pour un revirement, produit énuméré comme une liste, intrigue toujours valide après suppression du produit, magie sans mise en place, accessoire sans origine, voix off remplaçant une action clé, slogan final remplaçant la résolution de l'intrigue. Pour les publicités en mouvement continu, s'ajoutent les personnages qui posent seulement ou marchent lentement, le simple changement de fond, et l'utilisation de mouvements de caméra pour imiter l'action du sujet.

Élevez le concept sélectionné en narrative_qc.story_chain avant la table de lecture. Répondez pour chaque étape narrative : qu'est-ce que le public se demande à ce moment, qu'apporte cette prise, qui prend une décision ou réagit, quelle action visible pousse la prise suivante, l'acteur peut-il naturellement l'accomplir dans le temps imparti. Vous devez lire les dialogues à voix haute et chronométrer, et exécuter le test de "suppression du produit" ; si l'histoire tient toujours après suppression, retournez en salle de rédaction. N'entrez pas dans le script seconde par seconde tant que tous les problèmes de table de lecture ne sont pas résolus.

Inscrivez dans le contrat creative_room l'ADN du mécanisme, les 5 candidats, les scores détaillés, les disqualifications strictes, les raisons de sélection/élimination et les résultats de la table de lecture. La porte machine ne vérifie que les preuves et les conditions d'accès ; elle ne peut pas prétendre garantir un succès viral avant la publication. Seules les données de rétention des 3 premières secondes, de complétude et d'interaction après publication valident le résultat de diffusion.

Phase 4 : Registre des rythmes de la vidéo originale, contrat de réplication et mappage unique

Écrivez d'abord un registre des rythmes Rxx ordonné par temps pour chaque changement de causalité, pouvoir, signification d'accessoire, vérité spatiale et relation cyclique de la vidéo originale. En mode haute-fidélité, les nœuds causaux adjacents (question → erreur → attaque → révélation d'accessoire → excuses → seconde erreur → révélation spatiale → boucle finale) ne doivent pas être fusionnés, réordonnés ou supprimés ; le produit ne peut entrer qu'à une position explicitement autorisée par l'utilisateur.

En haut de 03_structure_mapping.md, indiquez le mode, la densité de rythme, les contraintes matérielles de l'univers visuel, ce qui doit être conservé et ce qui peut être remplacé. Établissez une chaîne unique :

R01 (preuve originale) → S01 (script nouveau) → B01 (fichier storyboard) → P01 (paragraphe Seedance)

Chaque nouveau plan doit remplir : timecode de référence, timecode du nouveau plan, fonction psychologique/visuelle du plan original, ce qui doit être conservé, ce qui peut être remplacé, fichier storyboard et paragraphe prompt. N'utilisez pas "semble cohérent" à la place d'une preuve vérifiable.

Créez simultanément un 08_replica_contract.json au format schema v4 selon la spécification JSON du contrat de réplication. Verrouillez d'abord avec brief_alignment le mode original de l'utilisateur, la durée originale, production_scope et les valeurs finales d'exécution ; tout changement doit être confirmé explicitement par l'utilisateur et la raison enregistrée. Il est interdit de modifier silencieusement le contrat pour passer la validation. Le contrat doit couvrir tous les Rxx du fichier d'analyse, et lier chaque rythme à un Sxx, Pxx, fichier storyboard et production_design.motion_beats uniques. Ne générez pas d'images ou n'écrivez pas de fiche IA tant que le contrat n'est pas terminé. L'ancien schema v3 est réservé à la révision des packs historiques ; les nouveaux projets ne doivent pas créer de v3.

Le contrat utilise schema_version=4. Terminez d'abord creative_room et sélectionnez l'unique concept ayant passé le seuil de 85 et la table de lecture, puis terminez narrative_qc.story_chain et le storyboard : la première étape doit être une question, le milieu doit contenir un choix du personnage et une conséquence visible, la dernière étape doit répondre à la question initiale ; chaque étape est liée aux précédentes par caused_by. Le produit assume au moins un rôle de preuve, d'enjeu, de déclencheur, d'obstacle ou d'outil de résolution. Par défaut, allows_unexplained_magic=false ; si l'utilisateur spécifie explicitement un univers fantastique, vous pouvez le passer à true, mais chaque changement surnaturel doit encore être déclenché par l'action précédente. Un "coupon soudainement activé, foule soudainement apparue, célébration soudainement commencée" sans choix du personnage est considéré comme une rupture causale et doit être réécrit.

Remplissez également :

  • dialogue_requirements : chaque Clip non silencieux doit contenir au moins une phrase ou un mot clé à ne pas perdre.
  • prop_continuity_requirements : événements d'apparition, de transmission/utilisation et de résultat des accessoires clés.
  • director_requirements : point de mémorisation final et arc de performance du personnage "départ → tournant → résultat".
  • finale_policy : ne peut être que story_action ou source_fact_card. Le premier exige une action/réaction visible dans les 3 dernières secondes ; le second n'autorise la conclusion de l'intrigue qu'après sa résolution visible, en utilisant une image factuelle réelle fournie par l'utilisateur, avec verrouillage du fichier source et des timecodes de début/fin.
  • production_design : enregistre les actifs de référence produit et leurs hachages, les six caractéristiques immuables, le verrouillage de style, l'état de la musique, le type de mouvement, et pour chaque Pxx, l'état de départ → action du personnage → action du produit → réaction de l'environnement → mouvement de caméra → changement de vitesse → état final → déclencheur de transition → point de synchronisation musicale.

Chaque rythme de mouvement est chaîné via handoff_in/handoff_out de START à END en une chaîne unique, et utilise product_visibility=visible/withheld_for_reveal pour distinguer l'exposition réelle du retard dramatique ; seuls les rythmes visible forcent la liaison de l'actif produit dans le prompt. Les plans dynamiques doivent passer le test "après suppression du mouvement de caméra, le personnage ou l'environnement a encore un mouvement significatif" ; l'immobilité intentionnelle n'est autorisée que pour les preuves de la vidéo originale, une brève accumulation d'ouverture ou un logo final, avec justification écrite. Les actions complexes doivent lier au moins trois images clés (début, milieu, fin). Les publicités en mouvement continu doivent comporter au moins trois niveaux différents d'escalade dynamique, le niveau le plus élevé étant au moins 4.

Exécution selon le mode :

  • Réplication visuelle haute-fidélité : conserve l'ordre des plans, les proportions de durée, l'échelle, la position de la caméra, le mouvement, la direction d'action, les transitions, la structure des scènes, la lumière et les couleurs.
  • Transfert de mécanisme viral : conserve les points d'arrêt, le chemin d'erreur, les changements de pouvoir, les niveaux de rebondissement, l'escalade causale et le point de mémorisation final, sans exiger de similarité visuelle plan par plan.
  • Réplication mixte commerciale : reconstitue le conflit commercial dans les 0 à 3 secondes ; après 3 secondes, restaure l'ordre des plans, les proportions de durée et les rythmes visuels de la vidéo originale.

N'appliquez pas de règles de validation supplémentaires d'autres modes.

Phase 5 : Écriture du script seconde par seconde selon la chaîne causale originale et découpage dynamique

Terminez d'abord le script seconde par seconde entier, puis découpez-le en Clips aux endroits qui ne coupent pas les dialogues ou les rebondissements causaux. Chaque segment doit durer de 1 à 15 secondes, couvrant en continu la durée cible à partir de 0 seconde. Chaque segment contient au maximum 3 unités exécutables ; pour les films narratifs, au maximum 2 unités de dialogue et 1 ligne principale de faits sur le produit. Chaque unité de temps doit utiliser un tableau Markdown lisible, la colonne de temps peut être dans les trois premières colonnes, format début-fin, et spécifier Sxx/Pxx, l'échelle, le mouvement de caméra, la position gauche/droite/avant/arrière des personnages, les directions du corps et du regard, le locuteur et le destinataire, les actions des mains et du corps, le début/évolution/résultat de l'expression, le dialogue en mandarin, la synchronisation labiale, les points d'ancrage de continuité et le son.

Immédiatement après avoir terminé le script, exécutez l'analyse automatique, sans plus de déclaration manuelle du nombre de secondes de parole, de caractères chinois ou de rythmes :

python3 "${SKILL_DIR}/scripts/analyze_script.py" \
  "<répertoire projet>" --out "<répertoire projet>/07_script_analysis.json"

Le programme calcule la durée minimale de parole à 4,2 caractères par seconde ; le dialogue narratif occupe au maximum 60% du Clip, la voix off de montage au maximum 75%, la récitation de poèmes classiques au maximum 92%. Il rejette également les unités surchargées, les tours de parole excessifs, les dialogues de type liste de produits, le placement du produit dans les 30% avant sans autorisation et les explications magiques non autorisées. En cas d'erreur, ne générez pas d'images.

En principe, la vente forcée du produit ne doit pas apparaître dans les 30% avant. Le produit résout un problème d'intrigue via des avantages confirmés dans la seconde moitié ; si la vidéo originale utilise le produit comme accroche de la première seconde, cela n'est autorisé que si l'utilisateur le demande explicitement et que les faits sur le produit sont complets. La fin par défaut doit comporter une action, une réaction de groupe ou un second rebondissement. Seul le finale_policy.type=source_fact_card permet, après que le problème d'intrigue a été visiblement résolu, d'utiliser une image réelle du produit/avantage pendant 1 à 2 secondes pour conclure, sans dépasser 2,5 secondes ; il est interdit d'utiliser une image redessinée par IA ou une affiche statique sans fichier source lié pour remplacer la résolution de l'intrigue.

Phase 6 : Définition des personnages et storyboard en planches indépendantes

Avant la première génération d'images, lisez intégralement la description du skill imagegen installé dans l'environnement Codex actuel ; utilisez par défaut image_gen intégré, sans basculer arbitrairement vers CLI/API.

  1. Générez d'abord une image de définition unifiée du personnage : face, profil, dos et expressions clés.
  2. Utilisez cette image comme référence d'identité pour toutes les images narratives.
  3. Chaque plan de storyboard fait l'objet d'un appel de génération d'image séparé ; il est interdit d'utiliser des grilles 3x3, des colonnes de bande dessinée ou des collages pour remplacer des planches indépendantes.
  4. Enregistrez chaque image dans le répertoire projet, et vérifiez point par point le personnage, le décor, les accessoires, la direction d'action, le destinataire du dialogue, l'absence de sous-titres/codes QR/texte non autorisé, et le format 9:16.
  5. La dernière image d'un Clip et la première image du suivant doivent réutiliser le même fichier ou une copie identique pixel pour pixel ; la position, la posture, l'orientation, les accessoires, le temps et la lumière des personnages restent cohérents.
  6. Lorsque l'utilisateur spécifie des textes précis devant apparaître sur un éventail, une enseigne, un emballage, etc., seuls ces textes de la liste blanche sont autorisés ; dans le prompt de génération, écrivez-les caractère par caractère, après génération utilisez view_image pour vérifier visuellement qu'ils ne sont pas inversés ou mal orthographiés, puis inscrivez-les dans visual_text_requirements du contrat. À ce stade, il est interdit de continuer à utiliser une contrainte contradictoire comme "aucun texte dans l'image".
  7. Les actions complexes génèrent respectivement des images clés de début, milieu et fin ; les actifs de référence ne verrouillent que l'identité, le produit et l'état, sans figer la posture du personnage. Les images clés ne servent que d'entrée pour le modèle vidéo, pas comme plans dynamiques finaux.

Chaque plan de storyboard doit être lié à un ID de plan, un point temporel, un timecode de référence, un objectif visuel, une échelle/position de caméra/composition, trois états d'action et un prompt de génération.

Phase 7 : Prompts Seedance

Pour chaque segment, produisez un bloc de code copiable en entier, contenant le format d'image, la durée précise, le verrouillage produit, le lock_id de style avec le prompt de style complet réutilisable, le rôle de l'image de référence, le plan seconde par seconde, l'action, l'objet du dialogue, la synchronisation labiale en mandarin, la continuité de début/fin et les restrictions négatives.

En début de prompt, listez un par un les noms de fichiers des pièces jointes réelles de ce segment et leur rôle ; dans le corps, chaque Pxx répète le nom du fichier storyboard correspondant. Ne vous contentez pas d'écrire "pièces jointes de référence". Si vous utilisez la musique ou les effets sonores de la vidéo originale, le contrat doit enregistrer séparément les intervalles extraits de l'original et les intervalles d'utilisation dans la cible, et le prompt doit mentionner le nom du fichier audio, les heures de début/fin cibles et "ne pas remplacer par une autre musique". "BGM du même segment original" ne remplace pas un nom de fichier.

À l'exception du texte spécifié dans la liste blanche du contrat, l'image ne doit pas générer de sous-titres, d'anglais, de codes QR ou d'informations non pertinentes. En modes haute-fidélité et mixte commercial, spécifiez pour chaque ID de plan l'ordre, la durée, la position de la caméra, le mouvement, la direction d'action et la transition ; en mode transfert de mécanisme à densité élevée, fournissez d'abord un tableau des rythmes seconde par seconde, puis écrivez les prompts dans le même ordre.

Chaque Pxx doit répéter point par point la chaîne de mouvement du contrat : état de départ, action continue du personnage, mouvement du produit, réaction de l'environnement, mouvement spatial de la caméra, changement de vitesse, état final, action déclenchant la transition et point de synchronisation musicale. Un seul plan ne doit comporter qu'une action principale du personnage et un mouvement principal de la caméra ; si l'action du personnage est complexe, simplifiez le mouvement de la caméra, et vice versa. Il est interdit d'utiliser des zooms, des zooms numériques, des remplacements de fond ou des changements rapides pour simuler des événements dynamiques.

Phase 8 : Livraison facultative de la fiche IA

N'exécutez cette phase que si l'utilisateur demande explicitement l'écriture d'une fiche IA. Utilisez d'abord le skill DingTalk pour lire la Base réelle, les sous-tables, les champs et les enregistrements cibles, et ajoutez les champs de vidéo automatique, de formule, de coût et de résultat de génération dans aitable_handoff.protected_field_ids du contrat. L'écriture n'est autorisée que dans les champs de prompt et de pièces jointes ; chaque enregistrement ne doit pas dépasser 9 pièces jointes au total (personnages, storyboard, audio et produit), et vous devez d'abord réserver des places pour les images de personnages et l'audio avant de décider du nombre de planches de storyboard. Lors de la mise à jour des pièces jointes, lisez d'abord les pièces jointes actuelles et effectuez un remplacement complet avec conservation ; il est interdit de soumettre uniquement de nouveaux fichiers, ce qui ferait perdre les anciens. Après avoir écrit chaque enregistrement, relisez-le : le prompt, les noms/nombres de fichiers joints, et les valeurs d'origine des champs protégés doivent être conservés ; n'appuyez pas par inadvertance sur le bouton de génération. Après que l'utilisateur a explicitement demandé la génération, relisez enregistrement par enregistrement ID enregistrement → ID Clip → fichier/lien résultat → durée réelle → résolution → état d'achèvement, téléchargez, et assemblez uniquement dans l'ordre temporel des Clips du contrat, pas par ordre de téléchargement ou de ligne de tableau.

Phase 9 : Livraison après validation

Utilisez templates/tableau_de_qualite_avant_generation.md pour effectuer le contrôle qualité du contenu, puis exécutez la porte de qualité avant génération :

python3 "${SKILL_DIR}/scripts/run_quality_gate.py" \
  "<répertoire projet>" --stage pre-generation \
  --out "<répertoire projet>/07_quality_gate_pre_generation.json"

Seul decision=allow_generation autorise la génération d'images ou l'écriture de la fiche IA. La porte générale exécute simultanément la validation du contrat/des actifs et l'analyse automatique du script ; en cas d'échec, elle indique le niveau auquel revenir. --legacy ne permet de vérifier que les anciens packs, pas de servir de base de livraison pour les nouveaux projets.

Lorsque l'utilisateur demande explicitement une production complète avec VidMuse (génération, montage, export), n'entrez dans la branche de production complète VidMuse qu'après avoir obtenu allow_generation ici. Cette branche doit d'abord lire en temps réel le compte, les crédits, les modèles disponibles et les paramètres de génération, puis calculer le budget incluant la marge de régénération des plans problématiques ; ne présumez pas du nom du modèle, du prix, de la durée ou des capacités de la timeline uniquement à partir de ce document ou de l'historique. En l'absence de demande explicite de génération, arrêtez-vous ici.

Une fois que l'utilisateur fournit les rendus finaux, exécutez la validation structurelle :

D'abord, pour les vidéos segmentées retournées par la fiche IA, créez un 09_delivery_manifest.json n'enregistrant que dans l'ordre du contrat le clip_id et le fichier réel :

{"outputs":[{"clip_id":"clip01","file":"renders/clip01.mp4"}]}

Le format du manifeste après génération est décrit dans spécification des manifests de qualité après génération. Préparez le manifeste des segments de la fiche IA, le manifeste ASR candidat et les preuves du réalisateur ; avant l'assemblage, exécutez :

python3 "${SKILL_DIR}/scripts/run_quality_gate.py" \
  "<répertoire projet>" --stage pre-stitch \
  --delivery-manifest "<répertoire projet>/09_delivery_manifest.json" \
  --asr-manifest "<répertoire projet>/10_asr_manifest.json" \
  --director-manifest "<répertoire projet>/11_director_qc.json" \
  --out "<répertoire projet>/12_quality_gate_pre_stitch.json"

Seul decision=allow_stitch autorise l'assemblage. Cela rejette les segments manquants, dans le mauvais ordre, en double, avec des écarts de durée, non 9:16, sans piste audio, avec des pertes de dialogues clés, des étapes narratives invisibles, des arcs de performance manquants, des accessoires sans origine, des échecs de continuité, des points de mémorisation finaux manquants, des disqualifications strictes ou un score réalisateur inférieur à 85.

Pour le rendu haute-fidélité, exécutez également la validation structurelle par rapport à la vidéo originale :

python3 "${SKILL_DIR}/scripts/validate_render.py" \
  "<vidéo originale>" "<rendu>" --out "<répertoire projet>/QC/rendu"

Si la durée totale du rendu, la densité de changement de plans, l'énergie médiane audio ou la dynamique du centile inférieur audio n'atteint pas les seuils, déclarez directement "non aligné", même si l'événement principal de l'intrigue apparaît. La dynamique du centile inférieur permet de détecter les cas où le volume global est acceptable mais où les intervalles clés (explosions, impacts, musique de transition, etc.) sont en fait absents. Ensuite, examinez toutes les images à 0,5 seconde générées par le script et vérifiez les dialogues du contrat mot pour mot avec l'ASR candidat.

Quel que soit le mode, chaque segment retourné par la fiche IA doit être vérifié individuellement : durée réelle par rapport à la durée du contrat (tolérance 0,5 seconde), continuité des personnages/accessoires, chaque étape causale de narrative_qc et l'ordre des segments. Si un seul point échoue, le résultat est considéré comme "résultat de génération" uniquement, ne pouvant pas être assemblé ou publié.

Après l'assemblage, exécutez à nouveau prepare_reference.py sur le MP4 final lui-même, en écrivant l'ASR double modèle et la timeline fixe à 0,5 seconde dans un répertoire QC indépendant ; ne copiez pas manuellement l'ASR segmenté en le présentant comme l'ASR final assemblé. Conformément à la spécification des manifests de qualité après génération, créez un 13_final_manifest.json où la vidéo finale, les fichiers de preuve ASR et les images factuelles réelles sont tous liés par SHA-256. Ensuite, exécutez pour tous les modes :

python3 "${SKILL_DIR}/scripts/run_quality_gate.py" \
  "<répertoire projet>" --stage pre-publish \
  --delivery-manifest "<répertoire projet>/09_delivery_manifest.json" \
  --asr-manifest "<répertoire projet>/10_asr_manifest.json" \
  --director-manifest "<répertoire projet>/11_director_qc.json" \
  --final-manifest "<répertoire projet>/13_final_manifest.json" \
  --out "<répertoire projet>/14_quality_gate_pre_publish.json"

Seul decision=allow_publish permet de qualifier le résultat de "publiable". La porte finale lit réellement la durée, le format, la piste audio et le hachage du rendu assemblé, charge les résultats d'au moins deux modèles différents à partir du fichier de preuve ASR, et vérifie la similarité des pixels de la carte factuelle dans le rendu final. En cas d'incohérence entre les deux modèles, une personne ayant réellement écouté la piste audio du rendu doit remplir le vérificateur, l'heure, les ID de dialogue confirmés et la raison ; ni le modèle ni le résultat ASR ne peuvent marquer human_audio_qc comme réussi. En mode haute-fidélité, ajoutez également --render-validation comme porte supplémentaire pour l'alignement structurel avec la vidéo originale.

Répertoire de livraison standard

outputs/<nom_projet>/ 
├── 00_source_manifest.json 
├── 00_reference_evidence.md 
├── 01_reference_analysis.md 
├── 02_product_facts.md 
├── 02_visual_lock.md 
├── 03_structure_mapping.md 
├── 04_script.md 
├── 05_seedance_prompts.md 
├── 06_pre_generation_qc.md 
├── 07_script_analysis.json 
├── 07_quality_gate_pre_generation.json 
├── 08_replica_contract.json 
├── 09_delivery_manifest.json (après génération) 
├── 10_asr_manifest.json (après génération) 
├── 11_director_qc.json (après génération) 
├── 12_quality_gate_pre_stitch.json (après génération) 
├── 13_final_manifest.json (après assemblage) 
├── 14_quality_gate_pre_publish.json (après assemblage) 
├── asr/ 
├── audio/ (si nécessaire, musique ou effets sonores de la vidéo originale) 
├── watch/ 
├── character/character_sheet.png 
└── storyboard/ (PNG indépendants par plan ; lors de l'écriture de la fiche IA, réservez des places dans la limite totale de 9 pièces jointes pour les images de personnages, l'audio, etc.)

Les modèles d'appel sont décrits dans templates/modele_appel.md.

Périmètre du débriefing du rendu final

Lorsque l'utilisateur fournit ultérieurement un rendu, exécutez d'abord l'ASR double modèle du MP4 final et la porte générale pre-publish ; pour le mode haute-fidélité, exécutez également validate_render.py. Ensuite, confirmez si l'objectif est "vérification de correspondance" ou "évaluation de qualité". La vérification de correspondance compare la timeline fixe de la vidéo originale, le script, le storyboard, les prompts, les timecodes du rendu et l'ASR candidat ; n'utilisez pas d'adjectifs qualitatifs pour remplacer les preuves de la chaîne de plans. Une expression exagérée sur une seule image ne signifie pas un alignement de performance ; vous devez vérifier le début, l'évolution et le résultat de l'expression. Lorsqu'un nouvel accessoire apparaît, vous devez voir l'action de le sortir, de le transmettre ou de le transformer.

Skills associés