我如何自動化我們的部落格產製流程

我是 Ming。在 vm0 除了做產品設計，內容營運也是我的工作之一，結果發現這比我想像的複雜得多：工作流程設計、插圖、圖片製作、CMS 操作、翻譯。這是我逐步完成這些工作的方式。

內容是我在這裡做的其中一件事

我在 vm0 的一天大多分配在產品設計和 Next.js 程式碼庫之間。但內容營運也是我的責任，開始後才發現要讓部落格有成效其實需要很多事：穩定產出、真正的關鍵字研究、品牌一致的視覺、合適的 meta 描述，以及我們支援的四種語言翻譯。

剛開始認真做時，每篇文章幾乎要花掉我一天時間。寫作其實只是很小一部分。大多數時間都花在寫作周邊的產製工作：找對的關鍵字、做封面圖、在 CMS 填好欄位、每個語言都要重做一次。

所以我逐步把這條產線能自動化的部分都搬進 Lucas——我用 Zero 依照自己日常工作打造的 AI 行銷智能體。他被設定為「行銷經理」，負責所有行銷相關的事：目前部落格產製是最完整的一塊，隨著我陸續加入技能和連接器，他的能力也持續擴展。

現在 Lucas 可以存取我們的 Strapi headless CMS、Ahrefs 帳號、團隊 Slack、網站聊天、內部的 draw 品牌插圖技能，以及標準的 copywriting 寫作技能。

下面我會說明這套 AI 部落格自動化實際怎麼運作：Lucas 如何從模糊的提示拆解主題和關鍵字、起草文章、繪製封面、自然翻譯文本，最後把四種語言的草稿都送進我們的 headless CMS。然後我會談談我是怎麼走到這裡，以及哪些部分我刻意保留給人類（目前還是主要由我負責）。

我怎麼用 Lucas：網頁應用與 Slack

多個聊天泡泡匯聚到單一 AI 智能體

我主要透過 vm0 的網頁聊天介面和 Lucas 協作。這是我和他一起做大綱、起草、封面反覆調整和編輯的深度工作介面。長對話、長上下文，這種來回在一般聊天頻道會很彆扭。

Lucas 也接到我們團隊的 Slack，作為共用入口。我會用手機在那裡丟快速提示，團隊其他人也能叫他。不論誰輪到寫部落格，都是用同樣方式啟動。一樣的智能體，兩個介面共用同一上下文。

典型提示長什麼樣

我給 Lucas 的提示通常很短，最多三句。舉個代表性的：

Lucas，寫一篇關於如何有效舉辦每週會議的教學：涵蓋會議結構、常見陷阱，以及如何讓遠端團隊保持參與。教學風格，SEO 友善，結尾加上使用 Zero 的 CTA。只要草稿連結，不要發佈。

這就是全部說明。一則訊息。沒有大綱、沒有關鍵字清單、沒有設計說明、沒有字數目標。Lucas 會自己處理後續。

我花了一段時間才找到這種格式。剛開始我會寫很長的說明，以為智能體什麼都要交代清楚，後來發現大部分上下文應該放在他的常駐指令和技能裡，不用每次提示都重複。提示只是觸發點，剩下的設定才是重點。

Lucas 如何分析主題與關鍵字

一個漏斗從許多關鍵字標籤收斂到一個選定關鍵字

Lucas 的第一步是從模糊提示中提取結構。像上面那種請求，他的工作筆記會像這樣：

主題： 如何有效舉辦每週會議
格式： 教學 → 編號步驟、具體範例、「這樣做」語氣
隱含受眾： 團隊主管、遠端經理、創辦人
必備段落： 會議結構、常見陷阱、遠端參與
CTA： 引導讀者使用 Zero
限制： 只要草稿網址，不發佈

接著他會挑選關鍵字。這是我剛開始做內容行銷時最沒直覺的部分，所以我給 Lucas 一套流程，每次要做關鍵字時都照這個走。這不是他自動執行的技能，而是我信任他能按步驟完成的序列：

從 Ahrefs 拉候選詞。 他用主題詞呼叫 Ahrefs API，回傳長尾變體、每月搜尋量、關鍵字難度（KD）、母主題和 SERP 意圖。
依難度篩選。 我給他硬性規則：KD < 30。vm0 是新網域，權重有限，追高 KD 關鍵字不划算。長尾詞早期比較容易上榜。
交叉比對 Strapi 索引。 他用 Strapi REST API 拉出所有已發佈的 slug，移除已經覆蓋的關鍵字，避免自家內容互搶排名。
比對意圖與產品適配。 關鍵字意圖必須和我們的用例庫相符。「如何有效舉辦每週會議」→ 營運／團隊管理 → 適合。「東京最好吃的拉麵」→ 不適合，不論搜尋量多大。
選一個。 從篩選後的清單挑最高搜尋量的，作為文章主軸。例如 remote weekly meeting best practices。

