Come automatizzo end-to-end la produzione del nostro blog

Sono Ming. Oltre al product design in vm0, mi occupo anche della gestione dei nostri contenuti, e si è rivelata un'attività molto più articolata di quanto mi aspettassi: progettazione del workflow, illustrazioni, produzione delle immagini, lavoro sul CMS, traduzioni. Ecco come, poco alla volta, sono riuscito a portarla avanti.

Anche i contenuti fanno parte di quello che faccio qui

La maggior parte delle mie giornate in vm0 si divide tra product design e il nostro codebase Next.js. Ma anche la gestione dei contenuti è tra le mie responsabilità, e una volta iniziato mi sono reso conto di quanto lavoro richieda davvero un blog che funzioni. Servono output costante, una vera ricerca di keyword, immagini coerenti con il brand, meta description decenti e traduzioni nelle quattro lingue che supportiamo.

Quando ho iniziato a farlo sul serio, ogni articolo mi portava via quasi un'intera giornata. La scrittura, alla fine, ne era solo una piccola parte. La maggior parte del tempo se ne andava nel lavoro di produzione attorno alla scrittura: trovare le keyword giuste, realizzare le copertine, sistemare i campi nel CMS, rifare tutto per ogni lingua.

Così ho gradualmente spostato la maggior parte possibile di questa pipeline su Lucas, un agente di marketing AI che ho costruito su Zero attorno al mio lavoro quotidiano. È configurato come "Marketing manager" e il suo ambito è tutto ciò che riguarda il marketing: la produzione del blog è oggi la parte più sviluppata, e continua a crescere man mano che aggiungo skill e connettori nel tempo.

In questo momento Lucas ha accesso al nostro Strapi headless CMS, al nostro account Ahrefs, allo Slack del team, alla nostra web chat, a una skill interna draw per illustrazioni coerenti con il brand, oltre alla skill standard copywriting per la parte meccanica della scrittura.

Qui sotto ti mostro come funziona nella pratica questa automazione del blog basata sull'AI: come Lucas prende un prompt vago, lo scompone in argomento e keyword, scrive una bozza, disegna una copertina, fa passare il testo attraverso una traduzione naturale e deposita quattro bozze localizzate nel nostro headless CMS. Poi parlerò di come ci sono arrivato e di cosa lascio deliberatamente agli esseri umani (ancora per lo più a me).

Come uso Lucas: web app e Slack

Più fumetti di chat che convergono verso un singolo agente AI

Lavoro principalmente con Lucas attraverso la web chat di vm0. È l'interfaccia per il deep work, dove mi siedo con lui per la scaletta, la stesura, le iterazioni sulla copertina e le modifiche. Thread lunghi, contesto ampio, quel tipo di botta e risposta che in un canale di chat risulterebbe scomodo.

Lucas è anche collegato allo Slack del team, come punto d'accesso condiviso. Da lì gli lancio prompt veloci dal telefono, e anche il resto del team può chiamarlo in causa. Chiunque sia di turno sul blog avvia un articolo nello stesso modo. Stesso agente, stesso contesto su entrambe le interfacce.

Com'è fatto un prompt tipico

I miei prompt a Lucas di solito sono brevi. Tre frasi al massimo. Uno rappresentativo:

Lucas, scrivi un tutorial su come gestire riunioni settimanali efficaci: tratta la struttura della riunione, gli errori più comuni e come mantenere coinvolti i team remoti. Stile tutorial, SEO-friendly, chiudi con una CTA per usare Zero. Solo il link alla bozza, non pubblicare.

Questo è l'intero brief. Un solo messaggio. Nessuna scaletta, nessuna lista di keyword, nessun brief di design, nessun target di lunghezza. Da lì in poi se ne occupa Lucas.

Mi ci è voluto un po' per arrivare a questo formato. All'inizio scrivevo brief molto più lunghi perché davo per scontato che l'agente avesse bisogno che tutto fosse esplicitato, poi ho capito che gran parte del contesto appartiene alle sue istruzioni permanenti e alle sue skill, non a ogni singolo prompt. Il prompt è un innesco; tutto il resto della configurazione regge il peso.

Come Lucas analizza argomento e keyword

Un imbuto che si restringe da molti tag di keyword fino a una singola keyword selezionata

La prima mossa di Lucas è estrarre una struttura da un prompt vago. Per una richiesta come quella sopra, i suoi appunti di lavoro hanno questo aspetto:

