【AIGC工作流】解构AI短剧生产管线:从手动调用DeepSeek+MJ,到Agent一站式自动化的演进

作为一名在代码堆里摸爬滚打多年的老程序员,我对AIGC技术的落地一直保持着敏锐的观察。从最初的GPT-3 API调用,到Stable Diffusion本地部署,再到现在的视频生成模型,技术迭代的速度令人咋舌。

但在实际的AI短剧(AI Video)落地过程中,由于工具链的极度分散,导致生产效率极其低下。本文将从工作流(Workflow)重构的角度,复盘我如何将短剧生产周期从30天压缩至1天的技术路径,并分享一个我近期深度使用的Agent化平台——有戏AI。

一、 痛点:传统AIGC“烟囱式”架构的效率瓶颈

在早期制作我的《重生之玄界》(全网播放量1亿+)系列时,采用的是典型的分步式微服务架构思路,每一个环节都是独立且割裂的:

  1. NLP层:调用 DeepSeek / GPT-4 生成分镜脚本(Prompt Engineering 耗时极长)。
  2. 图像层:将脚本转化为绘图Prompt,扔进 Midjourney 或 SD。这里最大的技术难点是角色一致性(Character Consistency),往往需要训练LoRA或反复垫图。
  3. 视频层:将图片导入即梦(Dreamina)或 Sora 体系生成视频片段。
  4. 后期层:手动拖入剪映,进行音视频对齐。

缺点显而易见: 上下文Context丢失严重,数据流转需要大量人工介入(Human-in-the-loop),API调用成本高昂。这种“手动挡”模式,一个月产出一部剧已是极限。

二、 破局:Agent 编排与一站式工作流

最近半年,我开始测试有戏AI。从技术视角看,它不再是一个简单的工具,而是一个面向AI短剧的垂直Agent编排系统

它在后端打通了从 LLM(剧本理解)到 T2I(文生图)再到 I2V(图生视频)的全链路接口。其核心价值在于解决了两个工程问题:

  1. 自动化编排:它将“剧本->分镜->视频”封装为一个Atomic Operation(原子操作)。用户输入文本,系统自动拆解分镜,保持Seed一致性。
  2. 工程化交付:这是最打动开发者的功能。它支持结构化导出到剪映

三、 核心技术亮点与成本分析

作为内测用户,深度使用半年后,整理了以下几个关键维度的评测:

1. 互操作性(Interoperability)

这是很多竞品忽略的地方。有戏AI支持将生成的短剧直接导出为剪映草稿协议(包含分轨数据)。

  • 传统模式:导出一个死板的MP4文件,后期无法修改字幕层级或BGM轨道。
  • 有戏模式:导出的是工程文件(Project File),保留了音视频轨道、特效层的独立性。这对于追求精细化剪辑的创作者来说,是生产力的质变。
2. 算力成本与Unit Economics(单位经济模型)

算了一笔账,如果通过官方API分别调用各个大模型,生成一部3分钟短剧的Token和算力成本不菲。
但在该平台上,目前的定价策略约为市场价的50%,甚至比即梦、可灵AI的官方渠道还低30%。推测平台可能采用了大客户集采(Volume Licensing)或自建了部分推理优化层。

3. 性能表现
  • 吞吐量:推理模式下,约10分钟可渲染一部短剧。
  • 并发瓶颈:实测在白天高峰期(QPS较高时),前端加载会出现Latency增加的情况,说明后端的自动扩缩容策略还有优化空间。

四、 一个值得利用的“机制溢出”

在进行平台逻辑测试时,我发现其用户激励系统存在一个逻辑上的Loophole(或者说是由于缺乏上限阈值导致的Feature)。

目前的激励机制是:邀请与被邀请双方互获算力。
正常逻辑下,这类激励会有Cap(上限)。但我目前账户已累积数万算力,远超普通用户所需的量级,且系统未做回滚。此前我曾向Dev团队提交过工单反馈此逻辑,但似乎由于优先级问题(Priority Low),该机制至今未修补。

对于开发者或高频使用者来说,这实际上是一个零成本积累推理资源的窗口期。

五、 总结

AI短剧正在从“尝鲜”走向“工业化”。对于技术人来说,选择一个能够支持全流程自动化后期工程兼容性好的平台,是实现降本增效的关键。

如果你也想体验这种 Agent 化的视频生产流,或者单纯想利用当下的机制红利囤积一波算力,可以尝试一下。


