爆款视频拆解·短视频复刻

拿一条已经跑出成绩的短视频，摸清它底下的结构，再把这套结构重新搭到用户自己的题材上——最后交付分镜图、一条口播音轨，以及按所选路线，要么是一条做完的竖屏短片，要么是分段素材、字幕和一份给用户自己剪的带时间码剪辑清单。

适用范围与路线选择

这条路线是：一条参考视频、一份拆解、一份重写过的分镜表，以及一条复刻出来的视频。用户指着某一条具体的视频、想要属于自己的那一版时，走这条路线。

手上没有参考视频可拆时，别的工作流更合适。只有一个原创想法、没有对标，属于分镜脚本类工作流。一张商品图要变成带货视频，属于商品视频类工作流。文案已经写好、只差一个声音，属于配音类工作流。要动的是参考视频本身的画风、而不是把它重搭一遍，属于视频转风格类工作流。

输入与默认值

两个硬性输入：参考视频——以及复刻出来是讲什么的。

参考视频可以是好几种形态，每一种都能用。宿主 Agent 能直接打开的视频文件在画面上信息最全。关键时刻的截图、粘贴过来的逐字稿或标题文案、用户自己口述的每一段发生了什么，也都足够把拆解做完。拿到什么形态就用什么形态，并且只说一次、说清楚：哪些是你自己看到的，哪些来自用户的转述。绝不描述你没有看到的画面。

最常见的形态是一个链接，本包可以直接读：抖音、TikTok、小红书、Instagram、YouTube、X 上这条帖子的标题文案、作者和公开数据，它的评论区，以及——只有 YouTube——整段字幕逐字稿。每一项都是一次付费查询、都可选，并且都在各自运行之前单独确认，见从链接读参考视频。查询永远看不到画面：构图、运动和剪辑节奏，仍然只能来自文件、截图或用户。

题材是用户的产品、服务、选题或账号。对话里已经交代过的直接复用，不要再问一遍。

默认竖屏 9:16 画布，复刻片长与参考视频相同，开场那一拍加用户标出的其他拍各出一张参考帧——最终张数跟着重建路线走——口播音色按短视频内容匹配。重写之后，默认检查复刻稿的前 3 秒是否承担钩子——让人继续看下去的理由——而不是复述原片片头或自报家门。这一步在仍免费的分镜表里改完，再进入任何付费生成确认。这些默认值在确认时逐条说明，而不是拿去提问。

有两件事决定了后面的每一个判断。每一次视频生成调用都必须落在所选实时模型卡支持的时长里——一镜到底时，这条上限约束整条片子；分段重建时，它约束每一个单元，成片本身可以和单元序列一样长。真正有多少拍会被做活，也跟着所选重建路线走：参考片短、切得少、又装得进单个模型单元时，只动开场那一帧；参考片切得快、或比模型允许的更长时，就按单元分段，每一段有自己的参考帧。这两点都在确认时说明，而不是等付完钱才发现。

一镜到底时，同一条上限也约束口播：成片至少要和念出来的音轨一样长，所以整段脚本必须能在这个时长里念完。分段重建对整段口播没有这条天花板——正是单元拆分让成片可以超过任意一张模型卡的上限，口播仍然是一条连续音轨。无论走哪条，口播字段还是免费文本的时候就要编好预算：按每秒大约四到五个汉字、或者两到三个英文单词估算，在分镜表拿去批准之前先把念不完的删掉——合成之后再砍要多付一次，视频调用之后才发现超长，砍的是整条流程里最贵的那一次。

主张按来源分开。结构、节奏和呈现手法，是你从参考视频里读出来的。用户自己题材的规格、价格、效果、资质和活动，只能来自用户。这些缺失时就绕开写，绝不编一个看着像真的数字，因为最后要为它负责的是用户。

标准流程

把参考视频切开、重写到用户题材上、选定重建路线，以及拆解、分镜表和重建方案一起获批的那一关——这些本身不花钱。有两次调用可能排在这关前面，每一次都单独披露、单独确认，确认过才跑，形态相同：一次是可选的社交查询，另一次是——只要参考是视频文件、还要读它的真实画面——第 1 步里的 beatra.videos.understand。这两次都不并进后面的免费阶段；除此之外，用户看过拆解、分镜表和重建方案并一起批准之前，不再产生任何费用。

