Viva Video

Créez une vidéo de lancement de produit ou d'explication de concept précise, claire, et dont chaque image est générée par du code, à partir d'un seul document source.

Différence avec cinematic-product-video : celui-ci utilise SeedDance pour générer des plans cinématographiques, orienté marque. Celui-ci ne génère aucun plan, tout est rendu par code, orienté information. Les deux skills sont indépendants, ne les mélangez pas.

La livraison est une vidéo finale, pas un storyboard. Lorsque seules des modifications de spécifications ou des modifications du prompt sont demandées, limitez-vous à la révision et à la validation des fichiers, sans lancer de génération payante ou de rendu complet.

Première étape : comprendre le document. Si cette étape échoue, tout le reste est faux

La principale raison d'une vidéo confuse n'est pas le rendu, c'est de commencer la mise en page sans maîtriser le document. La section comprehension de film-rules.yaml est bloquante, compose_spec.py l'appliquera.

Vous devez produire trois fichiers

Fichier	Contenu	Rôle
`UNDERSTANDING.md`	Qu'est-ce que c'est, quel problème pour qui, la chaîne causale du mécanisme, les chiffres clés et leurs conditions de mesure, les trois questions auxquelles le spectateur doit pouvoir répondre après visionnage, ce que le document n'affirme pas, les points incompris marqués `unknown`	Empêche la vidéo de dire des absurdités ou d'exagérer
`CLAIMS.md`	Chaque conclusion sur une ligne : claim / source dans le document / mécanisme / bénéfice / conditions limites / preuve visuelle / formulation de risque	Chaque phrase dans la vidéo doit pouvoir être retracée à ce tableau
`CONCEPT_MAP.md`	Chapitres du document → claims → mécanismes et bénéfices → sujet et action visuels → erreurs d'interprétation interdites → preuves nécessaires au jugement	Traduit « quoi dire » en « quoi dessiner »

En même temps, remplissez les conclusions dans content.understanding de content.yaml, compose_spec.py le validera.

Fermez le document, répondez à ces cinq questions

Si vous ne pouvez pas répondre, relisez le document. Ne continuez pas avec des points d'interrogation.

Quel problème ce produit résout-il, comment l'utilisateur faisait-il avant, quelle était la douleur ?
Expliquez le mécanisme comme une chaîne causale, sans sauter d'étape.
Quel chiffre prouve le mieux la conclusion, dans quelles conditions a-t-il été mesuré, la conclusion tient-elle si les conditions changent ?
Quelle est l'interprétation erronée la plus probable du spectateur, comment l'image doit-elle la prévenir ?
Quelles phrases dans le document sont du langage marketing, et ne peuvent pas être présentées comme des faits ?

Après avoir compris, réorganisez, ne suivez pas la table des matières

L'ordre doit être : problème → coût de l'ancienne méthode → nouveau mécanisme → preuve → limites d'application → prochaine action. Chaque scène ne présente qu'une seule conclusion ; la conclusion d'abord, puis le mécanisme, puis la preuve. Expliquez chaque terme technique en une phrase lors de sa première apparition.

Interdit : Utiliser « amélioration massive », « mise à niveau complète », « optimisation significative » à la place des chiffres spécifiques donnés dans le document ; inventer des chiffres si le document n'en donne pas ; présenter une feuille de route comme déjà livrée ; réécrire un exemple de code pour le rendre plus joli mais inexécutable ; deviner le contenu d'un chapitre sur la base de son titre. compose_spec.py détectera ces expressions vides et signalera une erreur.

Point de contrôle

Avant d'écrire content.yaml, montrez UNDERSTANDING.md, le plan des chapitres, la conclusion d'un chapitre par une phrase, et le prototype visuel prévu pour chaque chapitre à l'utilisateur. Ne passez pas à la couche visuelle tant que la couche factuelle n'est pas approuvée. Cette étape est la moins chère pour faire des modifications ; refaire la vidéo finale est la plus chère.

Source de la méthode : les sections sur la table de décision des transitions, le trio de focus, le squelette énergétique, le test des trois mètres, et la typographie chinoise sont empruntées à huashu-design. Ce qui a été emprunté, ce qui a été consulté mais pas emprunté, et pourquoi, est consigné dans references/borrowed-from-huashu-design.md.

Structure à trois couches, seule la couche du milieu change à chaque fois

Couche	Fichier	À faire à chaque vidéo
Couche des règles	`references/film-rules.yaml`	Ne pas modifier. Ce qui doit être fait : comprendre le document, une idée par image, correspondance un-à-un entre narration et unités d'information, éclairer ce qui est dit, zéro cut sec, densité minimale, invariants de rendu R01–R30, portes de validation Q01–Q38, méthodes de mesure et seuils
Thème	`themes/<nom>/theme.yaml`	Modifier seulement pour changer l'apparence. À quoi ça ressemble : dérivation de la palette de couleurs, tailles de police, coordonnées, dessin des cartes et de la navigation, courbes d'assouplissement, sélection des transitions, encrage du focus, BPM et instrumentation de la musique
Contenu du produit	Votre `content.yaml`	Écrire uniquement ceci. Compréhension, faits, chapitres, claims, métriques, ressources de marque, table de prononciation, méthode d'explication de chaque chapitre et unités d'information
Produit de synthèse	`video-spec.resolved.yaml`	Ne pas modifier à la main, généré par script

Il n'y a qu'une seule ligne de démarcation entre la couche des règles et le thème : changer l'apparence ne devrait pas permettre de changer « la narration doit correspondre à l'image ». Les critères restent dans la couche des règles, l'apparence est confiée au thème ; theme_contract écrit les deux sous forme de listes vérifiables par machine ; si le paquet manque une clé, dépasse les limites, ou modifie les critères, validate_spec.py le rejette immédiatement. Le thème par défaut est daylight (fond quasi blanc + cartes blanches + dégradé de trois points d'ancrage aux couleurs de la marque), c'est l'apparence par défaut du skill. Comment créer un nouveau thème, voir themes/README.md.

