Sabitlenmiş Tweet
从 Prompt 工程师到 Loop 工程师:一个 AI 视频项目替我交的学费
最近 Loop Engineer 这个词很火。 我想用自己的项目讲讲,这个思路转变到底改变了什么。
背景:我在做一个 AI 视频生成的项目。
用户丢一张产品图 + 一句话需求,产出一条能直接发的短视频。
第一阶段:Prompt Only,也叫祈祷式生成
最早的架构极其朴素: 一个 2000 字的巨型 prompt,把脚本、分镜、字幕、节奏要求全塞进去, 一键生成,然后祈祷。
结果是: 十次里能有三四次能看的ai视频。
字幕溢出、产品图只出现半秒、音画对不上,全靠人眼兜底。 出错怎么办?改 prompt,重跑。 改 prompt 的过程像调风水—— 你不知道是哪个字得罪了模型。
最痛的是:每次重跑都是全量重跑。 一个镜头错了,十个镜头的钱重新烧一遍。
转变的那个瞬间
有天我盯着账单突然想通了: 我一直在优化"怎么一次做对", 但正确的问题是"做错了怎么被发现、被修正"。
一次做对是玄学, 发现错误是工程。
这就是 Prompt 思维到 Loop 思维的分水岭: 不再追求完美的一句话, 而是搭一个能自己收敛的循环: 尝试 → 评估 → 修正 → 达标或触顶就停。
我现在的四层循环长这样
1️⃣ 回合制循环:脚本和分镜阶段 模型出方案,我扫一眼,不行就下一轮。 这一层评估器是我自己,免费,而且我比任何模型都懂"这条能不能发"。 便宜的判断留给人,是省钱的第一课。
2️⃣ GOAL 循环:单镜头生成 这是改造的核心。每个镜头有一张明确的验收清单: 时长误差、字幕不出安全区、产品图出现 、分辨率达标。 生成 → 自动质检 → 不过就带着"错误原因"重试。 重试上限 3 次,三次不过转人工,绝不让它无限烧。
3️⃣ 定时循环:每天跑 3 个标准需求的回归测试，模型行为是会漂移的,今天好好的 prompt 下周可能变傻。 以前是用户告诉我坏了,现在是早饭前我自己先知道。
4️⃣ 事件循环:生成失败自动触发诊断 失败日志 + 上下文自动打包丢给模型分析原因, 我醒来看到的不是报错,是归因报告。
三条学费换来的心法
一、先写终止条件,再写 prompt。 循环最大的风险不是做不对,是停不下来。 次数上限、预算上限、超时上限,一个都不能少。 启动很便宜,停止很贵。
二、评估器分层,能用 if 解决的别请模型。 我的质检三层: 规则脚本(ffprobe 查时长分辨率,免费) → 小模型(看字幕看构图,便宜) → 大模型(只做最终成片验收,贵但只跑一次)。 用 Fable 5 去检查视频时长,等于请米其林主厨来试吃泡面。
三、大模型只出现两次:开头和结尾。 开头做规划,结尾做验收, 中间的循环全部交给便宜的小模型。 重构后单条视频成本降低，一次通过率从 30% 到 70%。
最后
Prompt 工程优化的是一句话, Loop 工程优化的是一个系统。
AI 不是不会做对,是你没给它发现自己做错的机会。
Prompt 是你对模型说的话,Loop 是你对模型立的规矩。
从祈祷到验收,中间隔着的就是工程两个字。
中文
