昨晚凌晨三点，看着Coze（扣子）工作流里最后一个节点亮起绿灯，一段3分钟的《赤壁之战》短视频自动弹进了我的飞书接收群，那一刻我深吸了一口冰可乐，知道这半个月的熬夜没白费。

我是苏增烨，广州商学院软件工程专业的大四学生。在别人眼里，我可能是一个拿了GPA 4.02和两次国家奖学金的“卷王”，但我自己知道，我只是一个极度讨厌重复性劳动、热爱折腾AIGC的“懒人”。今天这篇文章，不聊虚的，就硬核拆解一下：我是如何用Coze搭出一套历史短视频全自动生成工作流的。

起因：被流量密码折磨的“赛博包工头”

前段时间刷短视频，我发现历史类的内容（比如“三分钟看懂大明王朝”、“地图推演长平之战”）流量极其恐怖，动辄几十万点赞。但仔细拆解它们的制作流程，你会发现这是一个极其耗时的体力活： 找选题 -> 查史料写文案 -> 录制旁白 -> 全网到处扒符合语境的历史图片或视频素材 -> 剪辑卡点 -> 加字幕。

一套流程下来，熟手也得肝上一两天。作为一个软工学生，我的第一直觉是：这玩意儿高度结构化，绝对能用AI做成全自动的流水线。 既然AIGC现在有文本大模型、有文生图、有TTS（TTS），为什么不能用一个工作流把它们全部串起来，实现“输入一句话，输出一部片”？

说干就干，我打开了Coze。

架构设计：让AI打工的流水线长什么样？

在构建这套系统时，我没有选择自己写Python脚本调API，而是直接用了Coze。因为它的可视化编排（Workflow）极其适合做这种多模态的串联。

整个工作流的架构如下：

1. 输入节点 (Start)： 仅仅输入一个历史主题，比如“郑和下西洋”。
2. 大脑中枢 (豆包1.5 Pro)： 负责剧本创作与分镜拆解。我要求它必须输出严格的结构化数据，格式为：[分镜N/画面描述/旁白文案/预计时长]。
3. 视觉画师 (即梦AI)： 接收豆包输出的“画面描述”。为了保证整部视频的画风统一，我在这个节点注入了全局风格词前缀（如：“电影级光影，中国传统水墨与写实融合，8k分辨率，历史正剧风格...”），再拼上具体的分镜画面。
4. 配音演员 (微软TTS)： 提取豆包输出的“旁白文案”，调用微软的语音合成API，选择了一个浑厚的老者音色（适合历史沧桑感），逐段生成音频。
5. 剪辑后期 (剪映小助手API/自定义插件)： 接收前面生成的图片列表和音频列表，根据“预计时长”进行对齐，自动添加简单的推拉摇移特效（Ken Burns effect），最后合并输出MP4。

在这个流程里，数据像流水一样经过不同的AI模型，最终组装成成品。

核心挑战：Prompt工程是一门“控制论”

如果你也折腾过AI工作流，你一定会同意这句话：工作流的成败，90%取决于Prompt工程。

在跑通主流程时，我卡在“豆包1.5 Pro”这个节点整整三天。为什么？因为大模型太喜欢“自由发挥”了。如果它输出的格式稍微错了一点（比如少了一个括号，或者把旁白写进了画面描述里），后面的解析节点就会全面崩溃。

为了让模型稳定输出结构化分镜格式，我的Prompt迭代了不下20个版本。从一开始简单的“请按格式输出”，到后来我用上了软工里的“防御性编程”思维。

最终的System Prompt长这样（节选）：

你现在是一个顶尖的历史纪录片导演。你需要将用户输入的历史事件，拆解为6-8个分镜。
【严格约束】
你必须且只能输出JSON数组格式，不能包含任何多余的寒暄语、解释性文字！
如果违反格式，系统将崩溃。
【数据结构】
[
  {
    "scene": "分镜1",
    "visual": "画面描述，必须是纯英文的Midjourney/即梦提示词，重点描述主体、动作、背景",
    "voiceover": "旁白文案，字数控制在30字以内，口语化，有悬念",
    "duration": 5
  }
]
【Few-Shot 示例】
（此处省略我手写的3个标准示例...）

