Harvey 代理行銷影片案例：畫面先變資產，再批量產片

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

台北時間 10 月 22 日凌晨 1 點，法律科技公司 Harvey 在官方部落格發布長文《How Harvey is Building a Frontier Marketing Org》，作者是共同創辦人 Gabe Pereyra 與品牌負責人 Shawn Farsai。文章緣起寫在第一句：Figma 問 Harvey「你們用我們的 MCP 伺服器到底做了什麼」，這一整篇就是官方版的長答。六分鐘後 Gabe 在 X 發出原貼，Harvey 官方帳號隨後轉發；台北時間同日凌晨 3 點 8 分，Figma 共同創辦人 Dylan Field 分享這篇文，補了一句「讓這件事 end to end 在 Figma 裡完成，就快了」。

Pin

長答的內容是一條已經在跑的行銷產線：代理在 Figma 檔案裡批量製作個人化的產品影片，作者自述的一批成績，是 36 支影片花 69 分鐘完成；近 14 天，團隊核心使用者一個人跨 Figma、ElevenLabs 與 Weave 用掉 15.6B tokens。這兩個數字在社群上被大量轉述，但對想借用的團隊來說，真正該看的是數字前段：Harvey 先把產品畫面與動效整理成兩座共用資產庫，代理才有東西可以組合。順序反過來的話，加再多代理，只是同時產出更多各自長得不太一樣的介面。

誰該看這則案例：為很多客戶做產品影片的團隊

這不是一般使用者的功能更新，Harvey 也沒有開源任何東西。案例對準的場景很具體：公司想贏下的帳戶有數百個，目標是每個帳戶一支專屬的產品影片，內容跟著對方在意的事情走。這種工作形狀在 B2B 行銷很常見，做 SaaS、做顧問服務、經手多個客戶的內容團隊都會遇到：單支影片做得出來，批量做不出來。

原文對起點的描述相當誠實：最初的提示詞產出的成果只是還算可以，每支要再花 15 到 20 分鐘來回調整才到位。單支與批量之間，隔的就是這十幾分鐘乘上數百個帳戶。作者把題目定義成規模化問題，這是整篇案例的出發點，也是所有後面工程存在的原因。

反過來說，沒有固定產品畫面、沒有品牌規範、也沒有審片流程的團隊，直接照抄後面的流程意義不大。案例裡的每個速度數字，都建立在那些前置資產已經存在的前提上。

先證明單支可行，用的是一支全程在 Figma 裡做完的發布片

案例的前半段是暖場，也是能力證明。Harvey Artifacts 的發布影片全程由代理在 Figma 檔案裡完成：每個場景建成 Figma Motion 的影格，相機移動、介面狀態與每一行字都記在時間軸上，剪輯成品直接從檔案匯出，中間不經過剪輯軟體。

流程從分鏡開始。原文的比喻是工程人員很好懂的那種：分鏡對影片的意義，就像產品需求文件對程式碼，它坐在創意簡報與實際製作之間，讓每個鏡頭、每行文字與每次轉場在動工前就定案，逼人與代理對每個選擇都有自覺。音樂的處理也具體：團隊標記節拍該落下的時點，代理把每個場景重新對拍；結尾不理想時，代理剪掉一段音軌、調整等化、補上音效，還排出四五種收尾方式讓團隊挑。

這支發布片證明了單支可行，但單支可行與批量可行是兩件事，於是有了後面整套系統。

前後差異：兩座 Figma 資產庫是怎麼建出來的

第一座庫叫 Product Map。做法是讓代理把整個產品爬一遍、每個按鈕都點過，再把關鍵畫面重建成 Figma 元件，以元件庫的形式發布到組織層級。原文的動詞用得很直白：agents crawled the whole app, clicked every button。之後任何影片需要產品畫面，都從這座庫取用，不靠模型重新生成介面。它解決的問題是不一致：每支影片如果各自畫介面，按鈕位置與文字內容都會微妙地不同，觀眾等於看到兩個版本的產品。

第二座庫叫 Motion Primitives，整理的是產品怎麼動：鏡頭推進、畫面交接、穩定的點擊節奏，細到文件裡紅線修訂浮現的動態。這些動效同樣發布成組織元件庫。兩座庫共用一個關鍵性質：修正一個元件，所有引用它的影片一起更新。產品改版時，先改共用畫面，引用它的內容自動跟上，這比逐支影片回頭找同樣的錯誤容易管理。

