Zum Inhalt springen
Leitfaden6 Min. Lesezeit

Leitfaden für Cursor-Demovideos

Beweisen Sie mit einem Ablauf, dass ein Cursor-Build funktioniert, keine Codetour.

Zeigen Sie einen funktionierenden Ablauf aus einer in Cursor gebauten App, wo es keine Standard-Vorschau-URL und kein eingebautes Deploy-Ziel gibt.

Ansehen, wie es funktioniertDie ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um es herunterzuladen.

Cursor ist ein Code-Editor mit eingebauter KI-Unterstützung. Er stellt nichts bereit, hostet nichts und erzeugt keine Vorschau-URL. Diese eine Tatsache verändert die Vorbereitung eines Demovideos mehr als jedes andere Detail der Plattform: Bevor eine URL und ein Hinweis irgendetwas hervorbringen können, muss die App schon irgendwo laufen, wo ein Browser sie erreichen kann. Ein Entwickler, der von einer Plattform kommt, die automatisch bereitstellt, findet diesen Schritt ungewohnt, und ihn zu überspringen ist der häufigste Grund, warum ein erster Versuch scheitert, bevor er begonnen hat.

GogoScreen nimmt eine Webanwendungs-URL und einen einzeiligen Hinweis darauf, was gezeigt werden soll, entgegen und liefert ein erzähltes, geschnittenes MP4 mit Zooms auf Klicks, Cursor-Glättung, Schnitten toter Momente und eingebrannten Untertiteln. Es funktioniert mit jeder beliebigen URL, die Sie ihm geben, das bedeutet, ein Cursor-Projekt, das auf irgendeinem Hosting läuft, egal ob eine bewusst gewählte Plattform oder eine schnell für die Aufnahme eingerichtete Bereitstellung, ist gleichermaßen als Quelle nutzbar. Dem Tool ist egal, welche Plattform den Code geschrieben hat. Es kommt darauf an, ob die URL zu einer funktionierenden App führt.

Warum braucht Cursor einen anderen Startschritt?

Ein in v0, Bolt oder Lovable gebautes Projekt kommt typischerweise mit einem automatischen Vorschau-Link, sobald die Generierung abgeschlossen ist. Ein in Cursor gebautes Projekt hat das nicht, weil die Aufgabe von Cursor beim Code endet. Bestätigen Sie, dass die App unter einer erreichbaren URL bereitgestellt ist, bevor Sie versuchen, sie aufzunehmen. Das kann bedeuten, auf ein Hosting zu pushen, das das Team bereits nutzt, oder es kann bedeuten, eigens für das Video eine temporäre Bereitstellung aufzusetzen. So oder so muss dieser Schritt zuerst geschehen, und es ist leicht zu unterschätzen, wie viel länger er dauert als die Aufnahme selbst.

Das bedeutet auch, dass ein Cursor-Projekt fast überall gehostet landen kann, anders als eine Plattform, die jeden Build an ein Deploy-Ziel bindet. Diese Flexibilität ist für Produktionsarbeit nützlich, bedeutet aber, dass es keinen einzigen, vorhersehbaren Ort gibt, auf den ein Demovideo-Tool zeigen kann. Kennen Sie die genaue URL, unter der die App live ist, bevor Sie den Hinweis schreiben, und bestätigen Sie, dass es die aktuelle Bereitstellung ist, nicht eine ältere, die noch von einem früheren Test läuft.

Es ist üblich, dass ein Cursor-Projekt während der aktiven Entwicklung mehrere Bereitstellungen gleichzeitig laufen hat: eine Staging-Umgebung, eine persönliche Testinstanz, vielleicht eine alte, die niemand abgebaut hat. Eine Aufnahme gegen die falsche davon erzeugt ein Video, das technisch eine funktionierende App zeigt, nur nicht die, die das Team zeigen wollte. Prüfen Sie vor dem Schreiben des Hinweises das Bereitstellungs-Dashboard oder den Hosting-Anbieter direkt, statt sich auf ein Lesezeichen zu verlassen, das möglicherweise auf etwas Veraltetes zeigt.

