Guia7 min de leitura

Apresentação Guiada de Revisão de Aplicação Cursor

Prove que o pedido foi concluído sem pedir a ninguém que execute o código.

Entregue a um revisor uma compilação Cursor com um fluxo que prova que a alteração pedida funciona, em vez de lhe pedir para executar o código.

Ver como funcionaOs primeiros 60 segundos de vídeo são gratuitos, com marca de água.
Verifique o seu correio eletrónico para o descarregar.

Uma entrega para revisão tem um objetivo mais restrito do que uma demonstração, um discurso de vendas ou uma peça de portefólio. Alguém pediu algo específico, seja uma correção de erro, uma nova funcionalidade ou uma alteração a um fluxo existente, e a pessoa que revê o trabalho quer saber uma coisa: se aconteceu. Não está a avaliar o produto inteiro e normalmente não quer uma visita guiada. Uma apresentação guiada construída para este momento deve responder ao pedido original de forma tão direta como um sim ou um não, apoiada por filmagens que mostram a resposta em vez de a descreverem.

O Cursor é um editor de código, e o código que ajuda a escrever não se torna acessível por si só. Uma compilação feita no Cursor é executada num servidor de desenvolvimento local enquanto está a ser trabalhada, e só se torna algo que um revisor pode ver depois de ser implementada nalgum lugar, seja um ambiente de staging partilhado, um servidor pessoal ou uma ligação de pré-visualização do alojamento que o projeto utiliza. Antes de gravar uma apresentação guiada de revisão, confirme qual destes está realmente ativo, uma vez que um revisor que compare o vídeo com uma implementação avariada ou desatualizada não vai confiar nem no vídeo nem na compilação.

Isto importa mais numa apresentação guiada de revisão do que em quase qualquer outro tipo de vídeo de demonstração, porque todo o objetivo da gravação é que possa ser verificada. Um vídeo de demonstração dirigido a um estranho raramente é comparado com uma rota ativa que o próprio espetador abre. Uma apresentação guiada de revisão é frequentemente comparada dessa forma, por vezes minutos depois de ser enviada, e qualquer diferença entre o que o vídeo mostra e o que o revisor encontra quando olha por si próprio torna-se a história da revisão em vez da própria alteração.

O que é que o revisor realmente precisa de ver?

Volte ao pedido original e escreva-o como uma única frase que descreva um início, uma ação e um resultado. Se o pedido foi corrigir um botão de envio avariado, o fluxo é: abrir o formulário, preenchê-lo, submetê-lo, ver que teve sucesso. Se o pedido foi adicionar um filtro a uma lista, o fluxo é: abrir a lista, aplicar o filtro, ver a lista mudar. Tudo o que o revisor não pediu, por mais concluído que esteja, não pertence a esta gravação. Uma apresentação guiada que se desvia para funcionalidades adjacentes obriga o revisor a um trabalho extra para encontrar a parte que realmente pediu.

Tipo de pedido	O fluxo a mostrar	O que deixar de fora
Correção de erro	Os passos exatos que costumavam falhar, terminando em sucesso	Ecrãs não relacionados que nunca estiveram avariados
Nova funcionalidade	A funcionalidade utilizada a partir de um ponto de partida realista	Uma visita a toda a página circundante
Alteração visual ou de texto	Um antes e depois claro no mesmo local	Outras alterações pendentes que não fazem parte deste pedido

Como preparar a compilação para a apresentação guiada?

Abra você mesmo primeiro a rota implementada e percorra os passos exatos que interessam ao revisor. Confirme que a correção ou funcionalidade está presente na versão que está realmente ativa, não apenas num ramo local que ainda não foi implementado. Isto parece óbvio e é constantemente ignorado, especialmente sob pressão de prazos, e é o motivo mais comum de uma gravação de revisão envergonhar quem a fez.

Confirmar que a compilação implementada corresponde ao código que acredita ter sido integrado.
Eliminar quaisquer dados de teste de depurações anteriores que possam confundir o revisor.
Configurar uma conta de demonstração se o fluxo estiver protegido por um início de sessão, em vez de partilhar uma conta real.
Cronometrar a interação uma vez antes de gravar, para que a indicação corresponda ao que realmente acontece.

Se a aplicação precisar de autenticação para o revisor ver o ecrã relevante, peça uma conta de demonstração através do processo normal, em vez de enviar um início de sessão pessoal. No GogoScreen, quaisquer credenciais fornecidas para uma renderização são cifradas, utilizadas para uma única renderização e depois eliminadas, o que importa quando a compilação em questão pertence a um cliente e não a si. Se for planeado primeiro um storyboard, as credenciais ficam cifradas durante essa sessão e são eliminadas, no máximo, duas horas após a última utilização. Uma situação relacionada mas diferente é rever um pull request em si, em vez de uma aplicação em execução, o que o guia de vídeo de demonstração de PR de agente de IA aborda separadamente.

