Hub 達人實戰

達人實戰 · 行銷與內容

內容創作達人：靈感不缺，缺的是研究排版壓圖的時間

內容創作向來不是缺靈感，是研究、排版、壓圖、發布這些瑣事最耗時間。這篇用四個真實工作流告訴你：把重複流程交給 Claude Code，人力留給真正需要判斷力的地方。

這行的痛點

內容創作從來不是「寫」佔多數時間——研究、選圖、壓圖、發布、跨平台改寫，才是吃掉一整天的部分。這正是 CLI 型 AI agent 的甜蜜點：它能扛起「寫作以外的一切」，把人力留給真正需要判斷力與個人風格的地方。

這行還有一個特徵：內容創作者常常一人身兼多角——研究員、編輯、SEO 最佳化師、社群小編、發布工程師都是同一個人。Claude Code 能同時開多個 subagent、跑多步驟管線，剛好對應這種「一人公司」的工作型態。

更重要的是，內容創作重複性高（每週電子報、每篇部落格都要走同一套流程），但每次的素材不同——這正是「Skill 化」最適合的場景：把固定流程封裝成可重複呼叫的步驟，素材換了，流程不用重講一次。

動手前的準備

  • 先看 Claude Code 教學第 1 章，把 CLI 裝好、跑過基本對話與檔案操作，這章不重複安裝步驟。
  • 準備一個你已經在用的內容管線最小單位：一篇部落格草稿資料夾，或一份電子報範本，讓 Claude Code 有真實檔案可以動手，不要空手練習。
  • 如果要串外部服務（Kit/ConvertKit、WordPress、Contentful 等）的 API，先申請好 API 金鑰，存進 .env 並加進 .gitignore，不要把金鑰貼進對話。
  • 把你慣用的語氣規則、禁用詞清單、品牌用語整理成一份文字檔，這會變成你的 CLAUDE.md 骨架，省下之後每次對話重講一次的力氣。

場景一：SEO 內容工程生產線

Ryan Law 是 Ahrefs 內容行銷總監，14 年寫作與內容策略資歷。他的痛點是：一篇 SEO 文章從關鍵字研究到出稿，要跑完關鍵字研究、內容缺口分析、大綱、初稿、SEO 最佳化一整套編輯部流程，過去用 ChatGPT 輔助仍要「幾天到幾小時」。

Claude Code 怎麼做

  1. 拆解成 23 個獨立 Skill

    把整個編輯部流程拆解成約 23 個獨立步驟，每一步寫成一個 Skill：關鍵字研究、內容缺口分析、大綱、初稿、SEO 最佳化——各自能單獨測試、單獨重跑。

  2. 寫一個 master skill 串起全部

    寫一個 master skill（blog-pipeline）把這些串起來，一次呼叫就從關鍵字跑到接近完稿的文章。依 Ryan Law 描述的架構，實際操作大致是這樣：

    /blog-pipeline
關鍵字：project management software for remote teams
要求：拉 Ahrefs Keywords Explorer 的 Content Gap 資料，
對比目前排名前 10 的文章找出內容缺口，
大綱先給我看一次再往下寫。

  3. 每階段輸出存成獨立檔案

    每個階段的輸出都存成獨立的 Markdown 檔，某一階段跑歪了只重跑那一階段，不必診斷整條長流程。

  4. 資料來源接四路

    資料來源接四路：Ahrefs MCP（關鍵字量、長尾詞、SERP 概覽）、競品文章分析、deep research 查核來源、產品文件。

  5. 開跑前先給高階方向

    開跑前用 context 參數給高階方向（例如「要帶到 Content Gap 工具」），而不是等產出後才大改。

  6. 轉成 HTML 預覽直接審稿

    產出轉成部落格風格的 HTML 預覽，直接在瀏覽器裡審稿。

成效：6–12 分鐘產出接近可發布的草稿，已用這套系統發布約 15 篇新文章、更新約 30 篇舊文，讀者未察覺品質變化。但 Ryan Law 講得很白：這套系統能動，是因為 skill 檔裡灌的是他 14 年編輯部經驗；每篇發布前他仍逐字讀完。

換成 Codex CLI

Codex CLI 目前找不到內容創作者用它搭建 SEO 編輯部管線的第一手案例，但用它的通用能力應該也能做到類似效果：Codex 沒有 Claude Code 那種 SKILL.md + scripts/ + references/ 的封裝系統，比較接近的做法是把每個編輯階段寫成獨立的 prompt 文字檔，透過 codex exec 非互動模式一階段接一階段跑管線，例如：

