Hur jag automatiserar vår bloggproduktion från början till slut

Jag är Ming. Förutom produktdesign på vm0 ansvarar jag även för vårt innehåll, och det visade sig vara mycket mer omfattande än jag trodde: arbetsflödesdesign, illustrationer, bildproduktion, CMS-arbete, översättningar. Så här har jag stegvis fått det gjort.

Innehåll är en av mina uppgifter här

Större delen av min dag på vm0 delas mellan produktdesign och vår Next.js-kodbas. Men att driva vårt innehåll ligger också på mitt bord, och när jag väl började insåg jag hur mycket som faktiskt krävs för en blogg som presterar. Du behöver konsekvent output, riktig sökordsanalys, varumärkesanpassade bilder, bra metabeskrivningar och översättningar till de fyra språk vi stödjer.

När jag började ta detta på allvar tog varje inlägg nästan en hel dag. Själva skrivandet visade sig vara en liten del av det. Det mesta av tiden gick åt till produktionsarbetet runt texten: hitta rätt sökord, skapa omslagsbild, fylla i rätt fält i CMS:et, göra om allt för varje språkversion.

Så jag har gradvis flyttat så mycket som möjligt av den processen till Lucas, en AI-marknadsföringsagent jag byggt i Zero utifrån mitt eget dagliga arbete. Han är konfigurerad som "Marketing manager" och hans område är allt som rör marknadsföring: bloggproduktion är den mest utbyggda delen idag, och han växer allt eftersom jag lägger till färdigheter och kopplingar.

Just nu har Lucas tillgång till vårt Strapi headless CMS, vårt Ahrefs-konto, vårt team-Slack, vår webbchatt, en intern draw-färdighet för varumärkesanpassade illustrationer samt standardfärdigheten copywriting för skrivmekanik.

Nedan går jag igenom hur denna AI-bloggautomation fungerar i praktiken: hur Lucas tar ett vagt prompt, bryter ner det till ämne och sökord, skriver ett utkast, ritar ett omslag, översätter texten naturligt och levererar fyra språkversioner som utkast i vårt headless CMS. Sedan berättar jag hur jag kom hit och vad jag medvetet lämnar till människor (fortfarande mest mig).

Hur jag använder Lucas: webbapp och Slack

Flera pratbubblor som samlas hos en enda AI-agent

Jag arbetar mest med Lucas via vm0:s webbchatt. Det är gränssnittet för fokuserat arbete där jag sitter med honom genom disposition, utkast, omslagsiterationer och redigeringar. Långa trådar, mycket kontext, den typ av fram-och-tillbaka som skulle vara klumpig i en chattkanal.

Lucas är också kopplad till vårt team-Slack, som en gemensam ingång. Jag skickar snabba prompts där från mobilen, och resten av teamet kan också kontakta honom. Den som har bloggansvaret startar ett inlägg på samma sätt. Samma agent, samma kontext i båda gränssnitten.

Hur ett typiskt prompt ser ut

Mina prompts till Lucas är oftast korta. Max tre meningar. Ett representativt exempel:

Lucas, skriv en handledning om att hålla effektiva veckomöten: ta upp mötesstruktur, vanliga fallgropar och hur man håller distansteam engagerade. Handledningsstil, SEO-vänlig, avsluta med en CTA för att använda Zero. Endast utkastlänk, publicera inte.

Det är hela briefen. Ett meddelande. Ingen disposition, ingen sökordslista, inget designbrief, inget längdmål. Lucas tar det därifrån.

Det tog ett tag innan jag landade i detta format. I början skrev jag mycket längre instruktioner eftersom jag trodde att agenten behövde allt specificerat, men insåg sedan att det mesta av kontexten hör hemma i hans stående instruktioner och färdigheter, inte i varje prompt. Prompten är en trigger; resten av konfigurationen bär vikten.

Hur Lucas analyserar ämne och sökord

En tratt som smalnar av från många sökordstaggar till ett valt sökord

Lucas första steg är att utvinna struktur ur ett vagt prompt. För en begäran som ovan ser hans arbetsanteckningar ut så här:

Ämne: hålla effektiva veckomöten
Format: handledning → numrerade steg, konkreta exempel, "gör så här"-språk
Implicerad målgrupp: teamledare, distanschefer, grundare
Obligatoriska avsnitt: mötesstruktur, vanliga fallgropar, distansengagemang
CTA: leda läsare till Zero
Begränsning: endast utkast-URL, ej publicerad

Sedan väljer han sökordet. Det här var den del av content marketing jag hade minst känsla för när jag började, så jag gav Lucas en rutin att följa varje gång jag ber honom om sökordsarbete. Det är ingen färdighet han kör autonomt, bara en sekvens jag litar på:

Hämta kandidater från Ahrefs. Han anropar Ahrefs API på ämnesfrasen och får tillbaka long-tail-varianter med månatlig sökvolym, sökordssvårighet (KD), huvudämne och SERP-intent.
Filtrera på svårighet. Jag gav honom en hård regel: KD < 30. vm0 är en relativt ny domän med begränsad auktoritet, så att jaga höga KD-sökord är inte aktuellt än. Long-tail vinner tidigt.
Korsreferera vårt Strapi-index. Han hämtar alla publicerade slugs från vårt CMS via Strapi REST API och tar bort sökord vi redan täcker. Ingen kannibalisering.
Matcha intent mot produktpassning. Ett sökords intent måste passa vårt användningsfall. "Hur man håller effektiva veckomöten" → drift / teamledning → passar. "Bästa ramen i Tokyo" → gör det inte, oavsett volym.
Välj ett. Från den filtrerade listan väljer han det med högst volym och använder det som ryggrad för inlägget. Till exempel remote weekly meeting best practices.

För on-page SEO använder han en enkel tumregel: målsökordet i titeln, i minst en H2 och bland de första 100 orden. Synonymer och relaterade fraser vävs in naturligt. Interna länkar till två eller tre relaterade inlägg där det passar. Efter det: skriv naturligt, ingen sökordsfyllning.

Strukturen på inlägget (sex eller sju H2:or, en "Tips:"-ruta under varje steg, en CTA i slutet) kommer från en handledningsmall jag byggt upp genom exempel över flera inlägg.

Hur omslaget ritas

Omslaget är den del av bloggproduktionen jag bryr mig mest om, dels för att jag är designer och dels för att det är vad läsaren ser innan de läser ett ord. Det är också Open Graph-bilden när inlägg delas på X eller LinkedIn, och det är det som får vårt bloggindex att se ut som en publikation istället för en vägg av stockfoton.

Stockfoton var inget alternativ för det utseende jag ville ha, och att beställa illustrationer en och en hade gjort produktionskostnaden per inlägg ohanterlig. Så jag byggde en Zero-färdighet kallad draw. Det är ett 200 rader långt Python-skript som gör fem saker:

Tar två indata: en metafor (vad som ska skissas) och en färg (ett vänligt namn plus en hexkod).
Stoppar dem i en fast promptmall som låser resten av kompositionen: varmgrå bakgrund #eeeeee, akvarellfläck centrerad på duken i vald färg, handritad bläckskiss ovanpå, vm0-logga vid (25, 25) uppe till vänster.
Skickar den sammansatta prompten till fal.ai:s nano-banana-pro-modell på 16:9.
Laddar ner PNG-filen. Normaliserar alla nästan vita pixlar till exakt #eeeeee så att bakgrunden aldrig driver iväg. Skalar upp till 1600×900. Alpha-kompositerar den transparenta vm0-loggan ovanpå.
Laddar upp resultatet till vm0:s CDN och skriver ut URL:en.

En typisk körning ser ut så här:

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

Två indata och resten av varumärket förblir konsekvent. Jag väljer oftast en färg som passar inläggets tema. Korall eller salvia för varmare handledningar, blått eller lavendel för mer tekniska, senapsgult för nyheter. Några återkommande färger gör så småningom bloggindexet till en igenkännbar palett.

Det jag lärde mig den hårda vägen är att hävstången inte ligger i modellen. Den ligger i mallen. Om modellen får välja komposition, palett och layout fritt ser varje omslag ut som ett annat varumärke. Att låsa dessa och bara låta den välja metaforen gör att utseendet hålls sammanhängande mellan inlägg.