SKILL=~/.agents/skills/viva-video
cp $SKILL/templates/content.example.yaml ./content.yaml
# D'abord comprendre le document, remplir understanding ; puis remplir le reste TODO
python3 $SKILL/scripts/compose_spec.py  ./content.yaml -o ./video-spec.resolved.yaml  # Ajouter --theme <nom_du_thème> pour changer l'apparence
python3 $SKILL/scripts/validate_spec.py ./video-spec.resolved.yaml --self-test

examples/content.viva-video.yaml est un exemple rempli (vidéo de lancement de viva-video 1.0 elle-même, 7 chapitres).

Modèles vocaux et vidéo : l'utilisateur donne ce qu'il utilise, sinon on utilise seulement ses propres capacités

Le skill ne fournit aucune adresse ou clé pour des modèles vocaux ou vidéo.

Si l'utilisateur explique comment appeler sa synthèse vocale, sa reconnaissance vocale ou son modèle vidéo (commande, interface API, script existant) : encapsulez-le dans une commande dans providers.json, puis tts.mjs, pron_calibrate.mjs, asr_check.mjs --backend command l'utiliseront. Les clés restent uniquement dans les variables d'environnement ou la configuration de l'utilisateur, ne les écrivez pas dans les fichiers du projet, les logs et les messages.
Si l'utilisateur ne dit rien : utilisez uniquement les capacités dont dispose l'agent. Si un outil vocal existant est disponible dans l'environnement, utilisez-le ; sinon, produisez une vidéo avec sous-titres uniquement, sans narration, et marquez le contrôle de prononciation not_tested. Ne devinez pas et ne cherchez pas d'adresses ou de clés de service.

Voir references/providers.md pour le format, l'ordre de recherche et la table de dégradation.

Les trois premières choses lors du changement de produit, l'ordre ne doit pas être inversé

1. Définir la prononciation

La TTS chinoise lit Rspack comme un mot anglais entier, le s est avalé – les tests montrent qu'il est retranscrit Spac.

La correction est de faire lire la TTS lettre par lettre, pas de transcrire le nom en caractères chinois. Format : RS + espace + reste du mot anglais.

Affiché	Envoyé à la TTS	Prononcé
Rspack	`RS pack`	R-S-pack
Rsbuild	`RS build`	R-S-build
Rstest	`RS test`	R-S-test
Rsdoctor	`RS doctor`	R-S-doctor

Testé le 2026-11-04 (voix féminine chinoise, vitesse 1.24, retranscrit avec faster-whisper local après synthèse) :

Format	Retranscription	Verdict
`Rspack`	Spac	Non, `s` perdu
`RS pack`	RSPAC	Adopté, les quatre noms totalisent 7.78s
`R S pack`	RS Pack	Utilisable, légèrement plus long
`R 斯 pack`	OSPAC	Non, le caractère chinois « 斯 » dévie le `R` précédent
`R-S-pack`	RS Pack	Non, le trait d'union insère une pause, la phrase entière est plus longue de 1.5s
`而斯派克`	而斯派克	Non, entièrement sinisé, le mot anglais a disparu

Les unités doivent être développées : testé, 915.8 ms est lu « 915.8 mètres ». Écrivez « 915.8 毫秒 ». pronounce.py fait cela automatiquement (ne remplace que les unités après les chiffres).

Les abréviations en lettres (SSR / BFF / SWC / CLI), les décimales, les pourcentages, les numéros de version 3.0 sont tous lus correctement, ne les modifiez pas inutilement.

python3 scripts/pronounce.py --self-test                 # 8 tests
python3 scripts/pronounce.py "Le temps d'analyse passe de 915.8 ms à 51.6 ms."
node     scripts/pron_calibrate.mjs --terms terms.json   # Testez et choisissez le format lors du changement de produit ou de voix
node     scripts/asr_check.mjs --spec video-spec.resolved.yaml --voice voice/

Lors d'un changement de voix, de vitesse de parole, ou de l'introduction d'un nouveau terme, exécutez toujours pron_calibrate.mjs en premier pour tester, ne recopiez pas les conclusions ci-dessus. La prononciation des lettres varie selon les voix. Ne marquez pas la prononciation comme réussie sans un nouveau test ; le succès ASR ne signifie pas que la prononciation est naturelle, marquez not_tested sans écoute.

2. Définir la couleur du thème et le dégradé

python3 scripts/theme_resolve.py --svg brand/logo.svg --out qa/theme-resolution.json
python3 scripts/theme_resolve.py --hex '#F93920'

Selon design.theme.resolution_order : spécifié par l'utilisateur → SVG de la marque → variables CSS du site officiel → couleur décorative du document → fallback. Les couleurs brutes obtenues sont d'abord converties en OKLCH, la luminosité est serrée entre 0.45 et 0.62, la chrominance entre 0.12 et 0.22, la teinte d'origine est conservée. Si la couleur dépasse l'espace sRGB, la chrominance est réduite pour la mapper, il est interdit de découper canal par canal – le découpage modifierait la teinte, ce qui annulerait la normalisation.

Le dégradé à trois points d'ancrage suit la même direction sur le cercle chromatique, vers le point d'ancrage magenta (H=350°), la plage est serrée entre 55° et 86°, le secondary se trouve à 40%. Un aller-retour ferait faire demi-tour au dégradé au milieu, ce qui ressemblerait à un bug. En injectant la couleur principale de la vidéo de référence, on reproduit son propre #376CFF → #8E33F2 → #E3429B.

Deux pentes : les titres utilisent la pente pleine saturation, les grands chiffres ≥96px utilisent une pente plus claire (L +0.13, C −0.06) – les grands caractères ont une grande surface, la pleine saturation écraserait le titre.

