Sprachgesteuerte KI-Bilder und Inline-Diktiergerät in TAMSIV

Die v1.3.2 ist die ambitionierteste Veröffentlichung, die ich für TAMSIV herausgebracht habe. Zwei wichtige Funktionen, eine heikle technische Migration und ein Philosophiewechsel im Verhältnis zwischen Sprache und visuellen Inhalten.

Oberflächlich betrachtet ist es einfach: Du sprichst, die KI generiert ein Bild, das an deine Aufgabe angehängt wird. Darunter verbirgt sich eine Pipeline, die Speech-to-Text, kontextuelle Analyse durch LLM, Bildgenerierung, Supabase Storage Upload und Anzeige mit signierter URL miteinander verbindet. Dazu kommt ein Diktiergerät, das von einem Vollbild-Overlay zu einer inline integrierten Komponente am unteren Bildschirmrand wechselt. Und als Bonus eine Gesture-Handler-Migration, die mich dazu zwang, jede Datei des Projekts nach bösartigen Imports zu durchsuchen.

Kernpunkte

• KI-Bilder werden direkt aus der Sprache generiert: Das LLM analysiert den Kontext der Aufgabe, um einen optimierten Prompt zu erstellen, ohne Benutzereingriff.
• Das Inline-Diktiergerät ersetzt das Vollbild-Overlay, wobei die Transkription vor dem Ende des TTS angezeigt wird, um ein Gefühl sofortiger Reaktionsfähigkeit zu vermitteln.
• Die Gesture-Handler-Migration behob einen unsichtbaren Fehler unter iOS, der aber unter Android im Release-Modus blockierend war.
• Die Option "TTS überspringen" bietet einen doppelten Vorteil: halbierte Reaktionszeit und reduzierte API-Kosten für Benutzer, die keine Sprachantwort benötigen.

Wie funktioniert die KI-Bildgenerierung direkt aus der Sprache?

Die Idee entstand aus einer einfachen Beobachtung: Eine Aufgabe mit einem Bild ist sofort ansprechender als eine Aufgabe nur mit Text. Die kognitive Psychologie bestätigt dies: Laut einer Studie von John Medina (Brain Rules) verarbeitet das Gehirn Bilder 60.000 Mal schneller als Text. Wenn du jeder Aufgabe ein relevantes Bild zuordnen kannst, erhöhst du die Merkfähigkeit und Motivation.

Das Problem ist, dass niemand manuell für jede Aufgabe ein Bild suchen wird. Es musste automatisch, kontextbezogen und sprachgesteuert sein. Hier ist die vollständige Pipeline:

1. Der Benutzer spricht: "Erstelle eine Aufgabe, um die Kundenpräsentation mit einem Bild vorzubereiten".
2. Natives STT transkribiert die Sprache in Text, wie in meinem Artikel über natives STT vs. Deepgram beschrieben.
3. Das LLM analysiert den Kontext: Aufgabentitel, Beschreibung, vorhandene Tags.
4. Das LLM generiert einen optimierten Prompt für das Bildmodell, auf Englisch, mit Stil- und Kompositionsdetails.
5. Der Bildanbieter (Runware oder Gemini) generiert das Bild.
6. Upload zu Supabase Storage, Erstellung eines Eintrags in privat.task_attachments mit dem Typ ai_generated.
7. Sofortige Anzeige über signierte URL.

Ich hatte die Wahl zwischen den Bildanbietern in dem Artikel zur KI-Bildgenerierung detailliert beschrieben. Die v1.3.2 hat diese Pipeline direkt in den Sprachfluss integriert, wodurch sie ohne Reibungsverluste zugänglich ist.

Warum schreibt das LLM den Prompt anstelle des Benutzers?

Einen Benutzer aufzufordern, einen guten Bild-Prompt zu schreiben, ist wie jemanden aufzufordern, eine Sprache fließend zu sprechen, die er nie gelernt hat. Bildgenerierungsmodelle reagieren empfindlich auf die Formulierung: Die Reihenfolge der Wörter, Stilmodifikatoren, technische Begriffe wie "cinematic lighting" oder "shallow depth of field" machen einen massiven Unterschied im Ergebnis.

Die Lösung ist elegant: Das konversationelle LLM, das den Kontext der Diskussion bereits versteht, wird zu einem Übersetzer zwischen der menschlichen Absicht und der technischen Sprache des Bildmodells. Der Benutzer sagt "ein Bild einer professionellen Präsentation", das LLM übersetzt in "professional business presentation slides on a modern desk, clean corporate environment, soft directional lighting, photorealistic, 4K detail".

Das ist das gleiche Prinzip, das ich in der gesamten TAMSIV-Architektur anwende: Die KI muss die kognitive Arbeit leisten, die der Benutzer nicht leisten sollte. Ich habe darüber in dem Artikel zur Sprachpersonalisierung gesprochen: Intelligenz bedeutet nicht nur, Wörter zu verstehen. Es bedeutet, die Absicht hinter den Wörtern zu verstehen.

