Zwei Prompts bis live – Anatomie einer automatischen Content-Fabrik

Am Anfang der Produktion einer Lesson auf lernen.diy steht eine kurze Nachricht an einen KI-Agenten. Am Ende steht eine zweite. Dazwischen entstehen rund 3.000 Wörter geprüfter Text, ein Dutzend Bilder aus drei verschiedenen Modellen, unsichtbares Chat-Wissen und ein deploybarer Stand. Wenn der erste Wurf sitzt, sieht die gesamte menschliche Eingabe so aus:

In der Praxis kommen Zwischenschritte dazu: eine Plan-Freigabe per Klick, Review-Kommentare, wenn etwas nicht sitzt. Aber die Arbeitsteilung bleibt in jedem Fall dieselbe: Der Mensch liefert Richtung und Urteil, das System liefert Ausführung. Diese Lesson folgt der Produktion chronologisch, von Minute null bis zum Deployment, und zeigt an jeder Station zwei Dinge: was automatisch passiert und was dafür einmal gebaut werden musste.

Gebaut hat dieses System Rico Loschke. lernen.diy ist dabei kein Unternehmen mit Redaktion, sondern ein Ein-Personen-Projekt, und die Fabrik ist die Antwort auf eine nüchterne Rechnung: Neben allem anderen kann eine Person Lessons in diesem Umfang nicht regelmäßig von Hand produzieren. Mit kuratiertem Wissen, festen Regeln und automatisierten Pipelines geht es. Der Preis dafür ist an anderer Stelle bezahlt worden, vor dem ersten kurzen Prompt, und genau diese Vorarbeit ist der rote Faden der folgenden Steps.

Der Prompt ist kurz, weil der Kontext lang ist

Was bei Prompt 1 wirklich beim Modell ankommt, ist nicht der eine Satz. Bevor der Agent das erste Wort schreibt, laden automatisch: eine dreistufige Hierarchie von Kontext-Dateien (wer der Auftraggeber ist, welche Marke welchen Ton hat, was hart verboten ist), vier Projekt-Rules mit Technik-Konventionen und der Index von 32 Memory-Notizen, in denen frühere Korrekturen destilliert sind. Dazu kommt auf Abruf der Lesson-Factory-Skill mit Schema, Didaktikregeln und Bild-Workflow. Alles davon sind einfache Textdateien.

Der Auftrag oben hat rund 60 Wörter. Er funktioniert, weil auf jedes Wort des Prompts etwa 170 Wörter vorbereiteter Anweisung kommen. Das ist der Kern von Context Engineering: Die Qualität einer Antwort entsteht nicht im Prompt, sondern in dem, was neben dem Prompt im Kontextfenster steht. Wer jede Session bei null anfängt, muss jede Session alles neu erklären.

Geladen wird nur, was der Auftrag braucht

Die 10.000 Wörter landen nicht als Block im Kontext, sondern gestaffelt: Die CLAUDE.md-Ebenen und Rules laden immer, der Skill nur bei passender Aufgabe, und vom Skill wiederum nur die Dateien des gewählten Output-Pfads. Für eine JSON-Lesson liest der Agent die JSON-Referenz und die Bildregeln, die drei HTML-Referenzdateien bleiben ungelesen. Das Memory lädt als Index, einzelne Notizen erst bei Bedarf. Das Prinzip heißt Progressive Disclosure und hält das Kontextfenster frei für die eigentliche Arbeit. Eine echte Regel pro Schicht, damit greifbar wird, was dort steht:

• CLAUDE.md: „ogImage und audioSrc erst ins Frontmatter, wenn die Dateien existieren.“ Sonst zeigt die Seite kaputte Bilder und tote Player.
• Rules: „Nie Hex-Farben in Komponenten hardcoden, immer semantische Tokens wie text-accent.“
• Skill: „Nie zwei Textblöcke ohne visuelle Unterbrechung, jeder Content-Step endet mit einem Takeaway.“
• Memory: „Takeaways als nummerierte Regeln formulieren, Zähler konsequent auf allen Content-Steps.“

Erst verstehen, dann bauen

Bei größeren Aufträgen baut der Agent nicht sofort los. Er startet im Plan-Modus, in dem er nur lesen darf: Zwei Subagenten erkunden parallel das Repository (einer das Lesson-Format und den Skill, einer die Asset-Pipeline und die Gates), ein dritter entwirft daraus die Step-Architektur. Offene Entscheidungen gehen als Rückfragen an den Menschen. Dann erst kommt der Plan zur Freigabe, per Klick.

Drei Rückfragen, dann Freigabe

Was der Auftrag offenlässt, wird nicht geraten. Der Agent stellt Entscheidungsfragen als geschlossene Auswahl mit Empfehlung, der Mensch antwortet per Klick. Bei der Produktion dieser Lesson waren es genau drei:

Die Wissensbasis für den Inhalt ist nicht das offene Netz, sondern der Vault: ein Obsidian-Wissensspeicher mit Voice-Regeln, Themen-Zuordnung, Seminar-Material und dem Register aller publizierten Inhalte, angebunden über eine MCP-Schnittstelle mit Such-, Lese- und Schreibzugriff. Der Unterschied ist grundsätzlich: Das Modell recherchiert in einem Bestand, den ein Mensch kuratiert hat. Es findet die eigene Position zu einem Thema, nicht den Durchschnitt des Internets.

