TL;DR
Letzte Woche habe ich einen PDF‑Report mit fixer Struktur gebaut – ganz bewusst ohne LLM. Diese Woche bin ich den Gegenentwurf gegangen: Ein AI‑Report, der Wetter‑ und Energiedaten analysiert, auffällige Entwicklungen automatisch erkennt und einen frei formulierten Text generiert. Der Report wird erstellt, als PDF gerendert und per E‑Mail verschickt. Das größte Learning: Wenn die Struktur nicht vorgegeben ist, müssen Prompt, Datenvoranalyse und PDF‑Layout sehr gut zusammenspielen.
Kontext & Ziel
Ausgangspunkt war wieder ein bestehendes Dashboard mit Wetter‑ und Energiedaten (Weather & Energy Dashboard aus Woche 15). Der Report von letzter Woche hatte eine feste Struktur und kam komplett ohne LLM aus, da man diese Aufgabe sehr gut mit Templates lösen kann. Diese Woche wollte ich im Kontrast dazu bewusst die Flexibilität von LLMs nutzen: Erkenntnisse nicht nur wiedergeben, sondern interpretieren lassen. Statt „Bausteine zusammensetzen“ sollte ein flüssiger Text entstehen, der Besonderheiten automatisch hervorhebt, Vergleiche anstellt und Trends einordnet. Der Scope für diese Woche: Daten aggregieren, kurze Voranalyse (z. B. stärkste Anstiege/Rückgänge), einen gut formulierten Freitext generieren lassen, als PDF ausgeben und per E‑Mail versenden.
Meine Anforderungen
Ich möchte einen Report, der wie „von Menschenhand geschrieben“ klingt, statt in immer gleichen Bausteinen zu sprechen
Der Text soll von selbst interessante Punkte finden – zum Beispiel auffällige Temperaturabweichungen oder veränderte Wind‑/Solarpotenziale
Ich will die Daten pro Stadt und Zeitraum vergleichen können, inklusive kurzer Einordnung, was sich verändert hat
Der Versand als PDF per E‑Mail soll automatisch laufen, ohne dass ich manuell Dateien anfügen muss
Das Design darf nicht an ein Template gebunden sein – es soll bei wechselnder Struktur trotzdem gut lesbar bleiben
Wenn die Datenlage dünn ist, soll der Report das transparent machen und keine falsche Sicherheit erzeugen
Mein AI-Workflow
Die Idee habe ich zunächst mit ChatGPT gebrainstormt.
Für das erste Gerüst des Backends habe ich OpenAI Codex eingesetzt. Als es dann darum ging die Prompts zu verfeinern, bin ich zu Claude Code gewechselt. Der Report war immer noch sehr im „Template“-Stil. Während Codex die Prompts immer strenger und ausführlicher machen wollte, hat Claude Code die Prompts vereinfacht, wodurch die Ergebnisse dann wieder natürlicher klangen. Für den Rest des Codes bin ich dann bei Claude Code geblieben.
Das Titelbild für den Blogpost ist mit ChatGPT entstanden.
Was das Tool kann
👉 Es sammelt Wetter‑ und Energiedaten aus der Datenbank für einen definierten Zeitraum ein und bildet Kennzahlen pro Stadt
👉 Es vergleicht aktuelle Werte mit dem vorangegangenen Zeitraum und hebt starke Veränderungen hervor
👉 Es erzeugt einen frei formulierten Report‑Text, der die wichtigsten Insights zusammenfasst, statt nur Zahlen aufzulisten ✨
👉 Es rendert den Text als sauber strukturiertes PDF und verschickt es automatisiert per E‑Mail an definierte Empfänger 📩
👉 Es lässt sich auf ausgewählte Städte einschränken und berücksichtigt Zeitzonen sowie eine sinnvolle maximale Textlänge
Stack & Tools
- Frontend: kein separates Frontend – der Fokus liegt auf automatisierter Erstellung und Versand
- Backend: Python, ReportLab (Report‑Generierung), Groq API
- Daten: MariaDB (Wetter‑ und Energiedaten)
- Deployment: Docker
Herausforderungen & Learnings
- PDF‑Design ohne feste Struktur: Wenn die Textabschnitte variieren, müssen Layout‑Bausteine (Hervorhebungen, Info‑Boxen, Kopf‑/Fußzeilen) so generisch sein, dass sie in jeder Reihenfolge gut funktionieren – ohne „Template‑Look“.
- Lokal vs. Server: Ein lokales Tool sollte es zunächst werden; wegen des isolierten Docker‑Datenbankcontainers war der direkte Zugriff von außen jedoch nicht praktikabel. Die Lösung: Report‑Erzeugung als Skript auf dem Server.
- Prompt‑Feintuning: Zu „strenge“ Prompts führten zu formelhaften Texten. Mit freierer, aber klarer Aufgabenstellung klangen die Reports natürlicher. Claude Code war hier hilfreicher als Codex.
- Voranalyse gegen Rauschen: Bevor das LLM schreibt, helfen einfache Metrik‑Deltas und Schwellwerte, um irrelevante Mini‑Schwankungen auszufiltern.
Keine Live-Demo
Keine Live‑Demo – das Tool läuft serverseitig als Skript und liefert das Ergebnis als PDF per E‑Mail aus.
Fazit
Woche 17: ✅
Diese Woche ging es bewusst um den Unterschied zwischen „PDF aus Bausteinen“ und einem natürlich klingenden Textbericht mit LLM. Ich denke im Idealfall sollte man beides miteinander kombinieren, um einen Report zu erstellen, der alle wichtigen Informationen enthält.
Ich würde an dieser Stelle gerne die nächste Woche anteasern, aber ich habe keine Ahnung, in welche Richtung es gehen wird. Aber ich glaube ich hätte mal wieder Lust auf ein schönes Frontend!
