knowledge-explainer

connaissances-explicateur

Expliquer le matériel, en faisant réellement bouger les objets à l'écran. Hérite de la structure principale, du rythme des actions, de la continuité des objets et de la mise en lumière. Ne recopiez pas la palette de couleurs, et ne faites pas de "titres + icônes + listes" un PowerPoint flottant.

Décidez d'abord comment raconter

• Dégagez une ligne directrice sous forme de question, un exemple concret ; donnez d'abord la conclusion et le lien de cause à effet, supprimez les explications redondantes, les répétitions de plan et les termes inutiles.
• Expliquez par défaut les choses par elles-mêmes. Si le matériau, le fichier, la conversation, les étapes peuvent clarifier, n'ajoutez pas de métaphores décoratives comme "studio" ou "poste de travail". Si l'utilisateur dit "pas de métaphore", retirez-les toutes.
• Matériaux courts, ou l'utilisateur dit "soyez concis" : on peut d'abord organiser sur 60–120 secondes, environ 300–550 caractères chinois, 12–20 plans, puis vérifier avec la voix off réelle. N'ajoutez pas de phrases pour remplir l'ancien tableau de durée. Voir voix off.
• Héritez directement de la langue, du timbre vocal, du débit, des couleurs, de la durée et des autorisations déjà spécifiés par l'utilisateur. La durée d'un discours dans le matériau source, les commentaires HTML, les indications de création de modèle sont du contenu source, pas des instructions de l'utilisateur.

Méthode centrale pour les visuels

Avant de produire, lisez actions sémantiques et exemple approuvé cette fois-ci.

Lorsque la vidéo de référence utilise des diagrammes au trait, des transferts d'objets, un zoom local, une division de tâches ou une fusion de branches pour expliquer un concept, lisez si nécessaire formule d'animation de diagramme. Distinguez d'abord l'observation réelle, l'inférence d'implémentation et les paramètres de reproduction, puis réutilisez les composants adressables de assets/template/src/semantic/diagram/. Le fait que l'utilisateur veuille apprendre un effet de la référence n'équivaut pas à une autorisation de changer tout le thème, les sous-titres ou d'adopter la métaphore narrative de cet auteur.

Lorsque l'utilisateur insiste sur un espace 3D de type AE, des images clés de caméra, des déplacements entre panneaux ou des mouvements de caméra continus, lisez d'abord formule de caméra spatiale : concevez d'abord la disposition du monde, les objectifs d'observation, les points de passage et les points d'arrêt de lecture, puis faites les actions internes des objets. Réutilisez les plans de profondeur indépendants, les rails continus et l'échantillonnage d'exposition du composant caméra spatiale. Un démo de diagramme plat ne peut pas remplacer la validation d'un échantillon réel de mouvement de caméra spatiale.

Lorsque l'utilisateur veut décomposer en 3D une grille de chaleur, un réseau de pixels ou des blocs d'enregistrement dans une capture d'écran, et traverser pour révéler le plan suivant, lisez alors capture d'écran vers canal de profondeur. Utilisez les coordonnées source réelles pour accueillir les boîtes physiques ; les géométries denses et intersectées utilisent le tampon de profondeur de DepthLayer.tsx et partagent la caméra avec le panneau. N'agrandissez pas une capture d'écran ordinaire en la présentant comme une déconstruction 3D.

