TL;DR
製作 SaaS 解說影片時，應先鎖定已核準的來源素材 brief，明確一個受眾和一個 CTA，把每條主張映射到可見的狀態變化，審核分鏡計劃，再檢查匯出檔案的時長、資料身份、文字可讀性、字幕和 CTA 停留時間。在我們的 TapVid 實測中，第一版成片更換了範例客戶，還加入了未經批準的數值。修改版糾正了記錄，卻仍然只匯出 16.83 秒，而不是要求的 35 秒。應驗收實際檔案，而不是任務成功提示。
這篇指南展示的是完整製作閉環，而不只是啟動生成時使用的 prompt。範例中的 InvoiceFlow 是專為本次測試創建的虛構 SaaS 產品，並非真實公司、客戶或背書。TapVid 在這裡充當 Explainer Video Engine：你提供現有產品文案、腳本、文章或其他已核準材料，再由你決定哪些內容屬實、觀眾需要理解什麼，以及最終成片是否真正證明了它所表達的內容。
01
1. 先確定投放位置、目標受眾和唯一下一步行動
不要從功能列表開始。先確定影片最終會出現在哪個頁面或管道。
首頁解說影片通常需要快速回答三個問題：
- 這支影片是給誰看的？
- 產品幫助他們理解或處理什麼問題？
- 看完之後，他們應該做什麼？
在 InvoiceFlow 測試中，目標受眾是使用多個工具跟蹤發票的自由工作者。這個故事只有一個任務：展示一張發票從創建、付款狀態更新到每月總覽的過程。CTA 固定為：在一個地方查看整個月的情況。
這個邊界能防止影片變成對所有儀表板的逐一瀏覽，也為驗收提供了標準。如果某個畫面不能幫助觀眾理解這條路徑，它就不應該出現在這個版本中。
投放位置也會影響節奏。首頁影片可以留出幾秒，讓觀眾看清一次產品操作；付費社群媒體版本可能需要更快切換；新手引導影片則可以在具體控制項上停留更久。先選位置，再定目標時長。
02
2. 建立單一事實來源 brief
來源素材 brief 應把已核準事實與創意方向分開。這比一段很長的描述性 prompt 更有用，因為它明確告訴影片系統哪些內容可以解釋、哪些內容不能自行編造。
SaaS 解說影片的 brief 應包括：
- 目標觀眾和投放位置。
- 已核準的產品操作。
- 準確的 CTA。
- 必須保持一致的範例資料。
- 不得出現的主張、數值和介面標簽。
- 格式、語言、旁白和大致時長。
本次測試批準的產品機制被刻意控制得很小：
自由工作者在一個地方創建並傳送一張發票。付款到帳後，同一張發票進入一個帳本。每月總覽展示已付款和未付款的工作。
範例記錄也被固定為：Client A、INV-001、$1,200。把這三個值視為同一個身份非常重要。如果後續畫面改變了客戶或發票編號，觀眾跟蹤的就不再是同一條記錄。
這正是可見文案白名單發揮作用的地方。它列出 motion graphics 可以顯示的文字和數值。黑名單只告訴系統少數不能做的事，而白名單能劃定更清晰的邊界。
TapVid 的 SaaS 解說影片製作工具 可以把你提供的材料整理為場景和旁白。應提供足夠的產品事實來構建故事，但不要讓它自行補齊本應由產品團隊回答的資訊。
03
3. 把故事改寫為可見的狀態變化
場景大綱應該描述畫面中發生了什麼變化，而不只是旁白說了什麼。
InvoiceFlow 的故事分為五個節拍：
| 場景 | 旁白任務 | 必須出現的畫面變化 |
|---|---|---|
| 問題 | 展示分散的工作 | 分散的卡片連接成一條路徑 |
| 創建並傳送 | 展示一次發票操作 | 顯示 Client A、INV-001 和 $1,200，然後完成傳送操作 |
| 帳本 | 展示付款進入同一條記錄 | 同一張發票從 Sent 變為 Paid |
| 每月總覽 | 展示同一條記錄最終出現的位置 | 顯示已付款和未付款類別，但不編造總額 |
| CTA | 給出一個下一步行動 | 產品名稱和準確 CTA 保持清晰可讀 |
注意，每一行都包含一個狀態變化。“展示一個儀表板”還不夠具體；“付款到帳時，讓同一張發票從 Sent 變為 Paid”則可以在最終影片中被檢查。
旁白也應該保持同樣的聚焦。批準腳本中的兩句核心旁白是：
你可以在一個地方創建並傳送發票。
付款到帳後，它們會進入同一個帳本。
畫面负責呈現產品機制，旁白负責讓觀眾保持方向感。如果一句旁白同時提到三個產品操作，畫面往往會變成一堆很小的卡片。
04
4. 在消耗渲染額度之前審核方案
生成影片前，應同時檢查場景表和腳本，重點查看時長、連續性、無依據文案和文字密度。
使用這份渲染前檢查清單：
- 每個場景是否只有一個主要資訊？
- 範例資料是否在所有場景中保持一致？
- 每條口頭主張是否都有可見動作作為支持？
- 是否有某句旁白相對於分配時長過長？
- CTA 是否完全準確，而不是改寫版本？
- 主要介面在 16:9 畫面中是否足夠大，嵌入網頁後仍然可讀？
本次運行中，最初的問題場景旁白在 6 秒內包含約 39 個英文單詞，無法以正常語速清楚讀完。我們將它替換為：發票和付款狀態可能分散在不同工具中。
我們還把結尾旁白替換為準確 CTA。這些腳本修改確實生效，最終 transcript 按正確順序包含了全部五句已核準旁白。
但這並不代表成片正確。腳本驗收與影片驗收是兩個獨立門槛。
05
5. 生成影片，然後檢查真實成片
生成的成片為 1280×720、30 fps，並使用單聲道 AAC 音频。實測時長為 16.83 秒。五句旁白都存在，但原定節奏被壓縮到五個章節，每個章節只有 1.9 到 4.9 秒。
乍看之下，創建並傳送場景很干淨。主要卡片足夠大，已核準的客戶、發票、金額和按钮也都清晰可見。
仔細看會發現，場景還顯示了 Draft、字段標簽，以及動畫前段的 $0.00 中間狀態。這些內容不在可見文案白名單中。它們並不會讓整個畫面完全不可用，但說明渲染結果没有遵守批準的資料邊界。
更嚴重的連續性問題出現在下一幕：帳本把記錄改成了 Acme Corp 和 #INV-2024-001。
金額仍是 $1,200，但只匹配一個數值還不夠。觀眾看到的是另一張發票，從創建、傳送到付款的因果路徑因此被打斷。
每月總覽又加入了一組没有依據的結果：$0、FULLY SETTLED 和 NO OUTSTANDING。
這些補充看似無害，卻改變了產品主張。“展示已付款和未付款工作”並不能證明没有未付款项目，也不能證明所有款项已經結清。
因此，審核完成的解說影片時應把它當成一個連續過程，而不是一組好看的靜帧。先不暫停完整觀看一次，再逐場景核對名稱、數值、狀態變化和轉場。
06
6. 拒絕較差結果，並編寫針對渲染問題的修改指令
面對有問題的第一版成片，正確回應並不總是“讓它更好”。這種指令會給系統再次改變腳本、風格和資料的空間。
把修改要求拆成四類鎖定條件：
時長鎖定。 為每個場景指定固定時長。下一版本中，我們要求 6、8、8、9 和 4 秒，總計 35 秒，最後 4 秒專門留給 CTA。
身份鎖定。 明確唯一允許出現的記錄：Client A、INV-001、$1,200，並要求同一行從 Sent 變為 Paid。
可見文案鎖定。 列出允許出現的文字和數值，並明確刪除真實成片中發現的錯誤文案。這比重複原始 brief 更有效，因為它直接回應已經觀察到的失败。
構圖鎖。設定可讀尺寸目標。我們要求主介面佔據幀的55%至70%，沒有微小的浮動卡片，也沒有爭奪注意力的第二張唱片。
可以複用下面這個模式：
保持當前 transcript 不變。使用固定時長重新渲染相同的五個場景。只使用一條記錄：[客戶]、[發票]、[金額]。在同一條記錄上顯示 [狀態 A] 變為 [狀態 B]。只顯示以下批準文案：[白名單]。刪除已觀察到的錯誤：[實際錯誤標簽和數值]。讓準確 CTA 保持 [秒數]。
CTA 畫面本身很清楚，但該章節只持續 1.9 秒，短於要求的停留時間。
不要因為最後一帧看起來不錯就批準整個版本。只有完整路徑準確且可讀時，才能通過驗收。
下一次渲染說明了為什麼每次修改都需要重新驗收。修正版在創建發票場景中保留了批準記錄，並把這一身份帶入帳本。
帳本隨後继續使用同一張發票，没有切換到第二個虛構客戶。修改後的每月總覽將批準記錄放在 Paid work 下，同時保留 Outstanding work 類別，但没有編造總額或“全部結清”的主張。
這些都是有意義的改進：可見文案鎖定和身份鎖定生效了，但時長鎖定没有生效。
TapVid 项目聊天稱修改版會按 6、8、8、9 和 4 秒的場景分配生成一支 35 秒影片。然而下載的 MP4 實測只有 16.833 秒，播放器仍展示壓縮後的五章節版本。這個檔案確實是新的，因為 checksum 和檔案大小都與上一版不同，並非誤下載舊檔案。修改引擎改變了畫面，卻没有應用要求的節奏。
因此，最新版本可以作為修改效果的證據，卻還不能作為最終批準的首頁解說影片。當編輯器聲稱某项約束已經應用時，應檢查匯出時長、章節時間和完整播放結果，再判斷是否可發布。
07
7. 匯出，並在真實投放位置測試
版本通過內容審核後，匯出並檢查實際檔案。不要只相信編輯器中的標簽，應核對真實時長和分辨率。
發布前請確認：
- 寬高比與投放位置匹配。
- 旁白與字幕表達相同內容。
- 字幕保持同步，並且不遮挡關键控制項。
- 產品標簽在真實嵌入尺寸下仍然可讀。
- 同一組範例資料贯穿每個場景。
- CTA 文案準確，並停留足夠長時間。
- 水印、字幕和分辨率設定符合目標管道要求。
對於预錄媒體，無障碍字幕應該準確表達口頭資訊，並與音频保持同步。W3C Web Accessibility Initiative 字幕指南解釋了字幕對無法聽到音频的使用者所起的作用。
最後，在影片實際出現的頁面上觀看一遍。在大型編輯器裡清晰的場景，放進首頁欄位或移動端 viewport 後可能過小。如果介面難以閱讀，應簡化構圖，或為該投放位置單獨製作版本。
08
可複用的 SaaS 解說影片 brief
下一個项目可以直接複用這個結構：
使用以下已核準來源素材，為 [具體受眾] 製作一支 [時長]、[寬高比] 的 SaaS 解說影片：[粘貼或附加來源素材]。觀眾應該理解 [一條產品路徑]，並執行這個行動：[CTA]。展示以下可見狀態變化：[場景動作]。只使用這些範例名稱、數值和狀態：[白名單]。不要增加主張、總額、集成、結果或客戶資料。渲染前先返回場景方案和旁白供審核。
然後按以下順序審核：來源素材 brief、場景動作、旁白、第一版渲染、完整播放、檔案 metadata 和投放位置。這個順序更容易判斷問題來自來源素材、腳本還是 renderer。
如果你已經有產品文案或腳本，可以從 TapVid 的 AI 解說影片生成器 開始，並在審核過程中始終把事實來源 brief 放在项目旁邊。
09
如何製作一支真正可以發布的 SaaS 解說影片
最安全的流程很簡單：在匯出檔案通過與腳本同等級別的檢查之前，把每支生成影片都視為草稿。來源素材 brief 應控制產品事實；場景方案應讓每條重要主張變得可見；最終審核應在真實 MP4 中確認身份、狀態變化、時長、可讀文案、字幕和 CTA。
本次測試也說明，修改品質比嘗試次數更重要。第二次渲染糾正了範例記錄，刪除了没有依據的結果標簽，卻仍然忽略了要求的 35 秒時長方案。這一結果證明，每次修改後仍然需要完整 artifact QA。
使用 SaaS 解說影片製作工具時，應提供已核準的來源素材和精確約束，並把編輯審批保留給人工審核者。這樣才能製作出真正解釋產品、又不會把生成細節變成意外主張的 SaaS 解說影片。
10
常見問題
| 審核問題 | 安全默認做法 |
|---|---|
| 來源素材是否已經批準？ | 在產品事實和範例資料固定之前，不要開始渲染。 |
| 腳本是否正確？ | 旁白應與影片分開驗收。 |
| 渲染結果是否正確？ | 發布前逐場景檢查匯出檔案。 |
SaaS 解說影片應該包含什麼？
應包含一個觀眾問題、少量可見產品操作、一致的範例資料和一個 CTA。每個場景都應該讓產品路徑中的一個新環節更容易理解。
SaaS 解說影片應該多長？
應根據投放位置和可見操作數量決定時長。不要為了凑整數而拉長簡單故事，也不要把場景壓縮到標簽、狀態變化和 CTA 難以看清。
SaaS 解說影片製作工具可以編寫旁白嗎？
它可以把你提供的產品材料整理為旁白，但渲染前仍應核對術語、主張、時長和最終 CTA，並始終把來源素材視為權威來源。
為什麼腳本正確，影片仍可能很差？
視覺 renderer 可能增加介面文案、改變範例資料、壓縮場景時長，或在旁白解釋原因前先顯示完成狀態。因此，應把實際影片與已核準腳本分開審核。
應該使用螢幕錄影還是 motion graphics？
當準確介面步骤本身就是證據時，應使用螢幕錄影；當主要任務是解釋產品流程或關系時，應使用 motion graphics。只有兩種格式各自承担明確任務時，混合形式才有效。
修改 prompt 中應該包含什麼？
寫明失败場景、觀察到的錯誤、要求的替換內容、固定資料、時長，以及允許出現的準確文案。保留已經通過的部分，例如 transcript 或視覺方向。
一個場景有問題，需要重做整支影片嗎？
不一定。如果受眾、故事和 CTA 仍然有效，可以只修改對應場景；如果目標觀眾、產品承诺或因果路徑已經改變，則應完整重做。