頁面 SEO 他用簡單準則：目標關鍵字要出現在標題、至少一個 H2、以及前 100 個字內。自然穿插同義詞和相關詞。內部連結兩三篇相關文章。其餘就自然寫作，不要硬塞關鍵字。

文章結構（六七個 H2，每步驟下有「Tip:」提示、結尾有 CTA）來自我自己累積的教學模板。

封面怎麼畫出來的

封面是我最在意的部落格產製環節，一方面因為我是設計師，一方面因為讀者在閱讀前先看到它。它也是文章在 X 或 LinkedIn 分享時的 Open Graph 圖片，讓我們的部落格首頁看起來像出版品，而不是一堆庫存照片。

庫存照片不符合我想要的風格，一張張委託插畫又會讓每篇成本過高。所以我做了一個叫 draw 的 Zero 技能。這是一個 200 行的 Python 腳本，做五件事：

接收兩個輸入：隱喻（畫什麼）和顏色（友善名稱加 hex 色碼）。
把它們丟進固定的提示模板，鎖定其他構圖：暖灰底 #eeeeee，畫布中央水彩色塊（指定顏色），上面手繪墨線稿，vm0 標誌放在 (25, 25) 左上角。
把組合好的提示送到 fal.ai 的 nano-banana-pro 模型（16:9）。
下載 PNG。把接近白色的像素歸一成 #eeeeee，確保背景不會偏色。放大到 1600×900。把透明 vm0 標誌疊上去。
上傳到 vm0 的 CDN，印出網址。

典型呼叫長這樣：

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

兩個輸入，品牌其他元素都固定。我通常會選和文章主題搭配的顏色。教學類用珊瑚或鼠尾草色，技術類用藍色或薰衣草，公告用芥末黃。幾個重複出現的顏色慢慢讓部落格首頁形成可辨識的色盤。

我最深刻的體會是，關鍵不在模型，而在模板。讓模型自由決定構圖、色盤和版面，結果每張封面都像不同品牌。把這些鎖定，只讓它選隱喻，才能讓整體風格一致。

還有一個姊妹技能叫 illustration，用來畫文內插圖（你在本文段落間看到的小圖）。同樣概念：風格固定，只變隱喻和顏色。只是調整成正方形 1024×1024 圖，而不是 16:9 封面。

關於圖片 SEO：同一張封面圖會設為文章的 Open Graph 和 Twitter Card 資產，社群分享時能正確抓到。Strapi 上傳時自動產生四種尺寸（縮圖、小、中、大），但我還沒讓文章內文自動載入這些尺寸（srcset），這是前端小待辦。內文插圖 Lucas 會在 markdown 裡寫好描述性 alt 文字；封面自己的 alternativeText 欄位我還想補齊。

文章怎麼寫出來的

左側垂直大綱向右展開成填滿的段落區塊，並有提示燈泡

主題、關鍵字、封面都定好後，起草就變成機械流程。Lucas：

先列大綱。 六七個 H2，每個有明確功能：問題定義、步驟說明、「Tip:」提示、總結、CTA。
用 copywriting 技能展開每個 H2 成段落。 文章語氣（短句、具體例子、適時用第二人稱、偶爾乾式幽默）來自我放在 Lucas 常駐指令裡的規則，不是技能本身。
每步驟下加實用「Tip:」提示。 教學文很需要，因為多數讀者只會略讀，提示能幫他們抓重點。
寫文章的 description 欄位。 Strapi 限制 80 字以內，所以要簡短且像人寫的。這會當作副標題和 OG/Twitter 卡片描述。
結尾加 CTA， 指名產品並連結到免費工作區。

第一版草稿通常兩三分鐘就回來。我會讀一遍，語氣不對就請他調整，Lucas 會反覆修改到滿意。第一版很少能直接用，通常大致正確但細節還差一點，我大部分審稿時間都花在這裡。

草稿怎麼進 Strapi

包裝好的草稿被放進 CMS 信箱，上方有暫停圖示

我們用 Strapi 當 headless CMS。articles 內容型別有 cover（媒體）、author 和 category（關聯）、locale（字串），還有一個 blocks 動態區塊放內文。

Lucas 的 CMS 同步流程：