Seuils de contraste : texte principal 4.5, grands caractères avec couleur de marque 3.0, valeurs principales ≥96px 2.3 (la vidéo de référence elle-même mesure 2.37–2.86, un seuil plus strict rendrait tout le dégradé trouble).

Le rouge, le vert et l'orange sont des couleurs sémantiques, ne participent pas à la dérivation. Il est interdit d'utiliser le rouge error comme bordure de conteneur ordinaire ou décoration.

3. Choisir un prototype visuel et une méthode d'explication pour chaque chapitre

Les prototypes visuels sont choisis parmi les huit de scene_language.archetypes : graphe de dépendances, code plus relations, requête-réponse, découvrir puis demander, métriques avant-après, matrice de capacités, machine à états, architecture en couches. Deux chapitres adjacents ne doivent pas se répéter.

La méthode d'explication (explanation_mode) est choisie dans explanation_modes.vocabulary, elle détermine si cette page doit être animée ou non et comment. Regardez d'abord le type d'information, puis consultez la table de sélection (voir section « Comment expliquer les informations abstraites » ci-dessous).

Les unités d'information : chaque chapitre écrit 3 à 5 courtes étiquettes, c'est à la fois la base de la densité minimale et la limite supérieure de « trop de contenu sur une seule image ».

Les trois éléments sont vérifiés par compose_spec.py.

Mise en page : plénitude ou dispersion

Le titre est toujours en deux parties : « préparation, conclusion »

La première partie est en encre normale, la deuxième partie entière est en dégradé. La séparation ne peut tomber que sur un signe de ponctuation, la partie conclusion occupe 35% à 70%.

Concise, linéaire, | chaque étape a du sens même lue indépendamment
Déclaré une fois,   | vérification à l'exécution et documentation automatiquement prêtes
Testé sur la même machine, | exécute plus, plus vite, plus économique

Dans content.yaml, écrivez headline_lead + headline_emphasis, compose_spec.py vérifie la proportion et la séparation. Notez que c'est différent de title (nom du chapitre) : le nom du chapitre apparaît sur la page de chapitre et la navigation, le headline est le grand titre de la page de contenu.

Budget de dégradé : au maximum 1 titre + 1 valeur principale + 2 mots-clés par page. Au-delà, ce n'est plus un signal de mise en valeur. Le dégradé est interdit sur les polices <32px (des bandes de rupture sont mesurées), il est interdit d'ajouter des contours, des ombres portées, de la lueur, ou un dégradé animé.

Remplir d'abord les emplacements, donner le contenu clé ensuite

Dessinez d'abord tous les emplacements dans la première image de la scène – bordures de conteneurs, titres d'emplacements (chip + titre + ligne de séparation), squelette du contenu ; ensuite seulement modifiez le contenu et l'opacité, la boîte englobante ne bouge pas. Le contenu clé (valeurs, code, étiquettes) est laissé jusqu'à ce que la narration le mentionne.

Cette règle résout trois problèmes à la fois : la page est pleine dès la première image, le spectateur ne voit pas de page vide « en construction » ; il n'y a pas de tremblement de remise en page pendant le remplissage ; le premier regard voit la structure de la page, et sait que plusieurs choses seront expliquées.

Le squelette doit avoir un titre ou une structure d'espace réservé, il ne doit pas s'agir d'un rectangle arrondi blanc vide.

L'en-tête de l'emplacement ne doit pas attendre le contenu pour apparaître. Bug mesuré le 2026-11-05 : les emplacements feature et stage avaient leurs titres attachés à l'événement de révélation du contenu, ce qui faisait que les deux cartes du bas étaient des rectangles blancs purs au début de la page. L'en-tête fait partie du conteneur, le contenu fait partie du rythme.

Cette règle a un seuil de détection au pixel près (test réel de R18) : le plus grand rectangle vide dans la zone de texte de la première image de la scène (au moment où la transition se termine) ≤ 0.26. Tester uniquement l'image stable ne suffit pas – sur l'image stable, la page est bien pleine, mais on ne voit pas l'état semi-vide des huit premières secondes.

Ne pas assombrir les emplacements vides. Voir la section « Focus » ci-dessous : si les emplacements vides sont également abaissés au niveau de perte de focus, la page est immédiatement lue comme « pas encore construite », ce qui est exactement le problème que l'allocation préalable des emplacements vise à résoudre. Les tests montrent qu'en augmentant le niveau des emplacements vides de 0.38 à 0.80, le plus grand rectangle vide dans les premières images de sept scènes est passé de 0.29–0.62 à 0.058–0.199.

Le contenu sans cadre doit être contenu

Retour d'utilisateur : « Sans carte, c'est très dispersé. » La règle est renforcée :

Chaque unité d'information dans la zone de texte doit appartenir à un conteneur ou à un groupe étiqueté.
Seules trois exceptions sont autorisées sans cadre : une liste de points clés directement sous un conteneur, une phrase de conclusion en bas de page, et le kicker et le titre en haut.
Les points clés sans cadre doivent partager la bordure gauche et la largeur avec le conteneur adjacent, au maximum 7 colonnes de large, au maximum 4 lignes, format : « numéro de cercle + titre court en gras + deux-points + texte du corps » sur la même ligne de début.
Tous les blocs de texte sans cadre d'une même page ne peuvent avoir qu'une seule bordure gauche.
Si la zone occupée par le contenu sans cadre dépasse 40% de la zone de texte, il doit être placé dans un conteneur.

Interdit : trois ou quatre paragraphes de texte centrés avec des espaces blancs entre eux ; utiliser des lignes vides pour « remplir » en espaçant ; une page avec plus de deux types de bordures gauches différentes.

Densité minimale (zone de texte `[120, 280, 1680, 610]`)