原文還給了一個判斷角度：他們把 Figma 檔案當程式碼庫在維護。對讀者實用的啟發是分層的：如果你的影片回饋總是在修同一種畫面錯誤，缺的是 Product Map 這一層；如果總在調節奏與轉場，缺的才是動效庫這一層。先補常出錯的那層，比一開始就建一套大而完整的資產更省力。

個人化影片實際在做什麼

在兩座庫之上，團隊與代理一起整理出 44 個與特定公司無關的示範流程，分成 13 類，每個流程對應買方常要求親眼看到的一個時刻，例如把 playbook 修訂放進 Word 文件的完整過程。這份清單扮演選單：每支影片按帳戶的需求，挑選並組合其中的片段。

個人化的材料也不是憑空生成。代理透過 Enterpret 提供的 MCP 整合，拉出該帳戶的 Gong 通話紀錄、Salesforce 的勝敗分析報告與 Slack 討論，再決定腳本要強調哪些功能。畫面上的公司名稱與人名一律用虛構替代，真實客戶的名字不進示範片。

Pin

旁白是固定班底。聲音的主人叫 Ashleigh Whittaker，Harvey 用她 10 分鐘的素材在 ElevenLabs 建立這個聲音，之後每支影片的旁白都由它演出，代理經 ElevenLabs 的 MCP 直接呼叫。聲音庫裡還有其他同事受訪聲音做成的版本。要借用這個做法，聲音本人的同意與可用範圍，得在建庫之前就講清楚，這是案例裡沒有展開、卻不能省的一段。

工具鏈值得寫完整，因為社群轉述常只剩 Figma：Claude 在這套流程裡出現在三個具體位置。Gabe 的原貼直接標註 @claudeai；案例圖說裡有一張工作便利貼，註明是 Shawn 和 Claude 一起把修改順過來的；整批影片的追蹤表本身就是一個 Claude artifact，人與代理共同讀寫，每支影片一列，記客戶、故事、狀態與連結，代理自己更新進度。

跑出 69 分鐘一批的前提：引擎、分流與額度

先把引擎講清楚。約 750 行 JavaScript 把每份腳本轉成影片：鏡頭、轉場、字幕、游標的點擊節奏與結尾卡都由它排程；完成後自動輸出縮圖總覽，標記截斷的文字、太小的字與多餘的游標，讓明顯錯誤在人工觀看前就被挑出來。行數描述的是規模，不是門檻，這是一份把重複決策寫死的腳本工程，不是模型研究。這一層在開源世界有現成對照：我們實測過的 MoneyPrinterTurbo 就是把腳本、字幕與配音組裝成影片的剪輯台，差別在它組的是外接素材，Harvey 組的是自家產品畫面。

分流是全案例最像工程日記的部分。Figma 一個檔案同時只能有一個代理工作，所有代理擠在同一個檔案時，呼叫排隊排到約 2 分鐘然後逾時。團隊的解法是開三個 lane 檔案，各配一個建置代理，另外用一個協調者處理匯出、混音與交付。36 支 69 分鐘就是這個架構跑出來的整批成績。這個數字不能換算成「每支不到兩分鐘」的單片等待時間，也不保證其他帳號得到相同吞吐。

Pin

額度管理是第三個前提。撞到當日的 Figma 呼叫上限後，夜間代理先為下一批 97 支完成腳本與配音。要看清楚動詞：完成的是腳本與配音，原文沒有把這 97 支算成已交付的影片。

消耗量級也一併公開：近 14 天，Shawn 一個人跨 Figma、ElevenLabs 與 Weave 用了 15.6B tokens，Harvey 官方帳號轉發時也用了 15 billion 這個量級。原文沒有附任何金額，這個數字換算不出帳單。想評估成本的團隊可以先記住形態：資產與引擎建好之後，每多一支影片的成本，大量從人力工時移往 token 消耗，實際費用要看自己用的工具與方案。

品牌規範為什麼從文字檔搬進 Figma

Harvey 把整套規範做成頂層的 AGENTS.md，每個專案資料夾再掛自己的 AGENTS.md 頁，只加該專案需要的規則。代理讀資料的順序是漸進的：先讀品牌、再讀專案、最後只讀任務需要的那部分，避免把所有規範一次塞進同一個提示。這套檔案慣例原本長在工程專案裡，這裡被搬去管創意工作。