Argomento: gestire riunioni settimanali efficaci
Formato: tutorial → passaggi numerati, esempi concreti, linguaggio del tipo "fai così"
Pubblico implicito: team lead, manager remoti, founder
Sezioni richieste: struttura della riunione, errori comuni, coinvolgimento da remoto
CTA: portare i lettori verso Zero
Vincolo: solo URL della bozza, non pubblicato

Poi sceglie la keyword. Questa è la parte del content marketing per cui all'inizio avevo meno intuito, così ho dato a Lucas una routine da seguire ogni volta che gli chiedo di lavorare sulle keyword. Non è una skill che esegue in autonomia, solo una sequenza che gli affido:

Estrae candidati da Ahrefs. Chiama l'API di Ahrefs sulla frase dell'argomento, ottenendo variazioni long-tail con volume di ricerca mensile, keyword difficulty (KD), parent topic e intent della SERP.
Filtra per difficoltà. Gli ho dato una regola ferrea: KD < 30. vm0 è un dominio relativamente nuovo con un'autorità limitata, quindi inseguire keyword ad alto KD non ha ancora senso per noi. All'inizio vince il long-tail.
Incrocia con il nostro indice Strapi. Recupera ogni slug pubblicato dal nostro CMS tramite l'API REST di Strapi e rimuove qualsiasi keyword che già copriamo. Niente cannibalizzazione.
Allinea l'intent al product fit. L'intent di una keyword deve essere compatibile con la nostra libreria di use case. "Come gestire riunioni settimanali efficaci" → operations / gestione del team → calza. "Il miglior ramen di Tokyo" → no, a prescindere dal volume.
Ne sceglie una. Dalla lista filtrata, sceglie l'opzione con il volume più alto e la usa come spina dorsale dell'articolo. Per esempio, remote weekly meeting best practices.

Per la SEO on-page applica un'euristica semplice: keyword target nel titolo, in almeno un H2 e nelle prime 100 parole. Sinonimi e frasi correlate intrecciati con naturalezza in tutto il testo. Link interni a due o tre articoli correlati dove ha senso. Dopodiché: scrivere con naturalezza, niente keyword stuffing.

La struttura dell'articolo (sei o sette H2, un callout "Tip:" sotto ogni passaggio, una CTA in chiusura) deriva da un template per tutorial che ho costruito per esempi nel corso di diversi articoli.

Come viene disegnata la copertina

La copertina è la parte della produzione del blog a cui tengo di più, un po' perché sono un designer e un po' perché è ciò che i lettori vedono prima di leggere una sola parola. È anche l'immagine Open Graph quando gli articoli vengono condivisi su X o LinkedIn, ed è ciò che fa sembrare l'indice del nostro blog una vera testata e non un muro di foto stock.

Le foto stock non erano un'opzione per il look che volevo, e commissionare le illustrazioni una a una avrebbe reso ingestibile il costo di produzione per articolo. Così ho costruito una skill di Zero chiamata draw. È uno script Python di 200 righe che fa cinque cose:

Prende due input: una metafora (cosa disegnare) e un colore (un nome semplice più un ancoraggio hex).
Li inserisce in un template di prompt fisso che blocca tutto il resto della composizione: sfondo grigio caldo #eeeeee, blob ad acquerello centrato nella tela nel colore scelto, schizzo a inchiostro disegnato a mano sopra, logo vm0 a (25, 25) in alto a sinistra.
Invia il prompt composto al modello nano-banana-pro di fal.ai in 16:9.
Scarica il PNG. Normalizza eventuali pixel quasi bianchi riportandoli esattamente a #eeeeee, così lo sfondo non deriva mai. Fa l'upscale a 1600×900. Compone in alpha il logo vm0 trasparente sopra.
Carica il risultato sulla CDN di vm0 e stampa l'URL.

Un'invocazione tipica ha questo aspetto:

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

Due input e tutto il resto del brand resta coerente. Di solito scelgo un colore adatto al tema dell'articolo. Corallo o salvia per i pezzi più caldi in stile tutorial, blu o lavanda per quelli più tecnici, giallo senape per gli annunci. Alcuni colori ricorrenti trasformano lentamente l'indice del blog in una palette riconoscibile.

La cosa che ho capito a mie spese è che la leva non sta nel modello. Sta nel template. Lasciare che il modello scegliesse liberamente composizione, palette e layout significava avere copertine che sembravano ogni volta di un brand diverso. Bloccare quegli elementi e lasciargli scegliere solo la metafora mantiene il look coerente di articolo in articolo.

C'è una skill sorella chiamata illustration per gli spot art interni agli articoli (i disegni più piccoli che vedi tra le sezioni di questo articolo). Stessa idea: stile fisso, varia solo la metafora e il colore. Solo, tarata per art quadrate 1024×1024 invece che per copertine 16:9.