Métrique	Minimum	Méthode de mesure
Occupation des conteneurs occupancy	≥ 0.55	Boîte englobante des objets de la scène
Portée verticale	≥ 0.72	Boîte englobante des objets de la scène
Portée horizontale	≥ 0.86	Boîte englobante des objets de la scène
Plus grand rectangle vide	≤ 0.14	Boîte englobante des objets de la scène
Plus grande bande vide	≤ 150 px de conception	Boîte englobante des objets de la scène
Unités d'information indépendantes	≥ 3	Liste des objets de la scène
Plus grand rectangle vide sur image stable	≤ 0.20	Carte des bords de l'image stable

La dernière règle est au niveau des pixels, les pages de chapitre, de couverture et de fin sont exemptées. N'utilisez pas le « ratio de pixels non d'arrière-plan » : dans cette esthétique visuelle (cartes blanches sur fond quasi blanc), le remplissage des cartes deviendrait la couleur majoritaire, et la métrique serait inversée (la vidéo de référence mesure 0.144, la version jugée esthétiquement inférieure mesure 0.419, la direction est complètement fausse). La carte des bords n'est pas affectée.

Lorsque le contenu est insuffisant, utilisez density.escalation pour ajouter du contenu, l'étape 0 consiste d'abord à vérifier si les emplacements n'ont pas été pré-alloués ou si le contenu n'est pas dans des conteneurs – la plupart des cas de « vide » sont dus à cela, pas à un manque de contenu. Il est interdit de laisser un espace vide. Il est interdit d'agrandir la police pour remplir la page. Il est interdit d'utiliser des particules, des halos, des formes géométriques pour faire semblant d'être des unités d'information.

Le cadre de fenêtre est déterminé par la quantité d'information, pas par une préférence

À utiliser : le contenu appartient naturellement à une interface (fichier, configuration, terminal, éditeur, tableau de bord, rapport) ; les unités d'information ≤ 3 semblent clairsemées et nécessitent un regroupement par une bordure ; pour exprimer la relation d'appartenance « nom de fichier + contenu ».

Ne pas utiliser : s'il existe une forme d'expression plus précise qui peut remplir la zone de texte ; si les deux plans précédents ont déjà utilisé un cadre de fenêtre ; si le contenu est un mécanisme abstrait plutôt qu'une interface spécifique.

Lorsque vous l'utilisez, remplissez-le complètement : taux de remplissage du contenu ≥ 78%. Utilisez le nom de fichier réel pour le titre de la fenêtre, pas « exemple » ou « Démo ». Les scènes avec fenêtre ne doivent pas dépasser 50% du film, et trois plans consécutifs ne doivent pas avoir la même composition.

Diagrammes de relations et organigrammes

Au moins 4 nœuds et 3 arêtes. Chaque nœud doit avoir un titre et une ligne d'explication. Chaque arête orientée doit avoir une étiquette d'action et une flèche, les deux extrémités doivent être ancrées à un point réel de la limite de l'ID de l'objet ; une extrémité flottante est un défaut. Un panneau d'explication est obligatoire, occupant 30% à 42% de la largeur de la zone de texte : pseudo-code, fragment de configuration, table d'état, exemple de message, barre de métrique, séquence d'étapes au choix. Le pseudo-code doit comporter 5 à 12 lignes, chaque ligne correspondant à un nœud ou une arête du diagramme, et est mise en évidence de manière synchrone lors du rendu.

Pages de métriques

En plus de la valeur principale, au moins 2 éléments de support : graphique avant-après, décomposition, bloc de conditions de test, deuxième métrique du même mécanisme, configuration réelle qui a produit la métrique, définition de référence. Les graphiques partagent une ligne de base, des échelles et des valeurs sont annotées. Les unités différentes (qps vs ms) doivent être sur des graphiques ou des axes séparés. Ordre : d'abord afficher la valeur d'origine avec les conditions de test → changement vers la nouvelle valeur → l'amélioration se stabilise → reste stable. Les chiffres ont une largeur fixe, les unités sont fixes, et ne sont mises en valeur qu'une seule fois.

Typographie chinoise : ce qui fonctionne pour l'occidental ne s'applique pas tel quel

	Règle	Pourquoi
Interlignage	display 1.15, titre 1.35, corps 1.65	Les caractères chinois sont des blocs pleins, il n'y a pas d'espace naturel entre les minuscules comme dans les écritures occidentales. Un interlignage insuffisant brouille le tout. Le chinois est environ 0,2 plus grand que l'occidental.
Espacement des caractères	display (>60px) −0.02em, titre 0, corps 0	L'espacement des caractères chinois est naturellement uniforme. Ajouter un espacement aux titres les rend lâches, un espacement négatif aux display les fait se chevaucher. Seules les petites étiquettes occidentales en majuscules ont besoin de 0.08–0.15em.
Longueur de ligne	22–38 caractères, idéal 28–32	La densité des caractères chinois est élevée, la même largeur contient plus d'informations que l'occidental. Une ligne trop longue perd le lecteur lors du retour à la ligne.
Pile de polices	Occidentale en premier, chinoise en second	Correspondance caractère par caractère : la police occidentale ne contient pas de points de code CJK, les caractères chinois utilisent donc naturellement la police chinoise. Si l'ordre est inversé, tous les caractères occidentaux seront affichés avec la police chinoise et ses caractères occidentaux laids.
Emphase	Changer le poids de la police ou ajouter une couleur de fond	Le chinois n'a pas d'italiques, les italiques synthétisées par le navigateur/rendu déforment les caractères chinois. Même chose pour le gras synthétique, à proscrire.
Guillemets	Guillemets droits «»『』	Les guillemets courbes dans une police chinoise occupent une largeur pleine et ont une forme occidentale, ils flottent visuellement.
Chiffres	Utiliser la police occidentale + `tabular-nums`	Sinon, 1 et 8 ne sont pas de la même largeur, les colonnes de données trembleront.