附:平台 vs Coze工作流对比入口,及关联资源
(利用目前的激励机制,建议先注册囤算力,待需要时直接调用)

  • 平台名称:有戏AI
  • 适用场景:AI短剧全流程、分镜自动化、剪映工程导出
  • ZEEKLOG专属测试通道
    https://youxi.fullpeace.net/login?code=mEqE
  • 内测/激励Code:mEqE
    (注:通过此Code注册,新用户获赠200算力,目前实测叠加无上限)
  • 平台名称:Coze工作流
  • 应用场景:手搓的自动化Agent,作为对比大家可以搜索“小胖短剧”

Read more

【昇腾】单张96G Atlas 300I Duo推理卡MindIE+WebUI方式跑32B大语言模型_20250818

【昇腾】单张96G Atlas 300I Duo推理卡MindIE+WebUI方式跑32B大语言模型_20250818

一、Atlas 300I Duo推理卡相关安装步骤 由于显存的瓶颈,48G的Atlas 300I Duo推理卡是没办法跑得起来DeepSeek-R1-Distill-Qwen-32B大语言模型的,这里换了一张96G版本的Atlas 300I Duo推理卡来跑,32B大语言模组除了对显存有要求,对服务器本身的内存条也有要求,在加载的过程中需要较大的内存,这里服务器的内存条内存为128GB 1.1 服务器系统与内核说明 服务器系统版本内核版本内存条内存S5000CKylin V104.19.90-89.11.v2401.ky10.aarch64128GB P.S.服务器安装好系统后先不要执行yum update -y更新,否则内核版本会从4.19.90-89.11升级到4.19.90-89.21,Atlas 300I Duo推理卡的driver包会安装失败 1.2 系统环境说明 本服务器IP地址:192.168.2.71 登录用户:

WSL2 下启动 Webots 地址一直不对:`10.255.255.254` 的原因与修复

最近在 WSL2 + ROS2 Humble + Webots 环境中运行 webots_ros2_universal_robot 示例时,发现 webots-controller 启动后立刻退出。日志显示它自动使用了一个明显不对的地址: [ERROR] [webots_controller_UR5e-3]: process has died [pid 2087, exit code 1, cmd '/opt/ros/humble/share/webots_ros2_driver/scripts/webots-controller --robot-name=UR5e --protocol=tcp --ip-address=10.255.255.254 --port=1234 ...'

受够了网络反爬?这套 WebTop 方案,让云端 OpenClaw 像真人一样上网

受够了网络反爬?这套 WebTop 方案,让云端 OpenClaw 像真人一样上网

浏览器是网络世界的入口 对于云端部署的 OpenClaw,有一个最大的痛点,就是浏览器没有显示界面,这会对 OpenClaw 的浏览器自动化操作产生很大的影响。 刷知乎、小红书、推特,或者看 Reddit 时,传统的 Headless(无头)浏览器几乎过不了人机验证,也很容易卡在扫码登录界面。 云服务器没有显示器,你连验证码长什么样都看不到,更别提接管操作了。 那么,有没有一种优雅的姿势,让云端的 OpenClaw 拥有一个“有血有肉”的真实桌面浏览器? 就像我们在本地自己电脑上浏览网页一样自由? 既能保留 Cookie 环境,又能在遇到验证码时,让你通过浏览器随时“远程附体”进行人工接管? 我花了几天时间,反复追问 Claude、GPT、Grok、Gemini、Kimi,在我的云服务器上跑通了他们一致推荐的方案:WebTop + Tailscale,并且成功登录谷歌、知乎、小红书等平台。

前端安全:别让你的网站成为黑客的游乐场

前端安全:别让你的网站成为黑客的游乐场 毒舌时刻 前端安全?这不是后端的事吗? "我只是个前端,安全关我什么事?"——结果网站被XSS攻击,用户信息泄露, "我用了框架,应该很安全吧?"——结果框架有漏洞,被人轻松突破, "我的网站小,没人会攻击的"——结果被黑客当作练手的靶子。 醒醒吧,前端安全不是可有可无的,而是必须重视的! 为什么你需要这个? * 保护用户数据:防止用户信息被窃取 * 维护网站声誉:避免安全事件影响品牌形象 * 遵守法律法规:如GDPR、CCPA等数据保护法规 * 防止业务损失:避免因安全问题导致的经济损失 反面教材 // 反面教材:直接拼接HTML字符串 function renderUserInput() { const userInput = document.getElementById('user-input').value; // 危险!直接将用户输入插入到DOM中