昨天文章最後，我預告要把發文、會議與影片三條產線攤在同一張責任表裡。今天先不加入第三條線。

因為把會議紀錄和影片深讀放在一起後，會先碰到一個更基本的問題：兩邊都有 AI、有步驟，也留下不少產物，這樣就能叫「自動化工作流」嗎？

如果每次開始前，仍要人重新選流程、貼資料、搬結果，再臨場決定下一步，AI 的確做了事，但控制流還在人的腦袋裡。這比較像一連串 AI 任務，不是一條已經接起來的自動化。

所以 Day 7 不再示範一個新工具。我想先替第一週收一個 checkpoint：AI 是執行元件，自動化是人設計的控制流。

下面我會先把三個層級分清楚，再拿前兩天的案例逐段檢查。

把第一週的題目排在一起，其實是同一條線

照目前的系列地圖，Day 1 已先把整座內容工廠攤開；Day 2 預計盤點手上有哪些工作流；Day 3、4 預計把能機檢的規則搬出 Prompt，再回頭測試那道品質閘門。Day 5、6 的待審草稿，則分別拆會議錄音與影片怎麼變成可回查的內容。

把這些題目排在一起，難點就浮出來了。工具之間怎麼交接：誰決定現在該走哪條路、輸入不合格時誰喊停、AI 完成一段工作後要留下什麼，以及失敗時能不能從正確的位置回來。

少了這些交接，一個 Skill 寫得再完整，仍可能只是「下次可以照著做」。有了固定 Prompt，也只代表任務比較容易重複。要走到自動化，還得把藏在人工操作裡的判斷變成看得見的狀態與規則。

一次 AI 任務、可重跑 workflow、自動化工作流

為了不要一看到 Agent、排程或 API 就把整條流程塗成「自動化」，這篇先用三個層級來檢查。

這不是 ISO、BPMN 或哪一套平台的正式成熟度模型，只是我拿來檢查內容產線的一把尺。它刻意不問「用了多強的模型」，而是問每一段交接目前由誰完成。

有一個常見誤會也要先拆掉：人工按下開始，不代表它就不是自動化。

GitHub Actions 的 workflow_dispatch 就是很直接的例子。人可以從網頁、GitHub CLI 或 REST API 啟動一條已經定義好的 workflow。要檢查的不是「有沒有人按按鈕」，而是按下去之後，步驟與狀態是否照既定控制流接續。

同樣地，中途需要人工批准，也不會讓自動化失效。批准本來就可以是一個明確 state。問題只在於：系統會不會真的停在那裡等人，還是 Prompt 裡寫一句「請先確認」，模型照樣一路做完。

自動化的主角不是 Agent，是 control flow

把內容工作流拉遠一點看，我會先拆成四段：

1. CHOOSE：我、明確入口，或我預先定義的 deterministic policy 先選定 workflow。
2. VALIDATE：程式核對輸入契約；格式、權限或必要資料不符合就停止。
3. TRANSFORM：AI 只在固定 stages 裡轉換內容，並留下可以回查的 artifacts。
4. GATE：規則檢查、人工批准、輸出與失敗恢復，各自留下狀態。

我不會把「選哪條 workflow」交給模型自由猜。路由本身帶著權限、成本與發布邊界，應該先由人或 deterministic policy 決定。AI 很適合在邊界內處理模糊內容，不適合一邊解讀資料，一邊替自己擴張能做的事。

這也是內容自動化和單純 Prompt chaining 最大的差別。Prompt chaining 在意上一段回答怎麼餵給下一段；control flow 還要處理「能不能開始」「下一站是哪裡」「何時必須停」和「失敗後從哪裡回來」。

先寫一份 Automation Contract v1

為了讓這些問題可以被比較，我先替這個系列整理一份 Automation Contract v1。它不是現有 repo 已經共用的 schema，也不是新的業界標準，而是後面 23 天都能繼續補的工作底稿。

如果把 Day 6 的影片深讀先套成一份提案，大概會長這樣：

name: video-to-deep-read
trigger: ci-selected-source
input_contract: public-video-url
stages: [capture, intake, ledger, architecture, article]
artifacts: [source-cache, source-ledger, article, meta]
gates: [input-check, artifact-check]
stop_conditions: [unsupported-input, missing-source]
human_approval: required-before-author-claim
output: reviewable-article
failure_recovery: resume-from-last-valid-artifact

這份 YAML 是設計提案，不是把目前的實作換個格式抄一遍。尤其 trigger 和 failure_recovery，現有證據還不足以證明整條線已經照這份契約運作。

一次 AI 任務要走向自動化，光把 stages 寫得很完整還不夠，階段之間的狀態轉移得真的存在。AWS Step Functions 的 state machine 會明確定義每個 state 收到什麼、執行什麼，再把輸出交給下一個 state。順序不是靠檔案剛好排在一起，也不是靠模型自己記得接下來該做什麼。

失敗後只會重問 AI，還不算 recovery

一條流程在順風時能跑完，不代表它已經接好。失敗路徑才會把隱藏的人工操作全部照出來。

AWS Step Functions 的錯誤處理 會把 Retry、Catch 與 execution failure 分開。移回內容產線，可以先得到幾個很實際的判斷：

Temporal 把 durable execution 的重點放在保存 workflow 狀態。這個對照很有用：如果流程只留下最後一篇文章，沒有中間 artifact，也不知道哪一站已經成功，那麼「恢復」通常只是全部再跑一次。

重試外部動作又更麻煩。AWS Builders' Library 在 idempotent API 的文章裡提醒，前一次呼叫可能已經產生副作用，只是回覆沒有送回來。內容產線後段如果會建立頁面、部署或發送，盲目重試就可能做出兩份。