Les polices à chasse fixe doivent être testées avec les glyphes CJK. JetBrains Mono ne prend pas en charge CJK, les commentaires chinois dans les fenêtres de code deviendront des blocs tofu. La famille mono doit explicitement inclure un repli vers une police chinoise.

Test des trois mètres

Arrêtez-vous sur une image quelconque. Le plus grand mot doit être lisible à trois mètres. La même image réduite à la taille d'un écran de téléphone doit encore être lisible. Le spectateur accorde moins d'attention à chaque image d'une vidéo qu'à une image statique, la police doit donc être plus grande, jamais plus petite. Cette règle et la densité minimale sont les limites supérieure et inférieure l'une de l'autre : la densité minimale empêche le vide, le test des trois mètres empêche de « réduire la police pour faire tenir le contenu ».

Une image pour une seule idée

Retour d'utilisateur : Le contenu, les effets, la narration doivent tous être clairs, ne pas être flous, ne pas mettre trop de contenu dans une seule image. Chaque règle de cette section peut être évaluée par motion_audit.py, ce ne sont pas des suggestions esthétiques.

Budget d'information : une limite inférieure ET une limite supérieure

	Valeur	Explication
Limite inférieure des unités d'information	3	En dessous, la page est vide.
Limite supérieure des unités d'information	5	Au-dessus, le test de l'image figée de 2 secondes échoue.
Texte total dans la zone de texte	≤ 120 unités de comptage	Caractères chinois comptés comme un, mots anglais comptés comme un.
Nouvelles informations par battement	1 emplacement	Un groupe stagger compte pour un.

Le comptage se fait par conteneur ou groupe étiqueté le plus externe, les sous-éléments à l'intérieur du groupe ne sont pas comptés séparément. Pour la page à 01:32 de la vidéo de référence, selon ce calcul, il y a 3 unités (fenêtre de code de configuration + groupe de cartes d'appareils cloud + barre de processus), même si la carte a 5 éléments, elle compte toujours pour 1 unité.

Si la limite est dépassée, ne réduisez pas la police pour faire tenir. Essayez dans l'ordre : diviser en deux scènes → fusionner les éléments similaires en un groupe avec un titre → déplacer les détails dans le panneau d'explication.

Le chemin de lecture suit un motif en F, et il est mesurable

Les études oculométriques montrent que la concentration du regard dans la zone de contenu se fait à trois endroits : la barre horizontale supérieure (kicker et titre), la deuxième barre horizontale (première rangée du contenu principal), et la barre verticale gauche (la bordure gauche partagée). Dans cette vidéo :

Point de départ : la première unité d'information révélée dans la scène doit avoir son centre de gravité dans le quadrant supérieur gauche de la zone de texte (x normalisé ≤ 0.50, y ≤ 0.45).
Ordre : le centre de gravité vertical de la séquence de révélations ne doit pas diminuer de manière monotone, un seul saut vers le haut est autorisé.
Barre verticale : les blocs de texte sans cadre partagent une seule bordure gauche (R14), la bordure gauche des conteneurs est alignée sur la grille de colonnes (R13).
Informations antérieures : le titre, le titre de l'emplacement, les deux premiers mots du titre du point clé doivent être informatifs. Les titres commençant par « À propos de », « Notre », « Meilleur », « Comment » seront directement rejetés par compose_spec.py.

Mesures effectuées (dans content_box, 12fps, centre de gravité des changements 1.5 seconde après chaque coupe) :

	Départ x	Départ y	Proportion de coupes qui se déploient vers le bas
Vidéo de référence	0.393 ± 0.121	0.336 ± 0.126	67%
Version précédente jugée esthétiquement inférieure	0.660 ± 0.175	0.498 ± 0.152	48%

La vidéo de référence part du coin supérieur gauche et se déploie vers le bas ; l'autre version part du milieu légèrement à droite et se déploie vers l'extérieur – c'est l'une des causes directes de l'apparence « dispersée », indépendante de la densité.

L'image et la narration doivent parler de la même chose

Chaque unité d'information doit mentionner la phrase de narration à laquelle elle correspond, et le temps de révélation doit tomber dans l'intervalle [début de la phrase −0.4, fin de la phrase +0.8] secondes. Si aucun correspondant ne peut être écrit, cela signifie que cette unité n'est pas mentionnée dans la narration et doit être supprimée ou que la phrase doit être ajoutée.

Les mots sur l'écran sont des phrases-résumés, des noms propres, des valeurs, des étiquettes, pas une transcription mot à mot de la narration – écouter et lire la même phrase en même temps se gênent mutuellement. Les sous-titres sont une piste indépendante et ne sont pas comptés dans le budget de texte.

La narration aussi : une idée par phrase

Une phrase = un fait. Écrivez deux phrases pour deux faits, ne les reliez pas par « et », « ainsi que », « en même temps ». Phrase ≤ 32 unités de comptage.
La première phrase de chaque scène est la conclusion, suivie du mécanisme et de la preuve.
N'utilisez pas « il », « cela », « ceci » de manière consécutive ; si une phrase est intercalée, répétez le nom.
Expliquez un terme technique lors de sa première apparition dans la phrase, ne le laissez pas pour la phrase suivante.
Lorsqu'un chiffre est donné, la même phrase ou la suivante doit immédiatement donner les conditions de mesure.
Interdit : lecture de liste de mots-clés (« plus rapide, plus fort, plus stable »), parallélismes de type publicitaire, trois noms propres en une phrase, répéter le contenu déjà clairement écrit à l'écran.

Copiez chaque phrase de la narration dans CLAIMS.md pour faire la correspondance ; les phrases non mappées doivent être supprimées ou complétées pour devenir une conclusion sourcée.

