軟體產品的啟動影片
製作一段 30–60 秒的影片，讓人理解並想要這個產品。
決定一切的關鍵：重建，不要錄製
螢幕錄影會跟你作對。真實延遲等於死寂時間。重拍成本高昂。 你無法凍結一個畫面、無法放慢一個節拍再加速另一個，也無法在不造成壓縮模糊的情況下精準裁切。
因此，將 UI 重建為 Remotion 內部以幀驅動的 React。每個視覺元素都是 useCurrentFrame() 的純函數。打字會在精確的曲線上落地，載入狀態會與節拍同步，而重拍只需要修改一個數字。
這種方法只有在你能讀取產品的實際程式碼（如果是本機）或 DOM+CSS（如果是在線服務）並忠實重現時才合理。這樣做——使用真實的 class 名稱、真實的顏色、真實的文案。重建的結果應該看起來與錄影無異，然後更好。
何時應該錄製： 涉及重度 3D、產品內含影片內容、Canvas/WebGL 表面，或是原生桌面應用程式。如果某個特定表面無法重建，請僅錄製該表面，並使用 <OffthreadVideo> 合成。
階段 1 — 了解產品
在開始此階段前，請閱讀 references/discovery.md。該文件涵蓋瀏覽與篩選流程、憑證對話，以及如何從即時網站提取設計系統。
簡要說明：
- 如果提供的是 URL：瀏覽它。先看登陸頁面（它會告訴你他們如何定位自己），然後再看應用程式本身。弄清楚這個產品為誰解決什麼問題。
- 如果提供的是本機儲存庫/開發伺服器：閱讀程式碼。內容豐富得多——你可以取得實際的元件、實際的主題 token、實際的種子資料。
- 篩選頁面。 大多數產品有 20 個畫面，但只有 3 個是關鍵的。驗證、設定、帳單、隱私、帳戶、入門引導樣板——這些幾乎從來都不是重點。找到那個產品能做到只有它才能做到之事的畫面。
- 如果好東西在登入後面，先詢問——測試憑證，或是他們本機開發環境中的種子帳戶。如果兩者都不可用，不要放棄，也不要偽造你從未見過的 session：切換到章節式結構，並從登陸頁面自己的功能卡片、文案和元件來建構。
discovery.md中有收集流程和誠實規則。
然後，在開始建構之前，與使用者確認你的理解——對產品的錯誤理解會導致整個建構失敗。向他們展示：你認為產品在做什麼、你計劃展示的 2–4 個畫面、英雄場景、鏡頭列表，以及音樂問題（見階段 4）。一次檢查點，然後開始執行。
階段 2 — 選擇結構
閱讀 references/structure.md。有兩種結構可選；選錯會導致建構失敗。
結構 A — 單一敘事。這是預設選項。 一個使用者完成一個任務並獲得一個成果。不是功能巡禮。
| 節拍 | 任務 |
|---|---|
| 鉤子（0–5 秒） | 用觀看者自己的話說出問題。尚未顯示 UI。 |
| 請求（5–12 秒） | 使用者請求這個東西。聚焦在輸入區域。 |
| 運作（12–25 秒） | 產品明顯地執行某個困難的動作。展示證據。 |
| 成果（25–35 秒） | 完整輸出，以可讀的大小顯示。 |
| 控制（35–45 秒） | 使用者進行修改並保持主導。 |
| 標題卡（45–50 秒） | 標誌、一行文字、網域。 |
運作和控制節拍是將真實示範與模擬區分開來的關鍵。"它詢問了我而不是猜測"和"我可以編輯它產生的內容"是信任論點，而信任正是啟動影片真正在銷售的東西。
選擇產品能做到一般人難以自行完成的那個時刻，並讓輸出變得具體且可見——一份產生的文件、一個建立的圖表、一個修復的錯誤、一個已部署的網站。具體的成果才是人們會記住的。
結構 B — 章節式功能影片。 三個功能，每個都由一張使用平實語言的標籤卡介紹，然後展示。
鉤子 → [01 標籤 → 功能] → [02 標籤 → 功能] → [03 標籤 → 功能] → 標題卡
當產品有門檻且你只能從其登陸頁面工作時使用，或當這些功能確實不共用同一個使用者旅程時，或當你想要從一次建構中獲得三個獨立片段時使用。三個是適當的數量——四個意味著沒有一個能留下印象。
不要將序列章節化。 如果這些能力在同一個 session 中一個接一個發生（研究 → 草稿 → 編輯），那是一個工作流程，將它標記為三個功能會與素材衝突。如果有人要求為一個序列式產品做章節，提供折衷方案：保留單一敘事，並在每個能力出現時將標籤疊加在動作之上。同樣的可讀性，同樣的片段邊界，沒有時間成本，故事完整。
structure.md 涵蓋章節卡設計、如何撰寫標籤（命名結果，而非機制；借用產品自己的用語）、轉場和排序。
階段 3 — 讓一切有根據
無論產品屬於哪個領域，不要憑空發明其內容。如果是法律產品，法條必須是真實的。如果是分析產品，數字必須合理且內部一致。如果是程式碼工具，程式碼必須能在讀者腦中編譯。
從儲存庫、API、種子資料或文件中提取真實內容。領域專家會觀看這些影片，一個發明的細節就會讓你失去他們所有的人。當事人姓名、日期和金額數字可以發明——這些是針對特定客戶的，不是關於世界的宣稱。
在資料檔案中保留出處註記，說明每個事實的來源。將來的你會需要它。
階段 4 — 建構
執行腳本，它會鎖定實際上能協同工作的版本並寫入配置：
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --fps 60 --seconds 45
它會建立一個獨立的 Remotion 專案（它自己的 git 儲存庫——除非被要求，否則永遠不要將影片工具加入產品的儲存庫），複製 useCamera.ts，並留下一個時間軸模組供你填入。
然後，依序進行：
-
src/timeline.ts— 幀數計算和鏡頭邊界。選擇一個節拍是整數幀數的 BPM（在 60fps 下：120 BPM = 30 幀，90 BPM = 40）。將每個鏡頭邊界放在一個節拍上。即使沒有音樂，這也能為剪輯賦予內在節奏，並且意味著之後可以加入音樂背景而無需重新編輯。 -
src/data/script.<lang>.ts— 每個字串、每個數字、每份文件內容，全部放在一個檔案中，並附帶出處註解。元件中不得有硬編碼。重新調整時間和翻譯都變得簡單。 -
元件 — 重新建立產品的 UI。複製真實的 class 名稱。如果產品使用 Tailwind，將其配置和主題 CSS 引入；如果它使用 CSS 變數來定義顏色，你必須將它們帶過來，否則所有內容都會以無色呈現。
-
src/scenes/ProductScene.tsx— 一個匯出的B物件，持有每個節拍作為絕對幀數。DOM、相機、聲音都從它讀取。重新調整時間意味著只編輯那個區塊，其他什麼都不動。
閱讀 references/camera.md 了解鏡頭系統，references/motion.md 了解持續時間和排版。
階段 5 — 音訊
兩個音軌，兩個檔案，兩個 <Audio> 標籤：音效和音樂。將它們分開，這樣任何一個都可以被替換，而無需重新產生另一個。
音效 — references/sound.md。克制是整個紀律：一部 45 秒的影片通常總共只需要三到五個事件。pop 表示有東西出現，swish 表示元素在鏡頭內移動，whoosh 表示鏡頭在移動。
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
音樂 — references/music.md。在開始建構之前先詢問。 大多數人都有意見，而且很多人已經有了一首曲子；詢問只會花一句話的時間，卻可能省下所有力氣：
你想要背景音樂嗎？如果你有曲子，請傳給我，我會配合它剪輯。如果沒有，我可以合成一段——活潑、平靜、電影感、極簡、溫暖或緊張？
如果他們有曲子，就配合它剪輯：找出它的 BPM，將時間軸設為匹配，將鏡頭邊界移到它的小節上。否則，合成一段編排變化恰好落在你的剪輯點上的背景音樂：
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
在每個真正的鏡頭邊界上放一個 sections 條目，在你最大的剪輯點上放一個 hits 條目，在任何你想要讓觀眾閱讀而非感受的持續台詞下面放一個 ducks 條目。音樂峰值約在 ~0.30，音效約在 ~0.62。根據產品本身選擇情緒——嚴肅的主題需要更平靜的背景，而忙碌的剪輯需要更稀疏的背景。
階段 6 — 先以靜態影格驗證，再進行渲染
這是緊湊的反饋迴圈，跳過它會浪費數小時。
npx remotion still <CompositionId> out/f0700.png --frame=700
然後實際查看那個 PNG。每個鏡頭渲染一張靜態影格，每個轉場也渲染一張。檢查：主體是否在畫面內，是否有任何文字被從中間截斷，是否有空白區域，文字是否合適。
新增一個靜態合成（defaultProps: { withAudio: false }），這樣靜態影格就不需要音訊檔案存在。
盡可能以數值方式調整。 緩動曲線、滾動距離、頻譜內容——這些都是可計算的。寫一個一次性的 Python 腳本來取樣曲線並印出你原本需要猜測的內容。這比渲染更快，而且結果是正確的。
只有在靜態影格都正確之後，才渲染完整影片。
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
在 16GB 記憶體的機器上，並發數限制在 4 左右——Remotion 會為每個 slot 產生一個 Chrome 分頁，而預設值（核心數）會導致記憶體交換。
階段 7 — 誠實地交付
傳送檔案。然後坦率地說：
- 你無法驗證的部分。你可以讀取靜態影格，但你無法判斷八秒鐘的感覺如何，也無法聽到音訊。要這麼說。
- 任何你重建而非親眼觀察到的畫面——特別是在有門檻的產品上。列出它們，並提議如果他們願意分享權限，你可以重做那些節拍。
- 你做出的他們可能不同意的判斷性決定。
- 如何更換音樂：將任何 WAV 或 MP3 放到
public/music.wav並重新渲染。 - 你在建構過程中發現的產品相關問題——一個渲染錯誤、一個錯誤的標籤、一個遺漏的狀態。你剛剛比大多數人更仔細地閱讀了他們的 UI。這個觀察本身的價值往往超過影片本身。
參考檔案
當你到達相關階段時再閱讀這些——它們很詳細，而且一次全部載入沒有意義。
| 檔案 | 何時閱讀 |
|---|---|
references/discovery.md | 階段 1 — 瀏覽、頁面篩選、憑證、設計系統，以及從有門檻產品的登陸頁面建構 |
references/structure.md | 階段 2 — 單一敘事 vs. 章節、章節卡設計、撰寫功能標籤、轉場、排序 |
references/camera.md | 建構鏡頭 — 佈局空間、焦點相機、切換 vs. 推近 vs. 變形、隔離元件 |
references/motion.md | 動畫持續時間、排版、鉤子模式、問題輪播 |
references/sound.md | 聲音設計 — pop/swish/whoosh 詞彙、克制、合成鍵盤和點擊聲 |
references/music.md | 尋找 vs. 合成背景音樂、選擇情緒、將段落對齊剪輯點、在音效下混合 |
references/pitfalls.md | 在你的第一次渲染之前閱讀這個。 那些會花費實際數小時的錯誤，每個都附有修復方法。 |
隨附腳本
下面的 <skill-dir> 是這個技能自己的目錄——技能載入時提供給你的路徑。不要假設固定的安裝位置；技能可能作為個人安裝、外掛程式安裝，或是被簽出到專案中。
| 腳本 | 用途 |
|---|---|
scripts/scaffold_video.py | 建立 Remotion 專案，包含可用的版本鎖定和配置 |
scripts/make_sfx.py | 從 JSON 事件列表合成音效軌道。無需範例檔案，除了 numpy 外無其他依賴。 |
scripts/make_music.py | 以六種情緒之一合成背景音樂，其編排與你的剪輯對齊。相同的依賴。 |
assets/useCamera.ts | 焦點相機鉤子——複製到 src/hooks/ |
assets/ChapterCard.tsx | 章節式結構的章節卡——複製到 src/components/ |
簡要版本
重建而非錄製。一個故事，一個成果——除非產品有門檻或其功能確實是分離的，在這種情況下使用三個章節和平實的標籤。讓每個領域事實都有根據。幀是一切的基本單位。隔離一個元件而非裁切頁面。UI 動畫為 150–300ms，相機移動約為 1 秒。四個聲音就夠了。在製作音樂之前先詢問。在渲染之前先查看靜態影格。說出你無法檢查的部分，以及你推斷出的部分。