把封面 PNG POST 到 /api/upload，存下回傳的 documentId。
POST 到 /api/articles?status=draft，帶上標題、描述（≤80 字，Strapi 會檢查）、slug、語言、封面/作者/分類關聯（數字 ID），還有一個 shared.rich-text 區塊包 markdown 內文。
重點：省略 publishedAt。 Strapi 把 null 當作草稿狀態。
用 vm0 的草稿網址格式回傳預覽連結：https://www.vm0.ai/{locale}/blog/posts/{slug}?status=draft。

Strapi v5 有個要注意的點：公開 REST API 可以覆寫某些內容型別的 publishedAt，也就是你用 API 建的「草稿」可能會直接上線。解法是做個小型 DB migration，讓草稿寫入時移除該欄位。

slug 策略對 SEO 也很重要。我們四種語言都用同一個 slug，不翻譯。/de/blog/posts/remote-weekly-meeting-best-practices 的讀者和 /en 的讀者看到一樣的網址結構，反向連結不會因翻譯分散。從語言關聯產生 hreflang link tag 也是前端小待辦，目前還沒上線。

i18n 翻譯怎麼做

一份中央文件分出四份標記 EN、DE、JA、ES 的副本

vm0 支援四種語言：英文、德文、日文、西班牙文。我們不會用 Google 翻譯。便宜的做法會毀掉語氣，正確做法要自然轉換成地道用語。

Lucas 先產生 EN 草稿，存下回傳的 documentId，再用自然翻譯的內容分別呼叫三次 PUT /api/articles/{documentId}?locale=de（還有 ?locale=ja、?locale=es）。Strapi 會把這些當作同一份主文件的語言變體，後台和前端語言切換器都能串起四個版本。

我給他的翻譯規則，大多是遇到錯誤結果後修正出來的：

不要翻譯已經是英語外來語的技術詞。「API」、「CMS」、「agent」、「prompt」在日文和德文都維持英文，翻譯反而怪。
自然轉換成地道用語。「kills your Friday」直譯成德文會變成胡言亂語，用當地人會用的隱喻才對。
CTA 依語言調整語氣。 德文命令語氣太強要柔化，日文通常改成禮貌邀請。
標題長度調整。 德文標題通常比英文長約 30%，日文則較短。Lucas 會依各語言 SERP 截斷限制把標題控制在 60 字內。

多語內容發佈曾經是最花時間的環節，現在只是同一個智能體執行的最後一步。

哪些沒自動化

這段很短但很重要。這個流程不是全部自動化，這是刻意的：

策略層級的主題選擇。 Lucas 只在主題內挑關鍵字，主題本身還是我決定，通常來自產品發佈、客戶對話或產品路線調整。
最終編輯審稿。 每篇草稿我都會看，尤其是英文版。語氣、技術正確性、內部產品脈絡都需要人眼把關。
我不流利的語言要母語審稿。 我德文不流利，DE 草稿會給母語者審一遍才發佈。
推廣。 發 X、寄給訂閱者、社群分享目前都還是手動。

重點不是把我從流程中移除，而是把我從那些其實不需要我參與的環節移除。

我怎麼走到這個工作流程

我不是某個週末坐下來設計好這一切的，而是每發一篇文章就注意哪些步驟最花時間，慢慢累積出來的。

我發現，值得自動化的不是創意部分，而是連接各環節的部分：拉關鍵字、產生封面、上傳、語言分發、預覽網址格式。老實記錄後發現，我花在物流上的時間比寫作本身還多。

所以我逐步把這些物流交給智能體。模型負責寫作，智能體負責搬運。我還是決定寫什麼、怎麼寫，只是不再需要自己拼湊各個零件。

對我來說，內容自動化實際上不是「AI 幫你寫部落格」，而是「AI 幫你處理寫作以外的所有事，讓你有時間真正審視內容」。

如果你也想試試類似做法

如果你和我一樣身兼多職，內容只是其中一頂帽子，大部分流程都能複製：

一個能讓你給智能體持久角色和技能的平台（我們用 Zero，Lucas 就在這上面）。
連接你現有工具的連接器：CMS、關鍵字研究工具、圖片生成器、Slack。
一小組針對品牌調整的技能（我們是 draw 畫封面、copywriting 控語氣）。
能承載上下文的常駐指令，讓提示可以很短。

開始免費 Zero 工作區 →

如果你想多看幾個智能體工作流程再決定，也可以到我們的用例庫，裡面有 19 個現成可複製的自動化，涵蓋工程、產品、行銷、營運。

如果你想直接複製 Lucas：建立一個智能體，給他 Marketing manager 角色，連接 Strapi（或你的 CMS）+ Ahrefs + 圖片生成工具，加一個依你需求調整的 draw 技能，以及一個捕捉品牌語氣的 copywriting 技能。剩下的他會從你的第一個提示自己摸索。