账号拆解与起号模板

只从眼前真正看得见的东西出发，读一个短视频或社交账号，摸清它底下的那套系统，再把这套系统变成用户自己账号的起号模板——终点是一条真的做出来的作品，而不是一段对它的描述。

适用范围与路线选择

这条路线是：一个账号、一份诊断、一套用户自己账号的起号模板，以及一条做出来的第一条作品。有人指着某一个账号——对手的、对标的，或者他自己的——想弄清它到底怎么跑起来的、接下来该做什么时，走这条路线。

viral-video-teardown-remake 是隔壁那条路线，边界很干净：那条拆的是一条视频，重做的也是这一条视频。这条拆的是一整个账号，产出的是账号定位和内容规划，最后落到第一条作品上。用户拿来一条片子、要的是属于自己的那一条时，把他送去那边。用户拿来的是主页九宫格、一张主页截图或者一份作品清单时，留在这条路线上。

别的起点属于别处。眼下正在热的一个话题，属于热点选题类工作流。已经写好、马上就要发出去的文案，属于发布前检查类工作流。写完了、只差一个声音的脚本，属于配音类工作流。

输入与默认值

两个硬性输入：被拆的那个账号，以及这套模板是给谁建号用的。

账号以用户能看到的任何形态送过来，每一种形态都能用。主页截图。一字不改的简介原文。粘贴过来的近期作品列表，带上每条作品的标题或文案，以及每条上面看得见的播放、点赞、评论、收藏、转发数。主页九宫格的截图。几条完整文案。其中任何一样都足以开始读这个账号；给得越多，读得越准。拿到什么形态就用什么形态，并且只说一次、说清楚：哪些是你自己直接读到的，哪些来自用户的转述。

用户最先想给的那一种形态是主页链接或者 @，本包可以直接读：抖音、TikTok、小红书、Instagram、YouTube、X 上这个账号的主页资料、一页近期作品和它们的播放、点赞、评论数（YouTube 要的是频道链接，不是一个光秃秃的 @）；评论区只有抖音、TikTok、小红书能读；YouTube、Instagram、X 没有评论操作，在这三个平台上，受众判读只能靠文案。每一项都是一次单独付费的查询、都可选、都在各自运行之前单独确认，见从主页链接读账号（references/account-lookup.md）。判据是白名单本身，不是一份例外清单：平台上没有白名单里的操作，这个账号就查不了。视频号就是这一类，快手、B站、微博、知乎同样是，而且不止这些；遇到这些平台就回到用户能看见、能粘贴的东西，绝不拿邻近平台的数字顶替。

第二个输入是用户自己这一边：所在行业、产品、专业能力或人设，以及他们已经有号的话，那个号本身。缺了这一项，诊断就只是一份关于别人的报告，而不是一份给用户的方案。对话里已经交代过的直接复用，不要再问一遍。

默认读最近十到二十条作品（查来的或用户提供的都算），定三到五个内容支柱，内容矩阵按「内容支柱 × 形式 × 更新节奏」排布，开局选题清单十条，真的做出来一条作品，封面按 9:16 竖屏，口播音色按社交短内容匹配。每一个默认值都连着它的结果一起说明，而不是拿去提问。

做出那条作品之前的每一步都不花钱——唯一的例外是那次可选的账号查询，只有在用户要求查、并单独确认过价格之后才会发生；停在起号模板这一步的一次运行，本身就已经是一次完整、有用的结果。把这一点说明白，而不是把用户往任何一个付费步骤上引。

每个数字都有出处

整份诊断都建在这条规矩上，没有商量余地。

关于被拆账号的每一个数字、每一条事实，只可能来自两个地方：本包跑过的一次查询，或者用户。没有第三个来源。

