Habilidade de Vídeo de Funcionalidade do Produto

Planear e criar um vídeo de demonstração/funcionalidade para um produto real e em funcionamento — capturado em ecrãs reais via Playwright, narrado com TTS real, acompanhado por uma música de fundo real (open-source, licença limpa) e montado no Remotion. Esta é uma disciplina diferente de um trailer de produto sintético com motion graphics: as imagens já existem e não podem ser redesenhadas para se adequar a um plano, por isso o plano tem de se adequar às imagens.

A principal diferença de um trailer sintético com motion graphics

Muitos fluxos de trabalho de vídeo no Remotion assumem que controlas cada pixel e podes reajustar qualquer coisa — porque o vídeo inteiro é construído de raiz: maquetes, fundos gerados, UI inventada. Essa premissa não se aplica aqui. Uma gravação de ecrã real segue o seu próprio ritmo; um clique real ocorre num frame específico, não quando um storyboard deseja; alguns momentos (uma janela nativa do SO, a barra de ferramentas do próprio navegador, uma interação que termina em meio segundo) não podem ser refilmados para se adequar a um plano. Esta habilidade é construída em torno dessa restrição desde o início — a arte do motion design (easing, transições, densidade de movimento) ainda é importante e é abordada na Fase 8, mas a verdadeira espinha dorsal do pipeline é o que o vídeo baseado em imagens reais exige especificamente: uma auditoria de protótipo-fallback para momentos impossíveis de capturar, segmentação com estabilidade verificada para zoom e ênfase de cliques em imagens reais, e um ritmo determinado pelas durações reais dos ativos, não por um plano.

Princípio central: imagens reais primeiro, protótipo depois, ilustração por último

Para cada cena, prefere, por esta ordem:

Imagens reais — uma gravação Playwright real da aplicação real em funcionamento.
Um protótipo HTML revisto, capturado da mesma forma, para tudo o que as imagens reais não conseguem mostrar estruturalmente (ver Fase 2).
Um placeholder honesto e claramente ilustrado — apenas quando nenhuma das opções anteriores é viável, e apenas se não fingir ser real.

Nunca finjas que a opção 1 é a opção 3 disfarçada de real. Um espectador confia num vídeo de demonstração precisamente porque é real; um momento com aparência fabricada desacredita todos os genuínos.

Fase 0: Briefing

Pergunta uma vez, em conjunto, antes de qualquer outra coisa:

Produto e repositório — nome, descrição de uma linha, URL/caminho local para a aplicação em funcionamento ou repositório.
Público e tom — quem está a ver e o que devem sentir (impressionados / tranquilizados / entusiasmados)?
Duração — teaser de 30s, visita guiada de 60-90s, ou um tour mais completo de 2-3 min? As imagens reais duram muito rapidamente; sê honesto quanto ao âmbito.
O momento que tem de resultar — se o espectador se lembrar de exatamente uma coisa, o que é? Este torna-se o clímax/momento heroico.
Conta de login/teste — capturar a aplicação requer uma conta? Pode ser criada uma conta de demonstração descartável, ou já existe alguma?
Contexto de publicação — página de destino, YouTube, feed de redes sociais (autoplay-muted é muito importante para decisões de legendas/texto no ecrã).

Se o produto for uma extensão de navegador, pergunta também se o Manifest V3 está em uso (altera a estratégia de lançamento do Playwright — ver Fase 6).

Fase 1: Reconhecimento — extrair o sistema de design real, não inventar um

Antes de qualquer decisão estética, lê o produto real:

Extrai os tokens de cor reais, a pilha de fontes e a escala de espaçamento do próprio ficheiro CSS/tema da aplicação. Usa-os como estão, mesmo que a cor de destaque se pareça com um cliché genérico de "SaaS de IA" (indigo/roxo em preto quase total é extremamente comum em paletas de produtos reais também — só é um sinal de alarme quando é um padrão inventado, não quando é a paleta real do produto). A autenticidade vence a novidade aqui.
Anota o texto real da UI do produto, a terminologia e a arquitetura de informação — as legendas e a narração do vídeo devem usar as próprias palavras da aplicação, não uma paráfrase de marketing.
Executa a aplicação uma vez, do início ao fim, como um utilizador faria. Identifica: qual é a única melhor interação "heroica"? O que é genuinamente difícil de demonstrar ao vivo (ver Fase 2)?