在第 1 步之前，只有用户给了链接并要求读它时才做：查这条帖子，以及拆解确实需要时再查它的评论区或 YouTube 字幕，见从链接读参考视频。用户已经给了文件、截图或逐字稿时就跳过——从那些做出来的拆解一样是真拆解。

1. 读参考视频。 参考是视频文件、真实画面还没读过时，这次读取是付费的——按入选的输入视频秒数计费，输入视频上限是 50 MiB 和 360 秒，这是工具写死的限制，超限会在计费前被拒——并且在运行之前单独确认，形态和上面那次可选查询完全一样：两条限制都说清楚，用 beatra.models.list（能力 video_to_text）读出现时的每秒价格并报这个数，绝不报记忆里的数字，并且说清楚：拆解仍然可以不花钱，用截图、逐字稿或用户自己的转述来做。只有用户同意、并且文件确认落在这两条限制之内之后，才打一次 beatra.videos.understand，把 response_format 设成 json，一次把整段视觉读完——绝不要一个问题打一次，因为每一次都会按整段片子重新计费。用之前先重标定： 模型自己报的时长是错的，所以从素材自己的元数据读真实时长，把返回的每一个时间点按这个比例缩放，绝不按模型声称的时长来。对白绝不来自这次调用——视觉模型没有音轨可听，所以对白走它自己的四级来源阶梯，绝不猜视觉模型对声音的臆测。按拆解参考视频填那四张表。
2. 把它重写到用户的题材上。 证据表的行数和每行时间预算、镜头表的镜头数和功能顺序都保留；内容本身全部换掉。每一拍写成两个分开的字段——画面上是什么，嘴里说的是什么——因为合成一个字段的分镜没法拍。一镜到底时，口播字段对着所选实时模型卡的时长上限编，编不进就删；分段重建不把整段脚本绑在同一条上限上，因为单元拆分就是用来消化比单张模型卡更长的参考片的。文案按重写到你的题材上所说的方式过一遍。
3. 先把 text_to_image 和 text_to_speech 两张实时卡片用 beatra.models.list 读出来，再用 beatra.voices.list 选一个音色。拍摄调用实际会用到的视频能力，也要读它的实时卡片——image_to_video 对应 beatra.videos.animate，frames_to_video 对应 beatra.videos.interpolate，分段重建里由有序参考搭起来的单元走 reference_to_video 对应 beatra.videos.generate_from_references，单镜必须越过单元上限继续拍时走 video_extend——因为决定成片怎么拆成生成单元的，是这张能力卡支持的时长，不是别张卡的。这一步要赶在分镜表签字之前做。
4. 选定重建路线。 片子的行数、有没有硬切、以及所选模型的时长上限，能直接排除一条路线时就先排除；只有两条在结构上都还能走时，才直接问用户自己会不会剪视频，见三条重建路线。
5. 把拆解、分镜表和重建方案一起拿出来，并让它们获批。 后面整条流程都建在这份产物上，它改多少次都免费。路线和单元数在这里定下来、说清楚，并把推导链讲明白——这张模型，所以是这条路线，所以是这么多单元，所以大约是这个量。一镜到底时，口播脚本必须在这次批准之前就能放进卡片支持的最长时长，因为后面没有任何一步能让一段过长的口播变短；分段重建对整段脚本没有同一条上限，消化比卡片更长的参考片的是单元拆分，不是口播。
6. 确认准备工作。 展示哪些拍会出帧、9:16 画布以及之后再改要付出什么代价、从 beatra.voices.list 里选出的现成音色——或者用户选择克隆一条时，实时 voice_clone 价格和它自己稳定的请求 ID——当前预估费用，以及每一次计划中的付费调用各自稳定的请求 ID。
7. 先找参考帧，再生成。 每一张先从用户这次上传的、或他自己库里已有的素材取；两档都没有能用的，才退到 beatra.images.generate，并且绝不为实物商品生成参考图——生成出来的商品图永远不是那件商品。整段片子的口播用 beatra.speech.synthesize 合成一次，然后读取实际返回的时长、大小和 MIME 类型。
8. 展示真实素材。 宿主能访问时就把帧显示出来、把口播放出来，并报告真实时长。把任务返回的事实和宿主无法查看的媒体区分开。
9. 出示视频入场卡，再跑付费生成。 先核定时长：一镜到底时，取不小于口播真实长度、且被所选实时模型卡支持的最小整秒——绝不为了压到上限而调低；改短口播字段再合成一次，这是整条流程里最便宜的一次调用。分段重建时，每个单元的时长从镜头表里属于它的那一段对着同一张卡核定，而不是从整段口播核定。然后展示所选路线、它会打的那一次或多次调用、已批准的参考帧、这段口播、时长——一镜到底以音频为准，分段重建则是每个单元自己从表里核定的时长——当前实时预估价、标准注册礼金通常启动不了这条视频这一事实，以及余额不够时怎么办。规划、比较或一句「做成片吧」都不算批准；参考帧或口播已批准也不等于批准了视频。在用户确认已充值、或确认余额足够这次预估之前，不要创建视频的 client_request_id，也不要提交。确认之后，按三条重建路线跑生成——一镜到底打一次，分段重建每个单元打一次，多于一个单元时按复刻工作流维持按单元台账——用 beatra.tasks.get 把每个任务轮询到终态，按路线交付结果，并复核你确实能看到的部分。