顺序是：用户要求查、而且这个平台有对应操作时就去查；否则用用户给的；并且每一行都标明是这两者里的哪一个，查来的还要带上读取时间——公开计数会变，不带读取时间的数字放久了就是错的。粉丝数、播放量、点赞与评论数、互动率、更新频率、收入、变现方式和涨粉走势，绝不估算、绝不用插值补齐，也绝不把同类账号通常的样子搬过来当成它的数字。有了查询这条路，这条禁令不是松了而是更重要——它正是查询值得跑的理由。两个来源都拿不到的那一项，就明说它没有来源。缺失时绕开它做诊断——内容矩阵、开头钩子的套路和账号定位这三件事，少一个粉丝数照样读得出来。还有一句要记住：查来的数字并不比粘贴来的数字更可靠，只是来源不同。它一样可能是旧的、有争议的，或者被账号自己灌过水的。标注清楚就往下走，别把它当成定论。在这里，一个看着像真的、关于一个真实账号的数据，是最糟糕的输出，因为用户真的会照着它去做事。

同一条界线贯穿所有的规律判读。某条作品为什么跑得好，是推断，不是事实。把它标成推断，给出背后的证据，并说清什么才能坐实它——通常是更大的作品样本，或者同一套结构在跑得最好的那几条里反复出现，而不是只出现过一次。

拆一个不属于用户的账号，是再正常不过的竞品研究，证据指向哪里，判读就走到哪里。而从另一头出来的，是用户自己那一版结构：他们自己的内容支柱、他们自己的开头钩子、他们自己的主张、他们自己的素材。绝不把另一个创作者实际的画面素材、录下来的声音或者一字不差的文案搬过来。

关于用户自己题材的主张——规格、价格、效果、资质、优惠——只能来自用户。缺了哪一项，就绕开它写，而不是编一个出来。

标准流程

第 1 到 7 步不花钱。唯一可能排在它们前面的付费调用是下面第 0 步那次可选的账号查询，只有在用户要求查、并确认过它自己的价格之后才会发生。除此之外，第一次付费调用在第 8 步，而且只发生在用户看过并批准了起号模板和第一条作品方案之后。

0. 可选：把账号查出来。 用户给了主页链接或 @、并且要求读它时才做这一步；用户没提，或者压根没给链接，就跳过。要做就先说清这一步能做什么、要花多少，再由用户决定。要查就单独确认一次：这次查的是哪个操作、实时价格是多少，以及这次计划一共几次查询——资料、每一页作品、每一页评论各算一次。各平台单价差得很远，绝不能只报一个价。详见从主页链接读账号（references/account-lookup.md）。用户已经粘了截图和数据就跳过——从那些做出来的拆解一样是真拆解。

1. 先做证据表。 把每一条作品——第 0 步查来的，或者用户提供的——连同它看得见的数据和它的文案或标题，一行一行列出来，再加上简介和主页上显示的其他信息。每一行都写清它从哪来，查来的那一行还要带上读取时间。缺的地方就照实标成缺口。按读懂这个账号（references/account-read.md），后面每一步只允许从这张表往下推。

2. 诊断这个账号。 账号定位、它真正在对话的那群人、主页作品背后的内容矩阵、跑得最好的那些作品反复复用的开头钩子与结构套路、更新节奏，以及这个账号自己的短板。把证据直接摆出来的东西，和你从证据里推断出来的东西分开写。

3. 读出差距。 把被拆的账号和用户自己的号并排放——哪些能搬过来、哪些搬不了、用户有而对方没有的是什么，以及机会的口子开在哪里。

4. 搭出起号模板。 一句账号定位、一版简介、带各自形式与更新节奏的内容支柱、写成用户能自己反复套用的爆款开头公式，以及开局十条的选题清单，按建你自己的号（references/build-template.md）来做。

5. 把第一条作品写出来，并拿去获批。 从开局十条里挑最强的那一条，完整写出来：封面文案、正文文案、话题标签，以及画面动作与口播台词分开写的脚本。付费产出就建在这份产物上，它改多少次都免费。

6. 把实时的 text_to_speech 卡片，以及封面这一步实际会走的那条路线对应的卡片，用 beatra.models.list 读出来——从零渲染一张新图走 text_to_image，用户上传了自己的封面或头像来改则走 image_edit——再用 beatra.voices.list 选一个音色。

7. 确认生产。 展示已获批的封面文案和脚本、9:16 画布以及之后再改要付出什么代价、选定的可用音色、当前预估费用，以及每一次计划中的付费调用各自稳定的请求 ID。

