Fallstudie: Ein Journal, das zweimal pro Woche einen geprüften Beitrag erhält

Dieses Journal wird von einer Pipeline geschrieben, die wir für den eigenen Betrieb gebaut haben. Wir beschreiben sie als Fallstudie, weil sie zeigt, wie wir Automatisierung verstehen: Die Maschine übernimmt den wiederkehrenden Teil, Regeln im Code halten sie innerhalb dessen, was wir behaupten dürfen, und ein Mensch steuert die Themen und greift bei Fehlern ein.

Das Problem

Ein Studio mit einer Person hat keine Zeit für zwei Fachbeiträge pro Woche in zwei Sprachen. Ohne Beiträge bleibt das Journal leer, und die Fachseiten verlieren den Anschluss an die Fragen, die Betriebe stellen. Beiträge, die ein Modell unbeaufsichtigt schreibt, bringen ein anderes Problem: erfundene Zahlen, Preisversprechen und Beispiele, die wie echte Kundenprojekte klingen.

Was die Pipeline tut

1. Eine Themenliste im Repository hält 67 Themen in vier Fachbereichen, jedes mit Suchbegriff und Absicht. Die Inhaberin pflegt diese Liste; die Maschine wählt daraus.
2. Montag und Donnerstag früh startet ein Lauf auf GitHub Actions. Er wählt ein Thema, das noch nicht in Arbeit ist, und lässt ein Claude-Modell von Anthropic den Beitrag schreiben, Deutsch und Englisch in getrennten Aufrufen.
3. Jeder Entwurf durchläuft eine Prüfung mit festen Regeln: keine Preisangaben, keine Zusagen über Ergebnisse, keine Prozentzahlen, kein Rechenbeispiel ohne Kennzeichnung als Annahme, eine Obergrenze für Gedankenstriche, keine Füllwörter, Pflichtlinks zur passenden Fachseite und zur Kontaktseite. Fällt ein Entwurf durch, bekommt das Modell die Begründung und schreibt neu.
4. Ein Foto kommt von Pexels, wird heruntergeladen und mit dem Beitrag abgelegt. Der Browser des Lesers ruft keinen fremden Server auf.
5. Der Beitrag wird als Pull Request eröffnet. Ein zweiter Lauf wartet, bis die normale Prüfung der Website grün ist (Tests, Build, Oberflächentests), und veröffentlicht dann. Schlägt etwas fehl, entsteht ein Ticket statt eines stillen Ausfalls.

Entscheidungen

• Veröffentlicht wird nur über Pull Request und die bestehende Prüfung der Website, nie direkt.
• Die Prüfregeln stehen im Code, nicht in einer Anweisung an das Modell. Eine Regel im Prompt kann übergangen werden; eine Regel, die den Build stoppt, nicht.
• Die Liste der Füllwörter und die Obergrenze für Gedankenstriche stehen an einer Stelle, die Prompt, Prüfung und Korrektur gemeinsam lesen. Vorher drifteten drei Kopien auseinander, und das Modell wurde an Regeln gemessen, die es nie bekommen hatte.
• Jeder Beitrag endet mit dem Angebot, das zum Thema passt. Welches das ist, legt die Themenliste fest, nicht das Modell.

Was seit dem Start entstanden ist

Stand Oktober 2026 sind 23 Beiträge in vier Kategorien veröffentlicht, jeder in beiden Sprachen. Die Skripte der Pipeline haben eigene Tests, die bei jeder Änderung an der Website laufen.

Was das für Ihren Betrieb bedeutet

Angenommen, Sie führen eine Steuerberatungskanzlei und wollen Ihren Mandanten jeden Monat eine verständliche Information zu Fristen und Änderungen schicken. Die Bausteine sind dieselben: eine Themenliste, die Sie steuern, ein Modell, das entwirft, Prüfregeln, die festlegen, was nicht behauptet werden darf, und eine Freigabe, bevor etwas hinausgeht. Wie wir solche Abläufe bauen, steht unter Apps & Automatisierung. Zeigen Sie uns Ihren heutigen Ablauf im Erstgespräch.