Também ajuda verificar a compilação num momento próximo daquele em que o revisor vai realmente assistir. Uma implementação que parecia correta há uma hora pode desviar-se se outra alteração for lançada no mesmo ambiente entretanto, sobretudo num servidor de staging partilhado por várias pessoas. Gravar imediatamente antes de enviar, em vez de reutilizar uma gravação mais antiga da mesma funcionalidade, mantém esse risco reduzido.

Como deve ser escrita a indicação do fluxo?

Reformular o pedido como um fluxo que o revisor pode ver do início ao fim.
Alcançar o estado exato que lhe responde, não um ecrã próximo com aspeto semelhante.
Cortar tudo o que o pedido não solicitou, mesmo que também esteja concluído.

Escreva a indicação com as mesmas palavras que o pedido original utilizou. Se o ticket dizia "o botão de finalização de compra", a indicação deve dizer botão de finalização de compra, não ação de pagamento. Um revisor que compara a filmagem com a sua própria memória do pedido nota diferenças de palavras mais depressa do que a maioria dos outros problemas, e uma diferença é lida como prova de que o pedido foi mal compreendido, mesmo quando não foi.

Onde é que isto se encaixa ao lado de uma demonstração ou de um vídeo de lançamento?

Uma apresentação guiada de revisão e um vídeo de demonstração parecem semelhantes à superfície, e ajuda manter os propósitos separados. Uma apresentação guiada de produto para SaaS é construída para um potencial comprador a decidir se vale a pena experimentar o produto, enquanto uma apresentação guiada de revisão é construída para alguém que já conhece o produto e está a verificar uma afirmação específica. Se a compilação precisar mais tarde de um vídeo de introdução adequado assim que o trabalho for aceite, um vídeo de demonstração Windsurf ou um vídeo de página de destino Windsurf do mesmo estilo é o melhor passo seguinte, uma vez que ambos são escritos para um espetador pela primeira vez e não para um revisor com contexto.

Alguns pedidos vêm de um público em geral, em vez de um revisor privado, como um vídeo de demonstração para o Show HN que responde a comentários num tópico de lançamento. Esse caso está mais próximo de uma apresentação guiada de revisão do que de uma demonstração, uma vez que também responde a uma pergunta específica que alguém fez, apenas em público em vez de em privado. A mesma disciplina de reformular a pergunta e mostrar a resposta aplica-se em ambos os casos. Uma necessidade de revisão semelhante surge noutras plataformas de construção com IA, incluindo o guia de vídeo de demonstração de aplicação v0 e o guia de vídeo de demonstração de aplicação Lovable, ambos escritos para o momento logo depois de uma compilação gerada precisar de ser verificada em relação ao que foi pedido.

O que deve verificar antes de o enviar?

Assista de novo à gravação em comparação com o texto do pedido original, linha a linha se o pedido tiver mais do que uma parte. Se a revisão for enviada a alguém que está a comparar vários construtores, uma entrada do estilo demonstração de portefólio Windsurf ou um vídeo de lançamento no Product Hunt Windsurf cobre essa comparação mais ampla, mas uma apresentação guiada de revisão deve manter-se restrita. Se o revisor precisar de partilhar mais a gravação, uma entrega do estilo partilha Windsurf com um cliente explica como a preparar para alguém que não vai clicar de todo numa ligação de pré-visualização.

Deixe espaço na sua agenda para uma nova tentativa, uma vez que aproximadamente uma em cada cinco renderizações precisa de uma. Cada conta nova recebe 60 segundos de vídeo uma única vez, com marca de água, o que normalmente cobre um único pedido confortavelmente, e depois disso o tempo comprado com carregamentos nunca expira e o tempo só é usado quando uma renderização é realmente bem-sucedida. Compare as opções de captura com o Loom se o revisor esperar uma partilha de ecrã em direto, verifique os preços para os planos, percorra mais guias e comparações, ou volte à página inicial do GogoScreen para começar uma nova renderização para o próximo pedido.

Esclarecimentos

Antes de começar

O que deve provar uma apresentação guiada de revisão de uma aplicação Cursor?

Deve provar que a coisa específica que o revisor pediu acontece efetivamente na aplicação em execução. Isso significa partir do pedido, não da base de código, e mostrar o estado exato que lhe responde.

A apresentação guiada deve explicar como o código funciona?

Não. Um revisor que aprova uma compilação normalmente quer saber que o resultado está correto, não como a implementação lá chegou. Guarde a explicação da implementação para a descrição de um pull request ou para uma chamada separada.

E se o revisor não conseguir aceder a uma compilação protegida por início de sessão?

Uma conta de demonstração pode ser preparada para a renderização no GogoScreen, onde as credenciais são cifradas, utilizadas para uma única renderização e depois eliminadas. Se for planeado primeiro um storyboard, as credenciais ficam cifradas durante essa sessão e são eliminadas, no máximo, duas horas após a última utilização. Isso elimina a necessidade de entregar ao revisor um início de sessão real.

Cole um URL, descreva um fluxo e obtenha um vídeo de demonstração da sua aplicação web.

Os primeiros 60 segundos de vídeo são gratuitos, com marca de água. Verifique o seu correio eletrónico para descarregar o vídeo.

Ver preços Ler os guias