純文字有極限。色碼與字體用文字交代得清楚，但格線關係、元素之間的相對位置、長篇版型的長相，用形容詞寫，代理讀不好。所以規範升級成 Figma 圖庫，從基礎、模板到完成範例都做成可見的畫面，代理直接引用實際配置。原文有一句值得記：設計大部分活在元素之間的關係裡，而文字描述這些關係的能力很差。

選 Figma 而不用網頁技術，原文給了一個少見的具體理由。團隊曾經在網頁排版引擎 Pretext 之上自建版面系統，但瀏覽器用行盒排字，字體上下緣的填充讓標題的字面高度永遠對不齊格線；Figma 把文字修剪到字面高度與基線，還處理懸掛標點，格線才真的成立。對經營品牌系統的團隊，這是少數把「為什麼是 Figma」講到機制層的公開說法。

生成素材的責任則畫在另一條線上。Figma Weave 是把圖像與影片模型串成工作流的畫布，現在是 Figma 的一部分，代理用同一個 MCP 就取用得到。畫面需要照片、材質或空鏡時，代理跑模型或既存的 Weave 工作流，把結果直接放回檔案。產品介面不走這條路：真實功能的畫面一律引用 Product Map 的元件，而不是重新畫一份。我們的解讀是，這也避免了生成出來的漂亮介面讓觀眾誤以為某個還沒上線的功能已經可用。

人的位置沒有變小：分鏡、規則與審片

這套創意工作的入口掛在 Harvey 內部代理平台 Spectre 上。開發工具團隊的 Shawn 和 Joey 把它指向品牌檔案庫與 Figma 檔案，它就變成一個住在 Slack 頻道裡的創意代理：有人在訊息裡標記需求，它在 Figma 把工作做完，回覆做了什麼、改了什麼、哪些決策需要人確認。產品、法務、業務與行銷的負責人，在彼此本來就在的對話裡給方向。這是 Spectre 的內部部署，並沒有公開版本。

人的判斷被制度化，沒有被省略。分鏡階段的審稿有時一次 50 則留言，代理每輪改完會問哪些意見該變成規則，讓一次修正沉澱成之後可重用的判斷；成品有縮圖總覽的機器品檢在前，但那道品檢只抓截斷的文字、太小的字這類明顯錯誤，字幕讀不讀得完、旁白與操作有沒有同步，仍要靠人看片把關。批次越大，這個審片位置越重要：自動化的是製作，故事對不對、產品真不真實，仍是人的決定。

現在可以做的事

對多數讀者，這則新聞的價值是理解一種已經跑通的工作法，不需要跟著改任何設定：案例裡的資產庫、引擎與 Spectre 都是 Harvey 內部系統，沒有可安裝的版本。行銷與設計團隊若想驗證這套順序，最小的一步是記錄最近十支影片的修改歷史，看回饋集中在畫面、節奏還是腳本；常修哪一層，就先補那一層的共用資產，用一小批同類影片試跑，再決定要不要投入引擎與分流的工程。

對倚重 Figma 的團隊，Dylan Field 分享時補的那句話值得放進雷達：他很期待讓這件事 end to end 在 Figma 裡完成，還加了括號說「就快了」。平台方把這條流程內建化的意圖已經寫在字面上，差別只是時間點。屆時單檔單代理的限制、分流工程與呼叫上限都可能是另一套故事。

還沒有答案的部分

這篇案例是單一團隊的自述，有幾件事它沒有給答案。36 支 69 分鐘沒有附單片品質的獨立驗證，我們也沒有看過成品；Figma 每日呼叫上限的實際數值沒有公開；15.6B tokens 沒有對應任何金額；那 97 支的後續交付狀態，原文沒有更新。這篇自述的可信度建立在它是公司官方一手、且細節連限制都寫了，但數字本身仍屬作者宣稱。

回查的觸發點也明確：Figma 若正式推出端到端的代理影片流程，或單檔單代理與呼叫上限的限制改變，這篇文章的工程段落就需要更新。在那之前，案例裡最耐用的部分是順序：資產先建、代理後組合，並且把人的判斷留在分鏡與審片這兩個位置。在我們看來，這個順序換到別的畫布工具上也成立，只是 Harvey 把它跑出了數字。