Ein Elternteil bat unseren Agenten, den Forschungsbericht eines Schülers — ein Word-Dokument über einen thermoelektrischen Trinkwasserspender — in eine Präsentation für einen stadtweiten Innovationswettbewerb zu verwandeln. Eine echte Aufgabe, mit echter Deadline und einer echten Lehrkraft, die das Ergebnis liest.
Das fertige Deck wurde gut — sauber genug, dass die editierbare Version so poliert aussah wie die aufwendig gerenderte. Aber auf dem Weg dahin brach es auf vier verschiedene Arten, und jeder Bruch war die Sorte Bug, die man nur findet, wenn jemand die Datei wirklich herunterlädt und auf einem Schullaptop öffnet. Hier ist, was passiert ist — und was wir deshalb am System geändert haben.
Bruch 1: Drei Slides kamen leer zurück
Die Vorschau sah perfekt aus. Das heruntergeladene HTML nicht — neun Bilder
renderten leer. Die Ursache: Das Deck referenzierte Bilder über relative Pfade
(src="assets/chart.png"), was in der Workspace-Vorschau sauber
auflöst, aber ins Leere zeigt, sobald die .html-Datei allein in einem
Downloads-Ordner landet.
Der Fix, der zählt, ist nicht „Bilder einbetten" — es ist die Invariante: Bevor
ein Deck als Deliverable gilt, muss grep -c 'src="assets/' null
zurückgeben. Bilder einzeln zu patchen ist der Grund, warum der erste Fixversuch
drei Charts übersah. Jede Regel in dieser Geschichte endet gleich: Schließe den Loop mit einem Check, nicht mit Augen.
Bruch 2: Charts, die nur online existieren
Interaktive Chart-Bibliotheken rendern auf ein Live-Canvas. Im Scroll-Modus-DOM-Klon unserer Vorschau verschwinden die gemalten Pixel; offline kommt das CDN-Skript nie an. Für ein Deck, das im Klassenzimmer projiziert werden muss, ist „funktioniert, wenn online" nicht gut genug — Präsentations-Decks rendern Charts deshalb jetzt als PNG vor und betten sie als Bilder ein. Interaktive Charts bleiben nur dann eine Option, wenn die Umgebung bekannt ist und Interaktion der Sinn der Sache.
Bruch 3: Der Export, der nicht passte
Der Nutzer wollte zwei Versionen: ein poliertes gerendertes PPTX und ein editierbares, das der Schüler vor dem Präsentieren noch anpassen konnte. Die Editable-Export-Pipeline stellte sich als hart limitiert im Input heraus — ein vollständig eigenständiges Deck ist viel zu groß — und sie ließ außerdem Bilder mit relativen Pfaden fallen und verschmolz Textboxen falsch. Also wurde das editierbare Deck nativ mit python-pptx neu gebaut. Das brachte drei weitere Realwelt-Fehler an die Oberfläche:
- Schriftgrößen-Mathematik muss von der Folie kommen, nicht vom
Bildschirm. Eine 16:9-Folie ist 960×540pt, während der Design-Canvas
1920×1080px ist — also
pt = px × 0.5. Die intuitive 96dpi-Umrechnung bläht jeden Run um 50% auf, und Texte brachen überall in Kollisionen. - Layout muss unterschiedliche Font-Metriken überleben. Paare aus „große Zahl + kleine Bildunterschrift" standen im Browser wunderschön ausgerichtet und überlappten in WPS, dessen Glyphenbreiten abweichen. Vertikal gestapelt sind sie immun; nebeneinander mit festen Offsets nicht.
- Geometrie braucht einen Lint. Ein Titelbild lief 200px über den Folienrand hinaus — entdeckt von den Augen des Elternteils, nicht vom Build. Jede Form bekommt jetzt vor dem Speichern eine Bounds-Assertion.
Bruch 4: Die Verifizierung, die das Deliverable zerstörte
Das QA-Skript verschob einmal die fertige Datei beim Validieren — der Check selbst
zerstörte das Geprüfte. Zwei leisere Lektionen blieben ebenfalls: Batch-Text-Edits
brauchen Toleranz pro Element plus einen Rest-grep nach
Überbleibseln, und Chart-Zahlen dürfen nur aus den Tabellen des Quelldokuments
kommen — nie erneut von einem kleinen Screenshot abgelesen, wo aus 4.62 einmal
5.89 wurde.
Was sich im Produkt geändert hat
Jede davon ist jetzt eine geschriebene Regel im Skill-Set des Agents — dieselben Skills, die jeder Nutzer bekommt. Die Deliverable-State-Invariante (null externe Referenzen, hash-verifiziert), die Limits der Export-Pipeline, die python-pptx-Geometrie- und Layoutregeln, Smoke-Builds mit einer Folie vor dem Batch und der QA-Loop, der jede Seite rendert, bevor er sie übergibt. Wir haben das rohe Write-up außerdem als Workspace-Skill behalten, damit sich Lektionen aus einem echten Projekt verzinsen statt verflüchtigen.
Das ist der Teil von „KI macht Slides", den niemand vorführt: Die Datei muss den Weg auf einen Schullaptop, eine WPS-Installation und einen Beamer überleben. Die Lücke zwischen „sieht in der Vorschau super aus" und „öffnet überall korrekt" ist genau der Ort, wo Handwerk wohnt — und der Grund, warum wir echte Aufgaben selbst durchs Produkt jagen und jeden Bruch aufschreiben.
Probier dieselbe Pipeline selbst unter Document to Slides — kostenlose Vorschau, du zahlst nur, wenn du die saubere Datei willst.