最近，一些创作者开始让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电脑，可以从一个短片、一个明确场景开始，让它完整做完，保留失败记录，再看自己补了多少工作。
等它交出一支你愿意发布的视频，再决定哪些订阅可以省下来。
