Zum Inhalt springen
Leitfaden6 Min. Lesezeit

Prüfvideo für eine Cursor-App

Beweisen Sie, dass die Anfrage erledigt wurde, ohne jemanden den Code ausführen zu lassen.

Geben Sie einem Prüfer einen Cursor-Build mit einem Ablauf, der die angeforderte Änderung belegt, statt ihn den Code selbst ausführen zu lassen.

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

Eine Übergabe zur Prüfung hat eine engere Aufgabe als eine Demo, ein Pitch oder ein Portfoliostück. Jemand hat um eine bestimmte Sache gebeten, sei es ein Bugfix, eine neue Funktion oder eine Änderung an einem bestehenden Ablauf, und die Person, die die Arbeit prüft, will eines wissen: ob es passiert ist. Sie bewertet nicht das gesamte Produkt und will in der Regel keine Tour. Ein für diesen Moment gebauter Rundgang sollte die ursprüngliche Anfrage so direkt wie ein Ja oder Nein beantworten, gestützt auf Aufnahmen, die die Antwort zeigen, statt sie zu beschreiben.

Cursor ist ein Code-Editor, und der Code, den er zu schreiben hilft, wird dadurch nicht von selbst erreichbar. Ein in Cursor erstellter Build läuft während der Arbeit auf einem lokalen Entwicklungsserver und wird für einen Prüfer erst sichtbar, sobald er irgendwo bereitgestellt ist, sei es eine gemeinsame Staging-Umgebung, ein persönlicher Server oder ein Vorschau-Link von dem Hosting, das das Projekt verwendet. Bestätigen Sie vor der Aufnahme eines Prüfvideos, welche davon tatsächlich live ist, denn ein Prüfer, der das Video mit einem defekten oder veralteten Deployment vergleicht, vertraut weder dem Video noch dem Build.

Das zählt bei einem Prüfvideo mehr als bei fast jeder anderen Art von Demovideo, weil der ganze Sinn der Aufnahme darin liegt, dass sie überprüft werden kann. Ein an einen Fremden gerichtetes Demovideo wird selten mit einer Live-Route verglichen, die der Betrachter selbst öffnet. Ein Prüfvideo wird oft genau so verglichen, manchmal Minuten nach dem Versand, und jede Lücke zwischen dem, was das Video zeigt, und dem, was der Prüfer selbst findet, wird zur eigentlichen Geschichte der Prüfung statt der Änderung selbst.

Was muss der Prüfer tatsächlich sehen?

Gehen Sie zur ursprünglichen Anfrage zurück und formulieren Sie sie als einen einzigen Satz, der einen Start, eine Aktion und ein Ergebnis beschreibt. Wenn die Anfrage war, einen defekten Absende-Button zu reparieren, lautet der Ablauf: das Formular öffnen, ausfüllen, absenden, den Erfolg sehen. Wenn die Anfrage war, einem Listen einen Filter hinzuzufügen, lautet der Ablauf: die Liste öffnen, den Filter anwenden, die Änderung der Liste sehen. Alles, wonach der Prüfer nicht gefragt hat, so fertig es auch sein mag, gehört nicht in diese Aufnahme. Ein Rundgang, der zu benachbarten Funktionen abschweift, zwingt den Prüfer zu zusätzlicher Arbeit, um den Teil zu finden, um den er tatsächlich gebeten hat.

Art der AnfrageDer zu zeigende AblaufWas wegzulassen ist
BugfixDie genauen Schritte, die früher fehlschlugen, endend im ErfolgNicht betroffene Bildschirme, die nie defekt waren
Neue FunktionDie Funktion, verwendet von einem realistischen Ausgangspunkt ausEine Tour durch die gesamte umgebende Seite
Visuelle Änderung oder TextänderungEin klares Vorher und Nachher an derselben StelleAndere ausstehende Änderungen, die nicht Teil dieser Anfrage sind

Wie bereiten Sie den Build für den Rundgang vor?

