Ich bin Ming. Neben Produktdesign bei vm0 gehört auch unsere Content-Arbeit zu meinen Aufgaben, und es hat sich herausgestellt, dass da deutlich mehr drin steckt, als ich dachte: Workflow-Design, Illustrationen, Bildproduktion, CMS-Arbeit, Übersetzungen. So bekomme ich das Schritt für Schritt geregelt.
Content gehört zu den Sachen, die ich hier mache
Den Großteil meines Tages bei vm0 verbringe ich zwischen Produktdesign und unserer Next.js-Codebase. Aber unsere Content-Arbeit liegt auch auf meinem Tisch, und als ich angefangen habe, ist mir aufgegangen, wie viel da tatsächlich dranhängt. Ein Blog, der performt, braucht konstanten Output, echte Keyword-Recherche, markenkohärente Visuals, anständige Meta-Descriptions und Übersetzungen in die vier Sprachen, die wir unterstützen.
Als ich das ernsthaft angefangen habe, hat jeder Beitrag fast einen ganzen Tag gekostet. Das eigentliche Schreiben war nur ein kleines Stück davon. Der Rest ging in die Produktion drumherum: die richtigen Keywords finden, Cover-Art machen, Felder im CMS richtig setzen, das alles für jede Locale wiederholen.
Also habe ich Schritt für Schritt so viel von dieser Pipeline wie möglich an Lucas übergeben, einen AI Marketing Agent, den ich auf Zero rund um meine eigene Alltagsarbeit gebaut habe. Er ist als „Marketing Manager" konfiguriert, und sein Scope ist alles Marketing-Bezogene: die Blog-Produktion ist heute der am stärksten ausgebaute Teil, und er wächst weiter, je mehr Skills und Connectors ich ergänze.
Aktuell hat Lucas Zugriff auf unser Strapi Headless-CMS, unser Ahrefs-Konto, unser Team-Slack, unseren Web-Chat, einen internen draw-Skill für markenkonsistente Illustrationen, dazu den standardmäßigen copywriting-Skill für die Schreibmechanik.
Im Folgenden gehe ich durch, wie diese AI Blog Automation in der Praxis funktioniert: wie Lucas einen vagen Prompt nimmt, daraus Thema und Keywords ableitet, einen Beitrag entwirft, ein Cover zeichnet, den Text durch eine naturalistische Übersetzung schickt und vier Locale-Drafts in unserem Headless-CMS landet. Danach schreibe ich darüber, wie ich dahin gekommen bin und was ich bewusst Menschen überlasse (immer noch hauptsächlich mir selbst).
Wie ich Lucas nutze: Web-App und Slack
Mit Lucas arbeite ich hauptsächlich über vm0s Web-Chat. Das ist das Deep-Work-Interface, in dem ich mit ihm durch Outlines, Drafts, Cover-Iterationen und Edits sitze. Lange Threads, langer Kontext, die Art Hin und Her, die in einem Chat-Channel unhandlich wäre.
Lucas ist außerdem in unser Team-Slack eingebunden, als geteilter Einstiegspunkt. Schnelle Prompts werfe ich dort vom Handy aus rein, und der Rest des Teams kann ihn ebenfalls anpingen. Wer in der Blog-Rotation dran ist, startet einen Beitrag auf die gleiche Weise. Derselbe Agent, derselbe Kontext über beide Interfaces hinweg.
Wie ein typischer Prompt aussieht
Meine Prompts an Lucas sind meistens kurz. Maximal drei Sätze. Ein repräsentativer:
Lucas, write a tutorial on running effective weekly meetings: cover meeting structure, common pitfalls, and how to keep remote teams engaged. Tutorial style, SEO-friendly, end with a CTA to use Zero. Draft link only, don't publish.
Das ist die ganze Brief. Eine Nachricht. Keine Outline, keine Keyword-Liste, kein Design-Briefing, kein Längenziel. Lucas übernimmt von dort aus.
Es hat eine Weile gedauert, bis ich auf dieses Format gekommen bin. Anfangs habe ich viel längere Briefs geschrieben, weil ich annahm, der Agent bräuchte alles ausbuchstabiert, und dann gemerkt, dass der meiste Kontext in seine Standing Instructions und Skills gehört, nicht in jeden einzelnen Prompt. Der Prompt ist der Trigger; den Rest trägt die Konfiguration.
Wie Lucas Thema und Keywords analysiert
Lucas' erster Schritt ist, aus dem Prompt Struktur zu extrahieren. Bei einer Anfrage wie der obigen sehen seine Arbeitsnotizen so aus:
- Thema: effektive wöchentliche Meetings führen
- Format: Tutorial → nummerierte Schritte, konkrete Beispiele, „mach das"-Sprache
- Implizite Zielgruppe: Team-Leads, Remote-Manager, Founders
- Pflicht-Sektionen: Meeting-Struktur, häufige Fehler, Remote-Engagement
- CTA: Leser zu Zero führen
- Constraint: nur Draft-URL, nicht published
Dann wählt er das Keyword. Das ist der Teil von Content Marketing, für den ich am Anfang am wenigsten Intuition hatte, also habe ich Lucas eine Routine gegeben, die er durchläuft, wenn ich ihn auf Keyword-Arbeit ansetze. Kein autonomer Skill, sondern eine Sequenz, der ich vertraue:
- Kandidaten aus Ahrefs ziehen. Er ruft die Ahrefs-API auf der Topic-Phrase auf und bekommt Long-Tail-Varianten mit monatlichem Volumen, Keyword Difficulty (KD), Parent Topic und SERP-Intent.
- Nach Difficulty filtern. Ich habe ihm eine harte Regel gegeben: KD < 30. vm0 ist eine relativ junge Domain mit begrenzter Authority, KD-60+-Keywords zu jagen ergibt für uns noch keinen Sinn. Long-Tail gewinnt früh.
- Mit unserem Strapi-Index abgleichen. Er zieht jede published Slug über die Strapi-REST-API und entfernt jedes Keyword, das wir schon abdecken. Keine Kannibalisierung.
- Intent zu Produkt-Fit matchen. Der Intent eines Keywords muss zu unserer Use-Case-Library passen. „How to run effective weekly meetings" → Operations / Team Management → passt. „Best ramen in Tokyo" → passt nicht, egal wie hoch das Volumen ist.
- Eines auswählen. Aus der gefilterten Liste wählt er die volumenstärkste Option und macht sie zum Rückgrat des Beitrags. Zum Beispiel remote weekly meeting best practices.
Für On-Page-SEO hält er sich an eine simple Heuristik: Ziel-Keyword im Titel, in mindestens einer H2 und in den ersten 100 Wörtern. Synonyme und verwandte Phrasen organisch eingewoben. Interne Links auf zwei oder drei verwandte Beiträge, wo es passt. Danach: natürlich schreiben, kein Keyword-Stuffing.
Den Rest der Struktur (sechs oder sieben H2s, eine „Tipp"-Callout pro Schritt, ein CTA am Schluss) habe ich ihm anhand von Beispielen aus früheren Beiträgen beigebracht.
Wie das Cover gezeichnet wird
Das Cover ist der Teil der Blog-Produktion, der mir am wichtigsten ist, teils, weil ich Designer bin, und teils, weil es das Erste ist, was Leser sehen, bevor sie überhaupt ein Wort lesen. Es ist auch das Open-Graph-Bild, wenn Beiträge auf X oder LinkedIn geteilt werden, und es ist das, was unseren Blog-Index nach Publikation aussehen lässt statt nach einer Wand aus Stockfotos.
Stockfotos waren für den Look, den ich wollte, keine Option, und einzeln Illustrationen zu briefen hätte die Produktionskosten pro Beitrag unhaltbar gemacht. Also habe ich einen Zero-Skill namens draw gebaut. Ein 200-zeiliges Python-Skript, das fünf Dinge tut:
- Nimmt zwei Inputs entgegen: eine Metapher (was zu skizzieren ist) und eine Farbe (Bezeichnung plus Hex-Anker).
- Trägt beides in eine feste Prompt-Vorlage ein, die den Rest der Komposition fixiert: warm-grauer Hintergrund
#eeeeee, Aquarell-Blob zentriert in der gewählten Farbe, handgezeichnete Tinten-Skizze obendrauf, vm0-Logo bei (25, 25) oben links. - Schickt den fertigen Prompt an fal.ais
nano-banana-pro-Modell im Format 16:9. - Lädt das PNG herunter. Normalisiert nahezu-weiße Pixel zurück auf exakt
#eeeeee, damit der Hintergrund nicht driftet. Skaliert auf 1600×900 hoch. Komponiert das transparente vm0-Logo per Alpha-Compositing on top. - Lädt das Ergebnis auf vm0s CDN und gibt die URL aus.
Ein typischer Aufruf sieht so aus:
python draw.py \
--metaphor "a tilted hourglass with sand draining into a small open notebook, a sparkle near the rim" \
--color-name "dusty rose" \
--color-hex "#e08b96" \
--upload
Zwei Inputs, und der Rest der Marke bleibt von Beitrag zu Beitrag konsistent. Ich wähle die Farbe meist passend zum Thema des Beitrags. Coral oder Sage für wärmere Tutorial-Beiträge, Blau oder Lavendel für technischere, Senfgelb für Announcements. Ein paar wiederkehrende Farben verwandeln den Blog-Index langsam in eine erkennbare Palette.
Was ich auf die harte Tour gelernt habe: die Hebelwirkung liegt nicht im Modell. Sie liegt in der Vorlage. Wenn das Modell Komposition, Palette und Layout frei wählen darf, sieht jedes Cover wie eine andere Marke aus. Das festzunageln und nur die Metapher dem Modell zu überlassen, hält den Look von Beitrag zu Beitrag kohärent.
Es gibt einen Geschwister-Skill namens illustration für Spot-Art im Beitrag selbst (die kleineren Zeichnungen zwischen den Sektionen dieses Beitrags). Gleiche Idee: fester Stil, nur Metapher und Farbe variieren. Nur auf quadratische 1024×1024-Art statt 16:9-Cover zugeschnitten.
Eine kurze Anmerkung zu Bild-SEO: Dasselbe Cover wird als Open-Graph- und Twitter-Card-Asset des Beitrags eingebunden, sodass Social Shares es sauber aufnehmen. Strapi erzeugt beim Upload automatisch vier vorab skalierte Varianten (Thumbnail, Small, Medium, Large). Die Artikel-Bilder im Body laden allerdings noch als plain <img> statt über srcset, das steht als kleiner Frontend-TODO an. Die Inline-Illustrationen bekommen beschreibenden Alt-Text in den Markdown geschrieben, wenn Lucas sie einbettet; das alternativeText-Feld am Cover selbst muss ich in Strapi noch nachpflegen.
Wie der Beitrag selbst geschrieben wird
Sobald Thema, Keyword und Cover stehen, ist das Drafting weitgehend mechanisch. Lucas:
- Macht zuerst eine Outline. Sechs oder sieben H2s, jede mit einem klaren Job: Problem-Framing, Schritt-für-Schritt-Anleitung, „Tipp"-Callouts, Recap, CTA.
- Schreibt jede H2 aus mit dem
copywriting-Skill. Die Stimme (kurze Sätze, konkrete Beispiele, zweite Person, wo es passt, gelegentlich trockener Humor) kommt aus Regeln, die ich in Lucas' Standing Instructions halte, nicht aus dem Skill selbst. - Setzt unter jeden Schritt eine praktische „Tipp"-Callout. Bei Tutorials sinnvoll, weil die meisten Leser scannen und die Callouts ihnen einen Pfad durch langen Content geben.
- Schreibt das
description-Feld des Beitrags. Strapi limitiert auf 80 Zeichen, also bleibt es kurz und liest sich wie von Hand geschrieben. Es wird als Untertitel und als OG/Twitter-Card-Description verwendet. - Schließt mit einem CTA, der das Produkt benennt und auf einen kostenlosen Workspace verlinkt.
Ein erster Draft kommt meist zwei bis drei Minuten nach dem Prompt zurück. Ich lese, bitte um Ton-Anpassungen, wenn die Stimme nicht passt, und Lucas iteriert, bis es sitzt. Der erste Draft ist selten ship-fertig. Meistens ziemlich nah dran, aber doch ein bisschen daneben, und genau dort verbringe ich den Großteil meiner Review-Zeit.
Wie der Draft in Strapi landet
Wir nutzen Strapi als Headless-CMS. Der articles-Content-Type hat ein cover (Media), author und category (Relations), locale (String) und eine blocks-Dynamic-Zone, in der der Body als Markdown lebt.
Lucas' CMS-Sync-Ablauf:
- Cover-PNG an
/api/uploadPOSTen. Die zurückgeliefertedocumentIdaufheben. - POST an
/api/articles?status=draftmit Title, Description (≤80 Zeichen; Strapi erzwingt das), Slug, Locale, den Cover/Author/Category-Relations als numerische IDs und einem einzelnenshared.rich-text-Block mit dem Markdown-Body. - Wichtig:
publishedAtweglassen. Strapi behandelt null als Draft-State. - Eine Preview-URL nach vm0s Draft-Pattern zurückgeben:
https://www.vm0.ai/{locale}/blog/posts/{slug}?status=draft.
Hinweis zu Strapi v5: Die öffentliche REST-API kann publishedAt bei bestimmten Content-Types überschreiben, was bedeutet, dass ein über die API erzeugter „Draft" stillschweigend live gehen kann. Der Fix ist eine kleine DB-Migration, die das Feld bei Draft-Writes wieder entfernt.
Auch die Slug-Strategie ist SEO-relevant. Wir verwenden eine einzige kanonische Slug über alle vier Locales hinweg, statt sie zu übersetzen. Eine Leserin auf /de/blog/posts/remote-weekly-meeting-best-practices sieht dieselbe URL-Struktur wie auf /en, und unser Backlink-Profil zerfasert nicht über übersetzte URLs. hreflang-Link-Tags aus diesen Locale-Relationen auszugeben ist ein kleiner Frontend-TODO. Wir liefern sie noch nicht aus.
Wie i18n-Übersetzung funktioniert
vm0 läuft in vier Locales: Englisch, Deutsch, Japanisch, Spanisch. Wir jagen Beiträge nicht durch Google Translate. Der billige Weg zerstört die Stimme, der richtige Weg adaptiert Idiome.
Lucas legt zuerst den EN-Draft an, merkt sich die zurückgelieferte documentId und schickt dann drei Folge-Calls PUT /api/articles/{documentId}?locale=de (sowie ?locale=ja, ?locale=es) mit naturalistisch übersetzten Payloads hinterher. Strapi behandelt das als Locale-Varianten desselben kanonischen Dokuments, was die vier Versionen im Admin und im Frontend-Locale-Switcher verlinkt hält.
Übersetzungs-Regeln, die ich ihm gegeben habe, meist daraus entstanden, dass mir falsche Outputs auffielen und ich korrigiert habe:
- Keine Fachbegriffe übersetzen, die in der Zielsprache schon englische Lehnwörter sind. „API", „CMS", „Agent" und „Prompt" bleiben in JA und DE auf Englisch. Übersetzt fühlt sich das in beiden Sprachen daneben an.
- Idiome naturalistisch adaptieren. Eine wörtliche Übersetzung von „kills your Friday" ist auf Deutsch Kauderwelsch; eine native Version derselben Metapher landet.
- CTAs pro Locale anpassen. Imperative wirken im DE pushiger, also mildere ich sie ab; die JA-Version weicht meist zu einer höflichen Einladung auf.
- Titel auf Länge re-tunen. Deutsche Titel laufen meist ~30 Prozent länger als ihre englischen Pendants. Japanische Titel sind meist kürzer. Lucas sorgt dafür, dass Titel pro Locale unter dem 60-Zeichen-SERP-Truncation-Limit bleiben.
Multilingual Content Publishing war der Teil des Workflows, der früher die meiste Zeit gefressen hat. Jetzt ist es einfach der letzte Schritt im selben Agent-Run.
Was nicht automatisiert wird
Ein kurzer, wichtiger Abschnitt. Nicht alles in diesem Workflow ist automatisiert, und zwar mit Absicht:
- Themenwahl auf strategischer Ebene. Lucas wählt Keywords innerhalb eines Themas, aber das Thema selbst kommt von mir, meist aus Produkt-Launches, Kundengesprächen oder Roadmap-Verschiebungen.
- Finaler Editorial-Pass. Ich lese jeden Draft, bevor er live geht. Vor allem die EN-Version. Ton, Genauigkeit technischer Aussagen, Verweise auf internen Produkt-Kontext brauchen alle ein menschliches Auge.
- Native Review für Sprachen, die ich nicht fließend lese. Ich lese kein flüssiges Deutsch. Der DE-Draft geht für einen letzten Pass an einen Native Reviewer.
- Promotion. Posten auf X, an Subscriber schicken, in Communities teilen werden (noch) manuell erledigt.
Es geht nicht darum, mich aus der Schleife zu nehmen. Es geht darum, mich aus den Teilen der Schleife zu nehmen, die mich nicht wirklich brauchen.
Wie ich auf diesen Workflow gekommen bin
Ich habe das nicht an einem Wochenende durchgeplant. Es hat sich Beitrag für Beitrag angesammelt, indem ich gemerkt habe, welche Schritte mir die Zeit gefressen haben.
Was ich gemerkt habe: die automatisierungswürdigen Teile waren nicht die kreativen. Es waren die verbindenden: die Keyword-Pulls, die Cover-Renderings, die Upload-Calls, der Locale-Fan-Out, das Formatieren der Preview-URL. Wenn ich ehrlich getrackt habe, ging mehr Zeit in Logistik als ins eigentliche Schreiben.
Also habe ich die Logistik nach und nach an den Agent übergeben. Das Modell schreibt; der Agent erledigt das Hin- und Hergeschiebe. Ich entscheide weiterhin, worüber geschrieben wird und wie es klingen soll, bin nur nicht mehr derjenige, der die Teile zusammenheftet.
Für mich endete Content Automation in der Praxis nicht mit „die KI schreibt den Blog". Sondern mit „die KI erledigt alles drumherum, sodass ich Zeit habe, das Schreiben tatsächlich zu lesen".
Wenn du etwas Ähnliches probieren möchtest
Wenn du in einer ähnlichen Lage bist, mehr Hüte aufhast als dir lieb ist, und Content einer davon ist, ist das meiste hiervon reproduzierbar:
- Eine Agent-Plattform, auf der du dem Agent eine permanente Rolle und Skills geben kannst (wir nutzen Zero, dort lebt Lucas).
- Connectors zu deinen bestehenden Tools: dein CMS, dein Keyword-Tool, dein Bildgenerator, dein Slack.
- Eine kleine Sammlung von Skills, auf deine Marke zugeschnitten (bei uns
drawfür Cover undcopywritingfür den Tonfall). - Standing Instructions, die Kontext tragen, damit Prompts kurz bleiben können.
Kostenlosen Zero-Workspace starten →
Oder wenn du dir lieber erst mehr Agent-Workflows ansehen willst: Unsere Use-Case-Library hat 19 fertige Automationen für Engineering, Product, Marketing und Operations.
Wenn du Lucas konkret klonen möchtest: Agent anlegen, Rolle Marketing Manager setzen, Strapi (oder dein CMS) + Ahrefs + ein Bild-Tool connecten, einen draw-Skill nach unserem Modell hinzufügen und einen copywriting-Skill, der deine Brand Voice einfängt. Den Rest leitet er aus deinem ersten Prompt ab.
