逐字稿只是原料。
它可以保留影片裡說了什麼，卻還不是一篇文章。因為文章得替讀者回答另一組問題：這支影片最值得寫的是哪一題？哪些句子只是作者的看法？哪些數字有時效？最後留下的觀點，又是誰願意負責？
昨天拆會議紀錄時，我問的是「AI 聽到了什麼」。今天同樣從影音開始，但再往前走一步：AI 聽到的內容，最後能被文章寫成什麼？
這兩件事看起來很接近，實際上中間隔著一整條內容產線。
我今天會拿一個已經存在的案例，把影片、字幕、intake、source ledger、文章架構、正文、配圖規劃與公開頁面排在一起。下面直接拆這些狀態怎麼接，也拆哪些地方不能假裝已經完成。
這次選的來源，是 Nate Herk | AI Automation 在 2026 年 7 月 24 日上傳的 YouTube 影片，長度 30 分 53 秒。影片比較 Opus 5 與 Fable 5 的實際工作流程。
我不打算在這篇重寫模型評測。這個案例值得拆，是因為它留下了完整的內容工作檔：影片 metadata、描述、英文字幕、intake、source ledger、architecture、article、image storyboard、report 與 meta。
最後也有一份可以打開閱讀的公開成品，分成 30 秒、5 分鐘與完整深讀三個層次。
先把邊界說清楚。這些檔案可以證明內容曾經走過不同階段，卻沒有一份未中斷的執行紀錄，能證明它們是同一次按鍵一路跑完。所以我會把它當成「內容狀態圖」，不把它寫成一鍵全自動的成功案例。
把工作檔按照責任排開，大致可以分成七站：
intake：決定讀者問題與來源拓樸source ledger：整理主張、時間碼、狀態與公開寫法architecture：決定核心問題、命題與閱讀層次article 與 image storyboard
report 與 meta，最後組成公開頁面每多一站，處理的是上一站還回答不了的問題。
字幕能回答影片說了什麼，卻不會替我決定讀者問題。source ledger 能記住每句話從哪裡來，卻不會自動形成一篇好讀的文章。article 已經可以閱讀，也不代表它通過人工審閱。
所以這些中間檔案不是重複備份。它們把「取得內容」「整理來源」「編輯判斷」與「公開交付」拆成不同責任。
這個案例先保存影片 ID、標題、頻道、日期、長度、描述與英文字幕，再把字幕整理成有時間範圍的區塊。
這一層看起來只是在存資料，但少了它，後面出問題時就不知道模型一開始看過什麼。
影片裡也有一個很實際的例子。講者說到 this one 時，只看逐字稿無法確定畫面指的是哪個模型。當時的 intake 選擇省略，沒有替它猜一個名稱。
老實說，AI 最容易讓人放鬆警覺的地方，就是句子讀起來很順。可是順，不代表指涉完整。畫面資訊不在字幕裡時，我寧可少寫一句。
intake 先決定：這篇到底要解釋什麼？拿到逐字稿之後，這條流程沒有立刻叫模型寫開場，而是先填一份 intake。
裡面有八個欄位：
| 欄位 | 它要先決定什麼 |
|---|---|
reader task |
讀者看完要能做什麼判斷 |
source topology |
來源是一條還是多條證據鏈 |
knowledge shape |
內容適合比較、解釋、教學或查核 |
evidence sensitivity |
哪些主張需要更嚴格的來源 |
timeliness |
哪些內容會隨時間改變 |
depth |
這次要做到多深 |
article form |
文章採用什麼組織方式 |
publication intent |
內容會交付到哪裡、給誰讀 |
這八欄不是所有文章都必須照抄的標準。它比較像開工前的路線選擇：先知道這次要去哪裡，才知道逐字稿裡哪些東西值得帶走。
後來才發現，這一步就是「影片摘要」和「深度文章」開始分岔的位置。摘要通常跟著影片順序走；文章要重新決定問題，甚至捨棄影片裡很大一部分內容。
這個案例的 source_topology 被標成 single。
雖然工作包裡同時有字幕、影片描述和許多數字，它們都回到同一支 YouTube 影片，仍然只有一條證據鏈。原本的執行沒有補官方文件，也沒有第三方複測。
這不代表單一來源沒有價值。它可以讓我整理講者做了什麼、比較了什麼、如何描述自己的結果，也可以分析他的測試設計。但寫法必須保留歸屬：
字幕切成十份、模型讀十次，來源仍然只有一條。AI 不會因為處理步驟變多，就自己長出第二個證人。
source ledger：把「他有說」和「事情是真的」拆開接著是這篇技術含量最高，也最容易被誤解的一份產物：source ledger。
它把影片裡值得處理的內容拆成一列一列，每列保留：
claim：這一列在談什麼主張這份 ledger 一共有 54 列，其中 48 列是 attributed，6 列是 editorial，verified 是 0 列。
54 列不是 54 個已驗證事實。
attributed 只代表這個主張可以回到影片，公開時必須寫成「作者表示」或「影片中展示」。editorial 是編輯流程依材料整理出的比較或推論。verified 則需要另一條能獨立支持主張的證據，但這次沒有。
這個結果看起來不漂亮，資料結構卻很誠實。來源只有一條，就把 0 留在那裡。硬把其中幾列升成 verified，才會讓文章顯得完整，證據反而變薄。
這個案例也沒有 claim-map.md，不是漏做。claim map 適合拿來對照多個來源的支持、衝突與缺口；當字幕、描述與數字都來自同一支影片，硬做一張多來源地圖，反而會製造已經交叉查核的錯覺。
模型價格、榜單與行為會改變。原流程沒有重新查官方頁，所以相關句子保留影片日期與講者歸屬，並列進之後要重查的項目。Day 6 只展示這個處理方式，不順便把文章變成另一篇模型評測。
architecture：不要照影片順序抄一遍如果逐字稿照著 00:00、03:20、08:40 一路整理下去，通常會得到一份很完整的影片筆記。
但讀者需要的順序，不一定跟講者錄影的順序相同。
architecture 先寫下讀者承諾、核心問題、核心命題，以及這次刻意不用的替代架構。接著把內容拆成三個閱讀層次：
這一步會重排材料。某段影片雖然講了很久，如果和核心問題無關，文章可以縮短；某個限制只出現幾秒，卻會改變整個結論，文章就該把它拉到前面。
AI 很適合提出幾種架構，也很會把段落排整齊。可是「這篇最值得回答哪一題」和「哪些東西應該刪掉」，仍然是作者的工作。
架構確認後，流程才開始產出 article。接著還有 image storyboard、report 與 meta。
這四份東西看起來都接近成品，責任其實不同：
| 產物 | 它負責什麼 |
|---|---|
article |
把來源句、編輯推論與限制組成可讀正文 |
image storyboard |
決定哪些關係需要用圖，而不是再寫一段文字 |
report |
把文字與圖片放進可閱讀的交付頁面 |
meta |
保存來源 URL、影片 ID、內容層級與審閱狀態 |
有了 image storyboard，圖就不只是裝飾。來源拓樸、狀態鏈與責任分工這些靠文字很難一次看懂的關係，可以先在文章裡定義清楚，再交給圖片處理。
這也是為什麼這篇會安排比較多圖。這裡要講的是狀態、資料流和責任邊界，用圖會比塞 code 更容易先看懂全貌。
這條 pipeline 有兩個很實際的 hard stop。
抓不到字幕時，它會先失敗，不讓模型只看標題就生文章。模型跑完後，也不只看 process exit code，而是檢查內容目錄是否真的出現新產物，meta.json 的 video_id 是否和輸入相同。
這些檢查很有用，但它們驗的是「輸入有沒有接到正確交付」，不是逐句查證文章內容。
這裡至少有四種完成狀態：
| 狀態 | 可以證明 | 不能代表 |
|---|---|---|
pipeline done |
有新內容，video ID 對得上 | 每個主張都正確 |
| build 成功 | 檔案符合站台結構 | 已通過人工編輯 |
| 公開頁 HTTP 200 | 讀者打得開頁面 | 我已批准內容 |
reviewed: false |
metadata 尚未標記人工審閱 | 文章沒有價值 |
公開站也直接標出「機檢通過、未人工逐篇審閱」。所以這份公開頁可以拿來看 pipeline 如何整理內容，卻不能拿來證明其中每個觀點都是我已經確認的立場。
當時自動產出的正文裡有些句子被標成「Ci 的判斷」。在我逐句確認之前，它們只能算 pipeline 的 editorial synthesis，不能因為頁面已經上線，就反過來變成我的意見。
走到這裡，AI 已經可以完成大量整理：抓輸入、切主張、標時間、提架構、寫初稿、規劃圖片和組交付頁。
人不用重做這些工作，但有四個地方不能直接略過：
attributed？老實說，這四題沒有一題能靠「文章已經生成」回答。
AI 可以把材料攤得很整齊，機器也能確認檔案與 ID 接得上。作者最後要做的，是決定這篇文章到底要留下什麼，以及願意替哪些判斷負責。
這種做法的成本也很直接。檔案變多，交接點變多，整條流程不會像「貼網址，拿摘要」那麼輕。
它也不能保證文章一定更好。source ledger 很完整，選題仍然可能無聊；架構很漂亮，觀點仍然可能站不住；站台順利部署，作者也可能不同意最後的文字。
但中間狀態留下來之後，至少知道問題出在哪一層：
intake。source ledger。architecture。image storyboard。reviewed 狀態，不用猜。我想從這個案例留下的方法很簡單：影片進來之後，不要急著把一篇文章吐出去。先讓每一次轉換都留下一個能看、能改、也能拒絕的狀態。
Day 3 和 Day 4 講的是機器怎麼擋住可機檢的錯誤；Day 5 的會議紀錄要保留時間、說話者與未確認；Day 6 的影片深讀則多了來源拓樸、編輯推論與人工批准。
下一篇，我會把發文、會議與影片這三條產線攤在同一張責任表裡。它們都用了 AI，但 AI 能碰到哪裡、什麼叫完成，以及哪一站必須找人，答案其實不一樣。
iThome鐵人賽
看影片追技術