Hvordan jeg automatiserer hele bloggproduksjonen vår

Jeg er Ming. I tillegg til produktdesign hos vm0, er innholdsarbeid også en del av jobben min, og det viste seg å være mye mer omfattende enn jeg trodde: arbeidsflytdesign, illustrasjoner, bildeproduksjon, CMS-arbeid, oversettelser. Slik har jeg gradvis fått det til å fungere.

Innhold er en av tingene jeg gjør her

Mesteparten av dagen min hos vm0 deles mellom produktdesign og vår Next.js-kodebase. Men innholdsarbeid er også mitt ansvar, og da jeg først begynte, innså jeg hvor mye som faktisk kreves for å lage en blogg som leverer. Du trenger jevnlig publisering, reell søkeordsanalyse, visuelle elementer i tråd med merkevaren, gode metabeskrivelser og oversettelser til de fire språkene vi støtter.

Da jeg begynte å ta dette på alvor, tok hvert innlegg nesten en hel dag. Selve skrivingen var bare en liten del av det. Mesteparten av tiden gikk med til produksjonsarbeidet rundt teksten: finne riktige søkeord, lage forsidebilde, fylle ut feltene korrekt i CMS-et, og gjenta det for hvert språk.

Derfor har jeg gradvis flyttet så mye som mulig av denne prosessen inn i Lucas, en AI-markedsføringsagent jeg bygget på Zero basert på mitt eget daglige arbeid. Han er konfigurert som "Marketing manager", og ansvarsområdet hans er alt innen markedsføring: bloggproduksjon er det mest utbygde området i dag, og han vokser stadig etter hvert som jeg legger til ferdigheter og koblinger.

Akkurat nå har Lucas tilgang til vårt Strapi headless CMS, vår Ahrefs-konto, teamets Slack, vår webchat, en intern draw-ferdighet for merkevaretilpassede illustrasjoner, samt standard copywriting-ferdighet for skrivearbeidet.

Nedenfor går jeg gjennom hvordan denne AI-baserte blogautomatiseringen fungerer i praksis: hvordan Lucas tar et vagt prompt, bryter det ned til tema og søkeord, skriver et utkast, tegner et forsidebilde, oversetter teksten naturlig, og leverer fire utkast til vårt headless CMS. Deretter forteller jeg hvordan jeg kom hit, og hva jeg bevisst lar mennesker gjøre (fortsatt stort sett meg).

Hvordan jeg bruker Lucas: webapp og Slack

Flere chatbobler som samles hos én AI-agent

Jeg jobber mest med Lucas via vm0s webchat. Det er grensesnittet for dypjobb hvor jeg sitter sammen med ham gjennom disposisjon, utkast, forsideiterasjoner og redigeringer. Lange tråder, mye kontekst, den typen frem-og-tilbake som ville vært tungvint i en chatkanal.

Lucas er også koblet til teamets Slack, som et felles inngangspunkt. Jeg legger inn raske prompts der fra mobilen, og resten av teamet kan også kontakte ham. Den som har bloggansvaret starter et innlegg på samme måte. Samme agent, samme kontekst på begge plattformer.

Hvordan et typisk prompt ser ut

Mine prompts til Lucas er vanligvis korte. Maks tre setninger. Et representativt eksempel:

Lucas, skriv en veiledning om å holde effektive ukentlige møter: dekk møtestruktur, vanlige fallgruver og hvordan holde fjernteam engasjert. Veiledningsstil, SEO-vennlig, avslutt med en CTA for å bruke Zero. Kun utkastlenke, ikke publiser.

Det er hele briefen. Én melding. Ingen disposisjon, ingen søkeordliste, ingen designbrief, ingen lengdemål. Lucas tar det derfra.

Det tok litt tid før jeg landet på dette formatet. Tidligere skrev jeg mye lengre brief fordi jeg trodde agenten trengte alt spesifisert, men innså at mesteparten av konteksten hører hjemme i hans faste instruksjoner og ferdigheter, ikke i hvert prompt. Prompten er en utløser; resten av oppsettet bærer hovedvekten.

Hvordan Lucas analyserer tema og søkeord

En trakt som snevres inn fra mange søkeord til ett valgt søkeord

Lucas sitt første trekk er å trekke ut struktur fra et vagt prompt. For en forespørsel som den over, ser arbeidsnotatene hans slik ut:

Tema: holde effektive ukentlige møter
Format: veiledning → nummererte steg, konkrete eksempler, "gjør dette"-språk
Implisert målgruppe: teamledere, fjernledere, gründere
Nødvendige seksjoner: møtestruktur, vanlige fallgruver, fjernengasjement
CTA: få leserne til å bruke Zero
Begrensning: kun utkast-URL, ikke publisert

Deretter velger han søkeordet. Dette var den delen av innholdsmarkedsføring jeg hadde minst intuisjon for da jeg startet, så jeg ga Lucas en rutine han følger hver gang jeg ber ham om søkeordsarbeid. Det er ikke en ferdighet han kjører autonomt, bare en sekvens jeg stoler på:

Hent kandidater fra Ahrefs. Han kaller Ahrefs API på temafrasen, og får tilbake long-tail-varianter med månedlig søkevolum, søkeordvanskelighet (KD), overordnet tema og SERP-intensjon.
Filtrer på vanskelighetsgrad. Jeg ga ham en fast regel: KD < 30. vm0 er et relativt nytt domene med begrenset autoritet, så å jakte på høye KD-søkeord gir ikke mening for oss ennå. Long-tail gir tidlig gevinst.
Kryssjekk mot Strapi-indeksen vår. Han henter alle publiserte slugs fra CMS via Strapi REST API og fjerner søkeord vi allerede dekker. Ingen kannibalisering.
Matcher intensjon mot produktpassform. Søkeordets intensjon må passe med vårt brukstilfellebibliotek. "Hvordan holde effektive ukentlige møter" → drift / teamledelse → passer. "Best ramen i Tokyo" → gjør ikke det, uansett volum.
Velg ett. Fra den filtrerte listen velger han det med høyest volum og bruker det som ryggrad for innlegget. For eksempel remote weekly meeting best practices.

For on-page SEO bruker han en enkel tommelfingerregel: målsøkeord i tittelen, i minst én H2, og i de første 100 ordene. Synonymer og relaterte fraser flettes naturlig inn. Interne lenker til to-tre relaterte innlegg der det passer. Etter det: skriv naturlig, ingen søkeordfylling.

Strukturen på innlegget (seks-syv H2-er, en "Tips:"-boks under hvert steg, en CTA til slutt) kommer fra en veiledningsmal jeg har bygget opp gjennom flere innlegg.

Hvordan forsiden blir tegnet

Forsiden er den delen av bloggproduksjonen jeg bryr meg mest om, dels fordi jeg er designer og dels fordi det er det leserne ser før de leser et ord. Det er også Open Graph-bildet når innlegg deles på X eller LinkedIn, og det er det som gjør at bloggindeksen vår ser ut som en publikasjon og ikke en vegg av stockfoto.

Stockfoto var ikke et alternativ for det uttrykket jeg ønsket, og å bestille illustrasjoner én og én ville gjort produksjonskostnaden per innlegg uholdbar. Derfor bygde jeg en Zero-ferdighet kalt draw. Det er et 200-linjers Python-skript som gjør fem ting:

Tar to input: et metafor (hva som skal tegnes) og en farge (et vennlig navn pluss en hex-kode).
Setter dem inn i en fast prompt-mal som låser resten av komposisjonen: varm grå bakgrunn #eeeeee, akvarellflekk sentrert på lerretet i valgt farge, håndtegnet blekk-skisse oppå, vm0-logo på (25, 25) øverst til venstre.
Sender den sammensatte prompten til fal.ai sin nano-banana-pro-modell på 16:9.
Laster ned PNG-en. Normaliserer alle nesten-hvite piksler tilbake til nøyaktig #eeeeee slik at bakgrunnen aldri driver. Oppskalerer til 1600×900. Alpha-kompositerer den gjennomsiktige vm0-logoen på toppen.
Laster opp resultatet til vm0s CDN og skriver ut URL-en.

En typisk bruk ser slik ut:

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

To input og resten av merkevaren forblir konsistent. Jeg velger vanligvis en farge som passer til temaet for innlegget. Korall eller salvie for varmere veiledningsinnlegg, blå eller lavendel for mer tekniske, sennepsgul for kunngjøringer. Noen få gjentakende farger gjør at bloggindeksen gradvis får en gjenkjennelig palett.

Det jeg lærte på den harde måten, er at styrken ikke ligger i modellen. Den ligger i malen. Hvis modellen får velge komposisjon, palett og layout fritt, ser hver forside ut som en annen merkevare. Ved å låse disse og kun la den velge metaforen, holder uttrykket seg sammenhengende fra innlegg til innlegg.