Det finns en syskonfärdighet kallad illustration för spot-art i artikeln (de mindre teckningarna du ser mellan avsnitten i detta inlägg). Samma idé: fast stil, bara metafor och färg varierar. Bara anpassad för kvadratiska 1024×1024-bilder istället för 16:9-omslag.

En liten not om bild-SEO: samma omslagsbild används som inläggets Open Graph- och Twitter Card-tillgång, så sociala delningar plockar upp den direkt. Strapi genererar automatiskt fyra förstorade varianter vid uppladdning (thumbnail, small, medium, large), även om jag ännu inte kopplat artikeltexten till att ladda dem via srcset. Det är en liten front-end-uppgift kvar. Inbäddade illustrationer får beskrivande alt-text i markdown när Lucas lägger in dem; omslagets egen alternativeText i Strapi är något jag fortfarande vill fylla i retroaktivt.

Hur inlägget skrivs

En vertikal disposition till vänster som expanderar till fyllda styckesblock med en tips-glödlampa

När ämne, sökord och omslag är klara är utkastet mest mekaniskt. Lucas:

Disponerar först. Sex eller sju H2:or, var och en med tydlig funktion: problemformulering, steg-för-steg-instruktioner, "Tips:"-rutor, sammanfattning, CTA.
Utvecklar varje H2 till löptext med hjälp av copywriting-färdigheten. Rösten (korta meningar, konkreta exempel, du-tilltal där det passar, ibland torr humor) kommer från regler jag lagt i Lucas stående instruktioner, inte från själva färdigheten.
Lägger till praktiska "Tips:"-rutor under varje steg. Användbart för handledningar eftersom de flesta läsare skummar, och rutorna ger dem en väg genom långt innehåll.
Skriver inläggets description-fält. Strapi begränsar det till 80 tecken, så det hålls kort och känns mänskligt. Det används som artikelns undertitel och som OG/Twitter card-beskrivning.
Avslutar med en CTA som nämner produkten och länkar till en gratis workspace.

Ett första utkast kommer oftast tillbaka efter två-tre minuter. Jag läser, ber om tonjusteringar där rösten är fel, och Lucas itererar tills det sitter. Första utkastet är sällan redo att publiceras. Det är oftast nästan där men lite fel, och det är där jag lägger mest av min granskningstid.

Hur utkastet hamnar i Strapi

Ett inslaget utkastpaket som placeras i en CMS-brevlåda med en pausikon ovanför

Vi använder Strapi som vårt headless CMS. articles-innehållstypen har ett cover (media), author och category (relationer), locale (sträng), och en blocks-dynamisk zon där brödtexten ligger.

Lucas CMS-synkflöde:

POST:a omslags-PNG till /api/upload. Spara returnerad documentId.
POST:a till /api/articles?status=draft med titel, beskrivning (≤80 tecken; Strapi kräver det), slug, språk, omslag/författare/kategori-relationer som numeriska ID:n och ett enda shared.rich-text-block med markdown-brödtexten.
Viktigt: utelämna publishedAt. Strapi tolkar null som utkastläge.
Returnera en förhandsgransknings-URL enligt vm0:s utkastmönster: https://www.vm0.ai/{locale}/blog/posts/{slug}?status=draft.

En notis om Strapi v5: det publika REST API:et kan skriva över publishedAt på vissa innehållstyper, vilket innebär att ett "utkast" du skapar via API:t kan gå live utan förvarning. Lösningen är en liten DB-migrering som tar bort fältet vid utkastskrivningar.

Slug-strategin är också viktig för SEO. Vi använder en kanonisk slug för alla fyra språk istället för att översätta den. En läsare på /de/blog/posts/remote-weekly-meeting-best-practices ser samma URL-struktur som en på /en, och vår länkprofil splittras inte över översatta URL:er. Att lägga till hreflang-länktaggar från dessa språkrelationer är en liten front-end-uppgift kvar. Vi har inte lanserat dem än.

Så fungerar i18n-översättningen

Ett centralt dokument som sprids ut till fyra mindre kopior märkta EN, DE, JA, ES

vm0 finns på fyra språk: engelska, tyska, japanska, spanska. Vi kör inte inlägg genom Google Translate. Den billiga vägen förstör rösten; den rätta vägen anpassar idiomen.

