vibe-video-producer

Producción para el Concurso Vibe de Conocimiento

Convertir un tema de conocimiento en un vídeo corto visible y materiales de publicación. Soporta producción completa, así como la modificación solo de subtítulos, ritmo, música de fondo, portada o texto; al modificar parcialmente, conserva el contenido ya confirmado y entrega solo la parte solicitada por el usuario.

Preferencias predeterminadas confirmadas

Los valores predeterminados se encuentran en assets/defaults.json; las solicitudes del usuario y la configuración del proyecto existente tienen prioridad:

• Contenido de conocimiento en chino; pantalla horizontal 16:9, 1920×1080, 30 fps; generalmente 30–45 segundos, determinado según el contenido y los tiempos musicales, sin forzar una duración fija.
• No agregar narración ni locución. Se conserva la voz humana presente en la música original del usuario; "sin locución adicional" no equivale a música instrumental pura.
• Texto grande, frases cortas, transiciones rápidas, énfasis visual claro. El color oscuro + verde menta + naranja cálido es un punto de partida utilizable, pero no se fija un estilo de circuito para todos los temas.
• Usar la música proporcionada por el usuario, mantener la velocidad original, analizar los tiempos musicales y organizar los cortes de escena. Se pueden usar alternancias de 4/6/8 tiempos, pero ajustar según el ritmo real de la canción y el tiempo de lectura.
• La entrega completa incluye MP4, portada horizontal 4:3, portada vertical 3:4, título, descripción, hashtags y el código fuente modificable.
• El formato de título predeterminado es Vibe知识大赏｜Gancho o pregunta específica, luego se agrega el nombre del conocimiento según sea necesario.
• La salida se coloca en un proyecto independiente dentro del espacio de trabajo actual, y se proporciona la ruta de archivo absoluta y accesible.

Al recibir una tarea

Primero verificar el project.json, storyboard, vista previa, producto final y comentarios ya confirmados del proyecto existente. No rehacer las partes ya completadas. Cuando el tema, la música, las especificaciones o la autorización ya estén claros en la conversación, no preguntar repetidamente. Solo preguntar cuando la falta de entrada realmente afecte el trabajo, y primero avanzar en las partes que no dependen de la respuesta.

La entrada mínima es el tema; la música se puede proporcionar después. Si no hay música, primero hacer el texto y el storyboard, no inventar una ruta de música ni afirmar que se ha completado la sincronización de tiempos. Cuando el usuario dice "a tu criterio", usar las preferencias predeterminadas para completar las elecciones habituales de forma autónoma. La autorización para la vista previa y la exportación local continúa siendo válida; no se requiere confirmación repetida para renderizados, correcciones y reintentos ya autorizados. Si el usuario solo quiere una vista previa, detenerse en esa etapa; si aún no se ha autorizado la exportación final, proporcionar una versión revisable y confirmar solo una vez. Este flujo no incluye la publicación automática en plataformas.

Flujo de producción

