![[代理程式設計 #3] AI 內容管線設計：從生成到發佈 封面圖](/assets/images/posts/1dba3ed2-79c4-4348-b5e7-3014c4d498aa/ai-content-pipeline-1.jpg)
提到用 AI 製作內容，通常會想到「一個提示詞搞定」。但一次生成的結果品質參差不齊，最後還是得由人全部修改。
如果換個角度，把生成像工廠產線一樣拆成多個階段，會怎麼樣？將草稿生成、品質審核、圖片生成與發佈各自設為獨立流程，並在流程之間加入驗證。
我實際運作了以這種結構自動產生部落格文章的管線，並整理從中得到的設計原則。雖然案例來自特定領域，但結構本身可以移植到任何 AI 自動化流程。
本文整理管線的階段組成、各階段之間的驗證機制，以及失敗處理設計。
先從重點摘要開始。
- 生成管線的骨架，是將生成 → 審核 → 資產建立 → 發佈分成不同階段
- 固定每個階段的輸出結構，就能進行中間驗證與重試
- 品質審核也是自動化對象。加入與生成模型不同觀點的審核階段
- 失敗是前提。無論在哪個階段中斷，都能保留原始內容才是設計重點
階段分離：與一次生成的決定性差異
管線的骨架如下。
關鍵字輸入 → 內文生成 → 文體審核（潤稿） → 圖片生成 → 儲存 → 發佈。每個階段都是獨立流程，只接收前一階段的輸出作為輸入。
相較於一次生成，有三個優點。
- 分階段重試：即使圖片生成失敗，內文仍然存在。只要重新執行失敗的流程
- 分階段替換：即使替換文體審核邏輯，也不必修改生成階段
- 分階段量測：可以透過指標追蹤品質在哪個流程中出現問題
模組化系列介紹的內聚力與耦合度原則可以直接套用。把會一起變動的邏輯放在一起，流程之間則透過結構通訊。
固定輸出結構
要讓階段分離成立，有一個必要條件：每個階段的輸出都必須是可驗證的形式。
在這條管線中，內文生成階段的輸出結構固定為「標題候選陣列＋內文＋圖片提示詞陣列＋標籤陣列」。內文中的圖片位置則以 [圖片標記]這類規約表示。
固定結構後，管線程式碼就能驗證 LLM 輸出，而不是直接信任它。
| 驗證項目 | 失敗時的處理 |
|---|---|
| 必要欄位是否存在 | 重試生成 |
| 圖片標記數量＝提示詞數量 | 重試生成 |
| 審核後標記是否受損 | 捨棄審核結果，保留原文 |
LLM 加入管線的瞬間，輸出就不再是「相信的東西」，而是「需要驗證的東西」。結構就是驗證的基準線。
審核也是獨立流程
文體審核階段很有意思。AI 撰寫的文章會留下特有痕跡，例如單調節奏、翻譯腔與機械式平行結構，因此我把去除這些痕跡的潤稿拆成獨立的 LLM 流程。
比起在生成提示詞中加入「請自然地撰寫」，分離流程更好的理由在這裡。
生成階段只專注內容正確性，審核階段只專注文體。把兩個目標塞進同一個提示詞，兩邊都會做得半吊子；拆開流程後，每個階段只需最佳化自己的單一目標。
這可以說是套用到提示詞上的單一職責原則。
這裡有一項規則：審核流程絕對不能改動內容、數值或引用，只能調整文體。
因此審核後會以機械方式比對圖片標記與關鍵數值是否保留；偵測到損壞時，就捨棄審核結果並使用原文。
以失敗為前提進行設計
從 LLM 呼叫、圖片生成 API 到渲染工具，管線中的所有外部呼叫都可能失敗。因此失敗處理不是附加功能，而是骨架本身。
原則有三個。
第一，保留原始內容。任何流程都不會覆寫前一階段的輸出。審核失敗時，原文必須完整保留。
第二，允許部分成功。四張圖片中若有一張失敗，就儲存成功的三張並記錄失敗即可。全部回滾是過度處理。
第三，讓失敗可視化。不要吞掉錯誤，而要記錄在狀態欄位中，讓人員能從儀表板只重新執行失敗流程。
總結
總結來說，AI 自動化的品質來自流程設計，而不是模型：拆分階段、用結構驗證，並為失敗進行設計。
傳統管線工程的原則，在 LLM 時代依然完全有效。
搭配閱讀 Harness Engineering 與 Context Engineering 篇章，就能描繪出「善用模型的技術」全貌。