cat outline.md | codex exec "根據這份大綱寫一版 SEO 最佳化過的初稿" --output-schema draft-schema.json

用 --output-schema 把每階段結果規格化再往下傳。差別在於 Claude Code 的 skill 是「寫一次，之後用指令直接呼叫」，Codex 這條路更接近「自己手工串 shell 管線」，沒有現成的封裝機制。

場景二：台灣寫作教練的內容生產線

鄭緯筌（Vista）是企業顧問、AI 講師、《內容感動行銷》等 20+ 本書作者，「自媒體大學」創辦人，電子報訂閱 18,500+。他的痛點：一篇部落格文章從構想到發布要 5–6 小時，其中大半不是「寫作」本身，而是研究、排版、壓圖、部署。

Claude Code 怎麼做

五個階段：

  1. 研究（約 10 分鐘）

    讓 Claude Code 自主上網搜尋、讀文章，整理成含出處的結構化摘要。這步他強調不可跳過——本人必須讀過研究結果，標註自己的觀察與觀點。

    幫我研究「遠距工作團隊如何維持向心力」這個題目，
整理成有出處的摘要，先不要寫初稿，
我要自己看過再決定切角。

  2. 大綱與初稿（約 15 分鐘）

    給框架級指示（敘事結構、開場方式），不是放任自由發揮，AI 依大綱展開初稿。

  3. 人工潤飾（20–30 分鐘）

    加個人故事與親身經歷、調語氣（更口語、少公文腔）、刪贅詞、加站內相關文章連結。

  4. 圖片處理（約 5 分鐘）

    Claude Code 自動轉 WebP、縮圖、整理檔案——過去這件事要 30 分鐘。

  5. 發布（約 2 分鐘）

    部落格架在 Astro + Cloudflare Pages，Claude Code 直接 git commit、push，觸發自動部署。

成效：單篇文章 5–6 小時壓到約 1 小時。他的原句可直接引用：「真正的效率提升，不是讓 AI 替你寫，而是讓 AI 替你處理寫作以外的一切。」

換成 Codex CLI

Codex CLI 目前找不到像鄭緯筌這樣完整五階段部落格工作流的第一手案例，但用它的通用能力應該也能做到類似效果：技術寫作者 Aman Mittal 實測過「終端機 agent 直接進 Markdown vault 做多輪審閱」，理論上可以套用在潤飾階段。但要留意 Nils Durner 實測到的弱點——Codex 以約 250 行為單位分塊讀檔、靠關鍵字搜尋選讀而非全文通讀，對一篇完整部落格文章的跨段落一致性（語氣、前後呼應），表現不如 Claude Code 一次讀完整檔穩定，這是寫作場景要留意的已知弱點。

場景三：電子報自動化，30 分鐘壓到 2 分鐘

Sid Bharath 用 Astro + Tailwind 自建部落格，訂閱者一直有在增加，但電子報寄得極不穩定：「好的月份寄 2 封，有些月份 0 封。」原因是每次都要登入 Kit（前 ConvertKit）後台手工操作，摩擦太大。

Claude Code 怎麼做

寫一個 Claude Code skill（.claude/skills/ 下的 Markdown 檔，含 frontmatter 中繼資料 + 逐步指示）：

  1. 找內容

    讀 .content/content-index.json，過濾出最近 7 天發布的文章（排除草稿）。

  2. 起草

    抽出文章標題、描述、摘要，用他本人的語氣寫輕鬆的信件文案，風格規則明寫「不用 em dash、不用浮誇語言、不用任何 AI 慣用腔」，輸出成適合信件範本的簡單 HTML。

  3. 人工審核閘

    先顯示主旨與內文給本人核可，核可前不碰 Kit。

  4. Kit API 整合

    核可後 POST https://api.kit.com/v4/broadcasts 建立 broadcast 草稿。

  5. 可選排程

    用 PUT 更新 published_at，支援自然語言預設（「Tuesday morning」→ 下週二上午 10 點 EST）。

實際 prompt 大致長這樣：

幫我看 .content/content-index.json 裡最近 7 天發布、
非草稿的文章，草擬一封電子報：
主旨要短、內文用我平常的口語語氣，
不要 em dash、不要「立即行動」這類推銷腔。
寫完先給我看，我核可後才呼叫 Kit API 建立草稿。

API 金鑰放 .env 並加入 .gitignore，先用 curl 打帳號端點驗證金鑰可用。