1. Crear el proyecto. Usar scripts/create_project.py para crear un proyecto independiente, guardar el tema/música/especificaciones; si ya existe un proyecto, continuar directamente. El script solo crea el directorio del proyecto y los registros de entrada, no reemplaza la creación, la detección de tiempos ni el renderizado.
2. Verificar el conocimiento. Priorizar fuentes primarias, dejar claro la conclusión central, las premisas aplicables, un ejemplo numérico verificable y los límites que se malinterpretan fácilmente; guardar en sources.md. Las metáforas deben indicar sus límites; no reescribir un teorema físico como una ley psicológica. Las matemáticas, circuitos, unidades y signos positivo/negativo deben ser coherentes.
3. Redactar texto corto y storyboard. Comenzar con una pregunta concreta, cada escena lleva un punto clave, al final retomar la pregunta. El título, la descripción y los gráficos transmiten información diferente; evitar explicaciones múltiples en una sola pantalla. Primero determinar la carga de lectura, luego organizar el ritmo rápido/lento; no reemplazar el impacto con la cantidad de escenas.
4. Música y línea de tiempo unificada. Si se necesita sincronización de tiempos, leer references/timing-and-render.md. Usar scripts/beat_plan.py analyze para detectar tiempos, verificar BPM, ambigüedades de medio tiempo/doble tiempo y ataques fuertes; basarse en el fragmento seleccionado por el usuario o los resultados de la escucha previa. Usar plan para convertir eventos como número de tiempos por escena, palabras clave, fórmulas y correcciones en un número de fotograma y línea de tiempo unificados. Los puntos de corte musical, escenas, subtítulos y efectos dinámicos usan todos esta tabla; no mantener múltiples conjuntos de segundos escritos manualmente.
5. Crear el proyecto y la vista previa. Por defecto, priorizar el proyecto HyperFrames disponible localmente. Cuando sea necesario, leer las hyperframes-vibe-169 disponibles y sus contratos de composición, cumplir con los requisitos de subcomposiciones y líneas de tiempo GSAP en pausa. Usar assets/hyperframes-clock.js o corrección de precisión equivalente para evitar que los seis decimales de GSAP retrasen el corte un fotograma. Al cambiar de motor, usar el proyecto existente del usuario; no rehacerlo para invocar la habilidad.
6. Verificar y completar el renderizado. Ejecutar la validación del motor, verificar cada escena, los bordes del texto grande, la reproducción aleatoria, los fotogramas antes y después de los tiempos clave, luego exportar localmente según la autorización existente. Usar scripts/audit_render.py para verificar las especificaciones reales del producto final, cantidad de fotogramas, decodificación completa y desplazamiento de la pista de audio; además, verificar todos los cortes de escena y efectos dinámicos clave fotograma a fotograma; pasar la decodificación del script no reemplaza la inspección visual. Si se encuentran problemas, solo volver a ejecutar las verificaciones afectadas y la validación del producto final. Ver la referencia de sincronización para más detalles.
7. Portada y materiales de publicación. Leer references/visual-and-delivery.md. Usar imagegen o las plantillas de portada existentes para generar composiciones independientes en 4:3 y 3:4, verificar caracteres chinos, fórmulas, flechas, márgenes y proporciones de píxeles reales. Generar título, descripción y algunos hashtags relevantes consistentes con el producto final.
8. Entrega. Confirmar que los archivos reales existen y proporcionar MP4, portadas dobles, texto de publicación y el directorio del proyecto. Indicar la duración y especificaciones, limitaciones importantes. Si no se ha exportado correctamente, indicar claramente "vista previa/código fuente completados", no afirmar que el producto final está completo. Conservar project.json, sources.md, storyboard.json, beat-map.json, resultados de verificación y código fuente para facilitar futuras modificaciones.

Combinación con otras habilidades

• hyperframes-vibe-169: Al seleccionar este motor, se encarga de la composición, lint, vista previa y renderizado. Sus ejemplos de estilo no reemplazan el tema actual.
• lemo-opuscar: Se usa cuando el usuario solicita esta habilidad o cuando el tema requiere su método de dirección/estilo; solo leer el estilo correspondiente. Las revisiones parciales de un producto final existente no reinician automáticamente el cuestionario de estilo de un nuevo vídeo.
• painted-animation / Joker-chichi/claude-mv-skill: Solo se usa para animación dibujada a mano, videoclips de letras o cuando se necesita su herramienta de detección de tiempos. Los vídeos de divulgación con BGM no requieren que el usuario proporcione un LRC adicional.
• imagegen: Se encarga de generar o modificar portadas de mapa de bits. Guardar la imagen final en el proyecto, registrar el prompt; no tratar la descripción de la habilidad como una API de imágenes directamente invocable.
• openfilm / jianying-editor: Solo se usa cuando el usuario lo especifica o cuando el proyecto existente realmente lo utiliza.

No se requiere ejecutar todas las habilidades simultáneamente para cada proyecto. Cuando una herramienta no está disponible, primero verificar el entorno de ejecución local existente y alternativas viables; no instalar silenciosamente dependencias grandes, no reemplazar el producto especificado por el usuario. Conservar mensajes de error claros, no usar reintentos infinitos para ocultar problemas.

Scripts auxiliares

Los scripts se ejecutan con Python 3; el análisis de audio y la verificación de sincronización requieren NumPy adicionalmente; FFmpeg/FFprobe se pueden pasar desde PATH o como parámetros explícitos. No se necesitan claves API, no se incluyen música, renderizadores ni binarios de terceros. Usar Python/Node ya descubiertos en la máquina local; no tomar rutas absolutas de proyectos antiguos como dependencias genéricas.

python scripts/create_project.py --workspace <workspace> --slug <slug del tema> --topic <tema> --music <MP3 opcional>
python scripts/beat_plan.py analyze --music <música> --out <beat JSON> --offset 0 --seconds 50 --ffmpeg <ruta de ffmpeg>
python scripts/beat_plan.py plan --grid <beat JSON> --story <storyboard JSON> --out <beat-map.json>
python scripts/audit_render.py --video <MP4> --plan <beat-map.json> --score <archivo de música final opcional> --out <audit.json>

El formato de entrada del storyboard, la corrección manual de tiempos y la precisión del renderizado se encuentran en la referencia de sincronización. La plantilla de directorio, portada y revisión del texto se encuentran en la referencia visual y de entrega. Los valores de salida de los scripts son evidencia de verificación, no una garantía automática de corrección artística o científica.