Lucas skapar först EN-utkastet, sparar returnerad documentId, och gör sedan tre uppföljande PUT /api/articles/{documentId}?locale=de-anrop (och ?locale=ja, ?locale=es) med naturligt översatta payloads. Strapi behandlar dessa som språkvarianter av samma kanoniska dokument, vilket håller de fyra versionerna länkade i admin och på språkväxlaren i front-end.

Översättningsregler jag gett honom, mest efter att ha rättat felaktiga utdata:

Översätt inte tekniska termer som redan är engelska lånord i målspråket. "API", "CMS", "agent" och "prompt" förblir engelska i JA och DE. Att översätta dem känns fel i båda språken.
Anpassa idiom naturligt. En bokstavlig översättning av "kills your Friday" till tyska blir obegripligt; en inhemsk version av samma metafor fungerar.
Justera CTA:er per språk. Imperativ känns mer påträngande på DE, så jag tonar ner dem; JA-versionen blir oftast en artig inbjudan.
Justera titlar för längd. Tyska titlar tenderar att bli ~30% längre än engelska motsvarigheter. Japanska titlar är ofta kortare. Lucas håller titlar under 60-teckens SERP-gränsen per språk.

Flerspråkig publicering var den del av arbetsflödet som tidigare tog mest tid. Nu är det bara sista steget i samma agentkörning.

Vad som inte automatiseras

En kort men viktig sektion. Allt i detta arbetsflöde är inte automatiserat, medvetet:

Ämnesval på strategisk nivå. Lucas väljer sökord inom ett ämne, men själva ämnet kommer från mig, oftast från produktlanseringar, kundsamtal eller förändringar i planen.
Slutlig redaktionell granskning. Jag läser varje utkast innan det publiceras. Särskilt EN-versionen. Ton, teknisk korrekthet och interna produktreferenser kräver mänsklig kontroll.
Modersmålsgranskning för språk jag inte behärskar flytande. Jag läser inte tyska flytande. DE-utkastet går till en modersmålsgranskare innan publicering.
Marknadsföring. Att posta på X, skicka till prenumeranter och dela i communities är fortfarande manuellt.

Poängen är inte att ta bort mig ur loopen. Det är att ta bort mig från de delar av loopen som inte egentligen behöver mig.

Hur jag kom fram till detta arbetsflöde

Jag satte mig inte ner en helg och designade detta. Det växte fram, inlägg för inlägg, genom att märka vilka steg som tog min tid.

Det jag märkte: de delar som var värda att automatisera var inte de kreativa. Det var de kopplande delarna: sökordsdragning, omslagsrendering, uppladdningar, språkfan-out, förhandsgransknings-URL-formattering. När jag var ärlig med tiden lade jag mer på logistik än på själva skrivandet.

Så jag flyttade gradvis logistiken till agenten. Modellen skriver; agenten hanterar flytten av saker. Jag fattar fortfarande besluten om vad som ska skrivas och hur det ska låta, men jag syr inte längre ihop bitarna själv.

För mig blev innehållsautomation i praktiken inte "AI:n skriver bloggen." Det blev "AI:n gör allt runt skrivandet, så jag får tid att faktiskt titta på texten."

Om du vill testa något liknande

Om du är i en liknande situation, med fler roller än du önskar och innehåll som en av dem, är det mesta av detta reproducerbart:

En agentplattform där du kan ge agenten en bestående roll och färdigheter (vi använder Zero, där Lucas finns).
Kopplingar till dina befintliga verktyg: ditt CMS, ditt sökordsverktyg, din bildgenerator, ditt Slack.
Ett litet antal färdigheter anpassade till ditt varumärke (i vårt fall draw för omslag och copywriting för ton).
Stående instruktioner som bär kontext, så att prompts kan hållas korta.

Starta en gratis Zero workspace →

Eller om du hellre vill se fler agentarbetsflöden innan du registrerar dig, har vårt use case-bibliotek 19 färdiga automations att kopiera inom teknik, produkt, marknadsföring och drift.

Vill du klona Lucas specifikt: skapa en agent, ge honom rollen Marketing manager, koppla Strapi (eller ditt CMS) + Ahrefs + ett bildgenereringsverktyg, lägg till en draw-färdighet modellerad på din, och en copywriting-färdighet som fångar din varumärkesröst. Han löser resten från ditt första prompt.