軟體產品的啟動影片
製作一支30–60秒的影片，讓人立刻了解產品並產生購買慾望。
決定一切的關鍵：重建，而非錄製
螢幕錄製只會帶來麻煩。真實的延遲會變成死寂的空檔。重拍的代價高昂。 你無法控制影格，無法放慢一個節拍再加快另一個，也無法在不壓縮成模糊畫質的情況下進行緊密裁切。
因此，請將使用者介面重建為基於影格的React，並在Remotion中執行。每個視覺元素都是useCurrentFrame()的純函數。文字輸入會精準地在特定曲線上演變，載入狀態會隨著節拍解決，而重拍只需要修改一個數字。
這種方法之所以合理，只有當你能讀取產品的實際程式碼（如果是本機）或DOM+CSS（如果是託管網站）並忠實地重現它時才成立。請這樣做——使用真實的類別名稱、真實的顏色、真實的文字。重建的結果應該與錄製的影片難以區分，然後更好。
何時應該錄製： 包含大量3D內容、產品內部的影片內容、Canvas/WebGL表面，或是原生桌面應用程式。如果某個特定表面無法重建，就只錄製該表面，並用<OffthreadVideo>合成。
第一階段——了解產品
在開始此階段前，請先閱讀 references/discovery.md。它涵蓋了瀏覽與分類的程序、憑證對話，以及如何從現有網站提取設計系統。
簡短版：
- 如果給的是URL：瀏覽它。先看登陸頁面（它會告訴你他們如何定位自己），然後再看應用程式本身。弄清楚產品為誰、做什麼工作。
- 如果給的是本地儲存庫/開發伺服器：閱讀程式碼。資訊豐富得多——你會獲得真正的元件、真正的主題令牌、真正的種子資料。
- 分類頁面。 大多數產品有20個畫面，但只有3個是重要的。驗證、設定、帳單、隱私、帳戶、入門指南等這些幾乎永遠不是故事的核心。找到那個產品能做、而且只有它能做的功能所在的畫面。
- 如果好東西需要登入才能看，先詢問——測試憑證，或他們本地開發環境中的種子帳戶。如果兩者都不可用，不要放棄，也不要偽造你從未見過的會話：轉而採用章節式結構，並從登陸頁面本身的特色卡片、文字和元件來建構。
discovery.md中有收集程序和誠實規則。
然後，在開始建構前，與使用者確認你的理解——對產品的錯誤理解會導致整個建構白費。向他們展示：你認為產品做什麼、你計劃展示的2–4個畫面、主要情境、鏡頭清單，以及音樂問題（請見第四階段）。一個檢查點，然後開始執行。
第二階段——選擇結構
閱讀 references/structure.md。有兩種結構可行；選錯會導致建構失敗。
結構A——單一敘事。預設選項。 一個使用者執行一項工作，並產出一個成果。不是功能導覽。
| 節拍 | 工作 |
|---|---|
| 鉤子 (0–5秒) | 用觀眾自己的話陳述問題。尚未顯示介面。 |
| 提問 (5–12秒) | 使用者要求某個東西。畫面緊湊地聚焦在輸入框上。 |
| 工作 (12–25秒) | 產品明顯地在執行困難的工作。展示結果。 |
| 成果 (25–35秒) | 輸出結果，以可讀的大小完整顯示。 |
| 控制 (35–45秒) | 使用者改變了它，並保持主控權。 |
| 結束畫面 (45–50秒) | 標誌、一行字、網域。 |
工作 和 控制 這兩個節拍是真正的展示與模擬之間的區別。"它問了我而不是猜測"和"我可以編輯它所製作的東西"是建立信任的論點，而信任正是啟動影片真正要販賣的東西。
選擇產品能做到、而一般人不容易自己做到的那個時刻，並讓輸出結果具體且可見——一份產生的文件、一個建構好的圖表、一個修復的錯誤、一個部署好的網站。具體的成果是人們會記住的。
結構B——章節式功能影片。 三個功能，每個都先由一張樸實的標籤卡介紹，然後展示。
鉤子 → [01 標籤 → 功能] → [02 標籤 → 功能] → [03 標籤 → 功能] → 結束畫面
當產品 有存取限制 而你只能從其登陸頁面工作時，或者當這些功能真的不共享一個使用者旅程時，或者當你希望一次建構產出三個獨立的片段時，使用此結構。數量是三個——四個表示沒有一個能真正留下印象。
不要將連續的流程章節化。 如果這些能力在單一會話中一個接一個地發生（研究 → 草稿 → 編輯），那是一個工作流程，將其標記為三個功能反而會與素材格格不入。如果有人要求對連續性產品製作章節，請提供中間路線：保留單一敘事，並將標籤 覆蓋在 每個能力出現時的動作上方。同樣的可讀性，同樣的片段邊界，無需增加執行時間，故事完整。
structure.md 涵蓋了章節卡的設計、如何撰寫標籤（命名結果，而非機制；使用產品自己的詞語）、轉場和排序。
第三階段——讓一切有根據
無論產品屬於哪個領域，請不要捏造其內容。如果是法律產品，法條必須是真實的。如果是分析工具，數字必須合理且內部一致。如果是程式碼工具，程式碼必須能在讀者腦中編譯。
從儲存庫、API、種子資料或文件中提取真實的東西。領域專家會觀看這些影片，一個虛構的細節就會讓你失去他們所有人的信任。當事人名稱、日期和金錢數字可以虛構——這些是特定於客戶的，而不是關於世界的陳述。
在資料檔案中保留出處註記，說明每個事實的來源。未來的你會需要它。
第四階段——建構
執行建置腳本，它會鎖定實際能協同運作的版本，並寫入設定：
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。複製真實的類別名稱。如果產品使用Tailwind，則將其設定和主題CSS供應進來；如果它使用CSS變數作為顏色，你必須將它們帶過來，否則所有東西都會渲染成無色。
-
src/scenes/ProductScene.tsx——一個匯出的B物件，將每個節拍持有為一個絕對影格編號。所有東西都從中讀取：DOM、攝影機、聲音。重新計時意味著編輯那個區塊，無需其他任何操作。
閱讀 references/camera.md 以了解鏡頭系統，references/motion.md 以了解持續時間和排版。
第五階段——音訊
兩個音軌、兩個檔案、兩個 <Audio> 標籤：音效 和 音樂。將它們分開，這樣任何一個都可以被替換，而無需重新產生另一個。
音效——references/sound.md。克制是整個紀律：一支45秒的影片通常總共只需要三到五個事件。一個「啵」表示東西出現了，一個「咻」表示元素在鏡頭內移動，一個「呼」表示 鏡頭本身 移動了。
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。根據產品 本身 的性質來選擇情緒——嚴肅的主題需要更平靜的背景音樂，而節奏快的剪輯則需要更稀疏的音樂。
第六階段——用靜態影格驗證，在渲染之前
這是緊密迴圈，跳過它會浪費數小時。
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會為每個插槽產生一個Chrome分頁，而預設值（核心數）會導致交換。
第七階段——誠實地交付
發送檔案。然後清楚說明：
- 你無法驗證哪些部分。你可以閱讀靜態影格；但你無法判斷八秒鐘 感覺起來 如何，也聽不到音訊。請如實說出。
- 你重建過的、而非實際觀察到的任何畫面——特別是在有存取限制的產品上。列出它們，並提議如果他們願意分享存取權限，你可以重做那些鏡頭。
- 你做出的、他們可能不同意的判斷。
- 如何替換音樂：將任何WAV或MP3檔案放到
public/music.wav，然後重新渲染。 - 你在建構過程中發現的任何產品問題——一個渲染錯誤、一個錯誤的標籤、一個遺失的狀態。你剛剛比大多數人更仔細地閱讀了他們的UI。那個觀察結果往往比影片本身更有價值。
參考檔案
當你到達相關階段時再閱讀這些——它們很詳細，而且一開始就全部載入並沒有價值。
| 檔案 | 時機 |
|---|---|
references/discovery.md | 第一階段——瀏覽、頁面分類、憑證、設計系統，以及從有存取限制的產品登陸頁面進行建構 |
references/structure.md | 第二階段——單一敘事 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秒。四個聲音就夠了。在製作音樂前先詢問。在渲染前先看靜態影格。說出你無法檢查的部分，以及你推測的部分。