当一个 AI 工作流节点数超过 30，你面对的就不再是"工具使用问题"，而是系统工程问题。
这篇文章，我想完整复盘一下我最近做的一个项目：
「每日英语」AI 自动短视频生成工作流。
它不是 Demo，也不是玩具，而是一条已经可以跑起来、但也真实暴露工程问题的 AI 内容生产流水线 。
一、为什么要做这个项目？
做英语短视频的人都知道，最费时间的不是"讲什么"，而是：
- 写文案
- 录音
- 配图
- 剪视频
- 调节节奏
一条 30 秒的视频，可能要花 30 分钟甚至更久。
于是我给自己定了一个目标：
能不能输入一个英文单词，就自动生成一条可直接发布的英语教学视频？
注意，我一开始就明确了一点：
❌ 我不想要"直接导出 MP4"
✅ 我要的是 剪映工程草稿
因为工程草稿，才是真正能用于生产的形态。
二、整体效果先说结论
最终实现的效果是：
-
输入：
apple -
系统自动完成：
- 英文解释
- 中文释义
- 示例句
- 教学口播
- 文案分镜
- TTS 音频
- 教学图片
- 背景音乐
-
输出：
- 一个可在剪映中直接打开的完整工程草稿
人工只需要：
- 打开剪映
- 简单检查
- 微调
- 导出
👉 剪辑从"手工劳动"变成了"审核动作"
三、这个工作流有多复杂？
我数了一下：
总共 37 个节点
而且不是那种"堆节点"的复杂，而是：
- 多模型
- 多模态
- 循环体
- 外部系统（剪映）
- 本地客户端加载
如果你也做过复杂工作流，你会知道：
节点数并不可怕，可怕的是依赖关系失控。
四、我把 37 个节点拆成了 6 个"功能域"
这是我能把这个系统控制住的关键。
1️⃣ 输入与触发域
- 输入英文单词
- 作为整个工作流的唯一入口
2️⃣ 英语内容生成域
- 英文释义
- 中文解释
- 示例句
- 教学口播文案
👉 所有内容只在这里生成一次
3️⃣ 文案结构 & 分镜域
- 把一段教学内容拆成多个分镜
- 控制视频节奏
- 决定展示顺序
这一步决定了：
视频像不像短视频，而不是 PPT。
4️⃣ 多模态生成域（循环体）
-
每个分镜：
- 生成 TTS 音频
- 生成配图
- 计算时间轴
这里是节点最多、也是最复杂的地方。
5️⃣ 剪映工程构建域
- 创建剪映草稿
- 添加音频轨
- 添加图片轨
- 添加 BGM
- 设置封面
⚠️ 这一步，也是后面踩坑最多的地方。
6️⃣ 输出与校验域
- 输出草稿 ID
- 本地下载草稿
- 打开剪映查看结果
五、我踩过的最大坑：Media Not Found
在 Coze 里：
- 工作流 全部运行成功
- JSON 正常生成
- 草稿创建返回成功
但在剪映里：
❌ 时间线一片红
❌ Media Not Found
一开始我以为是：
- 图片没生成？
- 音频 URL 错了？
- JSON 结构有问题？
但后来我确认了一件非常重要的事：
只要 Coze 能成功创建剪映草稿，JSON 本身一定是合法的。
六、真正的问题出在哪里？
结论很明确：
问题不在 AI，不在工作流，而在「剪映草稿创建 + 本地加载」这一段。
具体表现为：
- 草稿创建是成功返回的
- 但素材下载是异步的
- 某些素材偶发下载失败
- 剪映客户端对"外部写入草稿"的热加载不完整
最终表现就是：
- 需要多次创建草稿
- 看下载日志
- 有时还需要重启剪映客户端
这是一个典型的工程级现实问题 。
七、这次项目让我真正学到的 5 条经验
1️⃣ 数节点没意义，要数"功能域"
37 个节点 ≠ 复杂
6 个功能域 ≈ 可控系统
2️⃣ 主干必须是单向数据流
输入 → 内容 → 分镜 → 多模态 → 工程 → 输出
一旦反向依赖，系统一定会崩。
3️⃣ 外部系统一定要默认"不可靠"
剪映、下载服务、本地客户端
都不是强一致系统
重试、日志、人工兜底，才是现实解法。
4️⃣ 可定位性 > 一次成功
失败不可怕
不知道在哪失败，才可怕
5️⃣ 当你开始考虑"失败隔离"，你已经在做系统设计了
这一步，99% 的 AI 教程永远不会教。
八、最后的总结
这个「每日英语」项目，对我来说最大的收获不是：
- 学会了多少节点
- 接了多少模型
而是第一次真正体会到：
当 AI 从"生成内容"走向"生产内容"，
你面对的就是系统工程，而不是 Prompt 工程。
如果你也在做：
- AI 自动剪视频
- 多模态工作流
- 内容工厂类项目
希望这次复盘，能帮你少踩一些坑。