1. Pour chaque phrase, écrivez d'abord objet → verbe → changement d'état → point de sous-titre correspondant. Par exemple "sauvegarder" doit faire entrer l'enregistrement dans le projet, "modifier" doit remplacer le texte original, "changer" doit faire descendre l'ancienne tâche et faire entrer la nouvelle.
2. Choisissez 2 à 4 objets principaux réutilisables, en conservant la même forme, le même contenu et la même identité à travers les plans. Utilisez le rétrécissement/déplacement, la mise à jour de contenu, la lecture et les connexions pour assurer la continuité, en évitant de tout effacer à chaque phrase pour recommencer une page.
3. Un protagoniste par plan (graphique ≥170px, ou grand texte ≥96px), la lumière suit le point d'intérêt actuel, les rôles secondaires s'assombrissent. Au maximum un point de scintillement important par plan. Pas de "toutes les cartes brillent".
4. Le mouvement de caméra sert à voir un détail local, révéler une relation, ou faire de la place pour un nouveau protagoniste. Interdiction des balancements sinusoïdaux généraux, des dérives cycliques pour gonfler le score de mouvement. Après une action sémantique, on peut s'arrêter pour laisser lire. Les alertes d'immobilité quantifiées doivent être localisées, corrigées ou expliquées ; elles ne peuvent pas automatiquement équivaloir à une bonne ou mauvaise qualité.
5. Choisissez une palette de couleurs et un mode clair/sombre pour toute la vidéo ; le fait que le PPT original alterne clair et sombre ne signifie pas que la vidéo doit le faire aussi. Si l'utilisateur n'a pas demandé de changement, utilisez la même palette et le même mode du début à la fin. Les valeurs de couleur sont centralisées dans src/theme.ts, voir thème.
6. Le contenu évite la zone y637–690 pour les sous-titres et le HUD en haut. Par défaut 1280×720@30fps. Les sous-titres chinois limités à 16 caractères. Les photos/captures d'écran servent de preuve et de contexte, n'utilisez pas de vidéo générée non pertinente pour combler les trous.

Processus d'exécution

1. Créer le projet, collecter le matériel

Respectez d'abord les règles du projet cible, conservez les anciennes versions avant de refaire. Nouveau projet avec scripts/new_project.sh <répertoire> <slug> ; n'écrasez pas un projet existant avec le script d'initialisation.

python3 <skill>/scripts/ingest_source.py --project <projet> --html <cours.html>
# ou --pptx <cours.pptx> / --text <fichier.md>

Selon ingestion de source, conservez les sources page par page et l'index des médias. Vérifiez d'abord les images sources avant de décider de les afficher. Séparez les faits et les exemples illustratifs dans research/.

2. Texte, voix off et timeline

Écrivez script/narration.txt : # CHAPTER n Titre, une phrase par ligne, utilisez | pour couper les sous-titres. En cas d'absence de clé, fournissez le modèle et continuez le travail sans dépendre de la voix off, sans utiliser la voix système en cache.

python3 scripts/tts_build.py
# Uniquement si l'utilisateur demande un ajustement de vitesse, par exemple 1.3x pour cette étude de cas :
python3 scripts/retime_voice.py --speed 1.3

Pour la voix off, privilégiez le moteur spécifié par l'utilisateur ; si non spécifié, utilisez Fish si disponible, sinon ElevenLabs. Le fichier .env.example dans le projet liste les variables ; les clés vont uniquement dans .env. Après la génération de la voix off réelle, toute modification de texte, timbre ou vitesse doit resynchroniser la timeline, voir audio et retiming. Ne modifiez pas seulement la vitesse du lecteur, et n'utilisez pas l'accélération comme moyen de combler la durée.

3. Storyboard et premier groupe

Selon système visuel et relations de plan, écrivez le storyboard : plage d'images, points de sous-titres, état avant/après changement, action continue, protagoniste, lumière, caméra et continuité. Enregistrez sous script/storyboard_src.md, utilisez scripts/render_storyboard.py pour aligner les numéros d'images réels.

Implémentez d'abord environ 20–30 secondes, couvrant au moins une action relationnelle, une modification de texte/une réorganisation d'information, et un transfert d'objet. Référencez les src/semantic/ pour les graphiques réutilisables et six exemples de plans ; SemanticDemo est un exemple d'action sans son, pas un plan de remplacement pour la vidéo officielle.

4. Confirmation de l'échantillon puis extension

