我用 AI 做了一个 20 秒视频，最后把项目删了
我用 AI 做了一个 20 秒视频，最后把项目删了
工具真正留下来的，不一定是那个文件，而是你对工作流的理解。
前几天，我用 AI 折腾了一个 20 秒的网站产品宣传片。
流程看起来挺完整：抓网页截图，做动画，配旁白，加 BGM，导出 MP4。中间还试了几版配音，从 macOS 自带语音，到 MiniMax 的 MMX 声线，再到背景音乐和音量混合。
最后的结果也确实出来了。
但有意思的是，折腾完之后，我把整个项目删了。
这件事反而让我意识到一个很实际的问题：AI 工具的价值，不只是“生成一个东西”，而是让你看清一个东西是怎么被生成出来的。
我一开始以为是在做视频
本节摘要：这节讲的是“做视频”其实不是单纯剪辑，而是在搭一条 HTML、CSS、动画、音频、渲染组成的工程流水线。
刚开始的目标很简单：把一个网站变成一个 20 秒产品 promo。
于是我让 HyperFrames 来做这件事。它的逻辑不是传统剪辑软件那种“拖素材到时间线”，而是把视频当成一个 HTML 工程。
网页截图是素材。
CSS 是画面。
GSAP 是动效。
音频轨是旁白和 BGM。
最后浏览器逐帧渲染，再由 FFmpeg 编成 MP4。
换句话说，这不是“剪视频”，更像是“写一个会在 20 秒内播放完的网页”。
这个思路挺工程化。
如果用传统软件，我可能只关心最后那个 MP4；但用 HyperFrames，我会被迫看到它背后的结构：场景、轨道、时长、素材、缓存、导出版本。
这让我第一次很直观地感受到：视频也可以是一个可复现的工程，而不是一次性的手工活。
第一个坑：能出声，不等于能用
本节摘要：技术上能配音，不代表声音适合作为正式产品交付；原型验证和最终成品要分开看。
最早的配音，我用的是 macOS 自带的 say。
它确实能把中文念出来。
但效果很怪。
这个问题很典型：很多工具在技术上“可用”，但在产品上“不成立”。
就像一个 API 返回了 200，不代表用户体验是 200。服务活着，不代表交付合格。
macOS 系统语音适合做流程验证：证明音频轨能加载，证明视频能合成，证明导出不会报错。
但它不适合当正式广告片旁白。
后来换成 MiniMax MMX，声音自然很多。至少它开始像“内容素材”，而不是“系统提示音”。
这里的判断很简单：
原型阶段要快，交付阶段要像样。
不要在第一步就追求完美，但也不要把原型阶段的临时方案当成最终结果。
MMX 不是剪辑软件，是素材工厂
本节摘要：MMX 更像素材生成器，能产出配音、图片、音乐、视频片段，但真正的装配逻辑还要由人和工作流完成。
后来我顺手研究了一下 mmx。
它其实是 MiniMax API 的命令行工具，可以做很多事：配音、文本、图片、视频、音乐、搜索、看图、查额度。
但它不是一个完整的剪辑软件。
它更像素材工厂。
你给它文案，它吐出配音。
你给它 prompt，它吐出图片、音乐或视频片段。
真正把这些东西组织成一个完整作品的，还是你的工作流。
这点很重要。
很多人用 AI 工具容易有一个误区：以为“模型能生成素材”，就等于“模型能完成项目”。
其实中间差了好几层：
- 素材生成
- 素材筛选
- 时间线组织
- 音画匹配
- 风格统一
- 文件导出
- 版本管理
AI 可以加速每一层，但不自动替你建立这套系统。
工具负责产出零件，你要负责装配逻辑。
权限问题，本质上是工作流边界
本节摘要：权限弹窗不是单纯的麻烦，而是在区分“安全、明确的工具前缀”和“过宽、不可控的任意命令”。
这次还折腾了很久权限。
有些命令可以设置“始终允许”，比如 mmx、HyperFrames 这类明确工具前缀。
但有些命令不行，比如 rm -rf、任意 python3 -、bash -c、复杂 shell 管道。
一开始会觉得烦：为什么不能都放开？
后来想想，这其实是合理的。
因为“始终允许”不是一个按钮，而是一个信任边界。
允许 mmx，意思是允许一个明确的 AI 工具工作流。
允许 HyperFrames，意思是允许一个明确的视频生成工作流。
但允许任意 shell，基本等于允许系统做任何事。
这就不是提高效率，而是把保险丝拔了。
所以比较成熟的做法不是追求“无权限弹窗”，而是把常用工作流收敛成安全前缀。
比如：
mmx负责生成素材- HyperFrames 负责合成视频
- FFmpeg 负责检查音频视频参数
- 普通文件操作限制在项目目录内
这样既减少打断，也不至于把整个系统裸奔。
最后生成了很多东西，但真正有用的不多
本节摘要：AI 工作流会产生大量截图、音频、缓存、中间版本，最终真正有价值的可能只是一个交付物和一套流程理解。
那个视频工程最后大概 67 到 68MB。
里面有截图、音频、BGM、HTML、缓存、几个 MP4 版本。
最终真正有用的文件，其实就是一个 8MB 左右的 MP4。
其他大部分都是中间产物。
这件事挺像科研和写代码。
你看到的一篇论文、一个 demo、一个视频，背后一定有大量临时文件、失败版本、缓存、草稿和废案。
但如果不定期清理，它们会把你的系统占满。
更麻烦的是，它们会把你的注意力占满。
最后我把整个项目删掉了。
不是因为它完全没价值，而是因为它已经完成了它的使命：让我跑通了一遍从网页到视频的 AI 工作流。
文件可以删。
流程理解留下来就行。
我这次真正带走的东西
本节摘要：这节把经验压缩成几个判断：流水线思维、原型和交付分离、人类审美判断、权限边界、项目清理。
这次折腾下来，我带走的不是那个 20 秒视频，而是几个判断。
第一，AI 生成不是魔法，是流水线。
一个完整结果通常不是一个模型直接吐出来的，而是一串工具接力：截图、动效、配音、音乐、混音、编码、验证。
第二，临时方案不能假装成最终交付。
系统语音能跑通流程，但不适合正式内容。原型和成品要分清。
第三，命令行工具适合自动化，不适合替你做审美判断。
MMX 可以生成声线，HyperFrames 可以渲染视频，但“这个声音怪不怪”“这个节奏像不像广告片”，还是要人判断。
第四，权限不是障碍，是边界。
真正值得长期允许的，不是所有命令，而是可解释、可复用、风险可控的工具前缀。
第五，项目结束后要清理中间产物。
不是所有生成物都值得保存。保留最终结果、保留方法，删掉噪声。
写在最后
本节摘要：最后的硬结论是，别只问 AI 能不能生成一个东西，要问自己能不能把它变成稳定可复用的生产线。
这次看起来是做了一个视频。
但我更愿意把它理解成一次 AI 工作流排练。
它让我看清楚一件事：以后做类似内容，不应该从“我要生成一个视频”开始，而应该从“我要搭一条什么样的生产线”开始。
工具会越来越多。
模型会越来越强。
但最后决定产出质量的，还是那几个老问题：
你要什么？
你怎么验证？
哪些只是临时产物？
哪些值得沉淀成流程？
别只问 AI 能不能生成，先问自己能不能把它变成一条稳定的生产线。
本文来自「研路炼钢」
