軟體產品的上市影片
製作一段 30 至 60 秒的影片，讓觀眾理解並想要這個產品。
影響一切的關鍵決策：重建，而非錄影
螢幕錄影處處受限。真實延遲等於空白時間。重拍成本高昂。 你無法凍結畫面，無法放慢某個節拍並加快另一個，也無法在不導致壓縮模糊的情況下緊密裁切。
因此，請將 UI 重建為 Remotion 中以影格驅動的 React。每個視覺元素都是 useCurrentFrame() 的純函數。打字會在確切的曲線上出現，載入狀態會在拍子上解決，而重拍只需要修改一個數字。
這種做法之所以合理，是因為你可以讀取產品的實際程式碼（若是本機開發）或 DOM+CSS（若是託管服務），並忠實地重現。就這樣做——採用真實的類別名稱、真實的顏色、真實的文字內容。重建結果應與錄影無法區分，甚至更好。
何時該錄影： 產品內有大量 3D 內容、影片內容、Canvas/WebGL 畫面，或是原生桌面應用程式。如果某個特定畫面無法重建，則僅錄製該畫面，並使用 <OffthreadVideo> 合成。
第一階段——理解產品
在開始此階段前，請先閱讀 references/discovery.md。該文件涵蓋了瀏覽與分類的程序、憑證對話，以及如何從即時網站提取設計系統。
簡短版本：
- 提供 URL 時：瀏覽網站。先看登陸頁面（它會告訴你他們如何定位自己），然後再看應用程式本身。釐清該產品為誰解決什麼問題。
- 提供本機儲存庫/開發伺服器時：閱讀程式碼。資訊豐富得多——你能獲得真實的元件、真實的主題代碼、真實的種子資料。
- 對頁面進行分類。 大多數產品有 20 個畫面，但只有 3 個重要。認證、設定、帳單、隱私、帳戶、入門引導——這些幾乎從來都不是故事重點。找到產品執行其獨特功能的畫面。
- 如果重要功能需要登入，先詢問——測試憑證，或他們本機開發中的種子帳戶。如果兩者都不可用，不要放棄，也不要偽造你從未見過的會話：切換到分章形式，並從登陸頁面本身的特色卡片、文字和元件來構建。
discovery.md中有收集程序與誠實規則。
然後在開始構建前，向使用者確認你的理解——對產品的錯誤理解會導致整個構建失敗。向他們展示：你認為產品做了什麼、你計劃展示的 2 到 4 個畫面、主要情境、鏡頭清單，以及音樂問題（見第四階段）。進行一次檢查點確認，然後開始執行。
第二階段——選擇形式
閱讀 references/structure.md。有兩種形式可行；選擇錯誤會導致構建失敗。
形式 A——單一敘事。預設選項。 一個使用者執行一個任務，並獲得一個產出。不是功能巡禮。
| 節拍 | 任務 |
|---|---|
| 鉤子 (0–5 秒) | 用觀眾自己的話陳述問題。此時尚無 UI。 |
| 請求 (5–12 秒) | 使用者要求執行某個動作。鏡頭集中在輸入區域。 |
| 工作 (12–25 秒) | 產品明顯執行了某個困難的任務。展示證據。 |
| 產出 (25–35 秒) | 以可讀大小完整顯示輸出結果。 |
| 控制 (35–45 秒) | 使用者更改了內容並保持主導。 |
| 結尾 (45–50 秒) | Logo、一行說明、網域。 |
工作與控制節拍是區分真實示範與模擬的關鍵。「它詢問了我而不是猜測」以及「我可以編輯它製作的東西」是信任論點，而信任正是上市影片真正在銷售的東西。
選擇產品能做到一般人無法輕易自行完成的時刻，並讓產出具體且可見——一份生成的檔案、一張構建的圖表、一個修復的 Bug、一個部署的網站。具體的產出是人們會記住的。
形式 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 | 第二階段——單一敘事與分章，章節卡片設計，撰寫功能標籤，轉場，排序 |
references/camera.md | 構建鏡頭——佈局空間、焦點鏡頭、切換與推進與變形、隔離元件 |
references/motion.md | 動畫持續時間、字體、鉤子模式、問題重播 |
references/sound.md | 聲音設計——彈跳聲/嗖嗖聲/呼嘯聲詞彙、節制、合成鍵盤和點擊聲 |
references/music.md | 尋找與合成背景音樂、選擇情緒、將段落對齊剪輯點、在音效下進行混音 |
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–300 毫秒，鏡頭移動約 1 秒。四個音效就夠了。在製作音樂前先詢問。在渲染前先查看靜止畫面。說出你無法確認的事項，以及你推斷的事項。