Builder-PlattformVorschau-URLWas das für ein Demovideo bedeutet
v0Automatisch bei der Bereitstellung generiertMeist sofort erreichbar
CursorStandardmäßig keineDie App muss zuerst manuell bereitgestellt werden
Ein allgemeiner IDE-AblaufHängt vollständig von der Wahl des Entwicklers abBestätigen Sie die Live-URL, bevor Sie irgendetwas aufnehmen

Welchen Ablauf sollte das Video zeigen?

Wählen Sie den einen Ablauf, der beweist, dass der Build funktioniert, nicht eine Tour durch den Code, der ihn hervorgebracht hat. Ein Betrachter, der ein Demovideo ansieht, interessiert sich nicht dafür, dass das Projekt in Cursor geschrieben statt von einem Generator zusammengesetzt wurde. Ihn interessiert, ob die laufende App die Aufgabe erfüllt, die sie beansprucht. Wählen Sie die eine Aktion, die diese Frage am direktesten beantwortet: eine erledigte Aufgabe, ein erzeugtes Ergebnis, ein Zustand, der sich so ändert, dass der Betrachter folgen kann, ohne dass die Erzählstimme die ganze Arbeit übernimmt.

Weil Cursor-Projekte eher zu produktionsähnlichem Code als zu schnellen Prototypen neigen, enthalten sie eher eine echte Authentifizierung, eine echte Datenbank und echte Geschäftslogik hinter den Bildschirmen. Das kann die App leistungsfähiger machen, aber auch wahrscheinlicher einen Ablauf, der von einem vorherigen Zustand abhängt, planen Sie den aufgenommenen Pfad also um bereits vorhandene Daten herum, statt anzunehmen, dass ein leerer Zustand irgendetwas Sinnvolles zeigt.

Das bedeutet auch, dass die Fehlermuster anders sind als bei einem generierten Prototyp. Ein Prototyp könnte eine offensichtlich leere Tabelle zeigen. Ein produktionsähnlicher Cursor-Build scheitert eher leise, indem er einen korrekt aussehenden Bildschirm mit den falschen Daten zeigt oder eine Erfolgsmeldung für eine Operation, die tatsächlich nicht abgeschlossen wurde. Testen Sie den genauen Ablauf unmittelbar vor der Aufnahme von Hand, nicht am Tag davor, damit der vom Renderdurchlauf erfasste Zustand dem entspricht, was Sie zuletzt bestätigt haben.

  • Bestätigen Sie die genaue URL und Route, von der der Ablauf starten soll.
  • Bereiten Sie Daten vor, die das Ergebnis lesbar machen, da ein echtes Backend selten vorbefüllt startet.
  • Entfernen Sie vor der Aufnahme jeden Kundennamen, jede Kundendaten oder jedes private Material aus der Umgebung.
  • Wenn ein Login den Ablauf blockiert, verwenden Sie ein Demokonto statt eines echten.

Wie gehen Sie mit einem für die Produktion gebauten Login um?

Wenn ein Login den Ablauf blockiert, kann ein Demokonto über den genehmigten Prozess bereitgestellt werden, und bei GogoScreen werden die Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht. Wird zuerst ein Storyboard geplant, bleiben die Zugangsdaten für diese Sitzung verschlüsselt und werden spätestens zwei Stunden nach ihrer letzten Verwendung gelöscht. Das zählt bei einem Cursor-Build mehr als bei einem schnell generierten Prototyp, weil eine produktionsähnliche Authentifizierung eher die echte Sache ist als ein Platzhalter, und das Team sollte genau wissen, was mit jedem für ein einzelnes Video gewährten Zugang geschieht.