Det finnes en søsterferdighet kalt illustration for spot-artikler i teksten (de mindre tegningene du ser mellom seksjonene i dette innlegget). Samme idé: fast stil, kun metafor og farge varierer. Bare tilpasset kvadratisk 1024×1024-kunst i stedet for 16:9-forsider.

En liten merknad om bilde-SEO: samme forsidebilde brukes som Open Graph- og Twitter Card-ressurs for innlegget, slik at delinger på sosiale medier plukker det opp. Strapi genererer automatisk fire forhåndstilpassede varianter ved opplasting (miniatyr, liten, medium, stor), selv om jeg ennå ikke har koblet artikkelteksten til å laste dem via srcset. Det er en liten front-end TODO. Inline-illustrasjoner får beskrivende alt-tekst skrevet inn i markdown når Lucas legger dem inn; forsiden sin egen alternativeText i Strapi er noe jeg fortsatt ønsker å etterfylle.

Hvordan innlegget blir skrevet

En vertikal disposisjon til venstre som utvides mot høyre til utfylte avsnittsblokker med en tipslyspære

Når tema, søkeord og forside er på plass, er utkastet stort sett mekanisk. Lucas:

Disposisjon først. Seks-syv H2-er, hver med en tydelig funksjon: problemstilling, steg-for-steg-instruksjoner, "Tips:"-bokser, oppsummering, CTA.
Utvider hver H2 til prosa ved hjelp av copywriting-ferdigheten. Stilen (korte setninger, konkrete eksempler, du-form der det passer, tidvis tørr humor) kommer fra regler jeg har i Lucas sine faste instruksjoner, ikke fra selve ferdigheten.
Legger til praktiske "Tips:"-bokser under hvert steg. Nyttig for veiledninger fordi de fleste lesere skumleser, og boksene gir dem en vei gjennom langt innhold.
Skriver innleggets description-felt. Strapi setter grensen til 80 tegn, så det holdes kort og leses som om et menneske har skrevet det. Det brukes som undertittel og som beskrivelse for OG/Twitter-kort.
Avslutter med en CTA som nevner produktet og lenker til en gratis arbeidsplass.

Et førsteutkast kommer vanligvis tilbake etter to-tre minutter. Jeg leser gjennom, ber om justeringer hvis tonen er feil, og Lucas itererer til det sitter. Førsteutkastet er sjelden klart for publisering. Det er som regel nesten i mål, men litt feil, og det er her jeg bruker mest tid på gjennomgang.

Hvordan utkastet havner i Strapi

En innpakket utkastpakke som legges i en CMS-postkasse med en pause-ikon over

Vi bruker Strapi som vårt headless CMS. articles-innholdstypen har en cover (media), author og category (relasjoner), locale (streng), og en blocks dynamisk sone hvor hovedteksten ligger.

Lucas sin CMS-synkroniseringsflyt:

POST forsiden-PNG til /api/upload. Lagre returnert documentId.
POST til /api/articles?status=draft med tittel, beskrivelse (≤80 tegn; Strapi håndhever det), slug, språk, relasjoner for forside/forfatter/kategori som numeriske ID-er, og én shared.rich-text-blokk med markdown-teksten.
Viktig: utelat publishedAt. Strapi tolker null som utkaststatus.
Returner en forhåndsvisnings-URL med vm0s utkastmønster: https://www.vm0.ai/{locale}/blog/posts/{slug}?status=draft.

En advarsel om Strapi v5: det offentlige REST API-et kan overstyre publishedAt på visse innholdstyper, noe som betyr at et "utkast" du oppretter via API-et kan gå live uten varsel. Løsningen er en liten DB-migrering som fjerner feltet ved utkastskriving.

Slug-strategien er også viktig for SEO. Vi bruker én kanonisk slug på tvers av alle fire språk i stedet for å oversette den. En leser på /de/blog/posts/remote-weekly-meeting-best-practices ser samme URL-struktur som en leser på /en, og vår lenkeprofil fragmenteres ikke på tvers av oversatte URL-er. Å generere hreflang-lenketagger fra disse språkrelasjonene er en liten front-end TODO. Vi har ikke lansert det ennå.

Hvordan i18n-oversettelse fungerer

Et sentralt dokument som sprer seg ut til fire mindre kopier merket EN, DE, JA, ES

vm0 leveres på fire språk: engelsk, tysk, japansk, spansk. Vi bruker ikke Google Translate på innleggene. Den billige løsningen ødelegger tonen; den riktige tilpasser idiomer.