一镜到底时，视频模型必须显式选定，而不是交给 auto：这个能力下只有部分模型接受传入的口播，不接受的那些会把它丢掉。具体是哪张能力卡，跟着调用走——image_to_video 对应 beatra.videos.animate，frames_to_video 对应 beatra.videos.interpolate——检验标准是：卡片在接受这次调用所供的帧的同时，也接受这段口播，而不是某一组写死的输入组合，因为这两张能力卡宣传的帧输入并不相同。一镜到底也只打这两种调用：beatra.videos.generate_from_references 根本没有 driving-audio 输入，所以这条路线上的主体或商品锁，是靠参考帧来守的，那一帧按真实素材优先的阶梯、用用户自己的资产搭好，再交给调用去做活。分段重建的单元不会把口播带进视频调用——口播作为独立音轨交付，用户按剪辑清单上的时间码在自己的剪辑器里对齐——所以这条要求并不收窄单元能用的模型；仍然要为每个单元显式选模型，而不是 auto。

画布由第一张生成出来的参考帧定下来，所以画布定晚了，就意味着每一件付费产物都要再做一遍。

需要确认的决策

付费前先确认：凡是要跑参考查询，都先在最前面为它单独确认一次；参考是视频文件时，对它真实画面的 beatra.videos.understand 读取也单独确认、确认过才跑；然后是帧组和口播这一组、连同它们每一次计价的调用——用户选择克隆音色、因而要打一次 beatra.voices.clone，而不是从 beatra.voices.list 里免费挑一条现成的时，也包括在内；最后是付费生成本身——一镜到底一次视频调用，分段重建则每个单元一次，由有序参考搭起来的单元打 beatra.videos.generate_from_references，而不是 beatra.videos.animate 或 beatra.videos.interpolate，越过单元上限继续拍的那一镜打 beatra.videos.extend。视频这次确认要放在用户看过能访问的帧、听过口播之后，因为它是整条流程里最贵的工作。

同样需要确认、而不是自己拍板的还有：9:16 以外的画布、与参考视频不一致的分镜数量、用户没有核实过的题材主张，以及任何产物获批之后的改动。每改一个参数都是新的付费工作，需要新的请求标识和重新批准。

用户要的是把参考视频本身的画面、音乐或出镜人复制出来、而不是复用它的结构时，说明这条路线交付的是什么——一条建在同一套结构上的原创短片——然后接着往下走。

执行方式

每一次远程 Beatra 操作都只通过随包的 scripts/mcp_client.py：工具名作为命令行参数，参数以 JSON 从标准输入传入：

printf '%s' '{"capability":"text_to_image"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"capability":"text_to_speech"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"capability":"image_to_video"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"capability":"frames_to_video"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"capability":"reference_to_video"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"capability":"video_extend"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"capability":"voice_clone"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"language":"zh-CN"}' | python3 scripts/mcp_client.py call beatra.voices.list
printf '%s' '{"query":"video by url","platform":"tiktok","capability_family":"content"}' | python3 scripts/mcp_client.py call beatra.social.tools.search

不要配置或调用宿主 Beatra Connector，也不要使用 REST/OpenAPI 作为回退。每一个逻辑上的付费请求给一个稳定且不透明的 client_request_id，并且只提交一次。

交付与复核

