AI 漫剧一集的真实成本拆解，以及为什么按「集」定价会亏

2026-08-05 · 约 6 分钟

2026-08-05。成本数字来自真实调用后的账单，定价规则来自我们线上跑着的代码。

做漫剧功能定价的时候，我先犯了个错：把「一集」当成一个计费单位。

直觉上这很合理——用户要的就是一集片子，按集报价最好懂。但真接进去才发现，服务端根本不知道「一集」是什么。

一集是四到六次独立请求

漫剧编剧室的流水线是这样跑的：剧本拆成分镜，每个分镜出关键静帧，静帧再逐段转成视频，最后拼接。

段数由引擎决定：普通档一集切六段，加长档因为单段能到 30 秒，一集四段就够。每段都是一次独立的 HTTP 请求，串行发出去。

也就是说，用户点一次「生成本集」，服务端收到的是四到六个互不相关的成片请求。它们之间没有任何标识说明「我们是一集的」。

按 Seedance 720p 实测单价 $0.1512/秒算：

如果用加长档（单段 30 秒），四段就是 $9.07 一段成本、一集约 $20——但换来的是两分钟的成片，单位时长成本反而更低。

换算成人民币，一集成本在 70 到 110 元之间。这个数字对定价的意义是：一集卖 688 积分（约 447 元）看着贵，毛利率其实是 79%，跟单段档位持平，没有额外加价。

我原本想按集收 688，服务端一算总数扣一次钱。做不到，原因很实在：

服务端认不出这是哪一集的第几段。 集号和段号只存在于前端——节点 id 长成 clip-e01-g03 这样，episodeIndex 存在前端的 block 对象里。发给服务端的请求体里只有提示词、参考图、时长、画质这些，没有任何集号。

唯一残留的线索是提示词里的 【第 3 段·15s】，但这个也靠不住：出线前会被符号规范化处理，【】 会被换成 []，而且用户可以直接改提示词。靠正则反解一个用户能改的字符串来决定扣多少钱，这是自找麻烦。

所以最后的做法是：前端把 episodeIndex 明确透传进请求体，服务端见到它就按整集折算的段价扣（688 ÷ 4 = 172/段），没有就按自由画布的单段价扣（118）。

跑多少扣多少，用户中途停下来只付已跑的部分。这比「先收一集的钱再跑」对双方都干净——毕竟一集要跑十几分钟，中途失败或用户改主意都是常态。

这是接计费时最容易埋雷的地方。

我们的规则是：扣在调用前，失败即退回。所以自动重试的净效果是只扣成功那一次。

但有个边界情况值得说：出图那条链路走的是异步队列，超时会再入队一次。此时第一个任务可能仍在跑并最终成功——如果两次都扣，用户就为同一张图付了两遍。

处理办法是重入队那次不带扣费标记。代价是如果第一次最终失败了，第二次就相当于免费。宁可少收，不能误扣——多收一次的信任损失，比少收一次的钱贵得多。

Seedance 的计费公式是公开的：

tokens = 输出视频高 × 宽 × 秒数 × 24 / 1024

也就是成本严格按像素线性涨。720p 到 1080p 是 2.25 倍，到 2K 是 4 倍，到 4K 是 9 倍。

我实测验证过这个公式：4 秒 480p 扣 $0.269，反推 token 单价约 $7/M，套回 720p 得 $0.1512/秒，与已知账单吻合；再实测 4 秒 1080p，账单 $1.3608，正好 $0.3402/秒，与推算分毫不差。

这意味着如果你开放高画质档却沿用同一个价，每开一档就多亏一档。一段 15 秒 4K 的成本是 $20.41，按 720p 的价卖等于白送二十美元。

我们的处理是售价同比例抬：720p 118 积分、1080p 268、2K 472、4K 1062。各档毛利率都维持在 79% 左右。4K 那个价看着吓人，但成本摆在那儿——不这么定就是做慈善。

一、先搞清楚服务端能看见什么。 「按集」「按项目」「按工作流」这类打包定价，前提是服务端能识别这个包。识别不了就得从前端透传，而透传的字段用户能伪造——所以只适合往便宜方向用（认出来给折扣），不适合往贵方向用。

二、扣费点放在调用前，退款路径必须走通。 而且要确认新加的代码不会把异常吞掉——退款逻辑挂在 catch 上，一旦某个分支 return null 而不是抛错，钱就退不回去了。

三、错误分类要准。 我们踩过一个坑：余额耗尽的 429 和上游封禁的 403，因为错误文本里带 violation 一词，被判成了「内容审核拦截」，于是提示用户「请调整文案后再试」。用户改了三遍也没用——真实原因是备用密钥没钱了。报错把人引向错误的方向，比不报错更伤。

四、长任务要能中途停。 一集十几分钟，用户看到第二段效果不对就想停。按段扣费天然支持这件事，按集预收就得处理退款。

成本数字来自 2026-08-05 的真实调用。单价随上游调整会变，核算方法可复用。