最近，一些創作者開始讓Claude用代碼製作音樂影片。影片推主Aillex在10月12日發布的一次對照實驗中，把同一份任務交給Claude Code和本地Agent，記錄了它們從寫分鏡到交片的全過程。
它恰好回答了內容創作者眼前的一個問題：電腦已經能跑本地模型了，哪些工作可以放心搬回來，哪些工作還值得為雲端AI付費？
如果你正考慮用本地AI省下訂閱費，這個結果值得看。
15秒動畫，本地完成得更快，成片卻更簡單
參與比較的兩位「導演」，一位是Claude Code中的Claude Opus 5.5，通過訂閱使用；另一位是Hermes Agent，接入本地Qwen 3.6 27B，採用4-bit量化、關閉思考模式，配置64K上下文，在一張32GB顯示記憶體的RTX 5090上運行。
這些條件決定了比較的範圍：它反映兩套具體系統完成特定任務的表現，無法代表所有雲端與本地模型。
這次MV也沒有調用影片生成模型。
兩邊使用同一套開源動畫工具ClaudeAnimationBase。Agent編寫分鏡，用JavaScript描述場景和動作，瀏覽器畫出每一幀，再合成為影片。你要第12.4秒的畫面，程序就按那個時間點繪製。
雲端和本地的區別，主要在於誰負責理解任務、寫代碼、檢查和修改。兩邊的畫面渲染都在推主自己的5090上完成。
推主先用一個15秒動畫熱身：讓工具包里的橙色角色Clawd追一隻蝴蝶。
本地Agent第一次沒有輸出畫面，原因出在動畫工具的渲染配置。瀏覽器在這次Linux後台運行環境中未能正確啟用GPU渲染，轉用軟體渲染後又不斷超時。21分鐘後，推主停止任務。這次失敗屬於運行環境問題，不能歸到模型能力上。
調整瀏覽器啟動參數後，第二次本地Agent用了13分鐘完成。Claude則花了約一小時。
這裡比較的是修正配置後的單次任務耗時，本地的13分鐘不包含此前失敗的21分鐘，也不能直接理解成模型推理更快。
兩邊交出的作品複雜度不同。Claude畫出了山丘、雲、草地和光線變化，還安排了一朵被角色踩扁、隨後戴到身上的花。本地版本簡單得多：天空、地面，加上幾個點。
檢查投入也不同：Claude進行了17次渲染、查看22張圖片，本地Agent檢查了7次畫面。
本地版本還漏掉了一個分鏡要求：計劃寫著「蝴蝶落在角色頭上」，實際卻落在腳邊。它檢查後，仍給出「整體看起來不錯」的評價。
兩邊還有一個共同問題：背景閃爍。
動畫工具為模擬手繪質感，每秒重新生成12次筆觸抖動。落在線條上，畫面顯得鮮活；鋪滿天空，整片背景就會不停地閃。
推主還寫了一個腳本，檢測背景是否不停閃動。按檢測結果，本地版本似乎比Claude更穩定。
看完成片，發現本地版本的整片天空突然變綠了四次。
腳本為什麼沒發現？因為它會跳過畫面變化很大的片段，避免把正常轉場算成閃爍。本地Agent恰好用了四次覆蓋全螢幕的筆刷轉場，這些刺眼的變化也被一起跳過了。
也就是說，本地版本分數更好，是因為檢測漏掉了最明顯的問題。這提醒我們：自動檢查通過之後，成片仍要完整看一遍。
較低的檢測分數，並不保證更好的觀看體驗。
推主固定靜態背景的隨機筆觸，讓它每幀保持一致，同時保留角色運動和有意設計的光線變化。後面的66秒MV採用這個方法，鏡頭閃爍指標中位數分別降至0.86%和0.59%。
但全螢幕轉場仍在檢測盲區，完整觀看依然必要。
任務變長，64K上下文成為這套配置的限制
正式比較時，推主把在Suno中製作的66秒歌曲《Core Loop》交給兩位Agent，提供相同的創作要求、畫面邊框和同步歌詞。
Claude一次會話就完成了，約35分鐘。主角是一隻叫Bit的小黃機器人，場景從夜晚走向日出的桌面，還在副歌進入顯示器里的線框世界。
本地Agent嘗試同樣的做法，到了約第76步，配置的64K上下文被填滿。它還在修改場景文件，隨後返回空回復，停止工作，沒有輸出一幀。
模型裝進顯示記憶體，只是開始。文件內容、檢查記錄和工具結果會不斷進入會話，後續任務需要攜帶的資訊越來越多。
這裡暴露的是這套配置和流程的限制。64K並非本地部署的統一上限，雲端Agent同樣需要管理不斷增長的上下文。
推主沒有換更大的模型，而是把任務拆成六次短會話。
第一階段搭場景和角色，中間四個階段各做歌曲的一部分，第六階段檢查和渲染。每次開始，只讀取交接筆記、一頁簡化的工具說明，以及當前負責的分鏡；完成後，留下成果和未解決的問題，再結束會話。
下一次接手的Agent由此可以重新開始，不必攜帶此前全部操作記錄。
第六階段又遇到Hermes日誌功能崩潰，推主補了一次收尾會話。按部落格的時間記錄，失敗嘗試、六階段執行和收尾累計約1小時45分鐘，本地方案終於完成交付。
這次調整說明，分階段執行和明確交接，可以幫助當前本地方案完成原本中斷的長任務。
不過，交片還沒有解決質量差距。
推主更喜歡Claude的版本。本地版本主要是在同一張桌面前讓機器人跳來跳去；分鏡安排的「戴上像素圍巾」，也沒出現在對應畫面里。
Claude的表達則偏直白：歌詞唱什麼，它就畫什麼。完成度更高，畫面卻缺少歌詞之外的故事。
推主自己也引入過錯誤。他修正歌曲節拍後重新渲染Claude成片，卻沒有複查，結果出現兩段約3.5秒的空藍畫面。推主將其歸因於修改節拍後，原有場景時間未正確對應，並保留原版作為有效作品。
無論誰負責生成，改變成片的輸入之後，都需要重新驗收。
推主最喜歡的版本，經過了更多規則和人工修改
為了改善創意，推主組織了一個AI討論組。
Claude和三個本地模型分別提出三個方案，共12個。提案時互相看不到對方的想法，匯總後用字母編號，再選一個繼續製作。
評分者是Claude，而且它知道哪些方案來自自己。因此，這組評分不能當成嚴格匿名評測，也不能證明哪家模型的創意能力全面領先。
獲選方案很有意思：影片一邊播放，一邊努力把自己畫完，像在追趕歌曲結束的時間。這個版本叫Take 48，預埋的五個細節都在畫面里兌現了。
推主卻把它排在Claude第一版之後。
原因是轉場太多，世界又從灰色幾乎一下跳到全彩，缺少觀眾能感受到的變化過程。創意更有意思，執行效果卻沒得到同樣認可。
隨後，推主把討論改成分角色協作：有人負責敘事，有人負責幽默，有人研究參考作品，有人檢查工具能否實現。各方先獨立提案，再討論優點、弱點和可以組合的部分，最終由一個人決定。
新一版Take 49保留了「影片畫出自己」的創意，又補上具體規則：全曲最多五次設計轉場，顏色和完成度逐步變化，結尾給觀眾留下停留時間。
它最後成為推主的首選。
Take 49仍由Claude負責執行，Claude也主持討論，本地模型參與其中。同時變化的還有製作規則和人工反饋，因此無法把提升單獨歸因於多Agent協作，更不能寫成「本地模型反超雲端」。
回到成本，推主把本地方案標為「0美元」，同時說明：這只是沒有模型使用費用，電費沒有測量，硬體投入也沒計算。
雲端方案消耗訂閱資源，本地方案需要更多執行時間和流程調整。這次實驗沒有記錄完整人工工時，也沒有給出每支MV準確的雲端費用，無法判斷哪邊總成本更低。
對已有硬體、願意調整流程、能接受較長交付時間的人，這個案例展示了本地Agent完成動畫MV的一條可行路徑。對有明確截止時間的創作者，這次Claude的初版完成時間更短，也更受推主認可。
我的判斷是，衡量本地AI值不值得用，應該把人的時間一起算進去。省下調用費用之後，搭流程、做交接、修錯誤、查畫面花了多久，都是交付成本。
如果已經有一台本地AI電腦，可以從一個短片、一個明確場景開始，讓它完整做完，保留失敗記錄，再看自己補了多少工作。
等它交出一支你願意發布的影片，再決定哪些訂閱可以省下來。