Öffnen Sie zuerst selbst die bereitgestellte Route und durchlaufen Sie die genauen Schritte, die dem Prüfer wichtig sind. Bestätigen Sie, dass der Fix oder die Funktion in der Version vorhanden ist, die tatsächlich live ist, nicht nur in einem lokalen Branch, der noch nicht bereitgestellt wurde. Das klingt offensichtlich und wird trotzdem ständig übersprungen, besonders unter Termindruck, und es ist der mit Abstand häufigste Grund, warum eine Prüfaufnahme die Person blamiert, die sie erstellt hat.

  • Bestätigen Sie, dass der bereitgestellte Build dem Code entspricht, von dem Sie annehmen, dass er zusammengeführt wurde.
  • Entfernen Sie alle Testdaten aus früherer Fehlersuche, die den Prüfer verwirren könnten.
  • Richten Sie ein Demokonto ein, wenn der Ablauf hinter einem Login liegt, statt einen echten Login zu teilen.
  • Timen Sie die Interaktion einmal vor der Aufnahme, damit der Hinweis dem tatsächlichen Geschehen entspricht.

Wenn die Anwendung eine Authentifizierung braucht, damit der Prüfer den relevanten Bildschirm sieht, fordern Sie ein Demokonto über den normalen Prozess an, statt einen persönlichen Login zu versenden. Bei GogoScreen werden alle für einen Renderdurchlauf bereitgestellten Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht, was von Bedeutung ist, wenn der betreffende Build einem Kunden gehört und nicht Ihnen. 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. Eine verwandte, aber andere Situation ist die Prüfung eines Pull Requests selbst statt einer laufenden Anwendung, die der Leitfaden zum KI-Agent-PR-Demovideo separat behandelt.

Es hilft auch, den Build zu einem Zeitpunkt nahe an dem zu prüfen, an dem der Prüfer ihn tatsächlich ansehen wird. Ein Deployment, das vor einer Stunde korrekt aussah, kann abdriften, wenn in der Zwischenzeit eine weitere Änderung auf derselben Umgebung landet, besonders auf einem gemeinsamen Staging-Server, auf den mehrere Personen pushen. Die Aufnahme unmittelbar vor dem Versand zu machen, statt eine ältere Aufnahme derselben Funktion wiederzuverwenden, hält dieses Risiko gering.

Wie sollte der Ablaufhinweis geschrieben werden?

  1. Formulieren Sie die Anfrage als einen Ablauf, den der Prüfer von Anfang bis Ende beobachten kann.
  2. Erreichen Sie den genauen Zustand, der sie beantwortet, nicht einen ähnlich aussehenden benachbarten Bildschirm.
  3. Schneiden Sie alles heraus, wonach die Anfrage nicht gefragt hat, selbst wenn es ebenfalls fertig ist.

Schreiben Sie den Hinweis mit denselben Worten, die die ursprüngliche Anfrage verwendet hat. Wenn im Ticket „der Checkout-Button“ stand, sollte der Hinweis Checkout-Button sagen, nicht Zahlungsaktion. Ein Prüfer, der die Aufnahme mit seiner eigenen Erinnerung an die Anfrage vergleicht, bemerkt Wortabweichungen schneller als die meisten anderen Probleme, und eine Abweichung liest sich als Beleg dafür, dass die Anfrage missverstanden wurde, selbst wenn das nicht der Fall war.

Wo steht das im Verhältnis zu einer Demo oder einem Launch-Video?

Ein Prüfvideo und ein Demovideo sehen sich oberflächlich ähnlich, und es hilft, die Zwecke getrennt zu halten. Ein Produktrundgang für SaaS ist für einen möglichen Käufer gebaut, der entscheidet, ob sich das Produkt zu testen lohnt, während ein Prüfvideo für jemanden gebaut ist, der das Produkt bereits kennt und eine bestimmte Behauptung überprüft. Wenn der Build später, sobald die Arbeit akzeptiert ist, ein richtiges Einführungsvideo braucht, ist ein Windsurf-Demovideo oder eine Behandlung im Stil eines Windsurf-Landingpage-Videos der bessere nächste Schritt, da beide für einen erstmaligen Betrachter geschrieben sind, nicht für einen Prüfer mit Kontext.

