Guía7 min de lectura

Recorrido de revisión de una app de Cursor

Demuestre que la petición se cumplió sin pedirle a nadie que ejecute el código.

Entregue a un revisor una construcción de Cursor con un flujo que demuestre que el cambio solicitado funciona, en lugar de pedirle que ejecute el código.

Ver cómo funcionaLos primeros 60 segundos de vídeo son gratuitos, con marca de agua.
Verifique su correo electrónico para descargarlo.

Un traspaso de revisión tiene una función más estrecha que una demo, un discurso de venta o una pieza de portafolio. Alguien pidió algo concreto, ya fuera una corrección de errores, una función nueva o un cambio en un flujo existente, y la persona que revisa el trabajo quiere saber una cosa: si ocurrió. No están evaluando todo el producto y normalmente no quieren un tour. Un recorrido construido para este momento debe responder a la petición original con la misma claridad que un sí o un no, respaldado por imágenes que muestren la respuesta en lugar de describirla.

Cursor es un editor de código, y el código que ayuda a escribir no se vuelve alcanzable por sí solo. Una construcción hecha en Cursor se ejecuta en un servidor de desarrollo local mientras se está trabajando en ella, y se convierte en algo que un revisor puede ver solo una vez que se despliega en algún lugar, ya sea un entorno de staging compartido, un servidor personal o un enlace de vista previa del alojamiento que use el proyecto. Antes de grabar un recorrido de revisión, confirme cuál de ellos está realmente en producción, ya que un revisor que compare el vídeo con un despliegue roto o desactualizado no confiará ni en el vídeo ni en la construcción.

Esto importa más en un recorrido de revisión que en casi cualquier otro tipo de vídeo demo, porque todo el sentido de la grabación es que se pueda comprobar. Un vídeo demo dirigido a un desconocido rara vez se compara contra una ruta en vivo que el espectador abra por su cuenta. Un recorrido de revisión sí suele compararse así, a veces minutos después de enviarse, y cualquier diferencia entre lo que muestra el vídeo y lo que encuentra el revisor por su cuenta se convierte en la historia de la revisión en lugar del propio cambio.

¿Qué necesita ver realmente el revisor?

Vuelva a la petición original y escríbala como una sola frase que describa un inicio, una acción y un resultado. Si la petición era arreglar un botón de envío roto, el flujo es: abrir el formulario, rellenarlo, enviarlo, verlo funcionar. Si la petición era añadir un filtro a una lista, el flujo es: abrir la lista, aplicar el filtro, ver cambiar la lista. Nada de lo que el revisor no pidió, por muy terminado que esté, pertenece a esta grabación. Un recorrido que se desvía hacia funciones adyacentes obliga al revisor a hacer un esfuerzo extra para encontrar la parte que realmente pidió.

Tipo de petición	El flujo que hay que mostrar	Qué dejar fuera
Corrección de errores	Los pasos exactos que antes fallaban, terminando en éxito	Pantallas no relacionadas que nunca estuvieron rotas
Función nueva	La función usada desde un punto de partida realista	Un tour por toda la página que la rodea
Cambio visual o de texto	Un antes y un después claro en el mismo lugar	Otros cambios pendientes que no forman parte de esta petición

¿Cómo se prepara la construcción para el recorrido?

Abra usted mismo la ruta desplegada primero y recorra los pasos exactos que le importan al revisor. Confirme que la corrección o la función está presente en la versión que realmente está en producción, no solo en una rama local que todavía no se ha desplegado. Esto suena obvio y se salta constantemente, sobre todo bajo presión de plazos, y es el motivo más común por el que una grabación de revisión avergüenza a quien la hizo.

Confirme que la construcción desplegada coincide con el código que cree que se fusionó.
Elimine cualquier dato de prueba de una depuración anterior que pudiera confundir al revisor.
Configure una cuenta de demostración si el flujo está detrás de un inicio de sesión, en lugar de compartir una real.
Cronometre la interacción una vez antes de grabar, para que la indicación coincida con lo que realmente ocurre.

Si la app necesita autenticación para que el revisor vea la pantalla relevante, solicite una cuenta de demostración mediante el proceso normal en lugar de enviar un inicio de sesión personal. En GogoScreen, las credenciales proporcionadas para una renderización se cifran, se usan para una única renderización y después se eliminan, lo cual importa cuando la construcción en cuestión pertenece a un cliente y no a usted. Si primero se planifica un storyboard, las credenciales se conservan cifradas durante esa sesión y se eliminan como máximo dos horas después de su último uso. Una situación relacionada pero distinta es revisar una solicitud de extracción en sí en lugar de una app en ejecución, lo cual cubre por separado la guía de vídeo demo de PR de un agente de IA.

