Zuvor haben mich einige Nutzer gefragt, was mein KI-Entwicklungsprozess ist. Zufällig habe ich in den letzten Tagen mit KI eine kleine Funktion umgesetzt, die sich als Fallbeispiel gut eignet und auch als Referenz dienen kann.
Diese Funktion entstand, weil mich jemand in den GitHub-Issues ansprach (Bild 1) und fragte, ob ich der App BaoCut, die Untertitel transkribiert und übersetzt, eine Remote-Transkriptionsfunktion hinzufügen könne.
Das heißt: Ich habe zwei Computer. Einen sehr leistungsfähigen Rechner A mit NVIDIA-GPU, und einen zweiten Rechner B, den ich nur für den normalen Büroalltag nutze. Ich möchte die Rechenleistung von A verwenden, aber im Alltag nutze ich BaoCut normalerweise nur auf B. Wenn ich auf B transkribiere, soll die rechenintensive Transkriptionsarbeit von A erledigt werden.
Ich fand sofort, dass das eine ziemlich gute Anfrage ist, aber ich hatte diese Arbeit noch nie gemacht und wusste nicht, ob das überhaupt machbar ist.
Also habe ich meinen ersten Schritt nicht damit begonnen, direkt Code zu schreiben, sondern erst eine Machbarkeitsanalyse zu machen.
1. Machbarkeitsanalyse
Ohne Machbarkeitsanalyse blind loszulegen, ist wirklich teuer. Das habe ich schon viel zu oft gemacht – am Ende war es häufig umsonst. Selbst wenn man eine Machbarkeitsanalyse macht, kann man manchmal trotzdem falsche Annahmen treffen. Beispielsweise habe ich vor ein paar Tagen noch ein lokales Textmodell gebaut, um das Splitten und Ausrichten zu unterstützen. Bei der Machbarkeitsanalyse schien alles in Ordnung, aber nach der Umsetzung habe ich in der Praxis gemerkt, dass die Ergebnisse wirklich schlecht waren. Am Ende habe ich es wieder verworfen und dadurch mehrere Tage Zeit verloren und dabei auch viele Tokens verbraten – zum Glück waren es nur Tokens.
Eine Machbarkeitsanalyse hat normalerweise zwei Ebenen:
Eine ist aus Produkt-Sicht: Hat die Funktion für Nutzer einen echten Wert? Passt sie zur Ausrichtung der App?
Die andere ist aus technischer Sicht: Ist die Funktion technisch machbar? Sind die Kosten kontrollierbar?
Hier habe ich aus Produktsicht festgestellt, dass die Funktion für Nutzer wertvoll ist und zur Produktpositionierung passt. Deshalb habe ich mich nur auf die technische Machbarkeitsanalyse konzentriert.
Ich habe dann in Claude Code die ursprüngliche Anforderung eingegeben und es diese mit dem aktuellen Projektstatus eine Machbarkeitsanalyse machen lassen (Bild 2). Nach der Analyse gab es eine Entscheidung: machbar. Außerdem schlug es mehrere Ansätze vor (Bild 3).
Diese Ansätze erfordern eventuell etwas technischen Hintergrund, um besser zu verstehen. Nach dem Lesen hatte ich schnell meine eigene Einschätzung:
Ansatz 0 und Ansatz C benötigen zwar keine Code-Änderungen, sind aber für Nutzer zu unfreundlich – die Nutzer müssten selbst einen ASR-Server aufbauen.
Ansatz A sieht gut aus: Es muss nur die App installiert werden, dann kann man den eigenen Transkriptionsdienst starten.
Ansatz B ist für Windows nicht geeignet.
Also beschloss ich, mit Ansatz A weiterzumachen. Außerdem ist Ansatz 0 zwar nicht wirklich zuverlässig, aber der dort enthaltene http-Transkriptions-API ist trotzdem eine gute Zusatzfunktion, die man gleich mit einbauen könnte.
2. Design-Dokument schreiben
Nachdem klar war, dass es machbar ist, und nachdem ich mich auf einen groben technischen Plan festgelegt hatte, bin ich auch nicht sofort ans Programmieren gegangen, sondern habe erst ein Design-Dokument erstellt.
Dieses Design-Dokument ist eher eine Mischung aus Produktdesign-Dokument und technischer Design-Skizze. Es beschreibt im Wesentlichen klar: die Anforderungen, den Architekturentwurf und die UI-Design-Dokumentation.
Ziel ist es, dass die KI hilft, die Technologien, die man bei der Umsetzung braucht, sowie den aktuellen Projektstatus sauber zu strukturieren und festzuhalten. So hat man später bei der Implementierung eine gute Referenz, und es kann auch bei der Wartung in Zukunft als Grundlage dienen. Am wichtigsten ist: Menschen können einmal bestätigen, ob die Richtung stimmt (siehe Bild 4).
Natürlich gebe ich zu: Hier habe ich etwas faul gemacht. Ich ließ es einfach das Dokument fertig schreiben und dann direkt starten. Hauptsächlich, weil ich dachte, dass die vorher vorgeschlagenen Ansätze nicht wirklich große Probleme haben, und ich Fable ziemlich vertraue – wenn möglich, schaut man natürlich besser nochmal genauer nach.
3. Prototyping
Warum ich vor dem Schreiben des Codes erst einen Prototyp erstellt habe: Damit kann ich die Anforderungen mit geringem Aufwand validieren und schnell das UI-Design sowie die Interaktion klar definieren. Ich habe bereits die baoyu-design skill installiert (github.com/jimliu/baoyu-design), daher reicht es, „Prototyping“ zu sagen, und es wird automatisch ausgelöst.
Meine App hat eine eigene Prototyping-Seite. Jedes Mal, wenn ich eine Funktion hinzufüge oder ändere, aktualisiere ich zuerst diese Prototyping-Seite.
Mit dem Design-Dokument davor lief das Prototyping insgesamt ziemlich reibungslos. Die erste Version (Bild 5) hatte bereits gute Ergebnisse: In der Einstellungsseite wurde eine neue Option hinzugefügt, um den Dienst zu aktivieren und Knoten zu finden.
Achtung: Der Prototyp, den ich hier erstellt habe, ist eigentlich ein hochpräziser Prototyp, der Prototyping und UI-Design kombiniert – also der Prototyp ist zugleich das UI-Design. Das ist auch ein großes Merkmal von Claude Design.
Nachdem der Prototyp fertig war, musste ich ihn noch anpassen. Dabei braucht der Mensch Feedback auf Basis des Prototyping-Ergebnisses, damit der Agent entsprechend nachbessern kann. In meinem Fall habe ich das sogar viele Male iteriert (siehe Bild 6).
Zuerst habe ich das Layout auf Tabs umgestellt, damit „Dienst aktivieren“ und „auf andere Knoten zugreifen“ getrennt sind – in meinen Augen sind das zwei unterschiedliche Szenarien. Außerdem habe ich den Status des Dienstes über Icons angezeigt, sodass man anhand der Symbole klar erkennen kann, ob der Dienst gestartet oder gestoppt ist (siehe Bild 7).
Dann habe ich festgestellt, dass es im Einstellungsmenü nicht besonders praktisch ist, den Dienststatus zu beobachten. Also habe ich es wieder auf das Haupt-UI verschoben. Schließlich dachte ich, jetzt passt es ungefähr (Bild 8, Bild 9).
4. Implementierung
Wenn man bereits ein Design-Dokument hat und außerdem ein Prototyp (UI-Design), dann ist das für den Agent jetzt eine ziemlich einfache Aufgabe: AI schreibt den Code.
In der Regel schicke ich dann zusammen mit /goal die Dokumente an Claude Code (Fable 5) zur Umsetzung. Es setzt die Milestones aus der Dokumentplanung Schritt für Schritt um und macht außerdem selbst Screenshots, um die Ergebnisse zu verifizieren (Bild 10, Bild 11).
5. Test & Validierung
Auch wenn der Agent uns beim Validieren hilft, heißt das nicht, dass man die Ergebnisse komplett blind vertrauen kann. Als Nächstes muss man die Sache trotzdem ein paar Mal manuell durchlaufen lassen, die gefundenen Probleme dem Agent melden und ihn entsprechend anpassen lassen (Bild 12).
Nach ein paar Runden Feinschliff ist es dann ungefähr einsatzbereit.
Siehe das finale Ergebnis (Bild 13, Bild 14).
Wenn du fragst, ob ich den Code reviewed habe:
Nein. Ich habe mich als QA betrachtet und nur einen Black-Box-Test gemacht. Ich vertraue weiterhin auf die Fähigkeiten von Fable.
Diese Funktion entstand, weil mich jemand in den GitHub-Issues ansprach (Bild 1) und fragte, ob ich der App BaoCut, die Untertitel transkribiert und übersetzt, eine Remote-Transkriptionsfunktion hinzufügen könne.
Das heißt: Ich habe zwei Computer. Einen sehr leistungsfähigen Rechner A mit NVIDIA-GPU, und einen zweiten Rechner B, den ich nur für den normalen Büroalltag nutze. Ich möchte die Rechenleistung von A verwenden, aber im Alltag nutze ich BaoCut normalerweise nur auf B. Wenn ich auf B transkribiere, soll die rechenintensive Transkriptionsarbeit von A erledigt werden.
Ich fand sofort, dass das eine ziemlich gute Anfrage ist, aber ich hatte diese Arbeit noch nie gemacht und wusste nicht, ob das überhaupt machbar ist.
Also habe ich meinen ersten Schritt nicht damit begonnen, direkt Code zu schreiben, sondern erst eine Machbarkeitsanalyse zu machen.
1. Machbarkeitsanalyse
Ohne Machbarkeitsanalyse blind loszulegen, ist wirklich teuer. Das habe ich schon viel zu oft gemacht – am Ende war es häufig umsonst. Selbst wenn man eine Machbarkeitsanalyse macht, kann man manchmal trotzdem falsche Annahmen treffen. Beispielsweise habe ich vor ein paar Tagen noch ein lokales Textmodell gebaut, um das Splitten und Ausrichten zu unterstützen. Bei der Machbarkeitsanalyse schien alles in Ordnung, aber nach der Umsetzung habe ich in der Praxis gemerkt, dass die Ergebnisse wirklich schlecht waren. Am Ende habe ich es wieder verworfen und dadurch mehrere Tage Zeit verloren und dabei auch viele Tokens verbraten – zum Glück waren es nur Tokens.
Eine Machbarkeitsanalyse hat normalerweise zwei Ebenen:
Eine ist aus Produkt-Sicht: Hat die Funktion für Nutzer einen echten Wert? Passt sie zur Ausrichtung der App?
Die andere ist aus technischer Sicht: Ist die Funktion technisch machbar? Sind die Kosten kontrollierbar?
Hier habe ich aus Produktsicht festgestellt, dass die Funktion für Nutzer wertvoll ist und zur Produktpositionierung passt. Deshalb habe ich mich nur auf die technische Machbarkeitsanalyse konzentriert.
Ich habe dann in Claude Code die ursprüngliche Anforderung eingegeben und es diese mit dem aktuellen Projektstatus eine Machbarkeitsanalyse machen lassen (Bild 2). Nach der Analyse gab es eine Entscheidung: machbar. Außerdem schlug es mehrere Ansätze vor (Bild 3).
Diese Ansätze erfordern eventuell etwas technischen Hintergrund, um besser zu verstehen. Nach dem Lesen hatte ich schnell meine eigene Einschätzung:
Ansatz 0 und Ansatz C benötigen zwar keine Code-Änderungen, sind aber für Nutzer zu unfreundlich – die Nutzer müssten selbst einen ASR-Server aufbauen.
Ansatz A sieht gut aus: Es muss nur die App installiert werden, dann kann man den eigenen Transkriptionsdienst starten.
Ansatz B ist für Windows nicht geeignet.
Also beschloss ich, mit Ansatz A weiterzumachen. Außerdem ist Ansatz 0 zwar nicht wirklich zuverlässig, aber der dort enthaltene http-Transkriptions-API ist trotzdem eine gute Zusatzfunktion, die man gleich mit einbauen könnte.
2. Design-Dokument schreiben
Nachdem klar war, dass es machbar ist, und nachdem ich mich auf einen groben technischen Plan festgelegt hatte, bin ich auch nicht sofort ans Programmieren gegangen, sondern habe erst ein Design-Dokument erstellt.
Dieses Design-Dokument ist eher eine Mischung aus Produktdesign-Dokument und technischer Design-Skizze. Es beschreibt im Wesentlichen klar: die Anforderungen, den Architekturentwurf und die UI-Design-Dokumentation.
Ziel ist es, dass die KI hilft, die Technologien, die man bei der Umsetzung braucht, sowie den aktuellen Projektstatus sauber zu strukturieren und festzuhalten. So hat man später bei der Implementierung eine gute Referenz, und es kann auch bei der Wartung in Zukunft als Grundlage dienen. Am wichtigsten ist: Menschen können einmal bestätigen, ob die Richtung stimmt (siehe Bild 4).
Natürlich gebe ich zu: Hier habe ich etwas faul gemacht. Ich ließ es einfach das Dokument fertig schreiben und dann direkt starten. Hauptsächlich, weil ich dachte, dass die vorher vorgeschlagenen Ansätze nicht wirklich große Probleme haben, und ich Fable ziemlich vertraue – wenn möglich, schaut man natürlich besser nochmal genauer nach.
3. Prototyping
Warum ich vor dem Schreiben des Codes erst einen Prototyp erstellt habe: Damit kann ich die Anforderungen mit geringem Aufwand validieren und schnell das UI-Design sowie die Interaktion klar definieren. Ich habe bereits die baoyu-design skill installiert (github.com/jimliu/baoyu-design), daher reicht es, „Prototyping“ zu sagen, und es wird automatisch ausgelöst.
Meine App hat eine eigene Prototyping-Seite. Jedes Mal, wenn ich eine Funktion hinzufüge oder ändere, aktualisiere ich zuerst diese Prototyping-Seite.
Mit dem Design-Dokument davor lief das Prototyping insgesamt ziemlich reibungslos. Die erste Version (Bild 5) hatte bereits gute Ergebnisse: In der Einstellungsseite wurde eine neue Option hinzugefügt, um den Dienst zu aktivieren und Knoten zu finden.
Achtung: Der Prototyp, den ich hier erstellt habe, ist eigentlich ein hochpräziser Prototyp, der Prototyping und UI-Design kombiniert – also der Prototyp ist zugleich das UI-Design. Das ist auch ein großes Merkmal von Claude Design.
Nachdem der Prototyp fertig war, musste ich ihn noch anpassen. Dabei braucht der Mensch Feedback auf Basis des Prototyping-Ergebnisses, damit der Agent entsprechend nachbessern kann. In meinem Fall habe ich das sogar viele Male iteriert (siehe Bild 6).
Zuerst habe ich das Layout auf Tabs umgestellt, damit „Dienst aktivieren“ und „auf andere Knoten zugreifen“ getrennt sind – in meinen Augen sind das zwei unterschiedliche Szenarien. Außerdem habe ich den Status des Dienstes über Icons angezeigt, sodass man anhand der Symbole klar erkennen kann, ob der Dienst gestartet oder gestoppt ist (siehe Bild 7).
Dann habe ich festgestellt, dass es im Einstellungsmenü nicht besonders praktisch ist, den Dienststatus zu beobachten. Also habe ich es wieder auf das Haupt-UI verschoben. Schließlich dachte ich, jetzt passt es ungefähr (Bild 8, Bild 9).
4. Implementierung
Wenn man bereits ein Design-Dokument hat und außerdem ein Prototyp (UI-Design), dann ist das für den Agent jetzt eine ziemlich einfache Aufgabe: AI schreibt den Code.
In der Regel schicke ich dann zusammen mit /goal die Dokumente an Claude Code (Fable 5) zur Umsetzung. Es setzt die Milestones aus der Dokumentplanung Schritt für Schritt um und macht außerdem selbst Screenshots, um die Ergebnisse zu verifizieren (Bild 10, Bild 11).
5. Test & Validierung
Auch wenn der Agent uns beim Validieren hilft, heißt das nicht, dass man die Ergebnisse komplett blind vertrauen kann. Als Nächstes muss man die Sache trotzdem ein paar Mal manuell durchlaufen lassen, die gefundenen Probleme dem Agent melden und ihn entsprechend anpassen lassen (Bild 12).
Nach ein paar Runden Feinschliff ist es dann ungefähr einsatzbereit.
Siehe das finale Ergebnis (Bild 13, Bild 14).
Wenn du fragst, ob ich den Code reviewed habe:
Nein. Ich habe mich als QA betrachtet und nur einen Black-Box-Test gemacht. Ich vertraue weiterhin auf die Fähigkeiten von Fable.