交付拆解、已批准的分镜表和重建方案、作为静帧交付的每一张帧、口播，以及——按所选路线——要么是那一条做完的视频产物，要么是分段素材、一条连续口播音轨、字幕和带时间码的剪辑清单。每一个生成类任务，都交付它的任务 ID、返回的 artifact 链接、解析出的模型、返回的尺寸与时长，以及 billing.net_charged_credits。参考查询的报告方式不同——返回的载荷、任务 ID、终态和 billing.net_charged_credits，没有模型、尺寸或时长可报——见从链接读参考视频。只报告任务确实返回的事实。

宿主能查看或播放返回的媒体时，检查每一张帧或每一段是否对得上它所属的那一拍、口播是否存在并且结尾完整、成片或分段是否符合画布。哪些媒体细节无法查看就直接说明，而不是从任务元数据里推断出来。

故障恢复

任务 ID 一拿到就立即记下，并且只轮询这个任务。queued 和 running 表示继续等待。创建请求的响应丢失时，只用同一个标识重放逐字节相同的冻结载荷；任务 ID 丢失时，按对应能力把任务列出来，先把候选逐个对照自己的台账，再考虑重试——参考查询除外，它没有可以据以列举任务的能力，只能靠记录下来的 operation_key、参数和 schema_hash 去比对。重做某一张帧时，其余产物原样复用；分段重建时，只重做失败的那个单元，并维持复刻工作流里的按单元台账。遇到 insufficient_balance 时，原样转达返回的消息，把余额错误里的充值地址保持逐字不变，并且只有在用户说自己已经充值之后，才用同一个冻结的 client_request_id 重试。

账户余额

用户问还剩多少积分，或某次实时估价够不够时，调用 beatra.wallet.get。问已经扣了多少
时，调用 beatra.wallet.ledger。两者都是只读的。不要臆造查余额或充值的工具。也不要把
wallet.get 变成每次付费提交前的必需步骤。

模型卡返回里带 top_up 块时，按卡片给出的档位和顺序原样转述。不要给档位排高低，不要
贬低其中任何一档，也不要替用户挑。选哪一档是用户自己的事，钱包页会把整份清单摆在他
面前。任何时候都不要凭记忆报档位。

按任务查阅参考

• 按片长、切点密度、模型上限、以及用户自己会不会剪，在 R1 和 R2 之间做选择：三条重建路线
• 这条路线从参考视频借什么、什么绝对不能带过来，任何生成调用跑之前先核对：六条红线
• 从链接读参考视频、每次查询要花多少、查到的结果如何标注来源：从链接读参考视频
• 三层来源怎么叠、模型给出的时间点怎么按真实时长重标定、四张证据和评分表怎么填：拆解参考视频
• 把结构搬到新题材上、写成画面与口播成对的字段、选定模式和它的锁、参考帧先从真实素材取再生成：重写到你的题材上
• 确切载荷、每次确认冻结了什么、轮询、重做某一步或某一个单元、按单元台账、故障恢复与取消：复刻工作流
• 首次安装或授权过期：安装与认证
• 非计费的包注册：安装注册
• 任务轮询、artifact 与结果字段：任务与结果
• 余额、校验与结构化错误：计费、错误与恢复
• 随包客户端连不上时：随包 MCP Client 连接诊断
• 更新保证与开关：自动更新与安全
• 移除本包或共享凭据：卸载与断开连接

运行时与安全的自动更新

随包客户端会在每个安装中静默检查更新，最多每 24 小时一次。发现更高版本时，不另行确认地自动安装。它只从针对本包、渠道和语言环境固定的 Beatra 官方发现地址与不可变 CDN 路径下载，在替换之前校验发现数据、压缩包、清单以及每个文件的大小与校验和，并且只替换本包拥有的文件。它会拒绝重定向、降级、包与渠道与语言环境与版本对不上的数据、意料之外的地址、不安全的压缩包，以及落在归属目录之外的任何文件。

更新的检查、下载、校验、替换和回滚失败时都不会中断：当前安装仍然可用，原本请求的命令会继续执行。更新失败绝不构成重试付费生成的理由。这个设置会在本安装后续的命令中持续生效。

python3 scripts/mcp_client.py update --auto off
python3 scripts/mcp_client.py update --auto on
python3 scripts/mcp_client.py update --check

--auto off 关闭静默检查，--auto on 恢复静默检查，--check 报告官方可用版本但不替换文件。详见自动更新与安全。