AI 內容管線：一份 Markdown 發佈所有平台

你剛發了一篇部落格文章。現在再做四次。

晚上九點。你按下「發佈」，一篇 2,000 字的 git worktree 技術文章上線了。寫得好。範例清楚。你覺得結束了。

你沒有結束。

你的 Twitter 讀者要一串精悍的 thread -- 六則推文，每則 280 字元以內，像個迷你故事。LinkedIn 上的人要一篇打磨過的觀點 -- 專業語氣，前兩行要有 hook，底下掛 hashtag。電子報訂閱者想要個人版 -- 「我為什麼在乎這件事」的角度，加一個幕後花絮。dev.to 要一篇跨發文，要有 canonical URL、頂部加 TL;DR、開場重寫成社群調性。

四個平台。四種格式。四種語調。同樣的想法，不同的容器。

每個改寫花 15 到 30 分鐘。你開四個分頁，複製原文，開始重塑。到第三個的時候，你已經在偷工減料。LinkedIn 貼文變成敷衍的摘要。電子報失去了讓原文值得讀的技術深度。

問題是：這根本不是寫作問題。這是一個 pipeline 問題穿了寫作的外衣。核心內容已經存在。轉換是機械性的 -- 調語氣、套字數限制、重排版。就像同一份原始碼編譯給不同架構用。邏輯不變，只有輸出格式變了。

機械性的轉換，正是 AI agent 擅長的事。

這篇文章教你建一條內容 pipeline，輸入一個 Markdown 檔案，輸出 Twitter/X、LinkedIn、電子報和 dev.to 四個平台的成品 -- 一個指令搞定。

架構：先收束、再扇出

想像一條工廠產線。原料從一端進來。第一個工站：品質檢驗 -- 這塊材料的組成是什麼？最強的特性是什麼？檢驗報告跟著材料走到每一個後續工站。每個工站替不同的客戶塑形，但它們都根據同一份檢驗報告作業。

這條 pipeline 的運作方式一模一樣。兩個階段。

第一階段：基礎分析。 讀取 Markdown 原始檔，萃取核心訊息、主要論點、支撐證據、可引用的金句。建立對內容的共同理解。

第二階段：扇出。 把萃取出的結構同時送給多個平台適配器，平行產出。每個適配器知道自己平台的規則，據此重塑內容。

為什麼不跳過第一階段，直接把原始 Markdown 丟給四個平台 prompt？因為每個 prompt 會各自決定「重點是什麼」。結果發散。一個抓到程式碼範例，一個糾結在生產力角度，第三個發明一個原文根本沒有的論點。基礎分析階段是單一事實來源。每個適配器從同一個基礎出發。

這是標準的 prompt chaining 模式 -- 把複雜任務拆成聚焦的階段，每階段的輸出餵給下一階段。第二階段的扇出代表四個平台版本同時產生，不是依序等待。處理一篇 2,000 字的文章，整條 pipeline 在 8 到 15 秒內跑完。

實例：Git Worktrees 部落格文章

拿具體例子說明。假設你要把一篇「Git Worktrees：不用切 branch 的平行開發」轉成四個平台格式。原文 1,800 字，涵蓋 git worktree 是什麼、為什麼能消除上下文切換成本、怎麼搭配 AI CLI agent 使用。

第一步：定義各平台輸出 Schema

每個平台有不同的限制。把 schema 想成工廠裡的模具 -- 它們強制輸出符合各平台期望的形狀。用 structured output 定義，讓 agent 產出可機器解析的 JSON，不是自由格式的文字。

{
  "twitter_thread": {
    "tweets": [
      { "text": "string (最多 280 字元)", "position": "number" }
    ],
    "thread_length": "number (5-12 則)"
  },
  "linkedin_post": {
    "hook": "string (最多 150 字元，第一行可見文字)",
    "body": "string (最多 3000 字元)",
    "hashtags": "string[] (3-5 個標籤)"
  },
  "newsletter": {
    "subject_line": "string (最多 60 字元)",
    "preview_text": "string (最多 90 字元)",
    "body_html": "string (600-800 字)",
    "cta_text": "string",
    "cta_url": "string"
  },
  "devto": {
    "title": "string",
    "tags": "string[] (最多 4 個)",
    "canonical_url": "string",
    "body_markdown": "string (從原文改寫)"
  }
}

兩個用途。第一，schema 約束 agent 的輸出，確保產出符合各平台要求 -- 不會有 400 字元的推文，不會有少了 hook 的 LinkedIn 貼文。第二，輸出可以被程式直接消化。JSON 可以直接接上發文腳本或 CMS API，不用手動複製貼上。