Una piccola nota sulla SEO delle immagini: la stessa immagine di copertina è impostata come asset Open Graph e Twitter Card dell'articolo, così le condivisioni sui social la riprendono in modo pulito. Strapi genera automaticamente quattro varianti pre-ridimensionate all'upload (thumbnail, small, medium, large), anche se non ho ancora collegato il corpo dell'articolo per caricarle tramite srcset. È un piccolo TODO di front-end. Le illustrazioni inline ricevono un alt text descrittivo scritto direttamente nel markdown quando Lucas le incorpora; l'alternativeText della copertina stessa in Strapi è qualcosa che voglio ancora colmare.

Come viene scritto l'articolo

Una scaletta verticale a sinistra che si espande verso destra in blocchi di paragrafo riempiti, con una lampadina che indica un tip

Una volta fissati argomento, keyword e copertina, la stesura è per lo più meccanica. Lucas:

Fa prima la scaletta. Sei o sette H2, ciascuno con un compito chiaro: inquadramento del problema, istruzioni passo passo, callout "Tip:", riepilogo, CTA.
Espande ogni H2 in prosa usando la skill copywriting. La voce (frasi brevi, esempi concreti, seconda persona dove funziona, un'occasionale ironia asciutta) deriva da regole che tengo nelle istruzioni permanenti di Lucas, non dalla skill stessa.
Aggiunge callout pratici "Tip:" sotto ogni passaggio. Utili per i tutorial perché la maggior parte dei lettori legge di sfuggita, e i callout offrono loro un percorso attraverso contenuti lunghi.
Scrive il campo description dell'articolo. Strapi lo limita a 80 caratteri, quindi resta breve e suona come scritto da una persona. Viene usato come sottotitolo dell'articolo e come description della card OG/Twitter.
Chiude con una CTA che nomina il prodotto e rimanda a un workspace gratuito.

Una prima bozza di solito torna due o tre minuti dopo il prompt. La leggo, chiedo aggiustamenti di tono dove la voce è fuori posto, e Lucas itera finché non funziona. La prima bozza raramente è pronta da pubblicare. Di solito è quasi giusta ma un po' fuori fuoco, ed è lì che spendo la maggior parte del mio tempo di revisione.

Come la bozza arriva su Strapi

Un pacco-bozza confezionato che viene depositato in una cassetta postale CMS con un'icona di pausa sospesa sopra

Usiamo Strapi come nostro headless CMS. Il content type articles ha un cover (media), author e category (relazioni), locale (stringa) e una dynamic zone blocks dove risiede il corpo.

Il flusso di sincronizzazione CMS di Lucas:

POST del PNG di copertina su /api/upload. Salva il documentId restituito.
POST su /api/articles?status=draft con titolo, description (≤80 caratteri; Strapi lo impone), slug, locale, le relazioni cover/author/category come ID numerici e un singolo blocco shared.rich-text contenente il corpo in markdown.
Punto cruciale: omettere publishedAt. Strapi tratta il valore null come stato di bozza.
Restituisce un URL di anteprima usando il pattern di bozza di vm0: https://www.vm0.ai/{locale}/blog/posts/{slug}?status=draft.

Un avvertimento su Strapi v5: l'API REST pubblica può sovrascrivere publishedAt su certi content type, il che significa che una "bozza" creata tramite l'API può andare online in silenzio. La soluzione è una piccola migrazione del DB che rimuove il campo nelle scritture in bozza.

Anche la strategia degli slug conta per la SEO. Usiamo un unico slug canonico per tutte e quattro le lingue invece di tradurlo. Un lettore su /de/blog/posts/remote-weekly-meeting-best-practices vede la stessa struttura di URL di un lettore su /en, e il nostro profilo di backlink non si frammenta su URL tradotti. Emettere i tag link hreflang da quelle relazioni di locale è un piccolo TODO di front-end. Per ora non li includiamo ancora.

Come funziona la traduzione i18n

Un documento centrale che si dirama in quattro copie più piccole etichettate EN, DE, JA, ES

vm0 è disponibile in quattro lingue: inglese, tedesco, giapponese, spagnolo. Non facciamo passare gli articoli da Google Translate. La strada economica distrugge la voce; quella giusta adatta i modi di dire.

Lucas crea prima la bozza EN, cattura il documentId restituito, poi emette tre chiamate di follow-up PUT /api/articles/{documentId}?locale=de (e ?locale=ja, ?locale=es) con payload tradotti in modo naturale. Strapi li tratta come varianti di locale dello stesso documento canonico, il che mantiene le quattro versioni collegate nell'admin e nel selettore di lingua del front-end.

Le regole di traduzione che gli ho dato, per lo più frutto di output sbagliati che ho poi corretto:

Non tradurre i termini tecnici che sono già prestiti dall'inglese nella lingua di destinazione. "API," "CMS," "agent" e "prompt" restano in inglese in JA e DE. Tradurli suona strano in entrambe le lingue.
Adatta i modi di dire in modo naturale. Una traduzione letterale di "kills your Friday" in tedesco è incomprensibile; una versione nativa della stessa metafora funziona.
Ritara le CTA per ogni lingua. Gli imperativi risultano più insistenti in DE, quindi li attenuo; la versione JA di solito si addolcisce in un invito cortese.
Ritara i titoli in base alla lunghezza. I titoli tedeschi tendono a essere circa il 30% più lunghi degli equivalenti inglesi. I titoli giapponesi tendono a essere più brevi. Lucas mantiene i titoli sotto il limite di troncamento di 60 caratteri della SERP per ogni lingua.

La pubblicazione di contenuti multilingue era la parte del workflow che prima divorava più tempo. Ora è solo l'ultimo passaggio nello stesso run dell'agente.

Cosa non viene automatizzato

Una sezione breve ma importante. Non tutto in questo workflow è automatizzato, e di proposito:

La selezione degli argomenti a livello strategico. Lucas sceglie le keyword all'interno di un argomento, ma l'argomento stesso viene da me, di solito da lanci di prodotto, conversazioni con i clienti o cambi di roadmap.
La revisione editoriale finale. Leggo ogni bozza prima che venga pubblicata. Soprattutto la versione EN. Tono, accuratezza delle affermazioni tecniche, richiami al contesto interno del prodotto richiedono tutti un occhio umano.
La revisione madrelingua per le lingue che non parlo fluentemente. Non leggo il tedesco fluentemente. La bozza DE va a un revisore madrelingua per un passaggio finale prima della pubblicazione.
La promozione. Pubblicare su X, inviare agli iscritti, condividere nelle community per ora sono ancora attività manuali.

Il punto non è togliermi dal giro. È togliermi dalle parti del giro che non hanno davvero bisogno di me.

Come sono arrivato a questo workflow

Non mi sono seduto un weekend a progettare tutto questo. Si è accumulato, articolo dopo articolo, notando quali passaggi mi divoravano il tempo.

Quello che ho notato: le parti che valeva la pena automatizzare non erano quelle creative. Erano quelle di raccordo: le estrazioni di keyword, i render delle copertine, le chiamate di upload, lo smistamento per lingua, la formattazione dell'URL di anteprima. Quando l'ho tracciato onestamente, passavo più tempo sulla logistica che sulla scrittura vera e propria.

Così ho spostato gradualmente la logistica sull'agente. Il modello scrive; l'agente si occupa dello spostamento delle cose. Sono ancora io a prendere le decisioni su cosa scrivere e su come deve suonare, solo che non sono più io a cucire insieme i pezzi.

Per me, l'automazione dei contenuti nella pratica non si è rivelata "l'AI scrive il blog". Si è rivelata "l'AI fa tutto ciò che sta attorno alla scrittura, così io ho il tempo di guardare davvero la scrittura".

Se vuoi provare qualcosa di simile

Se ti trovi in una situazione simile, con più cappelli di quanti vorresti e i contenuti tra questi, gran parte di tutto ciò è riproducibile:

Una piattaforma di agenti che ti permetta di dare all'agente un ruolo e delle skill persistenti (noi usiamo Zero, dove vive Lucas).
Connettori ai tuoi strumenti esistenti: il tuo CMS, il tuo strumento di ricerca keyword, il tuo generatore di immagini, il tuo Slack.
Un piccolo set di skill su misura per il tuo brand (nel nostro caso draw per le copertine e copywriting per il tono).
Istruzioni permanenti che portano il contesto, così i prompt possono restare brevi.

Avvia un workspace Zero gratuito →

Oppure, se preferisci vedere altri workflow di agenti prima di registrarti, la nostra libreria di use case contiene 19 automazioni pronte da copiare tra engineering, prodotto, marketing e operations.

Se vuoi clonare Lucas nello specifico: crea un agente, dagli il ruolo Marketing manager, collega Strapi (o il tuo CMS) + Ahrefs + uno strumento di image gen, aggiungi una skill draw modellata sulla tua e una skill copywriting che catturi la voce del tuo brand. Capirà il resto dal tuo primo prompt.