通过引入JSON格式强制约束 + 角色预设 + Few-Shot（少样本提示），豆包1.5 Pro的输出成功率从最初的40%飙升到了99%。这种把自然语言当作代码来调试的过程，让我真正体会到了Prompt Engineering的魅力。

实测与翻车现场：10分钟出片，但曹操戴了明朝的帽子

工作流搭好后，我立刻扔了三个主题进去测试：赤壁之战、郑和下西洋、玄武门之变。

速度是真的快。从输入主题到飞书机器人把MP4文件发给我，全程平均只需要10分钟。看着进度条一段段跑完，那种造物主般的爽感是无与伦比的。

但是，到了“审片”环节，翻车现场也极其惨烈。 在《赤壁之战》里，即梦AI生成的火烧连环船极其震撼，但镜头一切到曹操，他老人家头上居然戴着一顶明朝的乌纱帽； 在《郑和下西洋》里，宝船的宏大感出来了，但仔细一看，甲板上居然出现了一个类似现代游轮的金属方向盘； 在《玄武门之变》里，李世民射杀李建成的画面，弓箭的弦是穿过李世民手臂的（AI画图经典的结构错误）。

这些“穿帮”镜头让我意识到：目前的文生图模型，在缺乏特定历史知识库（RAG）微调的情况下，很难做到严谨的历史考究。它更像是一个看过无数图片的缝合怪，能给出“氛围感”，但经不起“放大镜”。

深层思考：AIGC工程化的本质与程序员的未来

在广商读了四年软件工程，我经常在知乎上看到类似“AI要替代程序员了”、“大模型能写代码还要我们干嘛”的焦虑贴。但这次搭Coze工作流的经历，给了我一个截然不同的视角。

AI工作流的本质，是“让多个专注的小模型各司其职”，而不是依赖一个万能的大模型。

很多人幻想未来会有一个GPT-X，你对它喊一句“给我做一个赤壁之战的视频”，它就直接吐出完美成品。但在工程实践中，这种“黑盒”是不可控的。真正的AIGC工程化，是把复杂问题拆解。豆包负责逻辑与文本，即梦负责视觉，TTS负责听觉。

这和我们软件工程里的“微服务架构（Microservices）”何其相似！

这对我最大的启发是：AI不会替代程序员，它只是把程序员的抽象层级拉高了。 以前我们用Java/Python写业务逻辑；现在，大模型成了我们的“函数库”，Prompt成了我们的“参数”。未来的核心竞争力，不再是谁能手搓一个排序算法，而是谁能像架构师一样，把不同的AI能力组合成一个高容错、高可用的闭环系统。 梳理业务流、处理异常边界、做数据结构对齐，这些硬核的工程思维，大模型目前根本无法独立完成，这正是我们IT人的护城河。

局限性与后续想法：虽然粗糙，但未来已来

客观地说，这套工作流目前产出的视频，质量还无法直接用于商业化变现。由于画面穿帮、图片转视频的运镜略显生硬、旁白缺乏真人那种细腻的情感起伏，它目前只能算是一个高级的“动态PPT”。

但这套流程彻底验证了内容生产全自动化的可行性。

下一步我打算怎么折腾？

1. 引入RAG（检索增强生成）： 接入维基百科或《二十四史》的数据库，让豆包写剧本时有史料支撑，避免胡编乱造。
2. 升级视觉节点： 等Sora或者可灵（Kling）的API价格降下来，把“文生图”节点替换为真正的“文生视频”节点，彻底解决画面静态的问题。
3. 加入人工审核流： 在Coze里加一个Human in the loop节点，AI生成分镜后先发给我确认，我修改了帽子穿帮的提示词后，再往下执行。

做完这个项目，我的大学生涯也快走到尾声了。回想这四年，从大一为了GPA死磕C语言指针，到大四用AI搭建全自动流水线，技术的浪潮翻涌得比想象中快太多。

历史的车轮滚滚向前，AIGC就是现在的造浪机。在这个最好的时代，别焦虑，去折腾。去把手弄脏，去写下你的第一行Prompt，去构建你的第一个工作流吧！