2598588975/koubo-explainer-video

Video Explicativo Estilo 'Clase en Cámara'

Un video = una narración + un montón de fragmentos reales + una animación explicativa que sigue la narración. Todo se renderiza con código (página Lemo) y se obtiene un mp4 + srt.

Composición visual (la estructura de referencia del ejemplo ya se ha hecho; el estilo visual se define proyecto por proyecto):

• Aproximadamente 50% del tiempo corresponde al "cuadro de explicación": en primer plano va la animación explicativa con el estilo del proyecto, y detrás, desenfocados, se reproducen los fragmentos reales. Fondo negro con texto blanco y amarillo es solo una de las opciones.
• El resto son fragmentos reales: pantalla completa, tarjetas superpuestas, cuatro pantallas, tres tarjetas.
• Las secciones que hablan de "mal resultado, errores" usan material de muestra negativo (material de baja calidad especificado por el usuario) y llevan un sello rojo de "Ejemplo negativo".
• Los subtítulos inferiores se mantienen durante todo el video, y las palabras clave usan el color de énfasis unificado del proyecto; en el esquema fondo negro con texto blanco y amarillo, se usa amarillo.
• Audio: voz humana + efectos de sonido (ícono/físicos). Por defecto, no se incluye música de fondo ni sonidos de papel crujiente (el usuario ha dejado claro que los "crujidos" son molestos).

Colaboración de Modelos y Punto de Entrada de Ejecución

Esta skill es un conjunto de normas de producción y herramientas de renderizado local. No incluye un planificador de API entre modelos Claude / DeepSeek / GPT; el hecho de colocarla en Cherry Studio no significa que los tres modelos colaboren automáticamente.

• Claude: Responsable principal de la planificación general, la estética y la producción. Unifica la estructura de los argumentos, el ritmo del storyboard, la tipografía y los colores. Crea y modifica los paneles del storyboard y los presenta para confirmación del usuario. Una vez confirmados, se encarga de la implementación del renderizado, la composición y el control de calidad final del video. La auto-revisión de Claude no sustituye la confirmación del usuario.
• DeepSeek: Responsable del guion y su estructuración. Realiza la oralización, elimina frases redundantes, divide oraciones largas, extrae palabras clave, verifica la lógica y prepara el borrador de script.json. La verificación de hechos debe tener fuentes; no se puede tomar la aprobación entre modelos como evidencia.
• GPT: Responsable del análisis de imágenes de referencia y la generación de imágenes. Según la capacidad real de la herramienta, revisa videos de referencia o fotogramas extraídos con marcas de tiempo, extrae la composición de las tomas y genera las ilustraciones/activos visuales necesarios. La generación de imágenes debe utilizar una herramienta real de generación; no se deben hacer pasar sugerencias del modelo como imágenes ya generadas.
• Codex: Soporte auxiliar. Según lo que indique el usuario, se encarga del mantenimiento de la skill, la organización de datos/archivos, la verificación de herramientas o la resolución de problemas técnicos. Por defecto, no asume las funciones de Claude en la creación de storyboards, la comunicación de revisión y la implementación del renderizado.
• Usuario: Confirmación final del storyboard. Claude presenta los paneles completos del storyboard y las muestras necesarias, y modifica según las indicaciones del usuario. Solo después de que el usuario confirme explícitamente la versión actual, se procede al renderizado formal y la producción posterior.

Esta es la división de trabajo prioritaria definida por el usuario, no una clasificación de capacidad de los modelos, y no requiere que se consulten todos los modelos para cada pequeño cambio. Solo se invocan los modelos actualmente disponibles y autorizados. Si Claude no está disponible, se explica qué falta y se prepara el material de transferencia; no se permite que Codex/GPT asuman automáticamente su responsabilidad principal, a menos que el usuario lo indique. No se puede simular que otro modelo ya ha revisado algo. Para más detalles sobre la transferencia y el uso de Cherry / Codex, consulte Colaboración de modelos.

Línea Base Visual (Lectura Obligada al Inicio de Cada Proyecto)