Struktur ist nicht verhandelbar

Der Text entsteht nicht als freier Fließtext, sondern als JSON gegen ein Zod-Schema: elf erlaubte Block-Typen mit Pflichtfeldern, als discriminated union definiert. Ein Block, der dem Schema nicht entspricht, ist kein Stilproblem, sondern ein Build-Fehler. Dazu kommen die Didaktikregeln aus dem Skill: sechs bis acht Steps, eine Übung pro Content-Step, nummerierte Takeaways, eine Ton-Sperrliste gegen erfundenes Storytelling und Dramatik-Floskeln.

Das Schema hat drei Aufgaben zugleich. Es steuert das server-seitige Rendering, jeder Block-Typ hat genau eine Komponente. Es macht Review adressierbar, weil jeder Block über Step- und Block-Index eine Koordinate hat. Und es trägt das Chat-Grounding, weil derselbe JSON-Inhalt später den Frag-KI-Chat versorgt. Am Ende von Pass 1 laufen astro check und der Production-Build. Erst wenn beide grün sind, beginnt der teure Teil: die Bilder.

Die Ton-Sperrliste: ein Linter für Sprache

Jede Zeile dieser Tabelle ist wörtlich aus Review-Korrekturen destilliert und steht im Skill. Sie wirkt wie ein Linter für Ton: pro Text nicht verhandelbar, änderbar nur an einer Stelle, gültig für jede künftige Produktion. Genau das unterscheidet eine Stilregel im System von einer Stilbitte im Prompt.

Modellwahl ist Vorarbeit, keine Laufzeit-Entscheidung

In Pass 2 entstehen die Bilder, für eine Lesson dieser Größe rund ein Dutzend aus drei verschiedenen Modellen. Welches Modell welche Bildklasse übernimmt, steht vorher fest, dokumentiert und begründet im Skill: Step-Header über die Gemini API (trifft den warmen, gegenständlichen Hausstil), Cover über nano_banana_2 per Higgsfield-MCP (Stillleben mit sauberem Licht), deutsch beschriftete Schaubilder über gpt_image_2 (das einzige erprobte Modell, das Umlaute zuverlässig rendert). Jede Lesson hat zudem ein Leitmotiv, das sich durch alle Header zieht. In dieser Lesson ist es ein historischer Schreibautomat: eine Maschine, die auf Knopfdruck schreibt, mit offenem Räderwerk.

Die Messlatte ist wörtlich gemeint: Nach der Generierung misst ein sharp-Skript die mittlere Helligkeit jeder Datei gegen ein Zielband. Aus „wirkt zu dunkel“ wird eine Zahl. In einer vorangegangenen Produktion lag die erste Header-Serie bei 71 bis 102, also zu hell. Die Prompts bekamen Dunkel-Anker, sieben Header wurden neu generiert, und die Erkenntnis wanderte als Regel in die Skill-Doku. Beim nächsten Durchlauf, nämlich diesem hier, standen die Anker von Anfang an im Prompt. So lernt das System zwischen zwei Produktionen, ohne dass ein Modell trainiert wird.

Eine Quelle, vier Ausspielungen

Die Fabrik produziert nicht nur Text. Blog-Artikel bekommen eine Audio-Version: 400 bis 550 Wörter, dritte Person, eine eigenständige Zusammenfassung statt eines Vorlesetexts, gesprochen von gemini-2.5-flash-preview-tts mit der Stimme Fenrir und beim MP3-Export per ID3-Tag maschinenlesbar als KI-Stimme gekennzeichnet, wie es der EU AI Act in Artikel 50 verlangt. Das Vorschaubild für soziale Netzwerke rendert ein Skript per Playwright/Chromium aus einer HTML-Vorlage, bewusst ohne Bildmodell, weil eine deterministische Aufgabe deterministischen Code verdient. Und jede Lesson speist einen Chat.

Der entscheidende Punkt ist die Quelle: Alle Ausspielungen hängen an derselben Datei. Ändert sich die Lesson, ändert sich das Chat-Wissen mit. Das Audio entsteht aus dem Artikel, das Vorschaubild aus dessen Titel. Es gibt keinen zweiten Ort, der veralten kann, und keinen Abgleich, den jemand vergessen könnte.

Der Mensch sitzt an vier Stellen, nicht überall

Über die gesamte Produktion verteilt gibt es genau vier menschliche Berührpunkte: den Auftrag, die Plan-Freigabe, das Review und das Deploy-Go. Alles dazwischen läuft ohne Eingriff. Das ist keine Nebensache, sondern das Design: Der Mensch wird dort eingesetzt, wo sein Urteil unersetzlich ist, und nirgendwo sonst.

Das Review ist klickbar statt mündlich: Jede Lesson lässt sich mit dem URL-Zusatz ?review=true öffnen, jeder Block wird anklickbar, jeder Kommentar landet mit Koordinaten in einer JSON-Datei, die der Agent direkt liest. Ein echtes Beispiel samt Wirkung:

Dann der zweite Prompt. „Commit und Push“ ist bewusst das einzige Kommando, das veröffentlicht. Dahinter läuft die Deploy-Kette: eine Checkliste prüft Build, Typen, Draft-Status, Secrets und tote Links, der Push auf den Hauptbranch stößt bei Vercel automatisch Build und Deployment an, jede Änderung wird ein eigenes, rückrollbares Deployment. Der Agent selbst darf diesen Push nie ausführen, das steht als hartes Verbot in der Kontext-Datei. Human-in-the-Loop heißt hier: Schreibrecht beim System, Veröffentlichungsrecht beim Menschen.

Die sechs Checks vor dem Go

1. Build: der Production-Build läuft fehlerfrei durch
2. Typen: der Type-Check meldet null Errors
3. Drafts: nichts geht versehentlich mit falschem Status live
4. Secrets: keine API-Keys im Quellcode, nur Umgebungsvariablen
5. Offene Enden: keine TODO- oder FIXME-Marker in geänderten Dateien
6. Links: interne Verweise zeigen auf existierende Routen

Nach dem Deployment ist der Inhalt Rohstoff

Mit dem Go aus Schritt 6 endet die Produktion, aber nicht die Verwertung. Der Ressourcen-Bereich der Plattform zieht aus dem Lesson-Bestand neue Formate mit eigenen Schnitten. Flipbooks bündeln Inhalte aus mehreren Lessons zu kompakten Heften zum Durchblättern, aktuell fünf Stück, jedes mit einem eigenen Themencluster quer durch die Disziplinen. Podcasts tun dasselbe als Audio-Dialog mit zwei Stimmen, und zwar mit einer bewussten Redaktionsregel: Sie schneiden andere Cluster als die Flipbooks. Zweitverwertung heißt hier neu kombinieren, nicht wiederholen.

Auch hier gilt das Muster der ganzen Fabrik: einmal gebaute Pipelines, pro Stück nur noch Betrieb. Die Podcast-Produktion läuft über ein eigenes Skript (pnpm podcast:audio): Multi-Speaker-TTS mit zwei Stimmen, gerendert pro Gesprächsteil einzeln, weil die Stimmqualität über längere Strecken driftet, mit Pausen zusammengefügt und als MP3 exportiert. Danach schreibt das Skript Laufzeit und Kapitelmarken in die Episoden-Datei zurück, damit Player und Karten echte Zeiten zeigen. Jede Episode dokumentiert ihre Quellen selbst:

Zwei Checks, bevor die Produktion wirklich endet

1. Lernpfad-Zuordnung: Die Plattform führt sieben geführte Lernpfade als eigene Dateien mit Ziel, Rolle, Lernergebnissen und einer geordneten Lesson-Liste. Jede neue Lesson wird geprüft: Gehört sie in einen Pfad, an welche Stelle, und braucht sie einen Vorgänger? Diese Lesson ist Kandidatin für den Pfad „Mit KI bauen“.
2. LinkedIn-Teaser: Noch während der Produktion werden Teaser-Ideen vorgedacht und als Content-Idee in den Vault zurückgeschrieben, dorthin, wo der LinkedIn-Betrieb plant und terminiert. Der Kreis schließt sich: Die Fabrik liest nicht nur aus der Autorität, sie schreibt in sie zurück.

Der Zeitstrahl aus Schritt 6 hat eine ökonomische Pointe: Alles Teure passiert genau einmal, alles Häufige ist günstig. Die zwei Prompts vom Anfang sind kein Trick, sondern das Ergebnis dieser Verteilung. Dieselbe Rechnung, als Tabelle:

Die sieben Regeln der Strecke, gesammelt:

1. Regel 1: Ein kurzer Prompt ist das Ergebnis eines langen Kontexts. Investiere in die Dateien, die automatisch mitladen.
2. Regel 2: Automatisierung ist nur so gut wie das kuratierte Wissen dahinter.
3. Regel 3: Gib dem System ein hartes Schema statt einer weichen Formatbitte.
4. Regel 4: Triff Modell-Entscheidungen einmal, dokumentiert und begründet, und ersetze Geschmack durch Zahlen mit Zielband.
5. Regel 5: Multimodalität heißt eine Quelldatei mit mehreren Ausspielungen, jede mit eigener, einmal gebauter Pipeline.
6. Regel 6: Reduziere menschliche Eingriffe auf wenige, scharfe Punkte und automatisiere die Strecke, nie das Urteil.
7. Regel 7: Plane die Zweitverwertung als eigene Station: neue Cluster, unterschiedliche Schnitte, Ideen fließen an den Planungsort zurück.

Zum Schluss die Einordnung, die diese Lesson auch zu einem Referenzstück macht: Diese Fabrik ist ein Ein-Personen-Projekt und produziert Lessons, Blog-Artikel, Audio-Versionen, Bilder und deren Deployment als einen durchgehenden, qualitätsgesicherten Prozess. Die Bausteine zum Selberbauen liegen in Agent Skills bauen und Agent-ready Codebase.