8. 用 beatra.images.generate 渲染封面——用户上传了自己现有的封面或头像来改时，改用 beatra.images.edit，这种情况下，载荷里要把 9:16 画布显式写出来，因为编辑这条路线否则会沿用上传图自己的比例，把确认关口上冻结下来的画布悄悄覆盖掉——再用 beatra.speech.synthesize 把脚本合成口播，然后读取实际返回的时长、大小和 MIME 类型。

9. 用 beatra.tasks.get 把每个任务轮询到终态，把诊断、起号模板和做出来的这条作品一起交付，并复核你确实能看到的部分。

需要确认的决策

花钱之前分两道关口确认。第一道只在用户要求查账号时才有：每一次查询单独确认，说清它是哪个操作、实时价格是多少。第二道是封面文案和脚本一起确认，并点名列出它们每一次计价的调用。两道永远不合并成一次批准——查询发生在本包承诺免费的那几步里，而对生产的批准并不构成对它的批准。

同样需要确认、而不是自己拍板的还有：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":"image_edit"}' | 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' '{"language":"zh-CN"}' | python3 scripts/mcp_client.py call beatra.voices.list
printf '%s' '{"query":"user posts","platform":"douyin","capability_family":"creator"}' | python3 scripts/mcp_client.py call beatra.social.tools.search
python3 scripts/mcp_client.py upload ./current-cover.jpg --mime-type image/jpeg

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

交付与复核

交付：带来源标注的证据表、诊断、差距判读、起号模板、开局选题清单、第一条作品的封面及其封面文案、它的正文文案与话题标签、它的脚本、渲染出来的封面图，以及配好的口播音轨。每一个生成类任务都交付它的任务 ID、返回的 artifact 链接、解析出的模型、返回的尺寸与时长，以及 billing.net_charged_credits。账号查询的报告方式不同——返回的载荷、任务 ID、终态，以及这次实际扣掉的积分，没有模型、尺寸和时长可报。只报告任务确实返回的事实。

封面文案是生成出来的图上文字。把渲染出来的字对着已获批的封面文案读回去，没能清楚地渲染出来时就直说，而不是把一张没检查过的封面说成是对的。宿主能访问时就把口播放出来，并报告真实时长。哪些媒体细节无法查看就直接说明，而不是从任务元数据里推断出来。

故障恢复

每一个任务 ID 一拿到就立即记下，并且只轮询这个任务。queued 和 running 表示继续等待。创建请求的响应丢失时，只用同一个标识重新提交逐字节相同的冻结载荷；任务 ID 丢失时，按对应能力把任务列出来，先把候选逐个对照自己的台账，再考虑重试；账号查询也一样先列出来、对上再说，只是对照的是记录下来的操作、参数和 schema 指纹，而不是提示词和画布。换了任何参数（包括翻页）就是新的一次付费，不是重试。重做封面时，口播原样复用；反过来也一样。insufficient_balance 表示没有扣费，充值之后可以用完全相同的请求重新提交。

按任务查阅参考

• 做证据表、账号定位与人群判读、内容矩阵、开头钩子套路，以及更新节奏判读：读懂这个账号（references/account-read.md）
• 从主页链接读资料、作品和评论，每次查询要花多少，结果如何标注来源：从主页链接读账号（references/account-lookup.md）
• 把诊断变成一句账号定位、一版简介、内容支柱、爆款公式、开局选题清单和第一条作品：建你自己的号（references/build-template.md）
• 确切载荷、每次确认冻结了什么、轮询、重做某一步、故障恢复与取消：账号拆解流程（references/workflow.md）
• 首次安装或授权过期：安装与认证（references/installation-and-auth.md）
• 非计费的包注册：安装注册（references/installation-registration.md）
• 任务轮询、artifact 与结果字段：任务与结果（references/tasks-and-results.md）
• 余额、校验与结构化错误：计费、错误与恢复（references/billing-errors-and-recovery.md）
• 随包客户端连不上时：随包 MCP Client 连接诊断（references/mcp-connection.md）
• 更新保证与开关：自动更新与安全（references/automatic-updates-and-safety.md）
• 移除本包或共享凭据：卸载与断开连接（references/uninstall-and-disconnect.md）

运行时与安全的自动更新

随包客户端会在每个安装中静默检查是否有更新的版本，最多每 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 报告官方可用版本但不替换文件。详见自动更新与安全（references/automatic-updates-and-safety.md）。