Primero lea Guía de estilo visual, y luego cree el storyboard y la página de renderizado:

• Cada proyecto define primero una dirección visual y luego la unifica para todo el video. El fondo negro con texto blanco y amarillo es una opción; también se pueden probar estilos como el de edición clara, el minimalista frío, o el cinematográfico dominante. Claude propone un esquema basado en el tema y las referencias, y lo presenta al usuario junto con el storyboard/muestras para su confirmación. Una vez que el proyecto actual tiene un esquema seleccionado, no se mezclan colores, tipografías ni estilos de forma arbitraria.
• En el esquema de fondo negro con texto blanco y amarillo, no se mezclan caracteres azules discordantes. En otros esquemas se puede usar deliberadamente azul u otros colores coordinados como color principal/de énfasis; no se debe generalizar un problema de una muestra específica a una prohibición del azul en todos los estilos. El rojo se usa exclusivamente para errores, prohibiciones, riesgos o ejemplos negativos.
• En todo el video se fija la combinación tipográfica y la jerarquía de tamaños. Para el cuerpo del texto, se prioriza una fuente sans-serif clara. Para los títulos, se puede combinar una fuente serif según el estilo. La sensación de sofisticación se logra mediante el espacio en blanco, la alineación, el peso de la fuente y pequeños énfasis.
• El diseño en horizontal se basa en la visualización en teléfono móvil: en el video final de 1920×1080, el cuerpo del texto y los subtítulos tienen un tamaño predeterminado de 64–72 px. Las anotaciones auxiliares pueden ser un poco más pequeñas, normalmente 36–48 px. No se deben usar anotaciones pequeñas para transmitir información clave. El tamaño se mide por las dimensiones reales después del escalado. Cuando el texto esté apretado, se dividen oraciones o se cambia de toma.
• Los efectos de fallo y parpadeo no se utilizan por defecto: no se añaden activamente desplazamiento RGB, desgarros, tres fotogramas de cambio aleatorio, destellos blancos, destellos blancos y negros alternados, obturador que se cierra ni sacudidas de pantalla completa. Las muestras negativas se reproducen con normalidad, y se marcan con el sello rojo y explicaciones parciales del problema.
• examples/codex-jiangzhi/ es una referencia histórica de estructura, que contiene esquemas de color no unificados, texto pequeño clave, destellos blancos y diseño de fallos. No es una plantilla estéticamente aceptable para el estado actual. Al copiar un nuevo proyecto, se debe migrar al estilo seleccionado y luego generar las muestras. Si la apariencia de los ejemplos antiguos entra en conflicto con esta sección, prevalece esta sección.

Antes de Comenzar

1. Entorno: Se necesita la biblioteca Lemo-Opuscar (LIB, por defecto C:/Users/codex/lemo-opuscar) que contiene el renderizador, core/audio/sfx.py, el Python del .venv, y Node.js, FFmpeg y un shell disponible. Primero verifique las rutas y dependencias; si falta algo, indique qué falta exactamente, proceda según las instrucciones de instalación disponibles y no asuma que otra skill ya lo ha instalado. El directorio de trabajo después de la ejecución es la nueva carpeta del proyecto dentro del directorio de materiales del usuario (ejemplo: D:\zgc个人\作品 旧岛\codex-skill-koubo), no el directorio de la skill.
2. Pida al usuario los cuatro elementos: narración mp3, guion (una línea por frase + palabras a resaltar), material bueno (fragmentos reales, cuanto más específico mejor: nombre del video + punto temporal aproximado), material negativo (fragmentos de mala calidad, ej.: generados por minimax/kling). Si falta algo, pregunte primero; no busque material propio para suplantarlo.
3. Claude primero crea los paneles del storyboard y las muestras visuales, y solo después de la confirmación del usuario se avanza. Las muestras deben cubrir al menos el título, el cuadro de explicación con más información densa, y el ejemplo negativo (si lo hay), junto con una vista previa en tamaño de teléfono móvil. Después de presentarlas, se detiene en "esperando confirmación del usuario". No se puede considerar la auto-revisión de Claude, la verificación de herramientas, el silencio del usuario o un encargo genérico de "hacer un video" como confirmación del storyboard actual. Si el usuario ya ha confirmado explícitamente la misma versión, no es necesario preguntar de nuevo. Si el contenido de las tomas, el orden, la duración o el estilo visual sufren modificaciones sustanciales, se vuelven a presentar las partes afectadas para confirmación. El tiempo de renderizado depende del entorno real.