第二步：在 CLAUDE.md 設定平台語氣

CLAUDE.md 就像釘在工廠牆上的品管手冊。每個工人（每個 prompt）都看得到。加入內容 pipeline 區段，編碼各平台的語氣和風格規則。

## Content Pipeline -- Platform Adaptation Rules

### Twitter/X Thread
- Open with a bold claim or surprising stat. No "I just wrote about..."
- Each tweet must standalone but flow as a narrative
- Use short sentences. One idea per tweet.
- End with a concrete takeaway or call-to-read
- No hashtags in thread body. One relevant hashtag in the final tweet only.
- Technical terms are fine. Jargon is not.

### LinkedIn Post
- First two lines must hook. LinkedIn truncates after ~210 chars.
- Professional but not corporate. Write like a senior engineer, not a marketing team.
- Use line breaks aggressively. Dense paragraphs die on LinkedIn.
- End with a question to drive comments.
- 3-5 hashtags at the bottom, separated from the body.

### Newsletter
- Write as if speaking to a colleague over coffee.
- Assume the reader has 2 minutes. Front-load value.
- Include one thing the blog post does not: a personal observation or behind-the-scenes detail.
- CTA links to the full blog post.

### dev.to Cross-Post
- Add a canonical URL pointing to the original.
- Rewrite the introduction to fit dev.to culture: practical, slightly informal, community-oriented.
- Keep all code blocks and technical depth intact.
- Add a "TL;DR" section at the top that the original may not have.

第三步：Pipeline 腳本

以下是完整的 shell 腳本。用 Claude Code 的 headless 模式（-p 旗標）搭配 structured output。把每個 claude -p 想成產線上的一個工站 -- 它們都收到同一份分析報告，但各自產出不同的成品。

#!/bin/bash
set -euo pipefail

# ── 設定 ───────────────────────────────────────────────────────
SOURCE_FILE="${1:?用法: ./content-pipeline.sh <markdown-file>}"
OUTPUT_DIR="./dist/content-$(date +%Y%m%d-%H%M%S)"
BLOG_BASE_URL="https://yourdomain.com/blog"
SLUG=$(basename "$SOURCE_FILE" .md)

mkdir -p "$OUTPUT_DIR"

# ── 第一階段：基礎分析 ─────────────────────────────────────────
echo "[1/3] 分析原始內容..."
claude -p "
Read the file $SOURCE_FILE and extract:
1. The single core message in one sentence.
2. The 3-5 key arguments, each in one sentence.
3. Up to 5 quotable lines (punchy, self-contained phrases).
4. The target audience (who benefits from reading this).
5. One surprising or counterintuitive claim from the article.

Output as JSON with keys: core_message, key_arguments, quotable_lines,
target_audience, surprising_claim.
" --output-format json > "$OUTPUT_DIR/analysis.json"

echo "  分析結果已存至 $OUTPUT_DIR/analysis.json"

# ── 第二階段：扇出至所有平台（平行） ──────────────────────────
echo "[2/3] 產生各平台版本..."

# Twitter/X 串文
claude -p "
You are a content adapter. Using the source file $SOURCE_FILE and the
analysis in $OUTPUT_DIR/analysis.json, create a Twitter/X thread.

Rules from CLAUDE.md apply. Output as JSON matching the twitter_thread
schema: an array of tweet objects with text (max 280 chars) and position.
Thread length: 5-12 tweets.
" --output-format json > "$OUTPUT_DIR/twitter.json" &
PID_TWITTER=$!

# LinkedIn 貼文
claude -p "
You are a content adapter. Using the source file $SOURCE_FILE and the
analysis in $OUTPUT_DIR/analysis.json, create a LinkedIn post.

Rules from CLAUDE.md apply. Output as JSON matching the linkedin_post
schema: hook (max 150 chars), body (max 3000 chars), hashtags (3-5).
" --output-format json > "$OUTPUT_DIR/linkedin.json" &
PID_LINKEDIN=$!

# 電子報
claude -p "
You are a content adapter. Using the source file $SOURCE_FILE and the
analysis in $OUTPUT_DIR/analysis.json, create a newsletter edition.

Rules from CLAUDE.md apply. Output as JSON matching the newsletter schema:
subject_line (max 60 chars), preview_text (max 90 chars), body_html
(600-800 words), cta_text, cta_url (use $BLOG_BASE_URL/$SLUG).
" --output-format json > "$OUTPUT_DIR/newsletter.json" &
PID_NEWSLETTER=$!

# dev.to 跨發文
claude -p "
You are a content adapter. Using the source file $SOURCE_FILE and the
analysis in $OUTPUT_DIR/analysis.json, create a dev.to cross-post.