Test de l'image figée de 2 secondes

Prenez l'image stable d'une scène, masquez la narration et les sous-titres. Demandez à une personne qui ne connaît pas le produit de dire la conclusion de cette page et le chiffre clé. Si elle ne peut pas, la page n'est pas claire. Marquez passed / failed / not_tested pour chaque scène ; non fait = not_tested.

Comment répartir le temps : d'abord allouer le budget de temps d'arrêt, puis organiser les animations

La durée d'une vidéo à plusieurs plans n'est pas répartie uniformément. Le squelette en quatre parties a des pourcentages fixes :

Partie	Pourcentage	Énergie	Contenu	Indicateur clé
Ouverture	8–12%	Faible	Présentation de la marque + phrase expliquant de quoi parle la vidéo.	Logo fixe maintenu ≥1s ; la première image est la couverture complète.
Établir	10–16%	Faible à moyen, la plus lente du film.	Premier chapitre, la partie avec la plus haute qualité visuelle.	—
Ascension	52–64%	Moyen à élevé et faible en alternance.	Une capacité par plan.	Insérer une page de chapitre entre chaque 1 à 2 plans de contenu pour réduire l'énergie.
Clôture	10–16%	Le pic du film	Récapitulatif + chiffres clés + appel à l'action.	Ne pas fondre au noir, maintenir l'affichage jusqu'à la dernière image.

Ordre : ① Lister les capacités pour compter le nombre de plans → ② D'abord réserver les temps d'arrêt incompressibles (maintien du logo, pause de lecture, pages de chapitre maintenues 1.1s, fin maintenue 2s) → ③ Le temps restant est alloué aux animations → ④ Choisir une transition pour chaque jointure, la durée de la transition est prélevée sur le budget des deux plans adjacents, sans ajouter de temps supplémentaire.

Pas deux plans consécutifs de haute énergie. Les pages de chapitre servent à réduire l'énergie : ce sont des « cartes respiratoires » de faible densité, avec beaucoup d'espace blanc, 2 à 6 caractères. Ne les transformez pas en un autre plan d'information, cela reviendrait à ne pas en avoir du tout.

Liste noire des décorations de modèles

Ce ne sont pas « laids », ce sont « qui font immédiatement penser à un modèle préfabriqué ». Supprimez-les dès qu'ils apparaissent :

Étiquette courte en anglais en majuscules au-dessus de chaque titre · Chaîne de mots reliés par des points centrés « A · B · C » · Flèche décorative à la fin d'un bouton ou d'une étiquette · Mettre un seul mot en couleur dans le titre · Numérotation 01/02/03 pour un contenu qui n'est pas une séquence · Icône emoji sans rapport avec le mécanisme · Carte arrondie avec une barre de couleur à gauche · Particules lumineuses, flux de données, HUD holographique, néon · Fond foncé avec halo néon pour imiter un aspect technologique.

Le critère est : « Est-ce que cela découle du contenu ? », pas « Est-ce que cela ressemble à un modèle ? » Les numéros sont légitimes quand il s'agit réellement d'une séquence (chapitres, étapes de déduction) ; le dégradé est légitime quand il est dérivé des couleurs de la marque.

Jointures : zéro cut sec dans tout le film

Retour d'utilisateur (2026-11-05) : « La transition entre chaque chapitre doit être très naturelle, pas directement affichée, ce qui semble très brut. » Les films de lancement reconnus comme excellents n'ont aucun cut sec. Pour obtenir un effet de « coupe », utilisez une coupe conçue.

Chaque jointure de scène doit déclarer un type de transition, dont la durée est prélevée pour moitié sur le budget de chaque plan adjacent – la transition n'ajoute pas de temps au film, elle est empruntée aux deux plans. La fenêtre est [limite − durée/2, limite + durée/2], pendant laquelle les deux scènes sont présentes à l'écran simultanément.

Plans adjacents	Type de transition	Durée	Comment faire
Couverture → Page de chapitre	Fondu enchaîné	0.62s	La couverture s'estompe et devient floue, le numéro du chapitre devient net en même temps depuis le flou.
Corps → Page de chapitre	Fondu enchaîné	0.58s	Pendant que la page précédente s'estompe, le numéro entre flou et net, les deux choses dans la même fenêtre.
Page de chapitre → Corps	Balayage prismatique	0.92s	Le numéro s'agrandit et devient flou → une bande de lumière arc-en-ciel balaie en diagonale → la page suivante est formée derrière la bande lumineuse, le contenu clé n'est pas encore affiché.
Corps → Fin	Fondu enchaîné	0.62s	Idem.
Corps → Corps (changement de plan dans le même chapitre)	Relais par flou	0.50s	Seulement du flou, pas de déplacement horizontal.

Balayage prismatique : un voile fin de surface_tint (pic 0.62) recouvre tout l'écran, une bande lumineuse de 1 420 de large balaie à 17°, les couleurs d'arrêt sont la couleur principale 0.34 → couleur secondaire d'accentuation 0.30 → accent 0.26. Interdiction d'utiliser un flash blanc, un effacement complet de l'écran, un retournement de page, une rotation.

Les jointures sont ancrées aux pauses de la narration : seulement anticipées, jamais retardées, limite supérieure de 0,8 seconde. Le coût pour le spectateur de déplacer son regard est le plus faible pendant les silences auditifs.

Critère (R27) : échantillonnez la fenêtre de jointure à 12fps, calculez la variation par image de l'écran entier ; la variation d'une seule image ne doit pas dépasser 0,55 de la variation totale de la fenêtre. Un cut sec concentre plus de 90% de la variation dans une seule image. Les mesures montrent que les sept jointures de cette version tombent entre 0.155 et 0.35.