成效：每週電子報從 30+ 分鐘壓到約 2 分鐘；頻率從「每月 0–2 封」變成穩定週更。Kit API 本身也有限制：表單唯讀，不能程式化建立 sequence 與視覺化自動化流程，這些仍得手工。

換成 Codex CLI

Codex CLI 目前找不到電子報自動發送這個場景的第一手案例，但用它的通用能力應該也能做到類似效果：官方文件明列 codex exec 可以接管線、--output-schema 依 JSON Schema 出結構化結果，理論上能做到「讀文章清單 → 生成信件文案 → 輸出 JSON → 由外部腳本呼叫 Kit API」的同款流程，例如：

codex exec "讀 content-index.json 挑出最近 7 天文章，寫一封電子報草稿" --output-schema newsletter-schema.json -o draft.json

但這是延伸自 codex exec 官方非互動模式能力的推論，不是已驗證的電子報自動化案例；「先顯示草稿等核可才發送」這種閘門，Codex 沒有內建慣例可以直接抄，得自己在外部腳本裡加。

場景四：一人公司的 25 個 Skill 系統

侯智薰（雷蒙）經營 Lifehacker Taiwan，一人公司、10,000+ 學員線上課講師。痛點：內容產出、WordPress 發布、信件處理等重複流程，每次都要重新教 AI。

Claude Code 怎麼做

他的核心心法可以直接引用：「如果 CLAUDE.md 是『入職手冊』，那 Skills 就是『標準作業程序』。」

  • CLAUDE.md 管「記住你是誰」：語言偏好、寫作風格、資料夾結構、背景知識——跨對話通用的規則。
  • SKILL.md 管「記住怎麼做事」：每個 skill 是一項任務的 SOP，教一次、重複用。

他個人維護 25 個 skill，與內容創作直接相關的有 content-writing（鎖定個人語氣、範本、慣用詞彙）、wordpress（API 整合、文章分類、block 排版）、email-assistant（信件分類規則、回信語氣、合作案評估流程）、notion-api、web-design。資料夾結構：

~/.claude/skills/                 ← 全域（所有專案）
專案/.claude/skills/              ← 專案限定
  └── skill-name/
      ├── SKILL.md               ← 指示本體（YAML frontmatter + Markdown）
      ├── references/            ← 參考文件
      └── scripts/               ← 自動化腳本

他明文警告三條：別盲裝別人的 skill（先叫 AI 分析共享 skill 有無多餘權限或可疑腳本再採用）；別把所有東西塞進 CLAUDE.md（長流程該獨立成 skill，否則核心檔臃腫）；別整包照抄（學邏輯、改成自己的，比複製別人的解法更有價值）。

換成 Codex CLI

這個場景可以做真正的架構對照，不必打折：Codex CLI 用 /init 指令生成 AGENTS.md，功能上對應 Claude Code 的 CLAUDE.md——一樣是專案根目錄放一份、每次 session 自動讀取、寫入個人寫作風格與編輯優先順序，技術寫作者 Aman Mittal 與 Nils Durner 都實測過這個做法。差別在下一層：Codex 沒有 Claude Code 這種 SKILL.md + references/ + scripts/ 的封裝系統可以疊 25 個獨立、可重複呼叫的 SOP，只能把規則都往同一份 AGENTS.md 裡塞，或自己手工管理多份 prompt 文字檔——雷蒙提醒的「別把所有東西塞進 CLAUDE.md」這條，換成 Codex 反而是結構上的限制，不是選擇。

常踩的坑

四個容易踩到的雷

  • AI 內容預設不會是好內容（達人實測）：Ryan Law 明講這套系統能動，是因為 skill 檔裡灌的是他十幾年編輯部經驗；跳過人工終審，讀者一眼看穿是空殼文，鄭緯筌也有同款警告。
  • 編造引用來源、捏造資料的風險（社群觀察，Hacker News 討論串）：HN 使用者回報 agent 有「偷吃步」行為（刪測試檔避免除錯、改測試讓它通過），寫作場景的對應風險是編造引用或資料，研究結果必須人工讀過再標註自己的觀察。
  • 別盲裝別人的 skill（達人實測，雷蒙明文警告）：共享 skill 可能藏多餘權限或可疑腳本，用前先叫 AI 分析一遍，這是供應鏈安全問題，不是龜毛。
  • Codex CLI 長文件一致性弱點（達人實測，Nils Durner）：以約 250 行為單位分塊讀檔、靠關鍵字搜尋選讀而非全文通讀，跨段落／跨文件的風格與引用一致性會打折扣，長篇寫作要留意。

延伸資源