Schreiben Sie einen Hinweis, der Start, Aktion und Ergebnis benennt, und prüfen Sie dann den Kandidaten, bevor Sie ihn teilen. Ein Hinweis wie „Erstellen Sie vom angemeldeten Dashboard aus einen neuen Datensatz und zeigen Sie, wie er in der Liste gespeichert wird“ gibt dem Renderdurchlauf einen konkreten Pfad. Ein vager Hinweis wie „App bei der Arbeit zeigen“ riskiert einen Renderdurchlauf, der auf dem falschen Bildschirm landet oder eine Funktion erzählt, die der Ablauf nie tatsächlich zeigt.

  1. Bestätigen Sie, dass die App unter einer erreichbaren URL bereitgestellt ist, bevor Sie versuchen, sie aufzunehmen.
  2. Wählen Sie den einen Ablauf, der beweist, dass der Build funktioniert, nicht eine Tour durch den Code, der ihn hervorgebracht hat.
  3. Schreiben Sie einen Hinweis, der Start, Aktion und Ergebnis benennt, und prüfen Sie dann den Kandidaten, bevor Sie ihn teilen.

Wo passt dieses Video für einen Solo-Entwickler hin?

Der Leitfaden zum Demovideo für Solo-Entwickler behandelt den Fall, in dem dieselbe Person den Code geschrieben, ihn bereitgestellt hat und die einzige Prüfinstanz ist, bevor der Clip irgendwo öffentlich landet, was bei außerhalb eines Teams gebauten Cursor-Projekten üblich ist. Für ein Produkt, das bereits ausgeliefert wurde und ein schrittweises Update bekommt, behandelt der Leitfaden zum Produkt-Update-Video die Ausrichtung des Clips auf das, was sich geändert hat, statt auf die ganze App. Wenn der aktuelle Prozess einen manuellen Bildschirmrekorder als Alternative einbezieht, vergleicht der Leitfaden zur Screen-Studio-Alternative für Produktdemos diesen Ansatz direkt.

Etwa einer von fünf Renderdurchläufen schlägt fehl oder muss wiederholt werden, beobachten Sie den Kandidaten also, bevor Sie ihn irgendwohin versenden. Für ein Stakeholder-Update statt ein allgemeines Publikum behandelt der Leitfaden zum Investoren-Update-Demovideo die Eingrenzung desselben Ablaufs auf eine aktuelle Änderung. Für die Wahl, wie der erste Frame der Datei aussehen sollte, bevor sie geteilt wird, ist der Leitfaden zum Poster-Frame des Demovideos relevant, unabhängig davon, welche Plattform die App erzeugt hat.

Für dieselbe Aufgabe bei anderen Cursor-Seiten siehe den Leitfaden zum Cursor-Landingpage-Video, den Leitfaden zum Cursor-Product-Hunt-Launch-Video, den Leitfaden Cursor mit einem Kunden teilen und den Leitfaden zum Cursor-Portfolio-Demo, und für die Prüfung des Builds gegen ein Briefing den Leitfaden zum Cursor-App-Prüfvideo. Für einen direkten Vergleich von Aufnahme-Tools siehe GogoScreen versus Screen Studio. Beginnen Sie auf der Startseite für den URL- und Hinweis-Ablauf, durchsuchen Sie Leitfäden für den Rest der Reihe, prüfen Sie Vergleiche mit anderen Tools und sehen Sie sich die Preise an, bevor Sie einen Renderdurchlauf einreichen.

Klarstellungen

Bevor Sie beginnen

Warum braucht eine Cursor-App zusätzliche Vorbereitung vor einem Demovideo?

Cursor ist ein Editor, keine Hosting-Plattform. Er erzeugt von sich aus keine Vorschau-URL, daher muss die App schon irgendwo erreichbar bereitgestellt sein, bevor ein Demovideo überhaupt möglich ist.

Hat jedes Cursor-Projekt einen Login?

Nicht zwingend, aber ein in einem allgemeinen Editor gebautes Projekt enthält eher eine echte Authentifizierung als ein schnell generierter Prototyp, weil der Entwickler produktionsähnlichen Code schreibt, statt eine Standardeinstellung zu übernehmen.

Worauf sollte sich das Demovideo konzentrieren?

Auf einen funktionierenden Ablauf, der zeigt, was die App tut, erreicht über eine URL, der der Betrachter vertrauen kann. Es geht darum, zu beweisen, dass der Code als laufende App funktioniert, nicht zu erklären, wie er geschrieben wurde.

Fügen Sie eine URL ein, beschreiben Sie einen Ablauf und erhalten Sie ein Demovideo Ihrer Webanwendung.

Die ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um das Video herunterzuladen.