También ayuda comprobar la construcción cerca del momento en que el revisor realmente la verá. Un despliegue que parecía correcto hace una hora puede desviarse si otro cambio llega al mismo entorno mientras tanto, en particular en un servidor de staging compartido al que empujan varias personas. Grabar justo antes de enviar, en lugar de reutilizar una grabación anterior de la misma función, mantiene ese riesgo bajo.

¿Cómo debe redactarse la indicación del flujo?

Reformule la petición como un único flujo que el revisor pueda ver de principio a fin.
Alcance el estado exacto que la responde, no una pantalla cercana que se le parezca.
Recorte todo lo que la petición no pidió, incluso si también está terminado.

Redacte la indicación con las mismas palabras que usó la petición original. Si el ticket decía "el botón de pago", la indicación debe decir botón de pago, no acción de pago. Un revisor que compara las imágenes con su propio recuerdo de la petición nota los desajustes de palabras más rápido que la mayoría de los otros problemas, y un desajuste se lee como prueba de que la petición se malinterpretó incluso cuando no fue así.

¿Dónde encaja esto junto a una demo o un vídeo de lanzamiento?

Un recorrido de revisión y un vídeo demo se parecen en la superficie, y ayuda mantener sus propósitos separados. Un recorrido de producto para SaaS está construido para un posible comprador que decide si el producto vale la pena probar, mientras que un recorrido de revisión está construido para alguien que ya conoce el producto y comprueba una afirmación concreta. Si la construcción necesita más adelante una introducción como es debido una vez aceptado el trabajo, un tratamiento estilo vídeo demo de Windsurf o vídeo de página de destino de Windsurf es el siguiente paso mejor, ya que ambos están escritos para un espectador de primera vez en lugar de un revisor con contexto.

Algunas peticiones vienen de una audiencia pública en lugar de un revisor privado, como un vídeo demo de Show HN que responde a comentarios en un hilo de lanzamiento. Ese caso está más cerca de un recorrido de revisión que de una demo, ya que también responde a una pregunta concreta que alguien hizo, solo que en público en lugar de en privado. La misma disciplina de reformular la pregunta y mostrar la respuesta se aplica en ambos casos. Una necesidad de revisión similar aparece también en otras plataformas de creación con IA, incluidas la guía de vídeo demo de una app de v0 y la guía de vídeo demo de una app de Lovable, ambas escritas para el momento justo después de que una construcción generada necesita comprobarse frente a lo que se pidió.

¿Qué debe comprobar antes de enviarlo?

Vea la grabación frente al texto de la petición original, línea por línea si la petición tenía más de una parte. Si la revisión se envía a alguien que compara varios creadores, una entrada estilo demo de portafolio de Windsurf o vídeo de lanzamiento en Product Hunt de Windsurf cubre esa comparación más amplia, pero un recorrido de revisión en sí debe mantenerse estrecho. Si el revisor necesita compartir la grabación más adelante, un traspaso estilo compartir con un cliente de Windsurf explica cómo prepararla para alguien que ni siquiera va a hacer clic en un enlace de vista previa.

Deje margen en su calendario para un reintento, ya que aproximadamente una de cada cinco renderizaciones necesita uno. Cada cuenta nueva recibe 60 segundos de vídeo una vez, con marca de agua, lo cual suele cubrir cómodamente una sola petición, y después, el tiempo comprado con recargas nunca caduca y el tiempo solo se usa cuando una renderización sale bien. Compare las opciones de captura con Loom si el revisor espera una pantalla compartida en directo en su lugar, consulte los precios para conocer los planes, explore más guías y comparaciones, o vuelva a la página de inicio de GogoScreen para iniciar una nueva renderización para la siguiente petición.

Aclaraciones

Antes de empezar

¿Qué debe demostrar un recorrido de revisión de una app de Cursor?

Debe demostrar que lo concreto que pidió el revisor realmente ocurre en la app en ejecución. Eso significa partir de la petición, no del código base, y mostrar el estado exacto que la responde.

¿Debe el recorrido explicar cómo funciona el código?

No. Un revisor que aprueba una construcción normalmente quiere saber que el resultado es correcto, no cómo llegó la implementación a él. Reserve la explicación de implementación para la descripción de una solicitud de extracción o una llamada aparte.

¿Qué pasa si el revisor no puede acceder a una construcción protegida por inicio de sesión?

Se puede preparar una cuenta de demostración para la renderización en GogoScreen, donde las credenciales se cifran, se usan para una única renderización y después se eliminan. Si primero se planifica un storyboard, las credenciales se conservan cifradas durante esa sesión y se eliminan como máximo dos horas después de su último uso. Eso elimina la necesidad de entregarle al revisor un inicio de sesión real.

Pegue una URL, describa un flujo y obtenga un vídeo de demostración de su aplicación web.

Los primeros 60 segundos de vídeo son gratuitos, con marca de agua. Verifique su correo electrónico para descargar el vídeo.

Ver precios Leer las guías