Lucas lager først EN-utkastet, fanger returnert documentId, og sender deretter tre oppfølgende PUT /api/articles/{documentId}?locale=de (og ?locale=ja, ?locale=es) kall med naturlig oversatte data. Strapi behandler disse som språkvarianter av samme kanoniske dokument, slik at de fire versjonene holdes sammen i admin og på språkvelgeren i front-end.

Oversettelsesregler jeg har gitt ham, stort sett basert på feil jeg har rettet opp:

Ikke oversett tekniske termer som allerede er engelske lånord i målspråket. "API", "CMS", "agent" og "prompt" forblir på engelsk i JA og DE. Å oversette dem føles feil på begge språk.
Tilpass idiomer naturlig. En bokstavelig oversettelse av "kills your Friday" til tysk gir ingen mening; en innfødt versjon av samme metafor fungerer.
Juster CTA-er per språk. Imperativer føles mer påtrengende på tysk, så jeg toner dem ned; japanske versjoner mykes ofte opp til en høflig invitasjon.
Juster titler for lengde. Tyske titler er ofte ~30% lengre enn engelske. Japanske titler er ofte kortere. Lucas holder titler under 60-tegns SERP-grensen per språk.

Flerspråklig publisering var tidligere den delen av arbeidsflyten som tok mest tid. Nå er det bare siste steg i samme agent-kjøring.

Hva som ikke blir automatisert

En kort, men viktig seksjon. Ikke alt i denne arbeidsflyten er automatisert, med vilje:

Temavalg på strategisk nivå. Lucas velger søkeord innenfor et tema, men selve temaet kommer fra meg, vanligvis fra produktlanseringer, kundesamtaler eller veikartendringer.
Siste redaksjonelle gjennomgang. Jeg leser hvert utkast før publisering. Spesielt EN-versjonen. Tone, teknisk nøyaktighet og referanser til intern produktkontekst må vurderes av et menneske.
Innfødt gjennomgang for språk jeg ikke behersker flytende. Jeg leser ikke tysk flytende. DE-utkastet går til en innfødt korrekturleser før publisering.
Promotering. Publisering på X, utsending til abonnenter og deling i fellesskap er fortsatt manuelt foreløpig.

Poenget er ikke å fjerne meg fra prosessen. Det er å fjerne meg fra de delene som ikke egentlig trenger meg.

Hvordan jeg kom frem til denne arbeidsflyten

Jeg satte meg ikke ned en helg og designet dette. Det har vokst frem, innlegg for innlegg, ved å legge merke til hvilke steg som tok mest tid.

Det jeg la merke til: det som var verdt å automatisere, var ikke de kreative delene. Det var de koblende delene: søkeordhentingen, forsidegenereringen, opplastingskallene, språkfordelingen, forhåndsvisnings-URL-formateringen. Når jeg så ærlig på det, brukte jeg mer tid på logistikk enn på selve skrivingen.

Så jeg flyttet gradvis logistikken inn i agenten. Modellen skriver; agenten håndterer flyttingen. Jeg tar fortsatt beslutningene om hva som skal skrives og hvordan det skal høres ut, men jeg syr ikke lenger sammen bitene selv.

For meg ble innholdsautomatisering i praksis ikke "AI-en skriver bloggen." Det ble "AI-en gjør alt rundt skrivingen, så jeg faktisk har tid til å se på selve teksten."

Hvis du vil prøve noe lignende

Hvis du er i en lignende situasjon, med flere roller enn du ønsker og innhold som en av dem, er det meste av dette mulig å gjenskape:

En agentplattform som lar deg gi agenten en vedvarende rolle og ferdigheter (vi bruker Zero, hvor Lucas bor).
Koblinger til dine eksisterende verktøy: ditt CMS, søkeordverktøy, bildegenerator, Slack.
Et lite sett ferdigheter tilpasset din merkevare (hos oss draw for forsider og copywriting for tone).
Faste instruksjoner som bærer konteksten, slik at prompts kan holdes korte.

Start et gratis Zero workspace →

Eller hvis du heller vil se flere agent-arbeidsflyter før du registrerer deg, har vårt brukstilfellebibliotek 19 ferdige automasjoner for ingeniørarbeid, produkt, markedsføring og drift.

Hvis du vil klone Lucas spesifikt: opprett en agent, gi ham rollen Marketing manager, koble til Strapi (eller ditt CMS) + Ahrefs + et bildegenereringsverktøy, legg til en draw-ferdighet modellert etter din, og en copywriting-ferdighet som fanger din merkevarestemme. Han finner ut resten fra ditt første prompt.