La couverture doit être la première image. Le lecteur utilise t=0 comme affiche ; si la première image est vide, la couverture n'existe pas. Par conséquent, la couverture ne crée pas de mouvement par l'entrée d'éléments – les éléments sont tous présents dès le départ, le mouvement provient de trois choses qui ne changent pas la boîte englobante : un anneau concentrique statique, deux balayages lumineux, et l'étiquette correspondant à la direction mentionnée dans la narration qui s'illumine. Le critère est que le taux de couverture des bords de la zone de texte sur la première image doit être ≥ 0,90 fois celui de l'image stable de la couverture. Même les décorations doivent être en place dès la première image – les tests montrent que si l'anneau est en fondu de 0 à 1, ce rapport n'est que de 0.673.

Focus : éclairer ce qui est dit, mais ce qui a été dit doit encore être lisible

Retour utilisateur (deuxième tour) : « Quand un contenu est dit, les autres sont grisés, pour mettre en valeur ce qui est dit. » Retour utilisateur (troisième tour) : « Immédiatement après, il était grisé, je n'avais pas fini de lire. » « Ne pas le rendre trop flou, mais plus sombre, tout en restant lisible. » « Si le contenu dit est lié au suivant, ne l'assombrissez pas temporairement. »

Quatre niveaux, seule la densité d'encre change, pas la netteté

État	Densité d'encre	Carte	Quand
active	1.0	Ombre portée, bordure de la couleur principale	La narration est en train de le dire. Il est reconnu comme « flottant », pas parce que les autres sont flous.
read	0.70	Pas d'ombre, bordure normale	A été dit. L'encre est réduite visuellement à environ `#5A6070`, le contraste est encore de 6:1, lisible à trois mètres.
waiting	0.88	Normale	Pas encore le tour. Seulement légèrement réduite, la page doit sembler pleine.
settled	1.0	Normale	La narration est terminée, toute la page redevient opaque.

Pas de flou. Cette règle entre en conflit avec le « trio de perte de focus doit inclure le blur » de huashu-design. Ici, pour les vidéos d'information, le besoin est différent : le flou sert à empêcher un élément de concurrencer l'attention, mais le spectateur d'une vidéo d'information a encore besoin de le relire. Le flou est réservé à deux endroits seulement : les transitions entre scènes et l'entrée/sortie du numéro de page de chapitre.

Quand commencer à assombrir

           Début de phrase         Fin de phrase      +1.0s        +0.8s
             |--------------|------------|------------|
   active    ============================>
   Assombrir                                 [===Transition===]  read

Une unité ne peut pas commencer à s'assombrir avant la fin de sa propre phrase de narration (la moitié de la déclaration de R30).
Après la fin de la phrase, laissez 1,0 seconde au spectateur pour finir de lire, puis assombrissez progressivement en 0,8 seconde.
L'ancienne méthode était de « changer de focus dès que la phrase suivante commence ». Le spectateur était encore en train de lire la partie précédente, mais l'image la lui avait déjà enlevée.

Deux blocs liés s'éclairent et s'assombrissent ensemble

La configuration et ses limites d'application, la valeur et ses conditions de mesure – ces paires de contenu déclarent le même focus_group : tant qu'un élément du groupe est en cours d'explication, tout le groupe reste actif ; 1,0 seconde après la fin de l'explication du dernier élément du groupe, tout le groupe s'assombrit.

Critère (R28)

Prenez une image au moment où une unité perd le focus et la même image stable. Comparez l'amplitude moyenne du gradient à l'intérieur de la boîte englobante de la même unité. L'état de perte de focus doit être ≤ 0,85 de l'état stable.

Utilisez l'amplitude moyenne du gradient plutôt que le nombre d'arêtes seuillées : lorsque seule la netteté est réduite sans ajout de flou, le seuil laisse tout passer ou rien, la métrique serait déconnectée du traitement. L'amplitude moyenne du gradient varie linéairement avec la netteté, une densité d'encre de 0,70 donne une mesure d'environ 0,70.

Révélation : les éléments de support sont là dès le début, seuls les éléments clés attendent la narration

Retour utilisateur (troisième tour) : « Les cadres du milieu et du bas étaient vides mais avaient encore un style, très étrange au premier coup d'œil. » « On pourrait d'abord afficher le contenu non important. Et taper le contenu important à la machine à écrire pendant l'explication. » « Habituellement, juste la machine à écrire pour imprimer le contenu. Si le contenu est déjà imprimé et qu'il est mentionné plus tard, alors surligner l'arrière-plan. »

Cette règle rétrécit la règle du deuxième tour « laisser le contenu clé jusqu'à ce que la narration le mentionne », sans la renverser : Seulement l'élément clé de chaque unité est laissé pour plus tard, pas toute la carte.

Ce qui doit être dessiné dès l'ouverture

Cartes, chips, titres, lignes de séparation, étiquettes de ligne, lignes secondaires, structure. Une unité ne laisse qu'un seul élément clé pour la narration – cette valeur, ce code, cet ensemble d'étiquettes.

Un seul type d'animation par ligne

Moment	Utiliser	Ne pas superposer
Première apparition	Machine à écrire, de gauche à droite caractère par caractère, 0.4–1.0 seconde	Pas de balayage lumineux, pas de barre de couleur de fond, pas de barre de couleur à gauche
Mentionné plus tard	Barre de surlignage de fond `#FFF4D6` + barre de couleur à gauche de 3px, 0.42 seconde	—

Le surlignage est le langage de « mention ultérieure ». Si la première apparition est déjà surlignée, ce langage est perdu, le spectateur ne peut pas distinguer ce qui est nouveau.

La version précédente attribuait un balayage lumineux à chaque ligne, pour atteindre « un ratio d'images avec changement ≥ 0.45 » – l'utilisateur a dit : « Il y a trop d'animations sur les mots. » Empiler des animations décoratives pour atteindre un quota, c'est maintenant un échec direct.

Quand utiliser le squelette d'écran