Wie verändert das Inline-Diktiergerät die Benutzererfahrung?

Vor v1.3.2 öffnete das Diktiergerät ein Vollbild-Overlay. Du drücktest auf das Mikrofon, alles verschwand zugunsten einer speziellen Gesprächsoberfläche. Das war funktional, aber es unterbrach den Kontext. Du sahst deine Aufgabenliste nicht mehr, du wusstest nicht mehr, wo du warst.

Das Inline-Diktiergerät ändert das Spiel. Es integriert sich direkt am unteren Bildschirmrand, wie eine Tastatur. Du siehst immer noch deinen Inhalt darüber. Die Texttranskription erscheint in Echtzeit, während du sprichst. Und vor allem wird der transkribierte Text vor dem Ende der TTS-Generierung angezeigt.

Warum ist das wichtig? Laut Studien der Nielsen Norman Group zu Reaktionszeiten ist 1 Sekunde die Grenze, um den Gedankenfluss des Benutzers aufrechtzuerhalten. Darüber hinaus beginnt er, eine Verzögerung zu spüren. Indem wir die Transkription sofort anzeigen, während der Audio parallel generiert wird, täuschen wir die Wahrnehmung: Der Benutzer sieht, dass die KI verstanden hat, auch wenn die Audioantwort noch nicht bereit ist.

Dies ist eine bekannte Technik in der UX: Das RAIL-Modell von Google empfiehlt genau das. Visuell in weniger als 100 ms zu reagieren, damit die Interaktion sofort erscheint, auch wenn die vollständige Verarbeitung länger dauert.

Was bringt die Option "TTS überspringen" in der Praxis?

Nicht alle Benutzer müssen die Antwort der KI hören. Einige befinden sich in einer lauten Umgebung. Andere möchten einfach die Transkription lesen. Wieder andere verwenden TAMSIV aus Gewohnheit im stillen Modus.

Die Option "TTS überspringen" ermöglicht es, die Sprachsynthese der Antwort zu deaktivieren. Der Gewinn ist doppelt:

• Reaktionszeit: Ohne auf die Generierung und den Download des TTS-Audios zu warten, wird die Antwort nahezu sofort angezeigt.
• API-Kosten: Jeder TTS-Aufruf hat Kosten (OpenAI berechnet pro Zeichen). Bei Tausenden von täglichen Interaktionen summiert sich das schnell.

Es ist auch eine Frage der Barrierefreiheit. Manche Menschen lesen lieber als zuzuhören. Andere haben Hörbeeinträchtigungen. Indem wir die Wahl anbieten, respektieren wir die Vorlieben jedes Einzelnen. Das ist derselbe Geist wie das Design des ursprünglichen Diktiergeräts: Die Stimme ist ein Kanal, keine Verpflichtung.

Warum war die Gesture-Handler-Migration so kritisch?

Das ist die Art von Fehler, die dich an deinem Verstand zweifeln lässt. Im Debugging funktioniert alles. Unter iOS funktioniert alles. Du wechselst in den Release-Modus unter Android: Die Komponente reagiert nicht mehr auf Berührungen. Keine Fehler in den Logs. Kein Absturz. Es funktioniert einfach... nicht.

Der Übeltäter: Imports von TouchableOpacity, FlatList und ScrollView, die von react-native anstelle von react-native-gesture-handler stammten und innerhalb von GestureDetector verwendet wurden. Die Dokumentation von React Native Gesture Handler ist klar: In einem GestureDetector müssen alle Touch-Komponenten aus der Gesture-Handler-Bibliothek stammen, nicht aus dem Standard-React Native.

Der Fehler war aus drei Gründen tückisch:

1. Unsichtbar im Debugging: Die JavaScript-Bridge von React Native im Debug-Modus behandelt Touch-Ereignisse anders als der Release-Modus mit Hermes.
2. Unsichtbar unter iOS: UIKit und das Responder-Chain-System von iOS sind toleranter als das Event-Management-System von Android.
3. Kein expliziter Fehler: Keine Warnung, kein Absturz. Die Komponente wird angezeigt, hat den richtigen Stil, aber die Berührung löst nichts aus.

Die Korrektur erforderte das Durchsuchen jeder Datei des Projekts. Kein schnelles Grep, da einige Imports gemischt waren: Der TouchableOpacity stammte vom Gesture Handler, aber der ScrollView in derselben Datei stammte von React Native. Ich habe schließlich eine strenge Regel für die weitere Entwicklung aufgestellt, die ich bis heute anwende.

Wie kann man die Leistung mit diesen neuen Funktionen garantieren?

