Guide vidéo de démo Cursor

Quel flux la vidéo doit elle montrer ?

Choisissez l'unique flux qui prouve que la build fonctionne, pas une visite du code qui l'a produite. Un spectateur regardant une vidéo de démo ne se soucie pas que le projet ait été écrit dans Cursor plutôt qu'assemblé par un générateur. Il se soucie de savoir si l'application en cours d'exécution accomplit la tâche qu'elle prétend accomplir. Choisissez l'unique action qui répond le plus directement à cette question : une tâche accomplie, un résultat produit, un état qui change d'une manière que le spectateur peut suivre sans que la narration ne fasse tout le travail.

Parce que les projets Cursor tendent vers du code de style production plutôt que des prototypes rapides, ils sont plus susceptibles d'inclure une authentification réelle, une vraie base de données, et une logique métier authentique derrière les écrans. Cela peut rendre l'application plus capable mais aussi plus susceptible d'avoir un flux qui dépend d'un état antérieur, donc planifiez le parcours enregistré autour de données qui existent déjà plutôt que de supposer qu'un état vide démontrera quoi que ce soit d'utile.

Cela signifie aussi que les modes de défaillance sont différents de ceux d'un prototype généré. Un prototype peut montrer un tableau visiblement vide. Une build Cursor de style production est plus susceptible d'échouer silencieusement, renvoyant un écran d'apparence correcte avec les mauvaises données, ou un message de succès pour une opération qui ne s'est pas réellement terminée. Testez le flux exact à la main immédiatement avant l'enregistrement, pas la veille, pour que l'état capturé par le rendu corresponde à ce que vous avez confirmé en dernier.

• Confirmez l'URL exacte et la route où le flux doit commencer.
• Préparez des données qui rendent le résultat lisible, puisqu'un vrai backend démarre rarement pré rempli.
• Retirez tout nom de client, donnée de client, ou matériel privé de l'environnement avant l'enregistrement.
• Si une connexion protège le flux, utilisez un compte de démonstration plutôt qu'un compte réel.

Où cette vidéo s'inscrit elle pour un développeur solo ?

Le guide de la vidéo de démo pour développeur solo couvre le cas où la même personne a écrit le code, l'a déployé, et est le seul relecteur avant que le clip aille où que ce soit publiquement, ce qui est courant pour les projets Cursor construits en dehors d'une équipe. Pour un produit déjà lancé qui reçoit une mise à jour incrémentale, le guide de la vidéo de mise à jour produit couvre le cadrage du clip autour de ce qui a changé plutôt que de toute l'application. Si le processus actuel implique un enregistreur d'écran manuel comme alternative, le guide de l'alternative Screen Studio pour la démo produit compare directement cette approche.

Environ un rendu sur cinq échoue ou nécessite une nouvelle tentative, donc regardez le candidat avant de l'envoyer où que ce soit. Pour une mise à jour destinée à une partie prenante plutôt qu'à un public général, le guide de la vidéo de mise à jour investisseur couvre le recentrage du même flux sur un changement actuel. Pour choisir à quoi doit ressembler la première image du fichier avant qu'il soit partagé, le guide de l'image d'aperçu de vidéo de démo est pertinent quelle que soit la plateforme qui a produit l'application.

Pour le même travail sur les autres pages Cursor, voir le guide de la vidéo de page de destination Cursor, le guide de la vidéo de lancement Product Hunt Cursor, le guide du partage Cursor avec un client et le guide de la démo de portfolio Cursor, et pour relire une build par rapport à un brief, le guide de la visite de relecture d'application Cursor. Pour une comparaison directe des outils d'enregistrement, consultez GogoScreen contre Screen Studio. Commencez depuis la page d'accueil pour le flux de travail de l'URL et de l'indication, parcourez les guides pour le reste de la série, consultez les comparaisons avec d'autres outils, et vérifiez les tarifs avant de soumettre un rendu.