Manche Anfragen kommen von einem öffentlichen Publikum statt von einem privaten Prüfer, etwa ein Show-HN-Demovideo, das auf Kommentare in einem Launch-Thread antwortet. Dieser Fall ist näher an einem Prüfvideo als an einer Demo, da er ebenfalls eine bestimmte Frage beantwortet, die jemand gestellt hat, nur öffentlich statt privat. Dieselbe Disziplin, die Frage zu wiederholen und die Antwort zu zeigen, gilt so oder so. Ein ähnlicher Prüfbedarf zeigt sich auch bei anderen KI-Builder-Plattformen, darunter der Leitfaden zum v0-App-Demovideo und der Leitfaden zum Lovable-App-Demovideo, beide geschrieben für den Moment direkt nachdem ein generierter Build gegen die ursprüngliche Anfrage geprüft werden muss.

Was sollten Sie vor dem Versand prüfen?

Sehen Sie sich die Aufnahme gegen den ursprünglichen Anfragetext an, Zeile für Zeile, wenn die Anfrage mehr als einen Teil hatte. Wenn die Prüfung an jemanden geht, der mehrere Builder vergleicht, deckt ein Eintrag im Stil eines Windsurf-Portfolio-Demos oder eines Windsurf-Product-Hunt-Launch-Videos diesen breiteren Vergleich ab, aber ein Prüfvideo selbst sollte eng gefasst bleiben. Wenn der Prüfer die Aufnahme weiter teilen muss, erklärt eine Übergabe im Stil von Windsurf mit einem Kunden teilen, wie man sie für jemanden vorbereitet, der gar keinen Vorschau-Link anklicken wird.

Lassen Sie in Ihrem Zeitplan Raum für eine Wiederholung, denn etwa einer von fünf Renderdurchläufen braucht eine. Jedes neue Konto erhält einmalig 60 Sekunden Video mit Wasserzeichen, was in der Regel eine einzelne Anfrage bequem abdeckt, und danach verfällt Zeit aus Aufladungen nie, und Zeit wird nur verbraucht, wenn ein Renderdurchlauf gelingt. Vergleichen Sie Aufnahmeoptionen mit Loom, wenn der Prüfer stattdessen eine Live-Bildschirmfreigabe erwartet, prüfen Sie die Preise für die Pläne, durchsuchen Sie weitere Leitfäden und Vergleiche, oder kehren Sie zur GogoScreen-Startseite zurück, um einen neuen Renderdurchlauf für die nächste Anfrage zu starten.

Klarstellungen

Bevor Sie beginnen

Was sollte ein Cursor-App-Prüfvideo belegen?

Es sollte belegen, dass genau das, worum der Prüfer gebeten hat, in der laufenden Anwendung tatsächlich passiert. Das bedeutet, bei der Anfrage anzusetzen, nicht bei der Codebasis, und den genauen Zustand zu zeigen, der sie beantwortet.

Sollte der Rundgang erklären, wie der Code funktioniert?

Nein. Ein Prüfer, der einen Build freigibt, will in der Regel wissen, dass das Ergebnis korrekt ist, nicht wie die Umsetzung dorthin gelangt ist. Heben Sie die Erklärung der Umsetzung für eine Pull-Request-Beschreibung oder ein separates Gespräch auf.

Was, wenn der Prüfer keinen Zugriff auf einen loginpflichtigen Build hat?

Für den Renderdurchlauf bei GogoScreen kann ein Demokonto vorbereitet werden, wobei Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht werden. 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 macht es überflüssig, dem Prüfer einen echten Login zu geben.

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.