Funktionen hinzuzufügen ist einfach. Funktionen hinzuzufügen, ohne die Leistung zu beeinträchtigen, ist ein Handwerk. Die v1.3.2 führt eine Bild-Pipeline und ein Inline-Diktiergerät ein, zwei potenziell ressourcenintensive Komponenten. Hier sind die implementierten Optimierungen.

Zuerst: keine unnötigen Re-Renders. Das Inline-Diktiergerät verwendet React.memo und stabile Callbacks, um das Auslösen von Re-Renders in der Aufgabenliste darüber zu vermeiden. Jede Animation verwendet useNativeDriver: true, um auf dem nativen Thread zu laufen, nicht auf dem JavaScript-Thread.

Dann: aggressive Bereinigung. Der AudioPlayerService implementiert ein Sicherheits-Timeout von 30 Sekunden. Wenn ein Audio nicht innerhalb dieser Zeit beendet wird (Netzwerkproblem, beschädigte Datei), erzwingt der Dienst die Bereinigung. Ohne dies würden sich Audioressourcen im Speicher ansammeln. Ich hatte die Architektur dieses Dienstes bereits in dem Artikel über die Sprach-Pipeline detailliert beschrieben.

Schließlich werden die generierten Bilder mit Lazy Loading und einem unscharfen Platzhalter geladen. Das Bild wird nur heruntergeladen, wenn die Aufgabenkarte auf dem Bildschirm sichtbar ist. Bei einem Feed von 50 Aufgaben bedeutet das potenziell 50 Bilder, die nicht unnötig geladen werden. Das ist die Art von Optimierung, die sich direkt auf den Supabase-Egress auswirkt, den ich zu reduzieren versucht hatte.

Welche Auswirkungen hat die v1.3.2 auf den täglichen Gebrauch?

Die bemerkenswerteste Veränderung ist die Flüssigkeit. Vor v1.3.2 war die Nutzung von TAMSIV funktional, aber etwas starr. Danach wurde es natürlich. Du sprichst, du siehst, wie deine Aufgabe mit einem Bild erstellt wird, du machst deinen Tag weiter. Das Inline-Diktiergerät holt dich nicht mehr aus deinem Kontext.

Das Feedback der Alpha-Tester bestätigte die Intuition. Das Inline-Diktiergerät wurde einstimmig dem Overlay vorgezogen. Das KI-Bild wurde nach der grundlegenden Aufgabenerstellung zur meistgenutzten Funktion. Und vor allem behob die Gesture-Handler-Korrektur ein Dutzend Meldungen von "Knöpfen, die nicht funktionieren", die wir im Debugging nicht reproduzieren konnten.

Dies ist die Veröffentlichung, die TAMSIV von "es funktioniert" zu "es ist angenehm" gemacht hat. Und im Build in Public ist das ein ebenso wichtiger Meilenstein wie der erste Commit. Ich habe darüber in dem Bericht nach 650 Commits gesprochen: Die wahrgenommene Qualität macht den Unterschied zwischen einer App, die man ausprobiert, und einer App, die man behält.

Häufig gestellte Fragen

Kann man auch KI-Bilder für Memos generieren?

Derzeit ist die KI-Bildgenerierung für Aufgaben verfügbar. Der Mechanismus verwendet die Tabelle privat.task_attachments mit dem Typ ai_generated. Die Erweiterung auf Memos ist geplant und technisch einfach, da die Tabelle privat.memo_attachments bereits mit derselben Struktur existiert.

Funktioniert das Inline-Diktiergerät im Hintergrund?

Nein. Das Diktiergerät erfordert, dass die App im Vordergrund ist, um Audio aufzunehmen und die Transkription in Echtzeit anzuzeigen. Dies ist eine bewusste Entscheidung: Die native Spracherkennung des Geräts ist für den Vordergrund optimiert, und die sofortige Anzeige der Transkription ist der Schlüssel zur Erfahrung.

Ist die Option "TTS überspringen" dauerhaft oder pro Konversation?

Dies ist eine dauerhafte Einstellung, die im Benutzerprofil gespeichert wird. Einmal aktiviert, werden alle zukünftigen Konversationen nur im Textmodus geführt. Du kannst sie jederzeit in den Einstellungen wieder aktivieren.

Betrifft der Gesture-Handler-Fehler die App immer noch?

Nein. Die Migration wurde vollständig durchgeführt und eine strenge Entwicklungsregel wurde eingeführt: Jede Touch-Komponente innerhalb eines GestureDetector muss obligatorisch die Imports von react-native-gesture-handler verwenden. Dies wird bei jeder Code-Überprüfung überprüft.

Wie viel kostet die Generierung eines KI-Bildes?

Mit dem Anbieter Runware (HiDream-I1-Fast) etwa 0,003 Euro pro Bild. Mit Gemini 2.5 Flash Image etwas mehr. Die Kosten werden durch Quoten pro Abonnementplan kontrolliert: Der Free-Plan hat keinen Zugriff, Pro hat eine tägliche Quote, Team eine höhere Quote.