Guarda os tokens extraídos (cores, fontes) num ficheiro tokens.ts/tokens.css que todo o projeto de vídeo importa de um único local — cada cena, real ou construída em código, deve pertencer visivelmente ao mesmo produto.

Fase 2: Auditoria de Protótipo-Fallback (faz isto antes do storyboard)

Percorre a lista de funcionalidades planeadas e sinaliza tudo o que o Playwright não consegue capturar estruturalmente:

Cromado do navegador a nível do SO — o ícone da barra de ferramentas da extensão, chrome://extensions, menus de contexto do botão direito, seletores de ficheiros nativos, diálogos nativos do SO. O recordVideo do Playwright captura apenas o conteúdo da página, nunca a UI do próprio navegador.
Interfaces de desktop nativas (Tauri, Electron quando empacotado, Qt, etc.) — estas não são páginas web às quais o Playwright se pode anexar.
Interações demasiado rápidas ou pequenas para serem mostradas de forma fiável — um interruptor que se completa em menos de meio segundo de imagens reais é um mau alvo para um crop-zoom ou um anel de ênfase de clique; ambos precisam de uma janela estável de vários frames para aterrar (ver padrão ZoomCue/ClickRing da Fase 8 e a sua regra de estabilidade).

Para cada momento sinalizado, decide: imagens reais com uma solução alternativa (por exemplo, estado de semente através de uma chamada de API em vez de um clique real, conforme Fase 6), um protótipo HTML revisto (Fase 7), ou uma ilustração honestamente identificada (último recurso, e diz isso num comentário de código).

Fazer esta auditoria antes do storyboard, e não depois, evita que o storyboard se comprometa com um ritmo e uma cobertura que a etapa de captura real não consegue cumprir — esta foi a maior fonte de retrabalho nas versões v1-v3 do TabNemo.

Fase 3: Storyboard e Plano de Cena

Arco narrativo

A mesma estrutura funciona quer as imagens sejam reais quer sintéticas:

Ato	Propósito	Percentagem do tempo total
Gancho	Abertura a frio — o problema, ou um momento marcante, antes de o nome do produto aparecer	5-8%
Revelação	O nome do produto/marca surge	8-10%
Demonstração	3-5 funcionalidades reais, uma de cada vez	45-55%
Clímax	O momento heroico identificado na Fase 0 — dá-lhe o maior cuidado visual	8-12%
Fecho	Logótipo, slogan, CTA	8-10%

Especificação por cena

Para cada cena, decide de antemão e anota:

Fonte: clipe real / captura de protótipo / b-roll construído em código (conforme auditoria da Fase 2).
Narração: texto exato, ou null. A duração da narração é uma restrição real — a duração do áudio TTS torna-se o comprimento mínimo da cena (ver Fase 4).
As imagens reais seguem o seu próprio ritmo — o durationInFrames de uma cena é max(duração do clipe real, duração da narração), obtida dos ativos reais processados, nunca assumida a partir de um plano. Quando a narração ultrapassa o clipe, mantém o último frame do clipe em vez de fazer loop ou cortar a linha.
Plano de câmara: qualquer zoom/punch-in ou ênfase de clique, com coordenadas reais — decididas a partir de fotogramas reais, não adivinhadas (Fase 8).

Ponto de verificação de revisão

Mostra a lista de cenas + texto da narração antes de gravar um único clipe ou gerar uma nota de áudio. Um plano baseado em suposições erradas sobre as imagens disponíveis é caro de desfazer depois de existirem scripts TTS e Playwright.

Fase 4: Narração — guião e geração

Escreve dois documentos, não um:

Um guião de revisão — um bloco por cena, com o seu timecode planeado, para que um humano possa ler todo o arco da narração e aprovar o ritmo antes da geração.
Um guião de entrada TTS — as mesmas linhas, divididas uma por ficheiro de cena, com o ritmo transmitido apenas por pontuação (ou tags SSML <break>/<emphasis> se o motor as suportar), para que cada cena se torne o seu próprio clipe de áudio colocável no seu próprio offset.

Ferramentas de geração

