Warum ich Askling entwickelt habe
Beim Lernen erkenne ich einen Unterschied zwischen einem vertrauten Text und einem Konzept, das ich selbst erklären kann. Eine Folie wirkt beim zweiten Lesen schnell verständlich. Sobald ich jemandem den Zusammenhang ohne Vorlage beschreiben soll, fallen mir die offenen Stellen auf. Genau an diesem Übergang setzt Askling an: Die Anwendung gibt dem Erklären einen festen Platz im Lernablauf.
Die Idee verbindet meine Arbeit an Lernsoftware mit einer Frage, die mich auch als Tutor beschäftigt: Wie bringe ich jemanden dazu, einen Gedanken selbst zu formulieren? Die KI übernimmt dafür die Rolle eines neugierigen Gegenübers. Sie fragt nach einem Begriff, einem Zusammenhang oder einer Begründung. Ich antworte in eigenen Worten und bekomme Rückfragen oder Feedback zu meiner Erklärung.
Mein Beitrag umfasst die Produktidee, den Lernablauf und die technische Umsetzung: vom Import der Unterlagen über die Planerstellung bis zur Gesprächsansicht und lokalen Datenhaltung. Askling ist dabei die eigenständig nutzbare, selbst gehostete Variante dieses Ansatzes. Das Projekt ist vom separat geplanten, verwalteten Angebot TeachBack AI zu unterscheiden. Diese Fallstudie beschreibt ausschließlich das öffentliche Askling-Repository.
Von der PDF zum eigenen Erklären
Der Einstieg beginnt mit den eigenen Unterlagen. Ich wähle durchsuchbare PDFs aus, gebe ein Fach und den verfügbaren Lernzeitraum an. Askling extrahiert den Text auf dem Gerät und ergänzt Dokumentnamen und Seitenüberschriften. Der nächste Schritt arbeitet mit diesem Text: Ein Sprachmodell erzeugt Tagesabschnitte mit Thema, Zusammenfassung und Materialkontext. Der Plan wird lokal gespeichert und lässt sich anschließend öffnen.
Ein Lerntag führt in eine Gesprächsansicht. Die Fragen beziehen sich auf den jeweiligen Stoffabschnitt und fordern zum Beschreiben oder Erklären auf. Eine passende Frage zu objektorientierter Programmierung wäre etwa: Warum hilft eine gemeinsame Schnittstelle, wenn verschiedene Klassen dieselbe Aufgabe unterschiedlich umsetzen? Das ist ein beispielhafter Fragetyp, kein aufgezeichneter Dialog und kein garantierter Wortlaut des Modells.
Die Unterhaltung behält den Zusammenhang zwischen Hauptfrage, Antwort und Rückfragen. Dadurch bleibt nachvollziehbar, worauf sich eine Erläuterung bezieht. Plan, Fortschritt und Gesprächsverlauf liegen in derselben Anwendung. Der Ablauf soll die Hürde senken, tatsächlich mit dem Erklären anzufangen. Ob daraus ein besseres Prüfungsergebnis entsteht, lässt sich aus der vorhandenen Implementierung allein nicht ableiten.
Die wichtigste Produktentscheidung: selbst nutzbar
Für Askling habe ich mich für einen Aufbau ohne zentrales Benutzerkonto und ohne eigenen Anwendungsserver entschieden. Beim ersten Start wird der KI-Anbieter konfiguriert; danach führt der Weg direkt ins Dashboard. Es gibt keine Registrierung bei einem von mir betriebenen Dienst. Wer die Anwendung selbst betreibt, entscheidet auch, welchen Modell-Endpunkt sie verwendet.
Das reduziert die Infrastruktur, die für einen persönlichen Lernablauf nötig ist. Gleichzeitig verlagert es Verantwortung: Die Person am Gerät muss ihren Anbieter konfigurieren, dessen Kosten berücksichtigen und mit den eigenen Daten umgehen. Eine lokale Datenbank bietet außerdem keine automatische Synchronisierung zwischen Laptop und Smartphone. Diese Grenzen gehören zum Produkt und sollten vor der Nutzung verständlich sein.
Die Architektur passt zu einem persönlichen Werkzeug und zu Menschen, die ihr Lernsystem selbst kontrollieren möchten. Sie ist keine Behauptung, dass jede Berechnung ohne Netzwerk funktioniert. Für KI-Anfragen an einen externen Anbieter braucht die Anwendung eine Verbindung. Ein lokaler Modell-Endpunkt ist ebenfalls konfigurierbar; dessen Einrichtung und Eignung bleiben eigenständige Aufgaben.
Wie die Anwendung aufgebaut ist
Askling ist in Dart mit Flutter umgesetzt. Die Oberfläche und ihre Zustände sind nach Funktionen gegliedert: Einrichtung, Dashboard, Planer, Plandetails und Lernsitzung. Riverpod verbindet die Ansichten mit Repositories und Diensten. Die gemeinsame Logik für PDF-Verarbeitung, Planerzeugung und Modellanfragen liegt außerhalb der einzelnen Bildschirme. Dadurch muss ein Fehler in der Anbieterkommunikation an einer gemeinsamen Stelle behandelt werden.
Für die lokale Datenhaltung verwende ich Hive. Pläne, Lerntage, Nachrichten, Profilinformationen und extrahierter Dokumenttext haben getrennte Speicherbereiche. Im Web wird dafür der Browserspeicher genutzt; auf anderen Plattformen liegt die Datenbank im Anwendungsverzeichnis. Die lokale Speicherung ist keine automatische Datensicherung. Wer Browserdaten löscht oder das Gerät verliert, muss diesen Unterschied berücksichtigen.
Die Anbieterkonfiguration nutzt flutter_secure_storage. Dessen konkrete Speicherung hängt von der Plattform ab; deshalb verspreche ich keine überall identische Schlüsselablage. Die Zugangsdaten werden zur Laufzeit eingegeben und gehören nicht in das ausgelieferte App-Paket. Für die Fallstudie ist der wesentliche Punkt die Trennung: lokale Anwendungsdaten einerseits, konfigurierte Modellkommunikation andererseits.
Was lokal bleibt und was die KI erhält
Neue PDF-Importe werden lokal in Markdown-Text mit Dokument- und Seitenkennzeichnung umgewandelt. Die Originaldateien werden für diesen Import nicht dauerhaft gespeichert und nicht als PDF an das Modell übertragen. Der Text bleibt für die Planerzeugung und spätere Wiederholungsversuche erhalten. Die Seitenkennzeichnung bewahrt einen einfachen Bezug zur Quelle; sie rekonstruiert jedoch keine komplexen Tabellen oder das ursprüngliche Seitenlayout.
Bei der Planerstellung erhält der konfigurierte KI-Endpunkt den aufbereiteten Text sowie Angaben wie Fach und Lernzeitraum. Für die Lernsitzung kommen der relevante Stoffabschnitt und Gesprächsinhalte hinzu. Wer einen externen Anbieter auswählt, überträgt damit Inhalte an diesen Anbieter. Lokal gespeicherte Daten und lokale Verarbeitung sind daher getrennt zu betrachten. Die Grafik macht diese Grenze ausdrücklich sichtbar.
Durchsuchbarer Text ist eine Voraussetzung des Imports. Eine eingescannte Seite ohne Textebene braucht vorher OCR. Auch Formeln, Tabellen und ungewöhnliche Lesereihenfolgen können bei der Extraktion Information verlieren. Deshalb ist der erzeugte Lernplan ein Ausgangspunkt für das eigene Lernen und kein Beleg dafür, dass jede Seite vollständig und fachlich richtig verstanden wurde.
Eine gemeinsame Schnittstelle für verschiedene Modelle
Askling bietet Voreinstellungen für mehrere Anbieter und einen eigenen Endpunkt. Technisch unterscheide ich zwei Anfrageformate: OpenAI-kompatible Chat-Completions und Anthropics Messages-Format. Eine ähnliche Produktfunktion bedeutet nicht, dass Authentifizierung, Parameter und Antworten gleich aufgebaut sind. Diese Unterschiede bündelt der gemeinsame LLM-Dienst, statt sie in jeden Bildschirm zu verteilen.
Ein konkretes Beispiel ist das Ausgabelimit. Der Dienst verwendet für den offiziellen OpenAI-Endpunkt einen anderen Parameternamen als für kompatible Endpunkte. Anthropic benötigt wiederum eine eigene Nachrichtenstruktur. Solche Details sind für den Lernablauf unsichtbar, entscheiden aber darüber, ob eine Anfrage überhaupt angenommen wird. Tests prüfen diese Unterschiede mit kontrollierten Antworten und ohne echte Zugangsdaten.
Die freie Anbieterwahl hat einen Preis: Modelle unterscheiden sich in Kontextfenster, Antwortformat, Geschwindigkeit und Qualität. Ein erfolgreich getesteter Adapter garantiert deshalb nicht, dass jedes beliebige Modell einen brauchbaren Plan erstellt. Ich behandle Anbieterkompatibilität als technische Schnittstelle und die fachliche Eignung eines Modells als separate Frage. Beide müssen für einen konkreten Einsatz zusammenpassen.
Unvollständige Antworten dürfen nicht als fertiger Plan gelten
Eine lange Planerstellung kann an einem Ausgabelimit oder einem Verbindungsfehler scheitern. Für diesen Fall teilt Askling die Generierung in Pakete von höchstens drei Lerntagen. Jede Antwort wird auf die erwartete Zahl und Reihenfolge der Tage sowie auf notwendige Felder geprüft. Meldet der Anbieter eine abgeschnittene Ausgabe, wird daraus kein stillschweigend verkürzter fertiger Plan gespeichert.
Der bereits extrahierte Markdown-Text bleibt für einen erneuten Versuch verfügbar. Ein Fehler beim KI-Anbieter soll nicht dazu führen, dass alle PDFs erneut konvertiert werden müssen. Wird dagegen der Browser während der ursprünglichen PDF-Konvertierung neu geladen, können die noch nicht gespeicherten Dateien erneut ausgewählt werden müssen. Diese beiden Unterbrechungen brauchen unterschiedliche Rückmeldungen und Wiederanlaufwege.
Auch die Gesprächsoberfläche behandelt Modellantworten als Inhalte, nicht als beliebige Anweisung an die Anwendung. Beispielsweise werden Bildadressen in KI-generiertem Markdown als Alternativtext dargestellt, statt automatisch entfernte Bilder nachzuladen. Solche Entscheidungen lösen nicht jedes Risiko einer KI-Anwendung. Sie machen den Datenfluss jedoch berechenbarer und verhindern einen unnötigen zusätzlichen Netzwerkpfad.
Was ich am aktuellen Stand überprüft habe
Die Fallstudie basiert auf einem festgehaltenen Stand des öffentlichen Repositories vom 16. Oktober 2026. Ich habe den Quellcode für Import, lokale Speicherung, Modelladapter und Planvalidierung mit den zugehörigen Tests abgeglichen. Für denselben Commit liegt ein erfolgreicher GitHub-Actions-Lauf vor. Diese Zuordnung ist wichtig: Ein grüner Testlauf ist nur dann ein brauchbarer Nachweis, wenn klar ist, welchen Stand er geprüft hat.
Die Tests behandeln unter anderem unterschiedliche Anfrageformate, abgeschnittene oder unvollständige Planantworten und die Wiederverwendung des Dokumenttexts nach einem Anbieterfehler. Sie verwenden kontrollierte Testfälle. Damit lassen sich technische Eigenschaften gezielt prüfen, ohne Geld für Modellaufrufe auszugeben oder vertrauliche Vorlesungsunterlagen zu übertragen.
Diese Nachweise ersetzen keine Untersuchung der Lernwirkung. In der README stehen weitergehende Kennzahlen, für die ich im Rahmen dieser Recherche keine belastbare Versuchsdokumentation gefunden habe. Deshalb übernehme ich weder eine prozentuale Zeitersparnis noch eine Genauigkeits- oder Erfolgsquote. Der hier belegte Stand ist eine implementierte und technisch geprüfte Anwendung mit einem klaren Lernablauf.
Was das Projekt über meine Arbeit zeigt
Askling verbindet Produktgestaltung mit der technischen Arbeit hinter einer KI-Oberfläche. Die sichtbare Funktion ist ein Lerngespräch. Damit es nutzbar wird, müssen vorher Dateien gelesen, Kontext aufgebaut, Antworten strukturiert, Zustände gespeichert und Fehler verständlich behandelt werden. Gerade diese Übergänge haben das Projekt geprägt und sind auch außerhalb von Lernsoftware relevant.
Für die weitere Entwicklung würde ich zuerst mit kleinen, nachvollziehbaren Lernaufgaben prüfen, welche Rückfragen tatsächlich hilfreich sind und wo Modelle falsche Sicherheit vermitteln. Dazu gehören fachlich geprüfte Beispieldialoge, realistische PDF-Importe und eine klare Trennung zwischen technischem Funktionieren und didaktischem Nutzen. Mehr Anbieter oder zusätzliche Funktionen sind erst dann wertvoll, wenn der grundlegende Ablauf überzeugt.
Der Quellcode ist öffentlich unter der PolyForm Noncommercial License 1.0.0 verfügbar. Ich bezeichne Askling deshalb als source-available für nichtkommerzielle Nutzung. Das Repository ermöglicht einen Blick auf die Umsetzung und eigene Experimente innerhalb seiner Lizenzbedingungen. Für meine Website ist es ein konkretes Beispiel dafür, wie ich aus einer Lernidee ein zusammenhängendes Produkt mit nachvollziehbaren technischen Entscheidungen mache.