Harvey Figma 行銷影片案例：44 種流程、36 片 69 分鐘，靠什麼重用？
Harvey Figma 案例以共用產品畫面、動效與品牌規範，讓代理批次製作個人化行銷影片。本文拆解四十四種流程、三路檔案與作者自報三十六片六十九分鐘的條件，說明團隊怎麼參考。
Harvey Figma 代理案例把行銷影片的問題，從「能不能做出一支」推進到「怎麼為很多客戶持續做」。原作者說，最初每支還要來回調整十五到二十分鐘，光把同樣流程多做幾次，並不能自然放大產量。
Harvey 的 Shawn Farsai 和共同創辦人 Gabe Pereyra 在台灣時間十月二十二日公開團隊做法，Figma 官方隨後分享。他們先把產品畫面和動效建成共用資產，再讓代理依客戶脈絡編排影片。
團隊整理了四十四種示範流程，並自述一批三十六支影片花六十九分鐘完成。這個數字來自特定引擎、檔案分流與輸出流程，不能直接當成所有團隊的速度保證。
更容易被忽略的是，一份產品畫面和一個動作怎麼被不同影片重用。若每支都從頭重畫，再多代理也可能同時產生不一致的畫面，讓審片工作跟著增加。
我認為，有固定產品示範、品牌規範和審片人員的團隊，適合參考這個方法。先做一小批同類影片，比直接追求數百支，更容易知道資產重用能省下哪一段。
要理解這個案例為何能批次製作，先看他們如何把影片拆成能反覆組合的部分。
Harvey Figma 案例先改了什麼？從逐片調整到共用素材
團隊先把反覆出現的產品畫面與動作整理好，再讓代理組合，而不是只增加同時工作的代理。因此每次製作都有可共用的起點，讓重複工作有地方累積，也讓之後的修正能被其他影片利用。
原作者完整案例說明，早期提示可以做出還不錯的示範，但每支仍要十五到二十分鐘來回調整。問題不是完全做不出來，而是想為數百個客戶製作時，逐片修改會變成另一種大量工作。
所以團隊先建立兩份基礎：產品畫面庫 Product Map，以及動效庫 Motion Primitives。前者讓代理知道產品真的長什麼樣，後者讓常見的鏡頭與互動能按共同方式呈現。
影片也需要介於需求和製作之間的規格
作者以另一支產品發布影片說明，製作先從分鏡開始。分鏡把每個鏡頭、文字和轉場先放到可討論的順序，讓人和代理能在投入製作前，先確認故事是否成立。
這和只下一句「幫我做一支很酷的影片」不同。若鏡頭先後、想表達的功能和結尾都沒有決定，代理即使很快產出畫面，後續仍可能整段重排，生成速度便無法直接變成完成速度。
在 Harvey 的發布片案例中，代理會依回饋修改分鏡，並詢問哪些意見應成為規則。這讓一次修改有機會留下可重用的判斷，例如某類轉場該怎麼處理，而不是每次都由人重新說明。
Figma 官方轉述也把重點放在品牌與動效脈絡、畫布上的分鏡與動畫，以及生成素材。這是同一個企業案例的官方分享，本文沒有把它改寫成第三方實測報告。
素材能重用之後，還需要讓品牌規範和產品內容維持同一個依據。
Product Map 與 Motion Primitives：哪些內容不能每次重畫？
Product Map 保存共用產品畫面，Motion Primitives 保存可重複使用的動效，兩者各自解決不同的不一致。若產品畫面不固定，每支影片可能展示不同按鈕或文字，若動作不固定，影片的節奏也容易各走各的。
依案例描述，代理先瀏覽產品、操作畫面，再把重要頁面重建成元件。元件是可在不同設計中重複使用的部分，在這裡讓影片引用相同產品內容，而不必每次靠模型重新猜一張介面。
Harvey 把 Product Map 發布為組織共用元件庫。對產品更新而言，這個安排有明確用途：先修正共用畫面，再讓引用它的內容一起跟上，比逐支影片找出相同錯誤更容易管理。
動效庫保存的是產品怎麼動
Motion Primitives 則把常出現的動態整理成可組合部分，例如鏡頭推進、畫面交接和產品內的修訂標記。這讓個人化影片改變故事時，仍可以維持同一種產品展示語言。
因此動畫需要回到要說明的產品行為。若影片要讓買方看見文件如何被修改，標記出現的位置、先後與停留時間，都應服務那個動作，不能讓鏡頭效果遮住真正要展示的內容。
品牌規範也從文字檔進一步變成 Figma 圖庫。因為色碼與字體可以靠文字表達，但格線、元素關係和長篇版型需要可見的範例，代理才能參考實際配置，而非只讀抽象形容詞。
因此這份 Agentic Brand Guidelines 同時包含基礎、模板與完成範例。專案再加自己的規則，代理依任務讀取相關內容，避免每次把所有品牌資料一次塞進同一段提示。
對讀者，這個差別是「給代理更多背景」和「給它可直接引用的設計依據」。後者更容易檢查是否遵守，也讓人能指出哪個共用元件或範例需要改，而不是籠統要求更符合品牌。
共同依據固定之後，每個客戶的影片才能把變化放在敘事與需求，而不是產品長相。
客戶影片怎麼個人化？先把脈絡變成腳本
代理把銷售與對話資料整理成需求，再從既有示範流程編排內容，畫面中的公司則採虛構設定。這讓影片能對應某類客戶問題，同時不必把真實客戶名稱直接放進產品示範。
Harvey 團隊整理了四十四種與特定公司無關的流程，各自對應買方常想看的功能片段。所以這些流程是可選的敘事材料，一支影片可以按需求選用其中片段。
Harvey 作者描述，代理透過 Enterpret 的 MCP 整合 Gong 通話、Salesforce 銷售紀錄與 Slack。MCP 是讓 AI 工具連接外部功能的共同介面規範，在這裡幫助代理取得既有工作脈絡，再決定腳本要強調什麼。
個人化的是要回答的問題
例如一類買方關心文件修訂，另一類關心如何找到資料，影片就應從對方需要看見的工作開始。這是理解案例的例子，不能只把公司名稱換掉，就稱為已經完成需求層次的個人化。
腳本接著交由旁白與影像流程處理。作者說，團隊使用 ElevenLabs 建立和呼叫旁白聲音，並透過 Figma Weave 的工作流取得需要的圖片或影片，再放回設計檔案。
因為聲音和生成影像各有工作，產品真實內容仍需要另外維持。產品畫面仍應回到共用元件，否則一張生成得很漂亮的介面，可能讓觀眾誤以為某個並不存在的功能已經上線。
作者也把音樂節奏納入製作。例如先標記音樂應落下的時點，再讓代理調整場景，結尾不理想時則嘗試不同版本。這說明影片的時間安排仍是有方向的設計選擇，而非只把片段自動串起來。
延伸閱讀：Figma Weave 教學：把 Design System 變成可重複執行的 AI 內容工作流
腳本和旁白有了明確內容，批次生成仍需要處理工具和檔案的容量限制。
三十六支六十九分鐘：三路檔案如何處理併發？
案例用三個建置檔案分流，因為多個代理擠在同一檔案曾造成等待與逾時。這是團隊當時的實作限制和解法，不能直接讀成任何 Figma 專案都必須使用相同架構。
Harvey 作者自述，約七百五十行 JavaScript 的引擎，把每份腳本轉成一系列片段，再處理鏡頭、轉場、字幕、游標節奏與結尾卡。JavaScript 是程式語言，這個行數描述該案的實作規模，不是影片製作的必要門檻。
原本大家共用同一檔案時，因為排隊，呼叫拖到約兩分鐘並逾時。團隊因此建立三個 lane 檔案，各有自己的建置代理，另有協調者處理輸出、混音與交付，讓不同階段不必全部擠在同一條路徑。
批次耗時，不能當成單片等待時間
在這份流程下，Harvey 原作者報告一批三十六支影片花六十九分鐘。因為有分流與協調，這是整批的經驗，不應直接改寫成每支都能在固定秒數內完成，或任何帳號都能得到相同吞吐。
更重要的是，這個數字發生在共用畫面、動效和引擎已建立之後。若另一個團隊還沒有那些基礎，就需要先投入整理與開發，不能只把最後一批的時間拿來估第一天成本。
案例還提到達到當日 Figma 呼叫上限。後續夜間代理先替下一批九十七支準備腳本和旁白，這是把工作往前推進，不是已經完成另外九十七支可交付影片。
所以排程可以依工具可用情況，把不同階段分開處理。當畫布工具暫時不能再用，仍可先做不依賴該步驟的工作，但追蹤表要如實標記階段，讓人知道還有哪些內容尚未渲染或檢查。
分流能推進製作，但影片是否已經完成，仍要和檢查及交付狀態一起記錄。
自動檢查與共同追蹤表：哪一步仍需要人決定？
團隊讓代理先標記截字、小字與游標問題，再以共同追蹤表協調人和代理。這些檢查能減少一部分明顯錯誤，但故事是否說對、產品是否真實，以及該交付哪一版，仍需要明確決策。
作者描述，引擎會把完成影片排成畫面總覽，再找出被截斷的文字、太小的字和多餘游標。這比只看檔案是否成功輸出更接近成品品質，因為影片可以播放，也可能仍有畫面問題。
但一張畫面總覽難以完整表達節奏。字幕是否來得及讀、旁白和操作是否同步、轉場是否搶走重點，都需要按時間觀看，所以自動標記應是審片的起點，而不是把整支影片免驗收。
讓每支影片都有可見狀態
共同追蹤表記下客戶、故事、狀態與連結，由人和代理一起讀寫。因此「腳本已完成」「正在建置」「已輸出」和「已交付」能分開記錄，也讓某個步驟卡住時不必重新詢問所有代理。
案例中的內部平台 Spectre 也讓人從 Slack 發起工作。代理在 Figma 修改後，回覆產物、變更和需要查看的決策，讓產品、法務、銷售和行銷等工作負責人能在既有對話中給方向。
但這是 Harvey 的內部工作安排，不是本次發布一個人人可下載的同名產品。對其他團隊，值得參考的是狀態和決策如何留在共同位置，而非假設裝上某一個工具就能得到整套組織流程。
當回饋能變成共用規則，下一支影片才有機會少犯同一種錯。若每支都在私人對話裡改完，代理和其他人看不到修正，批次越大，重複解釋的成本也可能越高。
當每支影片的狀態能被看見，團隊才比較容易評估小批流程是否值得放大。
行銷團隊怎麼借用這個方法？先做一組能審完的小批
適合的起點是固定產品和影片類型，保留腳本、畫面與審片標準，再比較重用前後的工作。這是參考案例的方法建議，不是本站已重做的速度或品質結果。
可以先選幾個需求相近、但關注功能不同的客戶情境，使用同一套產品元件做影片。這樣較容易看出變化來自故事選擇，還是代理每次把產品畫面重新生成造成的差異。
第一次先記錄哪些部分最常被改。如果總在修同一段畫面，優先整理 Product Map 類型的共用素材。如果總在調鏡頭節奏，才把已確定的動作做成可重用片段，避免一開始建一大套沒人用的動效庫。
完成數量和商業結果分開衡量
因此比較結果時，影片批次完成應先記為產出能力。是否更能讓買方理解、是否改善後續對話，需要另一組觀察，不能直接把三十六支或六十九分鐘換成轉換率與營收成長。
原作者另報告十四天內使用了大量 Token，也就是模型處理內容的計量單位。但不同工具、模型與流程的用量，不能只用一個總數推算外部團隊的帳單。真正導入時要保留自己的工具費用和清稿時間。
我會先做一小批能完整審完的影片，再決定哪些內容值得自動化。若共用資產穩定、客戶差異也能被正確表達，再增加並行與數量，才比較容易讓製作效率轉成團隊可管理的工作。
延伸閱讀：Figma Specs 開放 Beta：把 Markdown、設計與 AI 代理接成共同規格
案例可提供流程設計依據，自己的完成時間、清稿成本與商業效果仍要分別建立。
Harvey Figma 常見問題
Harvey Figma 案例是新的影片工具發布嗎？
這是企業團隊公開的工作流程，運用既有 Figma、代理、ElevenLabs 與 Weave 等能力，不是發布同名的新模型。
三十六支六十九分鐘是普遍保證嗎？
這是原作者在特定共用資產、引擎和三路檔案安排下的自述，不能直接套到其他團隊。
九十七支已經全部完成影片了嗎？
作者描述達到呼叫上限後，代理先準備下一批九十七支的腳本與旁白，沒有把它們全數算成已完成影片。
先讓產品和品牌能重用，再擴大製作
Harvey 這個案例的價值，是把產品畫面、動效、客戶需求、代理分流與審片放到同一份工作裡。影片的個人化建立在可重用基礎上，而不是每次從頭生成一個看似合理的產品。
對行銷團隊，先找到最常重做的部分，再用小批作品確認改進，會比直接追求數百支更有依據。想追蹤 AI 創作工具、企業案例與代理工作流程，可以免費訂閱 AI 郵報。
