Beispielanleitung
Suchst du Code, den du anpassen kannst, statt eines Screenshots, den du nur betrachten kannst? Bestimme zuerst die Aufgabe, das Modell und die Antwortdaten, die dein Projekt benötigt. Diese Anleitung trennt die Suche nach Repositories von drei beispielhaften Workflows, damit du ein Beispiel bewerten kannst, ohne davon auszugehen, dass es unverändert funktioniert.
Ein Repository kann in den Suchergebnissen relevant wirken und trotzdem die falsche Frage beantworten. Prüfe, ob das Beispiel zu deinem Anwendungsfall passt, bevor du seine Anfrage übernimmst.
Du musst eine vom Nutzer eingegebene Beschreibung in ein Bild umwandeln, aber ein Repository-Beispiel kann Eingabe, Modell oder Verarbeitung der Ausgabe fest vorgeben. Eine erfolgreiche Beispielanfrage ist noch keine Funktion für Nutzer.
Verfolge nach, wo der Prompt in die Anfrage gelangt, wo die Antwort ausgelesen wird und wo Fehler angezeigt werden. Eine umfassendere Anleitung für den Einstieg findest du im verlinkten Nutzungsleitfaden.
So verwendest du runware AIDu möchtest aus demselben Briefing mehrere visuelle Richtungen entwickeln. Ein Beispiel zeigt möglicherweise nur ein einzelnes Ergebnis, ohne zu erklären, ob die Modellwahl zu deinem Motiv oder dem gewünschten Stil passt.
Notiere das im Beispiel genannte Modell und vergleiche Ergebnisse anhand eines einheitlichen Briefings, bevor du seine Einstellungen übernimmst.
runware-ModelleDu hast ein Codebeispiel gefunden, kannst aber nicht erkennen, welchen Dienst es aufruft, welche Zugangsdaten es erwartet oder ob die Struktur seiner Antwort noch mit der Dokumentation des Dienstes übereinstimmt.
Identifiziere zuerst den Dienst und den dokumentierten Ablauf der Anfrage. Teste das Codebeispiel dann in einer kontrollierten Umgebung, statt Repository-Code als Garantie für die Funktion des Produkts zu betrachten.
Was ist runware?Nutze diese drei Wege als Lesereihenfolge: Kläre zuerst die grundlegende Anfrage, prüfe dann die Modellwahl und sieh schließlich nach, was der Dienst und das Beispiel tatsächlich abdecken.
Die folgenden Ergebnisse sind beispielhafte Akzeptanzprüfungen, keine aufgezeichneten Antworten oder Aussagen über ein bestimmtes GitHub-Repository. Die tatsächlich beobachtete Ausgabe hängt davon ab, welches Beispiel Sie testen.
Eingabe: ein kurzes Briefing für ein Produktbild, das ein Nutzer bereitstellt. Erwartetes Anwendungsergebnis: das zurückgegebene Bild anzeigen und bei einer fehlgeschlagenen Anfrage einen sichtbaren Fehlerstatus beibehalten. Ein nützliches Beispiel zeigt sowohl den Aufbau der Anfrage als auch die Verarbeitung der Antwort; ein in einer README angezeigtes Bild beweist nicht, dass beides in Ihrer Benutzeroberfläche funktioniert. Legen Sie sich nicht auf ein vermutetes Antwortfeld fest, bevor Sie die aktuelle Dokumentation geprüft und eine tatsächliche Antwort getestet haben.
Eingabe: ein Briefing, das für mehrere visuelle Tests wiederverwendet wird. Erwartetes Evaluierungsergebnis: eine kurze Vergleichsaufzeichnung mit dem Briefing, dem verwendeten Modell und jedem beobachteten Ergebnis. So kann ein Team erklären, warum es sich für eine Richtung entschieden hat, ohne das Beispielbild eines Repositorys mit einem reproduzierbaren Benchmark zu verwechseln. Wenn das Beispiel Einstellungen bietet, ändern Sie jeweils nur eine; andernfalls beschränken Sie den Vergleich auf Einstellungen, die Sie überprüfen können.
Eingabe: eine Testanfrage aus einer Nicht-Produktionsumgebung. Erwartetes technisches Ergebnis: eine Aufzeichnung der Antwortfelder, die Ihr Code tatsächlich erhält, sowie des Verhaltens bei ungültigen Anfragen und fehlender Ausgabe. Das ist weniger fotogen als eine Galerie, aber genau hier wird aus einem ansprechenden Codeschnipsel ein Kandidat für eine zuverlässige Integration. Protokollieren Sie keine geheimen Zugangsdaten und gehen Sie nicht davon aus, dass ein Beispiel Wiederholungsversuche, Speicherung oder Zugriffskontrolle abdeckt.
Betrachten Sie GitHub-Beispiele als Code, den Sie prüfen müssen, nicht als Erlaubnis, sämtliche darin enthaltenen Abhängigkeiten, Bilder oder anderen Ressourcen wiederzuverwenden. Lesen Sie die Lizenz jedes Repositorys, prüfen Sie die Abhängigkeiten und vergewissern Sie sich, dass die Anweisungen mit der aktuellen Dokumentation des Dienstes übereinstimmen. Speichern Sie Zugangsdaten nicht in Dateien, die Sie committen, verwenden Sie in Test-Prompts keine vertraulichen Nutzerdaten und prüfen Sie die Bedingungen für Ihre geplante Nutzung. Wenn bei einem Beispiel die Lizenz oder der Wartungskontext unklar ist, fragen Sie nach oder wählen Sie einen besser dokumentierten Ausgangspunkt.
Bilderzeugung erkundenSuchen Sie auf GitHub nach dem Namen des Dienstes und der Aufgabe, die Sie ausführen möchten, etwa Bilderzeugung oder Verarbeitung von Antworten. Prüfen Sie, wer das Repository betreut, wann es zuletzt aktualisiert wurde und welche Lizenz gilt, bevor Sie ein Suchergebnis als verlässlichen Ausgangspunkt verwenden.
Gehen Sie nicht davon aus. Ein Beispiel kann bestimmte Zugangsdaten, Modellkennungen, Bibliotheksversionen oder Antwortfelder voraussetzen. Vergleichen Sie es daher mit der aktuellen Dokumentation und führen Sie einen kleinen Test durch, bevor Sie es integrieren.
Achten Sie auf die Eingaben für die Anfrage, die Modellauswahl und Code, der sowohl Ergebnisse als auch Fehler verarbeitet. Ein Beispielbild allein zeigt nicht, wie die Anwendung die Ausgabe empfängt oder anzeigt.
Prüfen Sie zuerst die Lizenz und etwaige Hinweise zu einzelnen Ressourcen; für Code und Bilder können unterschiedliche Nutzungsrechte gelten. Wenn die Bedingungen unklar sind, verwenden Sie eigene Ressourcen, statt anzunehmen, dass das Repository Wiederverwendungsrechte einräumt.
Betrachten Sie die Ausgabe als unbekannt, bis Sie das Beispiel in einer Testumgebung ausgeführt und eine tatsächliche Antwort geprüft haben. Halten Sie fest, welche Felder Sie vorfinden, und prüfen Sie, wie sich das Beispiel verhält, wenn eine Anfrage fehlschlägt.