把「看爆款影片學經驗」這件全憑感覺的事， 變成可量化、可比較、可複用的結構化資料。
做短影片帶貨的人每天都在做同一件事：看競品的爆款影片，拆解它為什麼有效。
這支影片幾秒鐘出現產品？開頭怎麼抓住人？用的什麼敘事套路？我以前是拿紙筆一秒一秒記，拆一支 30 秒的影片要花 20 分鐘以上。
但真正讓我受不了的不是慢，是拆完之後那三個問題無解：
這就像看病只靠「醫生摸一摸說你氣色不好」，而不是驗血報告。摸一摸也能判斷，但換個醫生說法就不一樣，也沒法跟三個月前比。我想要的是那張報告——每項指標都有數字，能存檔、能比較。
這三件事看起來是三個問題，其實是同一個：拆解結果沒有被結構化，所以既不能比較，也不能複用。
下面是實際運行畫面，不是設計稿。歷史記錄裡是真實處理過的影片。
那些歷史記錄的小圖不是我另外截的，是系統自己從影片裡抓出來的畫面。
這頁就是我要的那張「驗血報告」：產品幾秒出現、露出佔了全片多少、總共幾個鏡頭、屬於哪種敘事套路，全部是數字，不是形容詞。
五個步驟，每一步的產出都會存下來，不是跑完就丟。
整條鏈像做菜的反向工程：先把成品菜拆出用了哪些食材、什麼順序下鍋（拆解），記進食譜本（存檔），下次換個食材照著同一套做法再做一道（再生產）。
這節是整個專案我最想講的部分。
我用了四張表分層存放：
| 資料表 | 存什麼 | 白話說明 |
|---|---|---|
| Analysis | 整支影片的總結 | 相當於報告封面：這支影片多長、幾個鏡頭、屬於什麼套路 |
| Shot | 每一個鏡頭一行 | 相當於逐項檢查：這一鏡幾秒到幾秒、拍的什麼、有沒有產品 |
| Structure | 敘事階段 | 把鏡頭歸類到「停病藥信買」哪個階段，第幾秒到第幾秒 |
| Rewrite | 反向生成的新腳本 | 換品類重寫後的結果，以及給影片生成 AI 的提示詞 |
每個鏡頭我都額外記了兩件事：這一鏡有沒有出現產品、是不是產品第一次出現。
看起來很小，但差別在這裡：
| 做法 | 怎麼得到「產品幾秒出現」 | 結果 |
|---|---|---|
| ❌ 事後統計 | 分析完再回頭把所有鏡頭描述讀一遍，人工或 AI 判斷哪一鏡最早出現產品 | 每次問都要重算一次，答案還可能不一樣 |
| ✅ 存成欄位 | 存的時候就標好，要用時直接查「第一個標記為首次露出的鏡頭」 | 一句查詢就出來，永遠一致，還能跨影片比較 |
就像體檢：抽血的當下就把每項數值記進報告，而不是事後回想「我好像看到指數有點高」。當場記下的是數據，事後回想的是印象——而印象沒法比較。
量化指標必須從資料模型裡長出來，而不是後補。 想清楚「哪些東西該在存的時候就記下來」，比事後想辦法算出來重要得多——這是我做這個專案學到最有用的一課。
以下數據來自系統實際處理的一支 34.7 秒帶貨影片。
框架判定：開箱種草型 · 製造懸念型
鏡頭分類：開場 1 · 痛點 1 · 產品 2 · 信任 2 · CTA 2
另一支影片系統給出的建議是：「產品露出佔比偏低 → 建議增加產品展示鏡頭」。
這句話的價值在於它可執行。「這支影片節奏有點拖」是感覺，「產品只佔全片 18%，建議補產品鏡頭」是可以照著改的動作。
這個工具要連 Google 的 AI 服務，需要透過代理。代理沒啟動的時候，程式不會馬上報錯，而是一路卡到超時才失敗，等了半天什麼也沒發生。
修法：啟動時先花一秒鐘測一下代理通不通，通就用、不通就直連。
學到的：外部依賴要先「探活」再使用。不要讓「不可用」表現成「很慢」——慢比壞更難查。
我請 AI 用固定格式回覆結果，它常常在前後多加幾句廢話或包一層markdown 記號，程式一解析就崩。
修法：先把多餘的包裝剝掉，再抓出真正需要的那段來解析。
學到的：不要指望 AI 每次都乖乖守格式，程式這邊要先做好防禦。
最早的版本跑完直接把結果顯示在畫面上，沒有存。結果就是每次想回看都得重跑一次，白白浪費時間和 API 費用。
學到的：AI 應用的價值往往不在單次呼叫的結果，而在結果被存下來之後的累積。存了才能比較，能比較才有洞察。
這個工具需要四樣東西，而它們在免費的靜態網站託管上都跑不了：
與其部署一個點了沒反應的空殼，不如誠實說明：這頁是它的完整展示，實機可在面試中現場演示——當場上傳一支影片，跑完整條鏈路給你看。
要搬上雲端不是做不到：檔案存儲換成雲端物件儲存、資料庫換成託管服務、影片處理拆成獨立的背景工作。但那是一次不小的重構，為了求職做這件事不划算——知道什麼該做、什麼不值得做，本身也是工程判斷的一部分。