1. Ziel und Rahmen
Social Media ist für viele kleine Verlage ein notwendiges, aber wenig geliebtes Werkzeug. Sichtbarkeit entsteht heute nicht mehr allein über den Shop, die ISBN, die Verfügbarkeit bei Distributoren oder eine gut gepflegte Website. Bücher, Verlagsarbeit und fachliche Positionierung müssen regelmäßig sichtbar werden.
Das Problem: Regelmäßigkeit kostet Zeit. Und Social Media belohnt nicht unbedingt Qualität, sondern Wiederholung, Reaktion und Präsenz.
Für einen kleinen Verlag ist das ein schlechter Tausch: Jeden Tag manuell Beiträge formulieren, Plattformen öffnen, Texte anpassen, Bilder hochladen, Kommentare prüfen und Antworten schreiben – das ist operativer Kleinkram, der von der eigentlichen Arbeit ablenkt.
Dieses Handbuch beschreibt deshalb keinen Social-Media-Bot im primitiven Sinn. Es beschreibt ein technisches Assistenzsystem, das wiederkehrende Social-Media-Arbeit automatisiert, strukturiert und kontrollierbar macht.
Der Kern ist einfach:
Python erzeugt und steuert den Ablauf.
OpenAI erzeugt und prüft Texte.
Playwright bedient die Plattformen im Browser.
Der Verlag behält Kontrolle, Regeln und Verantwortung.
1.1 Zweck des Systems
Das System soll Social-Media-Arbeit für einen Verlag reproduzierbar machen.
Es geht nicht darum, möglichst viele Aktionen auszuführen. Es geht darum, die ohnehin sinnvollen Tätigkeiten eines Verlags technisch zu unterstützen:
Beiträge vorbereiten
Beiträge variieren
Beiträge prüfen
Beiträge planen
Beiträge veröffentlichen
Reaktionen erfassen
Antworten vorschlagen
Ergebnisse protokollieren
Für einen Verlag sind besonders geeignet:
Buchvorstellungen
Klassiker-Zitate
Hinweise auf gemeinfreie Werke
Einblicke in die Verlagsarbeit
Blogartikel-Zusammenfassungen
technische Werkstattberichte
Hinweise auf Neuerscheinungen
Antworten auf sachliche Rückfragen
Das System soll vor allem drei Dinge leisten:
Zeit sparen
Qualität stabilisieren
Regelmäßigkeit erzwingen
Ohne Automatisierung entsteht Social Media oft zufällig: Mal wird mehrere Tage nichts veröffentlicht, dann mehrere Beiträge auf einmal. Mal ist der Ton sachlich, mal werblich, mal zu lang, mal zu belanglos.
Ein automatisiertes System zwingt zur Struktur:
Welche Themen gibt es?
Welche Plattform bekommt welchen Text?
Welche Beiträge sind bereits veröffentlicht?
Welche Inhalte wiederholen sich?
Welche Beiträge dürfen automatisch erscheinen?
Welche brauchen Freigabe?
Damit wird Social Media nicht angenehmer, aber beherrschbarer.
1.2 Abgrenzung: Assistenzsystem statt Bot-Farm
Das System ist ausdrücklich kein Werkzeug für Spam, Reichweitenmanipulation oder massenhafte Interaktion.
Nicht Ziel des Systems:
automatisches Massen-Liken
automatisches Massen-Kommentieren
automatisches Folgen und Entfolgen
mehrere Fake-Accounts
Umgehung von Plattformschutz
CAPTCHA-Umgehung
zufällige Menschensimulation
gekaufte Reichweite
synthetische Diskussionen
Solche Mechaniken sind technisch möglich, aber strategisch unsinnig. Sie beschädigen die Seriosität eines Verlags und erhöhen das Risiko von Sperren.
Das System arbeitet nach einer anderen Logik:
Eigene Inhalte dürfen stark automatisiert werden.
Fremde Interaktion bleibt eng begrenzt.
Kommentare brauchen konkreten Bezug.
Verkaufsdruck wird vermieden.
Jede Aktion wird protokolliert.
Bei ungewöhnlichen Plattformreaktionen wird gestoppt.
Der richtige Vergleich ist nicht:
Bot ersetzt Mensch.
Sondern:
Assistenzsystem ersetzt wiederkehrende Handarbeit.
Ein Verlag würde auch manuell nicht hundert beliebige Beiträge am Tag kommentieren. Also darf es die Maschine ebenfalls nicht tun.
Eine brauchbare Grundregel lautet:
Die Maschine darf nur tun, was auch als manuelle Handlung plausibel, vertretbar und geschäftlich sinnvoll wäre.
1.3 Unterstützte Plattformen
Das System kann grundsätzlich jede Plattform bedienen, die im Browser nutzbar ist. Für ein pragmatisches Verlagssystem reichen zunächst wenige Kanäle.
Sinnvoll sind vor allem:
LinkedIn
Instagram
Facebook
eigener Blog
eigener Newsletter
LinkedIn eignet sich für die fachliche Verlegerperspektive:
Verlagsautomatisierung
KI in der Buchproduktion
E-Book-Workflows
Public Domain
digitale Distribution
Selbstständigkeit
Ein-Mann-Verlag
Backend- und Produktionsprozesse
LinkedIn ist weniger geeignet für bloße Buchwerbung. Besser funktionieren Beiträge, die eine fachliche Beobachtung enthalten.
Beispiel:
Warum gemeinfreie Literatur trotzdem verlegerische Arbeit macht
Oder:
Wie ein kleiner Verlag mit Automatisierung gegen operative Überlastung arbeitet
Instagram eignet sich für visuelle Formate:
Covermotive
Zitatkarten
Buchästhetik
Klassiker-Reihen
Autorenporträts
historische Stimmungen
kurze Leseimpulse
Da Instagram bildorientiert ist, benötigt das System hier zusätzlich eine Bildpipeline.
Minimal reicht:
Bilddatei
Caption
Hashtags
Alt-Text
Posting-Zeitpunkt
Facebook kann für ältere Lesergruppen, bestehende Kunden und allgemeine Buchhinweise weiterhin brauchbar sein.
Geeignete Inhalte:
Neuerscheinungen
Sonderaktionen
Klassiker-Hinweise
Shoplinks
längere erklärende Beiträge
Antworten auf Kundenfragen
Facebook muss nicht im Zentrum stehen, kann aber als Zweitverwertungskanal sinnvoll sein.
Eigener Blog
Der Blog ist der wichtigste eigene Kanal.
Social Media sollte nicht als endgültiger Veröffentlichungsort gedacht werden, sondern als Verteiler.
Die bessere Struktur lautet:
ausführlicher Inhalt im Blog
kurze Varianten für Social Media
Rückverweis auf den Blog
Archivierung auf eigener Domain
Der Blog ist unabhängig von Plattformregeln, Algorithmusänderungen und Account-Sperren.
Newsletter
Der Newsletter ist kein klassischer Social-Media-Kanal, gehört aber in dieselbe Content-Pipeline.
Ein Blogartikel kann automatisch Varianten erzeugen für:
LinkedIn-Beitrag
Facebook-Beitrag
Instagram-Caption
Newsletter-Absatz
Kurzmeldung im Shop
Dadurch entsteht aus einem Inhalt mehrfach verwertbarer Content.
1.4 Manuelle, halbautomatische und automatische Workflows
Nicht jeder Arbeitsschritt sollte denselben Automatisierungsgrad haben. Das System unterscheidet drei Betriebsarten.
Manueller Workflow
Beim manuellen Workflow erzeugt das System nur Vorlagen.
Geeignet für:
neue Plattformen
heikle Themen
Kommentare auf fremde Beiträge
Antworten auf Kundenbeschwerden
juristische oder politische Themen
ungeprüfte KI-Ausgaben
Ablauf:
System erzeugt Entwurf.
System speichert Entwurf in Review-Queue.
Mensch prüft.
Mensch bearbeitet.
Mensch veröffentlicht oder gibt frei.
Dieser Modus ist langsam, aber sicher.
Halbautomatischer Workflow
Beim halbautomatischen Workflow erzeugt das System Inhalte und bereitet die Veröffentlichung vor. Die Freigabe erfolgt manuell oder nach einfachen Regeln.
Geeignet für:
Buchvorstellungen
Blogartikel-Zusammenfassungen
Verlagswerkstatt
LinkedIn-Beiträge
längere Facebook-Beiträge
Antwortvorschläge
Ablauf:
System erzeugt Beitrag.
Quality-Gate prüft Beitrag.
Beitrag landet in Freigabe-Queue.
Freigabe erfolgt per CLI.
Playwright veröffentlicht den Beitrag.
System speichert Screenshot und Log.
Das ist für den Produktivbetrieb meist der beste Modus.
Automatischer Workflow
Beim automatischen Workflow darf das System ohne Einzelprüfung veröffentlichen.
Geeignet nur für robuste, wiederkehrende Formate:
Klassiker-Zitat
Hinweis auf vorhandenen Blogartikel
Buch des Tages
geplante Neuerscheinung
Zitatkarte
wiederkehrender Werkstatt-Hinweis
Ablauf:
System wählt freigegebenes Format.
System erzeugt Beitrag nach Template.
Quality-Gate prüft harte Regeln.
System veröffentlicht im geplanten Zeitfenster.
System protokolliert Ergebnis.
Automatisch heißt nicht unkontrolliert. Auch automatische Beiträge brauchen:
Limits
Logging
Stop-Regeln
Dublettenprüfung
Zeitfenster
Fehlerbehandlung
Eine sinnvolle Aufteilung:
Eigene Beiträge: halbautomatisch bis automatisch
Eigene Kommentarantworten: halbautomatisch
Fremde Kommentare: manuell oder stark begrenzt halbautomatisch
Likes: stark limitiert
Follows: nicht automatisieren
1.5 Technische Grundannahmen
Das System wird als schlanke Python-Anwendung aufgebaut.
Die Grundannahmen:
Python 3.11 oder neuer
Playwright für Browsersteuerung
OpenAI API für Texterzeugung und Textprüfung
SQLite oder JSON für den Einstieg
.env für Zugangsdaten und Konfiguration
Linux-Server für den späteren Betrieb
lokaler Entwicklungsbetrieb möglich
Keine API-Pflicht
Viele Plattformen bieten offizielle APIs, aber diese sind oft eingeschränkt, kompliziert oder für kleine Anwendungsfälle überdimensioniert.
Playwright steuert stattdessen den Browser. Das ist näher an der realen manuellen Nutzung.
Trotzdem gilt:
Keine Schutzmechanismen umgehen.
Keine CAPTCHAs automatisieren.
Keine Massenaktionen ausführen.
Bei Login-Problemen stoppen.
Bei Plattformwarnungen stoppen.
Persistente Browser-Session
Das System sollte Logins nicht ständig neu durchführen.
Stattdessen:
einmal manuell einloggen
Session speichern
Session wiederverwenden
bei Ablauf erneut manuell einloggen
Technisch geschieht das über Playwright Storage State oder ein persistentes Browserprofil.
Trennung von Generator und Publisher
Texterzeugung und Veröffentlichung dürfen nicht in einem einzigen Skript vermischt werden.
Besser:
generate_posts.py
review_queue.py
publish_posts.py
Damit kann ein Beitrag erzeugt, geprüft, bearbeitet, freigegeben und erst später veröffentlicht werden.
Dry-Run als Pflichtmodus
Jeder Publisher braucht einen Trockenlauf.
DRY_RUN=true
Im Dry-Run wird nichts veröffentlicht. Das System zeigt nur, was es tun würde.
Der Dry-Run ist Pflicht für:
neue Plattformadapter
geänderte Selektoren
neue Prompts
neue Beitragsformate
Serverumzug
Session-Erneuerung
Logging
Jede Aktion muss nachvollziehbar sein.
Mindestens speichern:
Zeitpunkt
Plattform
Aktion
Beitrags-ID
Text
Bildpfad
Status
Fehlermeldung
Screenshot-Pfad
OpenAI-Modell
Kostenindikator
Ohne Logging ist Automatisierung Blindflug.
Stop-Regeln
Das System braucht harte Abbruchbedingungen.
Beispiele:
Login-Seite erscheint unerwartet
CAPTCHA erscheint
Plattform zeigt Warnung
Post-Button wird nicht gefunden
Upload schlägt fehl
mehr als 2 Fehler hintereinander
Tageslimit erreicht
Textprüfung schlägt fehl
Bei solchen Ereignissen darf das System nicht weiterprobieren.
1.6 Projektstruktur
Eine einfache Projektstruktur reicht für den Anfang.
social-publisher/
├── .env
├── .env.example
├── config.yaml
├── requirements.txt
├── README.md
├── data/
│ ├── books.json
│ ├── topics.json
│ ├── drafts.json
│ ├── approved_posts.json
│ ├── published_posts.json
│ └── interaction_log.json
├── prompts/
│ ├── linkedin_post.txt
│ ├── instagram_caption.txt
│ ├── facebook_post.txt
│ ├── quality_check.txt
│ └── comment_suggestion.txt
├── src/
│ ├── main.py
│ ├── config.py
│ ├── openai_client.py
│ ├── content_generator.py
│ ├── quality_gate.py
│ ├── review_queue.py
│ ├── scheduler.py
│ ├── logger.py
│ ├── browser_session.py
│ ├── publisher.py
│ └── platforms/
│ ├── linkedin.py
│ ├── instagram.py
│ └── facebook.py
├── storage/
│ ├── sessions/
│ ├── screenshots/
│ ├── images/
│ └── logs/
└── tests/
├── test_quality_gate.py
├── test_content_generator.py
└── test_config.py
Die wichtigsten Bestandteile:
data/
Enthält Arbeitsdaten, Entwürfe, Freigaben und Protokolle.
prompts/
Enthält versionierbare Prompt-Templates.
src/
Enthält die Anwendung.
src/platforms/
Enthält die Plattformadapter. Jede Plattform bekommt eine eigene Datei.
storage/sessions/
Enthält gespeicherte Browser-Sessions.
storage/screenshots/
Enthält Belege nach Veröffentlichungen oder Fehlern.
storage/logs/
Enthält strukturierte Logs.
Minimaler Ablauf im Zielsystem
Der spätere Standardablauf sieht so aus:
1. Buchdaten oder Thema laden
2. Beitrag mit OpenAI erzeugen
3. Beitrag durch Quality-Gate prüfen
4. Entwurf speichern
5. Beitrag freigeben
6. Playwright öffnet Plattform
7. Beitrag wird eingetragen
8. Screenshot wird gespeichert
9. Status wird auf published gesetzt
10. Logeintrag wird geschrieben
Als Kommando könnte das später so aussehen:
python -m src.main generate --platform linkedin --type workshop
python -m src.main review
python -m src.main approve --id post_20260511_001
python -m src.main publish --id post_20260511_001
Oder im automatisierten Betrieb:
python -m src.main run-daily
Ergebnis dieses ersten Kapitels
Der Rahmen ist damit festgelegt:
Ein kleines, kontrolliertes Social-Media-System.
Python als Orchestrierung.
OpenAI als Text- und Prüfkomponente.
Playwright als Browser-Werkzeug.
Keine Massenautomatisierung.
Keine Bot-Farm.
Keine Plattformumgehung.
Starke Protokollierung.
Klare Trennung zwischen Entwurf, Freigabe und Veröffentlichung.
Damit ist die Grundlage für die eigentliche Implementierung gelegt.
0 Kommentare