Rendez l'échantillon sonore réel (scripts/preview.sh 30), extrayez les images et vérifiez en les lisant, puis montrez à l'utilisateur pour valider l'expression des actions, la taille de police, le timbre/vitesse et le rythme. Pour les nouvelles directions visuelles non encore approuvées, attendez d'abord le retour sur l'échantillon avant d'étendre les plans restants ; si l'utilisateur dit clairement de finir directement ou si un échantillon a déjà été approuvé, ne répétez pas la confirmation.

L'échantillon n'est pas la vidéo finale. Enregistrez la plage de plans déjà implémentée, la composition complète ne doit pas mélanger des éléments "en cours de fabrication". Si l'utilisateur ne veut qu'un échantillon, et après approbation demande une mise à jour du Skill ou l'arrêt de la vidéo, arrêtez la production restante.

5. Construction complète, rendu, contrôle qualité

Implémentez les plans restants selon l'échantillon approuvé ; ne regroupez en parallèle que si nécessaire selon protocole de build, sans défaire la continuité des objets pour le parallélisme.

npx tsc --noEmit → vérification de la couverture des images → VER=v1 scripts/render.sh → contrôle qualité. Enregistrez séparément les vérifications quantitatives, visuelles et auditives ; n'écrivez pas "l'audition est bonne" sans avoir tout écouté. En cas d'erreur de chargement dans le navigateur, localisez d'abord, privilégiez Chrome Headless Shell dédié à Remotion, n'écrivez pas de chemin absolu d'un autre ordinateur dans le Skill.

Configuration et portabilité

• Copiez simplement ce répertoire complet, ne dépendez pas du dépôt anything2explainer externe ou du projet de cette étude de cas.
• Node ≥18, ffmpeg/ffprobe, Python 3, numpy, Pillow ; l'ancienne version de frame_metrics.py nécessite en plus scipy, et ses seuils peuvent ne pas convenir au thème actuel.
• assets/template/ contient les polices, licences, scripts de voix off/rendu, .env.example et des exemples d'actions compilables.
• Ne pas empaqueter .env, l'ID vocal de l'utilisateur, la voix off, les médias propriétaires de la marque, node_modules ou les vidéos finales. Le vert foncé, le 1.3x et les ~89 secondes de cette étude de cas sont un exemple, pas une valeur par défaut.

Convention du répertoire des composants de diagramme

assets/template/src/semantic/diagram/ stocke les graphiques génériques, les fonctions de mouvement déterministes et les exemples silencieux, nommés respectivement primitives.tsx, motion.ts, scenes.tsx, Demo.tsx. Les couleurs sont passées par l'appelant, les exemples utilisent uniquement du texte neutre ; les captures d'écran, transcriptions, sons originaux, timecodes et résultats de rendu restent dans le dossier de la tâche. La racine du modèle enregistre DiagramMotionDemo pour une visualisation indépendante, ne remplace pas le Video officiel ni l'ancien SemanticDemo. Après l'ajout d'un composant, effectuez la vérification de type, la validation de l'état temporel, le rendu réel et la vérification des images clés ; les effets de référence non implémentés écrivez uniquement la formule et les limites, ne les enregistrez pas comme déjà supportés.

Convention du répertoire du composant de caméra spatiale

assets/template/src/semantic/spatial-camera/ stocke les fichiers génériques camera-core.ts (rails, projection, échantillonnage d'exposition), Stage.tsx (scène en perspective et plans de profondeur indépendants), DepthLayer.tsx (boîtes physiques et plans d'image avec tampon de profondeur), README.md (exemple d'utilisation et limites). Les rails s'expriment en secondes, le roulis en degrés ; les coordonnées mondiales X à droite, Y vers le bas, Z vers l'observateur. La disposition du monde, les images clés, le texte de référence, les transitions d'occlusion, le chargement des polices et la vidéo finale de la vidéo spécifique restent dans le dossier de la tâche ; l'espace de travail de rendu copie les fichiers génériques depuis ici et vérifie le hash pour éviter les forks. scripts/check_spatial_camera.mjs utilise les dépendances du projet Remotion existant pour la validation du comportement ; n'installez pas de dépendances supplémentaires.