Flujo de Trabajo

Estructura del proyecto (reutiliza la estructura de datos de examples/codex-jiangzhi/, pero la apariencia se rediseña según las normas visuales actuales):

<proyecto>/
  assets/voice.mp3        Narración
  script.json             Guion: {"cues":[{"id","sec","text","hl":["palabra a resaltar"]}]}; sec solo se marca en la oración que inicia ese párrafo
  storyboard/shots.json   Storyboard (generado por script)
  layers.json             Tabla de fotogramas extraídos: ruta del material + intervalo de tiempo de cada capa
  tools/                  align.py prep_layers.py storyboard.py mix.py build.sh qa.sh (copiados de scripts/ de la skill)
  index.html              Página de renderizado (copiada de examples/codex-jiangzhi/index.html y modificada)
  frames/                 (Fotogramas de cada capa) frames.json timeline.json cues.json events.json mix.wav

Primero mkdir -p <proyecto>/tools y copie scripts/*.py scripts/*.sh scripts/align.py en tools/.

1. Alinear la narración (unos minutos)

Después de escribir el guion y los sec en script.json:

cd <proyecto> && "$LIB/.venv/Scripts/python.exe" tools/align.py assets/voice.mp3 --model small --offset 0.8

Se realiza una alineación de secuencias entre las palabras con su marca de tiempo de Whisper y el texto exacto del guion, y se generan timeline.json (con t0/t1 para cada frase) y cues.json. Los puntos temporales de las imágenes deben venir de aquí — si después se modifica la narración, se vuelve a ejecutar y las imágenes se actualizan automáticamente. Si la tasa de coincidencia impresa es inferior a ~85%, significa que el guion y la narración difieren demasiado; hay que revisarlos.

2. Claude crea el storyboard, el usuario lo confirma y luego se avanza

1. Según la plantilla de estructura de references/storyboard-guide.md, divida la narración en tomas y escriba storyboard/shots.json.
2. Para cada toma, seleccione el material y el punto de inicio, y escríbalos en layers.json.
3. Genere las imágenes (los paneles del storyboard sirven para confirmar el contenido de las tomas; el tamaño real de la letra se juzgará con las muestras de la página de renderizado, no solo con las miniaturas del storyboard):

   "$LIB/.venv/Scripts/python.exe" tools/storyboard.py      # → storyboard/board_1..N.png
   

   Cada panel del storyboard contiene: la barra de color de todo el video, una miniatura de cada toma (fotograma real del material), la frase original de la narración, la imagen, el texto grande en pantalla, las transiciones, los efectos de sonido y, en el encabezado, la estadística de proporción de cuadros de explicación y ejemplos negativos. Primero revise todos los paneles con un visor de imágenes disponible, identifique las tomas donde la imagen no coincida con el diálogo y cambie el material para regenerar los paneles.
4. Claude presenta las imágenes del storyboard y las muestras visuales representativas al usuario. La confirmación del usuario es el punto de control para avanzar (duración, material, guion, colores, tamaño de letra). Se pueden implementar las muestras necesarias solo para esta revisión según el paso 4; no se debe crear el video completo formal primero. Debe quedar clara la versión actual del storyboard y esperar la respuesta del usuario. Si hay modificaciones, se actualiza y se vuelve a presentar; solo después de la confirmación explícita del usuario se procede a la producción formal posterior.

3. Extracción de fotogramas

"$LIB/.venv/Scripts/python.exe" tools/prep_layers.py     # → frames/<capa>/f0001.jpg… + frames.json

Cada capa = las imágenes de una toma: silenciadas, recortadas a 16:9, convertidas según la velocidad, 24 fps, el i-ésimo fotograma corresponde al tiempo t0 + i/24 segundos, con 0,5 segundos extra al final para la transición. Cuatro tamaños: full 1920×1080 / card 960×540 / bg 480×270 (primero se desenfoca, en la página se verá más suave) / inset 640×360. Miles de jpg se cargan bajo demanda en la página; no se cargan todos a la vez.

4. Claude implementa index.html

Copie el esqueleto del proyecto de examples/codex-jiangzhi/index.html. Primero, según references/render-engine.md y references/visual-style.md, complete la migración de la plantilla antigua:

• Conservar: la base del dibujo, cover, subtítulos, carga bajo demanda de fotogramas, el esqueleto de renderizado async y el mapeo de tiempo de la narración. Ajuste las etiquetas, barras de progreso, tarjetas y estilos de título según las nuevas normas.
• Desactivar llamadas a efectos antiguos: rgbSplit, slices, pixel dinámico, wflash, shutter, shake de pantalla completa e inserción de 2 fotogramas negros. Elimine también los efectos de sonido configurados específicamente para estos efectos. Los párrafos de ejemplo negativo mantienen el orden temporal normal del material original.
• Reescribir: el objeto de ritmo de los párrafos, las escenas de animación explicativa, BAD[n]/OVER[n], HITS, los puntos de transición, el nombre de la tecla de material → nombre del sello.
• Todos los puntos temporales se obtienen con T('cue id'), no se escriben segundos fijos.
• Los efectos de sonido se registran en las escenas con E(t, 'hit'|'whoosh'|'tick'|'stamp'|'ding'|'pop'|'clack'|'zap'|'boom', {...}).

Después de modificar, extraiga algunos fotogramas fijos para confirmar que no hay errores:

cd "$LIB" && node core/render/still.mjs "<ruta absoluta del proyecto>" 0.5 11.2 20.5 47.7 93.3 --out "<proyecto>/stills/chk"
"$LIB/.venv/Scripts/python.exe" "$LIB/core/render/sheet.py" <proyecto>/stills/chk/sheet.jpg <proyecto>/stills/chk/*.png --cols 4 --w 480

Use un visor de imágenes disponible para abrir la vista general y verificar la imagen, los subtítulos, los sellos y la proporción del cuadro de explicación. Además, verifique fotogramas individuales completos en 640×360 y aproximadamente 390×219; no amplíe la imagen antes de decidir si la letra se lee bien. Es obligatorio revisar las tomas con más densidad de información. Si algo no está bien, reduzca el texto, divida la toma o amplíe el sujeto y vuelva a extraer fotogramas. Después de pasar la verificación de fotogramas fijos, revise en vista previa dinámica las transiciones y los párrafos de ejemplo negativo para confirmar que no hay parpadeos, sacudidas o destellos en los subtítulos.

5. Después de la confirmación del usuario, Claude renderiza y compone el video

Primero verifique que el usuario ha confirmado explícitamente la versión actual del storyboard; si no hay confirmación, deténgase en la etapa de revisión del storyboard. La auto-revisión estética de Claude y las verificaciones del programa no reemplazan este paso.

sh tools/build.sh <nombre del video final>            # Todo en uno: events → mix → video → mux → srt → QA

Lo que hace paso a paso es:

cd "$LIB" && node core/render/events.mjs "<proyecto>"                                  # Eventos de sonido en las imágenes → events.json
"$LIB/.venv/Scripts/python.exe" tools/mix.py --out mix.wav                        # Voz humana + efectos de sonido (si se necesita música, añadir --bgm)
cd "$LIB" && node core/render/video.mjs "<proyecto>" --fps 24 --workers 5 --out "<proyecto>/video_<nombre>.mp4"
sh "$LIB/core/render/mux.sh" video_<nombre>.mp4 mix.wav <nombre>.mp4 24 0                  # −14 LUFS, sin añadir granulado a las imágenes vectoriales
"$LIB/.venv/Scripts/python.exe" "$LIB/core/render/srt.py" cues.json <nombre>.srt

El tiempo de renderizado depende del resultado real de la máquina. Use un nombre de archivo diferente para cada --out (el renderizador tiene un archivo de bloqueo; el mismo nombre impedirá el proceso).

6. Claude realiza el control de calidad y luego entrega el resultado

sh tools/qa.sh <nombre>.mp4 imprime: codec/duración, lista de fotogramas negros, sonoridad, y genera una vista general de fotogramas extraídos qa/sheet.jpg. Verifique punto por punto:

• Fotogramas negros: solo se permiten los degradados de apertura/cierre diseñados, etc. No se deben usar inserciones de 2 fotogramas negros, obturador o destellos negros como transiciones predeterminadas. Los fotogramas negros inesperados requieren verificar la carga del material y el tiempo de entrada de los elementos.
• Sonoridad: aproximadamente −14 LUFS, pico ≤ −1 dB.
• Vista general de fotogramas extraídos: Revise todo el video desde el principio con esta vista general; los subtítulos y las imágenes deben coincidir, y la posición de las pegatinas no debe tapar las caras.
• Legibilidad visual y en móvil: Según references/visual-style.md, verifique la paleta de colores, la semántica del rojo, la tipografía unificada, el tamaño real de la letra, la zona segura de los subtítulos y los fotogramas completos en tamaño de teléfono móvil.
• Comodidad dinámica: Reproduzca todas las transiciones y los párrafos de ejemplo negativo. La extracción dispersa de fotogramas y blackdetect no pueden demostrar que no haya destellos blancos o parpadeos de fallo. Finalmente, entregue el mp4 / srt / póster mediante el método de archivo adjunto/enlace disponible en el entorno actual, e indique claramente qué material se usó en qué frase y qué comprobaciones se realizaron realmente; no asuma que existe una herramienta report_artifacts.

Normas Estrictas

• Si el mismo error aparece dos veces seguidas, deténgase e informe, no intente repetir una y otra vez. En caso de error de red, no reenvíe tareas de pago repetidamente.
• Todas las muestras deben estar silenciadas; no use fragmentos con sonido original sin el consentimiento del usuario.
• Microsoft YaHei no tiene los glifos ✗ ⇢ ↘, por lo que se dibujarán como cuadros — use × → ↓.
• El storyboard debe ser finalmente confirmado por el usuario; sin esa confirmación no se puede proceder al renderizado formal y la producción posterior. Si el usuario modifica el guion, vuelva a ejecutar align.py, no modifique manualmente timeline.json. Si afecta a un storyboard ya confirmado, vuelva a presentar las partes afectadas para confirmación.
• Use un visor de imágenes real y disponible para ver las imágenes antes de sacar conclusiones. Si no ha visto el video, indique que la base son los fotogramas extraídos con marcas de tiempo específicas; no puede pasar la verificación de fotogramas fijos como una verificación dinámica de todo el video.

Referencias

• Guía de estilo visual — Lectura obligada cada vez: tipografía, colores, legibilidad en móvil, animaciones de bajo estímulo y verificación.
• Colaboración de modelos — División de trabajo Claude / DeepSeek / GPT, transferencia, límites de ejecución de Cherry y Codex.
• references/render-engine.md — Capas de index.html, implementación de cada tipo de toma, carga bajo demanda de fotogramas, trampas.
• references/storyboard-guide.md — Plantilla de estructura, reglas de selección de tomas, uso de material de muestra negativo, recetas de efectos de sonido de transición, escritura de shots.json.
• examples/codex-jiangzhi/ — Histórico v2 de "¿Realmente se ha vuelto más tonto Codex?": solo sirve como referencia de estructura del proyecto y narrativa; los colores antiguos, el texto pequeño, los fallos y los parpadeos no se pueden reutilizar directamente.
• scripts/ — align.py (alineación de narración), prep_layers.py (extracción de fotogramas), storyboard.py (paneles de storyboard), mix.py (mezcla de audio), build.sh (todo en uno), qa.sh (control de calidad).