製作影片
使用者與你一起製作 YouTube 影片：長篇解說影片 (16:9) 和短片 (9:16)，使用 Remotion 以程式製作動畫，由 Gemini 語音旁白，通常有一個角色精靈。這個技能涵蓋了整個流程。這些工具位於 <videokit>，也就是這個技能儲存庫的 videokit 資料夾 (執行任何操作前請先閱讀 references/toolkit.md)。如果 <videokit> 尚未被替換為實際路徑，請詢問使用者他們在哪裡複製了儲存庫 (含有 vk.py 的資料夾)，並使用該路徑。
使用者最在意的三件事，也是流程如此設計的原因：
- 在他們核准草稿之前，什麼都不會建構。 他們想先看到故事，以及每個場景的具體樣貌和聲音——包含轉場、動畫、燈光、音效和品質。修改計畫花費幾分鐘；修改已渲染的成品則花費數小時。
- 成品必須看起來專業。 帶有動態模糊的流暢轉場、緩動動畫、景深感、真實的燈光、每個事件都有對應音效、乾淨的 1080p 畫質。
references/pro-look.md說明了這在實務上的意義以及哪些元件負責實現。 - 他們想要完成的影片，而不是一連串的問題。 審查代理會負責回答過程中的問題，並根據固定的 10 項檢查清單為你的工作評分；使用者只有在分數達到 9/10 時才會看到完成的影片。
references/review.md說明了運作方式：誰決定什麼、檢查清單、提示詞，以及何時停止。審查會在早期進行 (草稿、動畫分鏡)，也就是修改成本低的時候，而不是只在最後階段。
階段
每個 ✋ 都是一個停止點：等待回答後再繼續。✋ 使用者：由使用者決定。✋ 審查者：由審查代理決定 (一個代理負責整支影片，透過 SendMessage 繼續進行 - review.md)。
0. 簡報 ✋ 使用者
使用 AskUserQuestion 詢問你無法從請求中判斷的資訊 (每次呼叫最多 4 個問題；剩餘的問題用第二次呼叫)。即使主題讓某些問題顯而易見，也不要預設以下任何一項：
- 格式： 長片 (16:9, 1920×1080) · 短片 (9:16, 1080×1920, 少於 3 分鐘) · 兩者 (長片加上從中剪輯的 3-5 部短片)。
- 旁白： AI 語音 (Gemini TTS；你會發送範例) · 無旁白 (音樂 + 螢幕文字) · 使用者自己的錄音。
- 外觀： 提供 3-4 個符合主題的具體風格 (例如：電影風格的程式繪製太空場景搭配真實光線；簡潔的扁平動態圖形；手繪塗鴉風格；故事書般的剪紙風格)，每個風格用一句話描述。
- 角色： 他們現有的角色精靈 (在
<videokit>/sprites中；執行python vk.py characters可列出) · 使用圖像生成工具 (如 Gemini (Nano Banana，需付費)) 生成的新角色 · 表情符號 · 用程式繪製 · 無。 - 所有其他素材 (道具、物體、圖示、背景) - 每次都必須分開詢問：用程式繪製 (免費；使用效果庫的外觀) · 表情符號 (免費；使用
Emoji元件，並像其他東西一樣打光) · 使用圖像生成工具 (如 Gemini (需付費)) 生成 · 混合方式，在草稿中逐項決定。每支影片都要問。生成的圖片只有在使用者在這裡選擇了該選項時才會製作。 - 音樂： 原創配樂 (情緒：驚奇 / 緊張 / 俏皮 / 史詩) · 為這支影片逐音符創作的配樂 (與場景同步的主題、和弦和重音 - toolkit.md "作曲家的配樂") · 他們自己的歌曲 (他們會發送音訊和歌詞 - 絕對不要下載) · 無。
如果主題、長度和語言不清楚，也要確定下來。然後建立專案：
python -X utf8 vk.py new <資料夾> --title "..." --format long|short|both (從 videokit 資料夾執行；專案會建立在該資料夾旁邊)。
1. 草稿 ✋ 審查者，然後 ✋ 使用者
研究主題 (檢查每個事實；注意任何依賴於今日日期的內容)，撰寫 script.md (旁白，每個 "> " 行對應一行錄製的台詞)，然後使用專案中已有的範本撰寫 plan.md。references/draft.md 解釋了每個部分。其核心是逐場景表格：每個鏡頭的旁白、我們看到的畫面 (以及角色在其中做什麼)、攝影機和動畫、進場和出場轉場、燈光和色彩、音效以及音樂。此外還有外觀、動態、燈光、轉場和聲音計畫、品質規格、短片 (如果是 "both")、帶來源的事實，以及成本。也撰寫 2-3 個鉤子選項 (每個包含第一行和第一個畫面)。如果是短片，請遵循 draft.md 的 "前 3 秒"：第 1 秒要有驚喜，第 0 幀要有帶聲音的動作，第一個畫面要明亮。真實的短片數據顯示，觀看次數的成敗就在那幾秒鐘；使用者的數據放在 references/channel-numbers.md。
草稿審查： 使用 plan.md 和 script.md 啟用審查者 (review.md, "啟用審查者")。修復它找到的所有缺陷，以及草稿可以修復的、評分低於 2 分的項目；將其鉤子選擇納入草稿；將你接受和未接受的內容記錄在 out/review/decisions.md。
然後顯示給使用者：在聊天中提供簡短摘要 (用幾行說故事，用簡潔列表列出場景，任何你需要他們決定的事項，以及審查者的預測分數一行) 並附上 plan.md 的連結。請求核准或修改，進行修改，並重複直到他們說「開始」。在此之前不要錄製、生成或動畫化任何東西——這是使用者的規則。
2. 語音 (如果有旁白)
- 預設語音 (video.json：Gemini "Kore" 在
speed1.2) 不需要提問。新的語音或風格：vk.py voice samples→ 發送範例 (SendUserFile) → ✋ 使用者：他們靠耳朵選擇 (代理無法聽見，所以這個步驟絕不交給審查者)。在video.json中設定，包含speed。 vk.py voice record(會快取；相同的台詞行可從其他專案免費重複使用)，然後vk.py words(單字時間戳 + 檢查每行是否與腳本一致；聽取任何它標記的台詞)。- Gemini 402 錯誤 = 預付額度用完：停止並告知使用者。
3. 外觀 ✋ 審查者
- 按照已核准草稿的素材清單指定的方式 (程式、表情符號、Gemini 或現有) 製作每個素材：
- 現有精靈放入
scripts/build.py的CHARACTERS/PROP_DIRS； - 生成的 (僅在核准後)：使用圖像生成工具，如 Gemini (Nano Banana)，裁切成透明 PNG 並以相同方式引入 (toolkit.md, "Gemini 圖片")；
- 表情符號：
<Emoji char="🚀" .../>(fx/emoji.tsx) 搭配場景的邊緣光與接觸陰影； - 程式繪製：在場景中使用 fx 函式庫 (LitSphere, Sun, shapes, DrawPath...) 繪製。
- 現有精靈放入
- 建立 3-4 個風格幀 - 草稿中的關鍵時刻，完全打光 - 作為聯絡表 (執行
vk.py stills ...) 並發送給審查者 ("途中的一個選擇")：核准該外觀或告知需要修改的內容。記錄答案。
4. 建構
-
scripts/build.py：根據草稿填入 - 暫停、提示 (c.at(line, 'phrase'))、MOVES(每個區段如何進場)、effects()(每個事件都有對應音效)、music()(情緒、強度曲線、重音 - 或作曲家的配樂)、ambience()、YouTube 文字。執行vk.py build。 -
場景：每個場景一個檔案，位於
src/scenes/，以故事秒數為單位依據提示撰寫，使用src/fx(攝影機、景深圖層、燈光、粒子、動態文字、角色的軌跡)。在src/Video.tsx中列出它們及其轉場。讓角色保持在動作中 (站在、騎乘、指向、對螢幕上的事物做出反應) - 一個只是漂浮的角色會看起來像填充素材。首先遮擋每個鏡頭 - 放置、對準其提示並移動 - 然後再進行燈光和豐富度調整。移動不僅僅是指角色：從遮擋階段開始，每個鏡頭都有一個漂移或移動的攝影機、CamLayer景深層級和其他一些在動態中的東西。一個在靜止世界背景下、角色在動的短片即使得了 20/20 分，在實際觀看時仍被認為過於平淡。 -
動畫分鏡 ✋ 審查者：
vk.py animatic以一半大小渲染整部影片，使用真實音效且無動態模糊 (30 秒短片約需 1.5 分鐘) 並對其執行節奏檢查。將其發送給審查者 (動畫分鏡提示)。在修飾之前，現在就修正鉤子、時機和清晰度。 -
短片 (如果是 "both")：透過
kit.shorts.build在 build.py 中指定規格，每個短片一個場景在src/shorts/。 -
豐富度調整：逐鏡頭對照
references/pro-look.md中的 "讓它豐富" 進行檢查，並在任何鏡頭顯得平淡的地方添加效果。每個鏡頭都需要：- 一個有景深的背景；
- 一個可見的光源；
- 主體存在於世界中；
- 前景有東西；
- 一個永遠不鎖定的攝影機；
- 背景的生命力；
- 完成度；
- 聲音。
每支影片都應該感覺豐富，所以這是工作的一部分，而不是額外選項。遵守節制規則以保持清爽，並讓效果遠離文字。
5. 檢查 (循環直到乾淨)
vk.py qa 將每個提示和每個轉場中點渲染成聯絡表 (out/qa/)，然後執行自動檢查 → out/qa/<comp>_checks.md：檢查 YouTube/TikTok 按鈕和標題下的文字、小於 44 px 的文字、重疊或跑出畫面邊框的文字 (在頁面本身上測量)；以及對最新渲染，檢查畫面幾乎不變的拉伸區域、背景靜止不動的鏡頭 (少於 25% 的畫面在移動)、語音中的間隙、畫面邊緣未覆蓋的條帶、循環接縫和響度。修復它列出的每個問題，並檢查每個 "值得一看" 的項目。然後，對照 references/pro-look.md 中的檢查清單逐個檢查聯絡表 - 轉場中間點、燈光方向、場景中的角色、沒有平淡的畫面 (任何看起來扁平或空洞的內容都要豐富化) - 修正，然後再次執行 (vk.py qa --auto 僅重新執行檢查，約需一分鐘)。在完整渲染之前，執行一個短暫的測試渲染 (vk.py render --frames 0-150) 以查看實際動畫和渲染速度。渲染會重複使用幀未改變的每 4 秒區塊，所以修正後只需再次執行渲染 (只有在變更畫布繪圖或交換影片檔案後才使用 --fresh)。
6. 最終階段 ✋ 審查者
vk.py final(以及每個短片的vk.py final --comp Short-<id>)：1080p H.264，備份為 v1/v2...，檢查尺寸、fps、編碼器、-14 LUFS 和真實峰值。不要製作手機預覽或 720p 副本 - 只提供 1080p 檔案。然後對其執行vk.py qa --auto。- 最終審查 (review.md, "輪次與停止時機")：審查者根據檢查清單評分並挑選標題。修復缺陷和排名最高的修正項目，記錄決策，再次渲染，並將新版本與前一個版本一起發送以進行比較。達到 18/20 分且無任何項目為 0 分且無未解決缺陷即為通過；3 輪後停止，或者當一輪檢查未發現新問題且分數維持不變時提前停止。
- TikTok (當使用者也在那裡發布短片時)：
vk.py final --platform tiktok→ "<標題> (TikTok).mp4"：無顆粒感、減少灰塵、更高的比特率和輕微銳化，因為 TikTok 會對每個上傳進行強力重新編碼。 - 縮圖 (
src/Thumbnail.tsx→ 1280×720 jpg)、captions.srt、youtube.md(標題、附章節的描述、標籤、AI 語音揭露)；短片則有shorts.md。
7. 交付
當完成的影片小於約 30 MB 時 (短片通常符合)，使用 SendUserFile 發送；否則提供可點擊的路徑 (TikTok 剪輯通常較大：提供其路徑)。逐場景摘要說明影片內容以及檢查結果：審查者的最終分數 (以及之前的輪次)、任何仍低於 2 分的項目、審查者的頻道備註 (關於整個頻道的事項——由他們決定)，以及審查者僅透過儀表判斷聲音的事實：使用者自己聽是最終檢查。附加上傳備註。然後儲存或更新專案記憶備註 (製作了什麼、在哪裡、使用者做了哪些決定)。當使用者稍後詢問已發布短片的表現時，將其資料行新增到 references/channel-numbers.md。
始終適用的規則
references/house-rules.md 包含常設規則 - 每支影片閱讀一次。簡短版：絕不列印 API 金鑰；未經同意不使用 Gemini 圖片；絕不下載歌曲或將其他藝術家的歌詞顯示在螢幕上；"只是問問" 的問題得到答案，而不是建構內容；先有草稿再建構；僅限 1080p；審查者回答階段的問題，而簡報、草稿、新語音、金錢和任何公開事項則由使用者決定。
參考資料
references/review.md- 審查代理：誰決定什麼、10 項檢查清單、每個階段的提示詞、決策記錄，以及何時停止。references/draft.md- 如何撰寫草稿 (plan.md) 並呈現，包括短片的前 3 秒規則。references/channel-numbers.md- 使用者自己 YouTube 數據的範本 (每個短片的留存率、每個開頭的效果) 以及如何閱讀 Studio。references/pro-look.md- 專業標準：轉場、動畫、燈光、粒子、文字、音效、品質檢查、渲染效能，以及每個部分的元件。references/toolkit.md- videokit 命令 (自動檢查、動畫分鏡、TikTok 剪輯)、專案佈局、故事時鐘、build.py 鉤子、短片、音樂影片、Windows 注意事項。references/house-rules.md- 常設規則及其原因。