ttsmp3.com — gratuito, sem registo, com backend Amazon-Polly. Sem API pública, por isso a geração é um clipe de cada vez através da UI do navegador — reserva uma sessão focada para fazer todos e nomeia os ficheiros de saída por cena (scene-03.mp3, não tts_export_1.mp3).
Para um pipeline que precise de funcionar sem supervisão (CI, um agente sem navegador), prefere uma opção open-source/local efetivamente programável: Piper (totalmente offline, licença MIT, rápido, vozes decentes) ou edge-tts (usa as vozes de leitura do Microsoft Edge, gratuito, sem chave, programável, mas depende de um serviço externo disponível). O Gemini TTS e o ElevenLabs são alternativas fortes não open-source se o custo da API for aceitável. Independentemente do motor, se não garantir consistência de voz entre chamadas separadas, gera todos os segmentos num único pedido com marcadores de pausa entre eles e depois divide-os com base no silêncio detetado — este truque resolve o problema da "voz diferente por linha", independentemente do motor.

Após a geração — o áudio é a fonte da verdade

Obtém a duração real de cada ficheiro gerado (não confies numa estimativa). Propaga as durações reais de volta para o plano de tempo da cena. Este único passo evitou todos os bugs de temporização na construção do TabNemo — a narração é aquilo contra o qual o ouvido do espectador mede uma cena, por isso é ela, e não o plano, que define o ritmo.

Fase 5: Música de Fundo — obter uma cativante sem um problema de licenciamento

Um loop de pad e drone monótono soa a música de elevador, não a uma base "cativa" — a diferença é quase sempre um gancho melódico repetitivo, não apenas pads harmónicos. Três opções reais, por ordem de "licença mais segura" a "mais fiávelmente cativante":

Opção A — Síntese procedural (risco zero de licença, precisa de esforço real para não soar monótono)

Gera um WAV estéreo curto e perfeitamente loopável em Node/Python puro — sem modelos, sem dependências, sem qualquer questão de licenciamento, porque tu escreveste cada amostra. A receita concreta que funcionou:

Um loop de acordes curto (8-16 compassos) usando osciladores simples (sine/triangle) com envelopes de ataque/lento release — isto sozinho é a armadilha da "música de elevador"; NÃO é o gancho.
O verdadeiro gancho: uma melodia de corda dedilhada (Karplus-Strong) a tocar por cima, num padrão rítmico repetitivo fixo, uma oitava acima do pad — isto é o que torna um loop sintetizado memorável em vez de papel de parede ambiente. Não saltes esta camada.
Um pulso suave de kick + hi-hat por baixo para dar movimento para a frente, suficientemente baixo para se sentar sob a narração.
Normaliza para deixar margem dinâmica, comprimento do loop escolhido para que toda a progressão termine numa fronteira de compasso (sem costura audível).

Isto é completamente seguro para distribuir comercialmente, mas a camada de gancho melódico é o que separa o "cativo" do "genérico" — orçamenta iteração real nisso e obtém uma audição e confirmação do utilizador antes de o ligar a uma renderização completa (regenerar um loop de 15-20s é barato; re-renderizar o vídeo inteiro para audicionar um diferente não é).

Opção B — Modelos de música generativa de pesos abertos (mais "produzido", verifica a licença sempre)

Stable Audio Open da Stability AI — pesos abertos, guiado por texto, produz genuinamente arranjos completos com conteúdo melódico real. Os termos de licença são mais permissivos do que a maioria dos modelos de áudio generativo, mas têm condições baseadas em receita — relê a licença atual antes de qualquer uso comercial, pois estes termos mudam.
MusicGen da Meta (via biblioteca audiocraft) — excelente qualidade, mas os seus pesos de modelo de música são tipicamente licenciados como CC-BY-NC (não comercial) — não utilizes a saída gerada num vídeo de lançamento de produto monetizado sem limpar isso separadamente.
Ambos podem ser executados localmente (GPU recomendada) ou através de um endpoint de inferência hospedado (Replicate, Hugging Face Spaces) se não houver computação local disponível.

Opção C (recomendação padrão) — usa B para a ideia, envia A para o ativo

Solicita um modelo de pesos abertos localmente apenas para inspiração ("gancho synth-pop cativante, ~110bpm, sensação de produto tecnológico otimista e acolhedor"), ouve algumas gera

akmishra56/skill-video-de-produto

O que é skill-video-de-produto?

Perguntar na sua IA favorita

Documentação