Day 7 不需要導入 Step Functions 或 Temporal。這些官方文件在這裡只負責一件事：讓 trigger、state、error path、durable state 與 idempotency 這些詞有明確的工程含義，而不是拿平台名稱替本機流程貼金。

不要替整條 workflow 一次上色

接下來是我覺得最實用的一張表：automation claim ledger。

每一段狀態轉移，都分開填兩個欄位：

• execution_mode：automated、repeatable、manual 或 unknown。它回答這一段目前怎麼接續。
• evidence_status：verified 或 unverified。它回答手上的證據能不能支撐前一欄，以及支撐的是設計還是某次執行。

這兩軸不能合併。程式碼可以證明某段設計已經寫下，卻不能證明現在每次都有執行；一份 artifact 可以證明產物存在，卻不能證明所有檔案都來自同一次 run。

我會把證據再拆成五種角色：

這不是在做一條由低到高的「證據排行榜」。五種東西回答的問題不同。把它們混在一起，才會出現「有程式碼，所以每天都在自動跑」或「頁面打得開，所以內容已經確認」這種跳躍。

把會議案例套進去：有產物，不代表交接已接上

Day 5 的會議案例，現在能核對的是一組去識別的狀態與元件：原始轉錄資料、時間戳逐字稿、純文字稿、ElevenLabs speaker_id、待確認說話者標籤、複核分段、整理後逐字稿、摘要與審閱報告。

這些 artifact 很有用。它們證明每個狀態有不同責任，也讓人能從摘要回到原話。但套進 automation claim ledger 後，仍有幾段不能直接升級：

這個結果不是說會議流程「不夠自動」。它只是把下一步講清楚：如果想提高自動化程度，要補的是 trigger、相鄰階段接法與 failure recovery，不是再寫一段更長的摘要 Prompt。

人工判斷的位置也沒有消失。speaker_id 無法可靠對應真實身分、摘要把選項寫成決定、承諾與期限需要回聽，或內容準備離開私人工作區時，workflow 應該把狀態送到人面前，停下來等答案。

再看影片案例：外層控制流和內層內容狀態要分開

Day 6 的影片案例留下 source cache、intake、source ledger、architecture、article、image storyboard、report 與 meta。這些 artifact 讓錯誤能回到不同內容層處理。

它的 wrapper 也有可以核對的 hard stop：抓不到字幕就停止；模型結束後，會檢查是否真的多出 content，並確認 meta.json 的 video_id 和輸入相符。這些 gate 驗的是輸入與交付有沒有接上，不是逐句驗證文章。

2026 年 7 月 26 日保留的紀錄，還能串起外層一次執行：播放清單輪詢找到來源，字幕快取通過，Agent 返回後由 wrapper 驗證新 content 與 video_id，接著完成 build 與 deploy。這足以把當次 outer wrapper 的控制流標成 automated / verified，但不能外推成目前排程仍長期正常運作。

但邊界要停在這裡。intake 到 source ledger、architecture、article 的內部階段，主要證據仍是產物與流程自述，沒有逐階段的獨立 trace。外層順利跑完，也不會自動證明每個主張是真的，更不等於我已經批准文章。

這也是為什麼 Day 6 那四種完成狀態不能合併：pipeline done、build 成功、HTTP 200 與 reviewed: false，分別是控制流、站台、外部可讀與人工審閱狀態。它們可以同時存在，卻不能互相代替。

兩條案例比的不是成熟度，是缺口

把會議和影片放進同一份 Contract，現在可以得到一張比較誠實的表：

老實說，替整條 workflow 打一個「自動化百分比」看起來很乾脆，卻會把每段不同的證據壓扁。我比較在意的是先挑一段轉移，寫清楚它的輸入、輸出、執行方式與證據，再決定要不要把人工交接往前推。

替自己的流程盤點時，可以照這個順序：

1. 先寫出 workflow 是怎麼被選中和啟動的。
2. 把每一段相鄰狀態拆開，不要只畫一條大箭頭。
3. 為每段填 execution_mode 與 evidence_status。
4. 標出 stop、人工批准與外部副作用。
5. 最後才問失敗後能從哪個有效 artifact 恢復。

如果填完出現很多 unknown，不是盤點失敗。它只是把原本藏在手動操作裡的工作照了出來。

第一週到這裡，驗證不是主角

走到 Day 7，前面確實花了幾篇談 gate、回查與狀態。但這個系列不是要變成「AI 驗證大全」。這些東西的用途，是把內容自動化真的接起來。

沒有 gate，錯的輸入會一路往後跑；沒有 artifact，失敗後只能重來；沒有 control flow，每次都要人臨場搬資料；沒有人工批准，模型產生的編輯判斷又會被當成作者立場。

發文、會議、影片或投影片，最後都會碰到同一組工程問題。這也是我想用內容產線來談 AI 自動化的原因：模型負責處理模糊內容，人負責定義邊界，程式負責讓狀態真的接得起來。

Day 7 先把這份 Automation Contract v1 立起來。下一篇會往第一個欄位裡鑽：workflow 已經由我或明確入口選好之後，input_contract 要怎麼檢查格式、必要欄位、權限與支援範圍；不符合時，程式應該安全停止，而不是讓 AI 自己猜路。

參考資料

• GitHub Docs：Manually running a workflow
• AWS Step Functions：Learn about state machines
• AWS Step Functions：Handling errors in workflows
• Temporal Docs：Durable execution
• AWS Builders' Library：Making retries safe with idempotent APIs
• Ci：media-to-text-skill
• Day 6 公開案例：Opus 5 vs Fable 5 真實工作流