Rules from CLAUDE.md apply. Output as JSON matching the devto schema:
title, tags (max 4), canonical_url ($BLOG_BASE_URL/$SLUG),
body_markdown (full article adapted for dev.to).
" --output-format json > "$OUTPUT_DIR/devto.json" &
PID_DEVTO=$!

# 等待所有平台適配完成
wait $PID_TWITTER $PID_LINKEDIN $PID_NEWSLETTER $PID_DEVTO

echo "  所有平台版本已產生。"

# ── 第三階段：摘要 ─────────────────────────────────────────────
echo "[3/3] 管線完成。輸出："
echo "  $OUTPUT_DIR/analysis.json    -- 基礎內容分析"
echo "  $OUTPUT_DIR/twitter.json     -- Twitter/X 串文"
echo "  $OUTPUT_DIR/linkedin.json    -- LinkedIn 貼文"
echo "  $OUTPUT_DIR/newsletter.json  -- 電子報"
echo "  $OUTPUT_DIR/devto.json       -- dev.to 跨發文"
echo ""
echo "所有呼叫的 token 總量："
cat "$OUTPUT_DIR"/*.json | wc -c | awk '{printf "  ~%.0f 輸出字元\n", $1}'

關鍵細節是每個平台指令後面的 & 和最後的 wait。四個平台適配作為平行背景程序同時跑 -- 四個同時進行的 API 呼叫。總牆鐘時間等於最慢的那一個（通常是電子報，8-12 秒），不是四個加總。就像四個廚師同時顧四個爐子，不是一個廚師依序顧四個。

第四步：執行

chmod +x content-pipeline.sh
./content-pipeline.sh posts/git-worktrees-parallel-dev.md

輸出：

[1/3] 分析原始內容...
  分析結果已存至 ./dist/content-20260322-143022/analysis.json
[2/3] 產生各平台版本...
  所有平台版本已產生。
[3/3] 管線完成。輸出：
  ./dist/content-20260322-143022/analysis.json    -- 基礎內容分析
  ./dist/content-20260322-143022/twitter.json     -- Twitter/X 串文
  ./dist/content-20260322-143022/linkedin.json    -- LinkedIn 貼文
  ./dist/content-20260322-143022/newsletter.json  -- 電子報
  ./dist/content-20260322-143022/devto.json       -- dev.to 跨發文

範例輸出：Twitter/X 串文

Pipeline 為 git worktrees 文章產出的結果：

Tweet 1:
Git worktrees let you work on three features simultaneously
without stashing, switching branches, or losing your terminal state.
Most developers have never heard of them.

Tweet 2:
The problem: you are deep in a feature branch. A hotfix comes in.
You stash, switch branches, fix, commit, switch back, pop stash.
Context destroyed. Flow state gone. This happens 5-10 times a week.

Tweet 3:
git worktree add ../hotfix main
That command creates a second working directory linked to the same repo.
Your feature branch stays untouched. Open the hotfix dir in a new pane.

Tweet 4:
Each worktree has its own working directory, its own HEAD,
its own index. But they share the same .git object store.
No cloning. No duplicate history. Instant creation.

Tweet 5:
The real power: pair worktrees with AI CLI agents.
One agent refactors in worktree A. Another writes tests in worktree B.
They run in parallel. No merge conflicts because they touch different files.

Tweet 6:
Three worktrees. Three terminal panes. Three agents working simultaneously.
That is not a future workflow. That is Tuesday.
Full guide: [link]

範例輸出：LinkedIn 貼文

Most developers context-switch 5-10 times per day between branches.

Each switch means stashing work, losing terminal state, and rebuilding
mental context. It takes 15-25 minutes to recover deep focus after
an interruption. The math is brutal: 5 switches x 20 minutes = nearly
2 hours lost daily.

Git worktrees eliminate this entirely. One command creates a parallel
working directory on a different branch. Your current work stays
untouched. No stashing. No switching. No lost state.

I have been running three worktrees simultaneously with AI CLI agents --
one per feature, each in its own terminal pane. The agents work in
parallel because they operate on isolated directory trees.

The setup takes 5 minutes. The time savings compound every single day.

What is the most time you have lost to a single context switch?

#git #developerproductivity #terminalworkflow #aitools

範例輸出：電子報

Subject: The git command that mass-produces flow state
Preview: You probably haven't used git worktree. You should.

Hi --

I spent last week rewriting how I handle parallel development,
and the results were dramatic enough to share immediately.

The core idea: git worktree lets you have multiple working directories
from the same repository, each on a different branch, all active
simultaneously. When a hotfix interrupts your feature work, you do not
stash and switch. You open a new directory and fix it there. Your
feature branch never notices.

What the blog post does not mention: I resisted worktrees for two years
because the name sounded like a data structure lecture. The actual UX
is one command: git worktree add ../hotfix main. That is it.

Pair this with terminal panes (one per worktree) and an AI CLI agent
in each, and you get genuine parallel development. Three features
progressing simultaneously. No merge conflicts because each worktree
operates on isolated files.

The full technical breakdown, including the multi-agent setup, is here:
[Read the full post]

-- Danny

範例輸出：dev.to 跨發文

---
title: "Git Worktrees: Parallel Development Without the Branch-Switching Tax"
tags: [git, productivity, terminal, ai]
canonical_url: https://yourdomain.com/blog/git-worktrees-parallel-dev
---

## TL;DR
Git worktrees let you check out multiple branches simultaneously in
separate directories from the same repo. Combined with AI CLI agents
in parallel terminal panes, you get true concurrent development with
zero context-switching overhead.

---

Hey dev.to -- if you have ever lost 20 minutes of focus because
a hotfix forced you to stash and switch branches, this one is for you.

[完整文章內容保留所有程式碼區塊，開場改寫以符合 dev.to 社群風格，
canonical URL 指向原文...]

成本比較：手動改寫 vs. AI Pipeline

來看數字。

有趣的地方來了。Token 用量細目：一篇 2,000 字原始文章跑一次 pipeline，基礎分析階段大約用 3,000 input token 和 500 output token。每個平台適配器大約用 4,000 input token（原文加分析結果）和 800-2,000 output token，依格式長度而異。五次呼叫合計：大約 25,000 input token 和 6,000 output token。用 Claude Sonnet 算，每次不到 $0.15 美元。用 Opus 追求更高品質，大約 $0.40 美元。

如果把所有平台打成一個 batch request 而不是個別呼叫，成本降約 50%。Batch 處理用延遲換省錢 -- 結果在幾小時內送達而非幾秒。不急著發的內容，一次 batch 處理八篇，每篇成本降到 $0.10 美元以下。比一顆口香糖還便宜。

擴展 Pipeline

腳本處理四個平台。加更多就像在產線上多加一個工站 -- 複製一個平台區塊、調整 prompt 和 schema、加一個背景程序。常見延伸：

• Hacker News 投稿：標題加 2-3 句提交留言
• Reddit 貼文：特定子版語氣、自發文格式、必選 flair
• Podcast 節目筆記：條列式摘要、時間戳定位點、來賓引言擷取
• 簡報大綱：每張投影片一個重點、講者備註、視覺建議

每個延伸就是扇出階段多一個 claude -p 呼叫。

你也可以在扇出之後串接一個 review 階段：一個最終 prompt 讀取所有產出版本，檢查事實不一致、語氣偏移、偏離基礎分析的內容。把它想成產線尾端的品管員。多花 3-5 秒，但能攔住偶爾出現的幻覺 -- 某個平台版本捏造了原文沒有的統計數據。

多面板的優勢

Pipeline 跑完了。三十秒後，四個 JSON 檔躺在輸出目錄裡。自然的問題：「這些東西可以直接發嗎？」

你需要同時審查四種不同格式的輸出。有效率的做法是一次全部看到。一個終端面板顯示 Twitter thread，另一個顯示 LinkedIn 貼文，第三個渲染電子報 HTML，第四個顯示 dev.to Markdown。

四個面板一次掃過。你發現某則推文超過 280 字元。你注意到 LinkedIn hook 太空泛。你抓到電子報漏掉了一個 Twitter thread 有保留的關鍵論點。調整 CLAUDE.md 規則，重跑一次。

對比一下在單一終端依序檢查每個輸出檔。看到第四個的時候，你已經忘了第一個有沒有涵蓋同一個關鍵論點。並排比較不是奢侈品 -- 它是你維持跨平台版本一致性的方式。跟 code review 工具把 diff 並排顯示是同一個道理。

總結

內容 pipeline 的模式很簡單：分析一次，平行適配。一個 Markdown 檔案在 30 秒內變成五個平台版本，每次成本 $0.15-0.40 美元。Structured output schema 像模具一樣確保每個版本遵守平台限制。CLAUDE.md 編碼你的語調和風格規則，讓 agent 不會滑向空泛的行銷文案。

最大的槓桿來自扇出架構。四個平台適配同時跑，代表 pipeline 的牆鐘時間不會因為多加目標平台而明顯成長。寫一次，發佈所有地方 -- 不是口號，是你今天就能跑的一個 shell 腳本。