Il peut être utilisé si le contenu doit vraiment être dit plus tard et si le squelette lui-même est conçu, mais il doit satisfaire : avoir un titre et une structure (pas un rectangle arrondi blanc vide), les barres d'espace réservé doivent avoir des largeurs différentes (ressembler au contour d'un contenu réel), le squelette ne doit pas dépasser 60% de la hauteur de la carte, et les squelettes de chaque carte ne doivent pas être identiques.

Narration et image doivent parler de la même chose, c'est la règle inébranlable

Retour utilisateur (troisième tour) : « Absolument absolument, la narration, le contenu de l'image et les animations doivent être cohérents !!! C'est la règle inébranlable. »

L'échec de la deuxième version venait du fait que la déclaration elle-même était erronée : R22 ne vérifiait que « si le temps de révélation se situe dans la fenêtre temporelle de la phrase déclarée », sans jamais vérifier si cette phrase parlait réellement de cette unité. Ainsi, la carte du facteur 2,8 était accrochée à « Un autre temps a été réduit de 12,6 s à 4,0 s » – cette phrase parlait de la deuxième ligne d'une autre carte – la fenêtre temporelle correspondait bien sûr, et tous les voyants étaient verts.

R29 : Correspondance un-à-un, et le texte correspond

Chaque unité d'information déclare exactement une phrase de narration.
Deux unités ne peuvent pas partager la même phrase, sauf si elles appartiennent au même groupe stagger et entrent ensemble au même battement.
Chaque phrase de narration dans la scène doit être déclarée par une unité, pas de phrase orpheline.
Le texte de cette phrase doit contenir un mot-clé de cette unité : titre de la carte, étiquette de ligne, valeur, texte de l'étiquette, nom de fichier, au choix. Donc, chaque unité d'information dans content.yaml doit écrire keywords.

R30 : L'image suit la narration

Au niveau de la déclaration : dim_t ≥ temps de fin de cette phrase + 1,0 seconde.
Au niveau des tests : pendant la lecture de chaque phrase de narration, il doit y avoir un changement visible dans la boîte de l'unité correspondante (mise à jour du texte, changement de surlignage, changement de mise en page). Uniquement un changement d'assombrissement ne compte pas.

Comment expliquer les informations abstraites : la déduction chronométrée laisse des traces

Pour expliquer un mécanisme abstrait : répartissez la propriété sur une séquence temporelle, chaque étape est un nouveau texte écrit à l'écran, l'étape précédente est conservée, et la dernière est un texte fondu. Le spectateur voit le processus de déduction depuis le début.

Les exposés frontaux traditionnels (une seule image, écrire toutes les formules) échouent au test des 2 secondes, et la densité de l'image figée donne l'illusion d'avoir été comprise, mais en réalité pas.

Protocole de la machine à état montrée étape par étape

La première image montre l'état initial et le problème : une situation déséquilibrée ou bloquée. Pas de transition en fondu, pas de dégradé, pas d'icône. Le problème est un texte clair.
Ajoutez une règle ou une entrée : un rectangle de code, un bouton, un fichier de configuration. La règle est écrite en toutes lettres, pas résumée.
Le résultat du calcul apparaît comme une nouvelle valeur ou une étiquette, changeant la couleur de l'état, ou la flèche de la règle.
(Répétez 2→3 si plusieurs cycles)
L'image stable : l'état final + une phrase de conclusion parent (pas « donc », mais le nom du résultat)

Interdit : utiliser une animation de particules, un flux de données, un trait de lumière pour représenter « un processus », laisser l'utilisateur deviner la logique de l'étape 2. La déduction se fait par étapes, pas par l'effet visuel.

Les diagrammes de relations, de code, de métriques suivent le protocole du type de scène correspondant, voir scene_language.protocols.

Code source : doit être réel et exécutable, ne doit pas être une habillage

Les blocs de code sont une scène à part entière, pas une décoration. Les données dans un bloc de code (noms de fichiers, noms de fonctions, dépendances, valeurs numériques) doivent toutes provenir du document source.

Ne pas : renommer sans nécessité (example.js ne convient que si le document ne donne pas de nom de fichier) ; simplifier les conditions de test ou supprimer les noms de configuration ; ajouter des commentaires qui n'existent pas dans le document ; supprimer les lignes expect ou assert des tests ; masquer la partie appelée du code de configuration ; réécrire la syntaxe d'un langage dans un autre langage.

Utilisez des blocs de code pour montrer des changements dans les fichiers de configuration et les API. Le code détermine le langage (languages dans packages.json).

Que faire si le chemin ne fonctionne pas

Le piège : la surface de la vidéo de rendu est belle, mais la couverture logique n'a jamais été approuvée par l'utilisateur, et les tests de prononciation et de couleur n'ont pas été effectués. Le rendu final est rejeté, et le plus important est de perdre l'effet de surprise du lancement.

La procédure de base du skill inclut des contre-mesures :

Vérification compose_spec.py : comprendre le blocage (comprehension), le nombre d'unités d'information dans chaque scène (3–5), le type de transition, le degré de densité de la mise en page.
Vérification validate_spec.py : R01–R30, test automatique, au moins 10 minutes de temps de calcul. Chaque run génère un rapport, voir qa/.
closed_review, scene_changelog : le rapport de révision ne demande pas à exécuter des commandes, mais à répondre aux questions par « Oui/Non/Prouvé par le test xx ». Le fichier qa/ permet de prouver la réponse.

La chose la plus chère est le rendu final de la vidéo. Avant de lancer ce rendu, assurez-vous que toutes les vérifications précédentes sont passées et que l'utilisateur a approuvé le plan de scène (pas la vidéo). Le lancement du rendu final est une action explicite de l'utilisateur : ne dépensez pas sur la base d'une supposition.

Demander à votre IA préférée

Documentation