專案資訊
- 專案：AI Video Writer
- 使用工具：Claude Code、Codex、Gemini CLI
- 使用模型：gemini-2.5-flash、gemini-2.5-pro、claude-sonnet-4.5、gpt-5.1、grok-4
起因
因為工作需要經營 YouTube 頻道，有定期的影片產出，每支影片都需要編寫「影片標題」、「影片說明」，抓出時間碼來設定「影片章節」等中繼資料，還要把影片內容改寫成搭配影片的 SEO 文章。這些事情每一件都不難，但加在一起就是一個龐大的時間黑洞。
初期我是將「影片腳本」丟到 LLM 中生成中繼資料，以及用 Whisper 生成的影片逐字稿來產出「影片章節」。後來 Gemini 的影片理解能力越來越強——從只能透過字幕或音訊來了解影片內容，到可以用影格的方式來「看」影片——我就開始直接用 Gemini App 來加速流程。使用方式很簡單：公開影片只要提供 YouTube 連結給 Gemini 即可，還沒公開的影片就直接上傳。
但一個一個貼連結還是有點慢。我當時就在想：能不能用 Gemini API 的「傳送 YouTube 網址」功能搭配 FFmpeg，讓 Gemini API 理解影片內容後編寫 SEO 文章，同時把影片下載下來擷取適合放在文章裡的截圖？甚至把這套流程做成 n8n 工作流，每週自動檢查頻道是否有新影片上傳，有的話就自動執行。
想著想著，覺得與其做一個單純的自動化流程，不如做一個完整的網頁工具——登入 Google 帳號選定頻道，就能看到影片列表，直接生成需要的中繼資料和文章。既然找不到現成的理想工具，那就自己做一個。但我不是全職工程師，沒辦法花幾個月慢慢刻——所以我選擇用 vibe coding 的方式，讓 AI 當我的協作開發夥伴。
過程
整個開發分散在業餘時間，從 2025 年 11 月斷斷續續做到 2026 年 4 月。
技術棧是什麼？老實說我也沒特別挑，就是告訴 AI 我要做什麼樣的工具，技術選型基本上是 AI 建議的——前端用 React + Vite、後端用 Node.js + Express。這就是 vibe coding 的好處，你不需要先花時間研究哪個框架比較好，AI 會根據你的需求給出合理的選擇，你只要專注在「我要做什麼功能」就好。
初期：先讓核心功能跑起來
一開始很單純，就是想讓「貼連結 → 生成文章」這件事能動。我跟 AI 說我需要一個網頁，可以把 YouTube 連結丟進去，然後自動生成文章和截圖。
核心就是圍繞 Gemini API 的幾個能力：
- 傳送 YouTube 網址：公開影片直接丟連結給 Gemini，它就能理解影片內容、生成文章和中繼資料，完全不需要下載影片
- Files API：非公開影片就用 yt-dlp 下載後上傳給 Gemini 分析，之後要重新生成的話會直接用已上傳的檔案，不用再花時間下載和上傳
- 自動截圖：Gemini 生成文章的同時會推薦「這個時間點的畫面適合當配圖」，再透過 FFmpeg 自動擷取
這裡有個細節值得記一下。Files API 的設計是「同一支影片只需要上傳一次」，後端會先用 videoId 查找 Gemini 上有沒有既有檔案，有的話直接重用，省掉下載和上傳的時間。這個快取邏輯是 Claude Code 在初期架構建議裡提的，當時沒特別意識到，後來做安全性審查的時候才發現這個設計有個副作用（後面會提到）。
文章生成之後我還需要發到 Notion，這部分是用 Codex 幫我寫的——我描述完需求，它就把 Notion API 的串接搞定了。
中期：加上頻道分析儀表板
基本功能穩定之後，我開始想：既然都串了 YouTube API 了，不如順便把頻道數據分析也做進來。觀看次數、流量來源、觀眾組成這些資料，平常要跑去 YouTube Studio 看，何不直接整合在同一個工具裡？
這裡踩了一個坑，YouTube Data API 的搜尋功能配額消耗很大，用沒幾次每日額度就見底了。後來的解法是把影片清單存到 GitHub Gist 當快取，搭配 GitHub Actions 定時更新，這個優化方向其實是 Claude Code 在幫我做 code review 的時候建議的。Gist 這個工具其實 11 月初就已經接進來放遠端文章模板（CUSTOM_TEMPLATE_URL），到這時剛好把同一條路重新利用在影片清單快取上。
Gist 快取這個方案聽起來有點繞，但邏輯很清楚：頻道的影片清單不需要即時更新，每天同步一次就夠了；與其每次開頁面都呼叫 YouTube API，不如把結果存在 Gist，要查的時候直接讀靜態 JSON，配額消耗降到幾乎為零。我這種對基礎設施設計不熟的人，大概自己不太會想到這個方向，這也算是 AI 協作開發裡「它比你想得更遠」的一個例子。
後期：多模型 AI 分析，Claude Code 全力介入
到了這個階段，我想讓工具不只是顯示數據，還要能用 AI 分析數據、給出頻道成長建議。而且不想只綁定 Gemini 一個模型，希望能切換 Claude、GPT、Grok 來比較不同模型的分析角度。
這是整個專案中 vibe coding 最密集的時期。我大量使用 Claude Code，開發流程基本上就是：我描述需求 → Claude Code 自己開一個分支寫程式 → 我看過覺得可以就合併。它在這段時間自動建了好幾個分支，分別處理多模型分析、快取優化、Notion 修正等功能。
不過功能越疊越多，分支也越來越亂。最後花了一輪時間整理，把所有分支合併到一起，用 Gemini CLI 重寫了所有文件，把程式碼結構也做了一次整理。
合併完以後有一個插曲。feature/ai-analytics 合進 main 之後，GitHub Actions 的定時快取更新突然壞掉了，跑出一堆 SERVER_MISCONFIGURED 的錯誤。查了一下才發現，合併進來的分支有新增 JWT 認證 middleware，GitHub Actions 啟動後端伺服器時沒有傳 JWT_SECRET 環境變數，所以 middleware 一啟動就掛了，所有 API 呼叫全部回 500。更正確的說，是兩個問題疊在一起，一是 workflow 缺少 JWT_SECRET，二是腳本呼叫 API 時也沒有帶 Bearer token。Claude Code 後來把這兩個問題一起修掉，讓 GitHub Actions 腳本自己用 JWT_SECRET 簽一個 session token 再打 API。
說到安全性，這個 JWT 認證是後來加的，不是一開始就有的。工具做到一定程度，部署到 Render 之後，我才意識到整個後端完全沒有保護，任何人只要知道網址就可以直接呼叫所有 API 端點，不需要登入也不需要任何憑證。我把這個問題丟給 Claude Code，它做了一次完整的安全性審查，列出了好幾個不同嚴重程度的問題，包含 Gemini 已上傳的私有影片可能被重用分析、filePath 路徑穿越風險、Notion OAuth callback 缺少 CSRF 防護、task API 回傳洩漏 accessToken 等。最後用一套 JWT 加頻道 ID 白名單的機制把所有問題一起解掉。這件事讓我體認到，vibe coding 做工具很快，但安全性這個環節不能省，還是得有人去想「如果這個端點被亂打會怎樣」。
成果
最終 AI Video Writer 變成了一個一站式的 YouTube 內容工具：
- 影片 → 文章：貼上 YouTube 連結就能自動生成附截圖的文章，還支援自訂模板
- 中繼資料生成：批次產出影片標題、描述、關鍵字，包含影片章節的時間碼
- 頻道儀表板：觀看數據、流量來源、觀眾組成、Shorts 分析、影片排行榜，全部整合在同一個畫面
- 多模型 AI 分析：可以切換 Gemini、Claude、GPT、Grok 來分析頻道數據、給出成長建議
- 一鍵發到 Notion：文章連同截圖直接推送過去
心得與建議
Vibe coding 真正改變的是什麼？ 以前想到要自己做一個工具，腦中浮現的是「要學哪個框架」「要怎麼處理 OAuth」「API 文件好長」，光想就累了。但用 vibe coding 的方式，這些技術細節 AI 會幫你處理，你只需要想清楚「我要什麼功能」和「使用流程長什麼樣子」。瓶頸從「能不能寫出來」變成「想不想得清楚」。
我的技術棧是 AI 選的，但產品方向是我定的。 React、Express 這些我沒有特別堅持，AI 建議什麼就用什麼。但「要有哪些功能」「使用者流程怎麼走」「哪些資料要顯示在儀表板上」——這些是我根據自己每天實際經營頻道的經驗來決定的。Vibe coding 不是把一切丟給 AI，而是你當產品經理，AI 當工程師。
最大的教訓： 不要因為 AI 寫程式很快就一直加功能。我在中後期因為「反正 AI 很快就能做出來」所以不斷加新功能，結果分支越開越多、程式碼越來越亂，最後還是得花時間整理。速度快不代表可以省略規劃，先想清楚再動手，不管是自己寫還是 AI 寫都一樣。