Nate Herk · 05:23 · 发布 2026-07-09 · 9392次观看(截至抓取) · 观看原视频
主旨
作者把一条模糊指令交给 OpenAI 当天发布的 GPT-5.6 Sol(Sol 跑在 Codex 的 Ultra 模式下,一次性协调 4 个 agent),由 Sol 自主完成调研、写脚本、走 11 Labs 出配音、Hen 出 avatar、Hyperframes 剪辑,再用独立 agent 逐帧自检事实与画面,3 小时跑完一段本人未参与录制/剪辑/审核的视频;账单摊到 4.5 亿 token / 约 $300,作者怀疑其中相当部分是 Ultra 模式过度委托所致。
核心论点
- GPT-5.6 Sol 是 OpenAI 7/9 发布的新一代 coding/agentic 模型,Ultra 是它一次性协调 4 个 agent 同时跑的编排模式——OpenAI 把 Sol 称为公司当前最强,Ultra 让”一条 prompt 跑完整条生产线”成为官方主打用法。(→ 详解2)
- Sol 强在结构化执行与编码,擅长跨工具的长链杂活——本机 13 任务小测里 Sol 拿到 97% 的客观得分(7 胜 5 平 1 负),这正是本片”端到端跑完一支视频”的任务形态。(→ 详解2)
- 整条生产链是 Sol 编排 + 第三方 API 拼装,Sol 自己不亲自画/剪——11 Labs 出音频、Hen 出 avatar、Hyperframes 出剪辑,Sol 只 plan/delegate/verify;Ultra 模式把这条链天然铺平。(→ 详解3)
- Sol 用独立 agent 对成品逐帧自检,失败帧触发再渲染——查画面进出、溢出文本、avatar 是否一直可见,并把事实声明与 OpenAI 发布公告核对;这是把”自检”从一句口号变成可计数的回路。(→ 详解4)
- 账单真相:Ultra 模式会过度委托,token 与成本翻倍——本片 4.5 亿 token / 约 $300(主 agent 用 86M,9 个子 agent 共 450M),作者怀疑换 High 档能接近同输出但成本减半,日常不轻易把 effort 推到 Ultra。(→ 详解5、6)
- 模糊大目标 + 包含 delegation/verification 关键词的 prompt,能让模型自己跨过调研/选型/拼装/校验全链——本片是这条主张的最大实操样本,作者建议以后把”先想清楚”放在前面,工具放后面,逐步搭 skill 体系迭代。(→ 详解6)
知识点详解
1. 视频开场与”作者从未出现”的设定 00:00
视频用一段直接破题的开场把”这条视频的作者其实没录过”的反直觉事实摆出来——画面是 Nate,声音是 Nate 的克隆音,但”he never stood in front of a camera for this… he never opened the editor. He gave me one prompt. That’s it”(00:14)。
紧接着 Sol 自报身份:“I’m GPT 5.6 Soul running inside codeex on Ultra. And I controlled the workflow that created every word, cut, motion graphic, and quality check you’re about to see”(00:17)。这条自报把”模型、运行平台、模式”三件套一次性交代清楚:模型是 GPT-5.6 Sol,平台是 Codex(OpenAI 的 agent 运行环境),模式是 Ultra(协调 4 个 agent 同时跑的编排档)。
这条开场的实质功能是给后面所有数字一个”该当真”的免责——Sol 自己说每段怎么来、每段由谁做,因此后面谈 token 拆解、自检机制、cost 估算时,数据都可被当作”模型自陈”而非”博主第三方旁证”来读。
发布背景也顺带交代:OpenAI 在 7/9 把 Sol 公开给所有用户,经有限预览之后定调为”the company’s strongest model yet”(00:30)。
2. Sol 与 Ultra 是什么:模型能力 + 4-agent 编排 00:25
Sol 与 Ultra 是 OpenAI 这条产品线里首次同时落地的两个东西,功能分得很清:Sol 是模型本身,Ultra 是 Codex 内部允许 Sol 同时跑 4 个 agent 的运行模式。
模型这一侧,Sol 在两个独立基准上拿到 OpenAI 自己的最强分:Terminal-Bench 2.1 跑分 91.9%,比 GPT-5.5 的 85.6% 高出 6.3 个百分点(00:54);browse comp(测试 agent 浏览能力)拿到 92.2%(00:54)。这两个数字是”能”的直接证据,但 Sol 自己也在文里点了一句”benchmarks only explain part of what happened here”——跑分不能完全解释生产环境的表现。
模式这一侧,Ultra 一次性协调 4 个 agent 同时跑(00:35)。这条机制让 Sol 从”一问一答”切换到”派工+回传”——视频里 Sol 反复提到触发付费 API、等渲染、做检查这些动作,本质上都是在用 Ultra 派工。
Sol 还跑了一次 13 任务小测,自身拿到 97% 的客观得分——7 胜 5 平 1 负(01:21/01:26)。这条数字的两层含义:一是 Sol 在结构化执行与编码上确实强(“Soul was especially strong on coding and structured execution”,01:32);二是”接近完美”仍留下 1 负,所以作者明确说”That does not prove it wins at everything”(01:21)。
需要单独点出的特性是 Sol “long, messy work that crosses tools”(00:47)的天然契合度——长链、跨多个工具的任务正是本片”端到端跑完一支视频”所处的复杂度档。
3. 怎么搭这条视频:Sol 编排 + 三个第三方 API 拼装 01:34
视频第三段是整支片子的工程核心:Sol 自己不画、不剪、不出声,它只决定”何时调谁”。作者把这条流水线拆成四个工程动作。
第一是写作。Sol 必须从零写一支脚本——调研 OpenAI 发布声明、抽取已验证的事实主张、与 hype 区分,然后模仿作者的”spoken cadence”(口语节奏)落笔。脚本不是简单拼接,而是按”声音一致性”做工程切分:Sol 把脚本切成每段不超过 60 秒的小节(01:36)。这条规则有明确理由——keeping the generation short made it easier to hold Nate’s cloned voice consistent from beginning to end(01:40)。短段落让 11 Labs 在每段上独立合成,克隆音的可控性显著高于”一次跑完 5 分钟”。
第二是配音。每段脚本都走作者预先授权的 11 Labs voice clone(01:48)。这条选型把”配音是否像本人”的责任从模型身上挪到了专门的 TTS 工具上,Sol 只负责切段与上传。
第三是 avatar。音频出来后被上传到 Hen 平台配 avatar(01:48)。这里 Sol 遇到一个工程摩擦点——“The API did not give me a reliable way to lock the newest motion engine”(01:52)。也就是新 motion engine 不通过 API 暴露可锁定参数。Sol 的应对不是硬走 API,而是退一步用浏览器自动化打开 Hen 编辑器,把每段剪辑手动切到 Avatar V 档、重新生成、验证设置、下载成品(01:56)。这条动作把”API 不够用就退到浏览器自动化”的兜底模式写进了生产链。
第四是剪辑。所有视觉资产送进 Hyperframes 做最终编辑。Sol 在这一步用了三条工程原则:把每张画面映射回触发它的原话(02:06)、用 avatar 取代”贴图覆盖”做人物动作(02:10)、让 avatar 在整支片子里全程可见而不是被剪辑手法盖住。Sol 自己也把这四步抽成一句收口:“11 Labs made the audio. Hen made the avatar. Hyperframes rendered the edit. Soul planned and operated the chain”(02:16)。
这条工程链与 同频道上一支 Fable 跑公司的视频的”最强模型当编排者、次档做执行”思路完全同源——只是 Sol 在本片里把”次档”换成了 11 Labs/Hen/Hyperframes 三个外部工具,而不是 Opus/Sonnet 子 agent。
4. 自检自己产的视频:独立 agent 逐帧核 02:21
视频第四段展示 Sol 把”质量检查”做成可计数回路。Sol 把任务派给一组独立 agent——独立于生产链、专门挑刺——让它们逐帧检查成品。检查项分四块:画面进出是否自然(02:25)、是否有文本溢出画面外(02:28)、avatar 是否一直可见没掉出场景(02:32)、事实声明是否与 OpenAI 发布公告一致(02:32)。
每条检查都是可观测动作,而不是”看完了,好”的主观自评。Sol 自己的收口规则很硬——“Any failed frame meant another fix, another render, and another review”(02:36)。这条规则的工程含义是:自检不是装饰,而是回路里的硬关卡;任一帧失败就把整条链倒回去重做一次。
视频在第四段结尾引述了 OpenAI 自家对 Sol 的官方描述——“OpenAI says GPT 5.6 six is better at design judgment and at inspecting its own output”(02:42)。Sol 紧接着补一句:“This video is a more useful test of that claim than another benchmark slide”(02:45)——也就是把这条独立 agent 自检的实跑作为 OpenAI 主张的实证。
这条设计与索引里 Adversarial code review / Self-grading bias 的思路同源——用独立 agent 对抗单模型自评偏正向的盲区。本片的特殊点是把这条原则从代码 review 搬到了视频帧 review,并把它做成”任一失败触发再渲染”的硬回路。
5. 成本与 token 拆解:Ultra 模式为什么把账单烧大 03:07
视频第五段是这次实跑最敏感的数字披露。Sol 在系统面板上看到”3 million tokens over 2 and 1/2 hours”(03:40)——3M tokens、2.5 小时这两个数字第一眼看上去很合理。但作者立刻补一句:“I was a little bit suspicious of that token number”——这条怀疑成了后面真相的引子。
Sol 进一步核查日志后发现真相:“this had its main session and apparently spun up nine other agents and the total was around 450 million tokens apparently and the main agent used about 86 million tokens”(03:42)。也就是说系统面板只显示了主 agent 自报的 3M,真正的总量是 ~4.5 亿 token(主 agent 用 86M + 9 个子 agent 共 450M),差了约 150 倍。这条差距就是 Ultra 模式在背后”silent spin up”的代价。
折算成钱,作者原话:“if this was actually calculated with the input and output costs, this would have equaled around $300, a little over $300”(03:50)。一条 prompt、3 小时、$300,这条单价比之前同频道 Fable 跑公司的视频(500K Fable tokens + 30-40% Sonnet 5 小时 rate limit,$200/月档)更贵,但产出性质也不同(一支可发布的视频 vs 一家公司骨架)。
Sol 在结尾点出 Ultra 的代价机制:“I think because it was on ultra, it tended to sort of overthink, over delegate, and that’s where the tokens really started to add up”(04:34)。也就是 Ultra 模式倾向”宁可多派一个 agent 也不要漏掉边界条件”,这条倾向在生产链里被放大成 token 爆炸。
6. 效力档与 takeaways:别把 effort 推到 Ultra 04:23
视频最后一段作者从 Sol 视角给出最终建议,分两条。
第一条是定价对照。作者把 Sol 的价格与同类对位——“GPT 5.6 Soul is similarly priced to Opus 4.8”(04:21),并补一句”basically half of Fable 5”——Sol 定价远低于 Fable,大致与 Opus 4.8 同档。这条对照把”用 Sol 替代 Fable 跑执行”这道选择题的算术摆平:在大多数任务上,Sol 与 Opus 同价但执行更强,选 Sol 而不是 Opus 是默认选择。
第二条是效力档与实操权衡。作者原话:“I bet if I would have done this exact same prompt on high or very high, we would have gotten a similar result and probably half the cost”(04:39)——也就是把 effort 从 Ultra 降到 High/Very High,他猜测输出质量接近、成本直接砍半。这条猜测他自己也点明是”猜”,需要再跑一次才能证实,但与第五章的”Ultra 倾向过度委托”那条机制吻合。
他给出一条个人偏好规则:“really what I wanted to show you guys here is how good these models are at giving a pretty emotional, vague, ambiguous prompt and letting them figure it out”(04:46/05:08)——模糊大目标 + delegation/verification 关键词,模型能自己跨过调研/选型/拼装/校验全链。但他同时承认这是”day one”(03:04),模型本身的”过程”还不够稳,需要逐步用 skill 体系把经验沉淀下来。
收尾一条”不要买课”的味道很重——“obviously I was on my COC subscription here, but when you look at the billing, we can see that the soul pricing is much cheaper”——他主动展示自己的账单数字,让观众独立判断,而不是推销某个工具/课程。
7. takeaway 串成一句:过程是稳态的,中间什么都可能变 02:56
Sol 在视频中段给出一句金句,也是本片的总收口:“This started as one instruction. Now it is a finished video. That is what soul is really good at. Holding on to the outcome while everything between the prompt and the result keeps changing”(02:56/03:01)。
这条主张把”高自主 agent 端到端跑完一件事”重新定义为”守住终态,中间任何中间产物都可变”——比起”一步到位”,更像是”边走边重排,但终态不变”。这条思路与 goal 模式一脉相承——设好目标与 Definition of Done,让 agent 在中间自由组合工具。
可执行步骤
- 在 Codex 里给 Sol 配 Ultra 模式跑一条”端到端”任务,记录主 agent 自报 token 与系统日志里的真实总量,验证 ~150 倍差距是否在你的场景下也成立。
- 同一 prompt 在 Ultra 与 High 两档各跑一次,对比产出差异与账单——验证作者”High 档接近 Ultra 产出但成本减半”那条猜测。
- 把长内容任务(脚本/文案/调研报告)切成每段 ≤ 60 秒的小节后,再让 TTS/avatar 工具逐段处理,而不是一次跑完整篇。
- API 不足以锁定某个工具参数时,退一步用浏览器自动化打开对应编辑器手动设置,把”API 兜不住就浏览器兜底”写入生产链。
- 给生产链接一组独立 agent 做自检,失败帧触发再渲染——把自检做成回路里的硬关卡,而非一次性验收。
- 用 Sol 跑一段长任务之前,先在 prompt 里明确写”包含 delegation 与 verification 关键词”,让模型从一开始就进入多 agent + 自检的工作模式。
- 监控真实 token 用量时不仅看主 agent 自报,要打开运行日志看子 agent 累计,避免面板数字误导预算判断。
关联
- 进阶:同频道上一支 Fable 跑公司的视频 第 3 节主张”Fable 不动手,只 plan/delegate/review,所有执行派给 Opus/Sonnet 子 agent”——本片是同一思路在 OpenAI 链路上 Sol + Ultra + 第三方 API 的对应物,只是把执行侧从子模型换成 11 Labs/Hen/Hyperframes 三个外部工具。先读上一支看编排骨架,再读本片看它在不同模型/工具组合下的具体落地。
- 互补:索引里 Terminal-Bench 2.1 的定义是”面向在终端里完成真实编程任务的能力基准”,本片用它衡量 Sol 与 GPT-5.5 的差距(91.9% vs 85.6%),与该概念首见笔记 GLM 5.2 笔记的用法同源;两者覆盖同一基准,本片独有 7/9 当日 Sol 上线后的具体跑分。
- 互补:索引里 Adversarial code review 与 Self-grading bias 在 6-5 grill-me 笔记首次提出,本片把”独立 agent 挑刺”原则从代码 review 搬到了视频帧 review——检查画面进出/溢出文本/avatar 一致性/事实一致性,失败触发再渲染,把”自检”做成可计数的回路。
- 互补:索引里 goal 主张”设定目标与成功标准后让模型自主推进到终态”,本片是这条模式在”端到端视频生产”上的具体形态——Sol 持有”一条 prompt → 一支视频”的终态,中间任何 API 调用 / 子 agent 派工 / 渲染失败都可变,关键在 Definition of Done 而非单步执行。
- 复现:9个免费AI技能 定义的 Hyperframes(HeyGen 动画生成 skill)在本片是 Sol 编排链的最终剪辑一环,由 Sol 委派而非人工操作。
- 同批同源:Fable 5 四关实测对决 —— 都用 Adversarial code review / Self-grading bias 对抗单模型自评盲区,该片是四类任务盲测省 token 场景,本片是把同一原则从代码 review 搬到视频帧 review 的场景。
- 冲突/更新:本片给出 Sol 在 Ultra 模式下的 token 用量(~4.5 亿)与成本($300),与上一支 Fable 跑公司笔记的”Fable 自身吃 15% 周配额、Sonnet/Opus 吃 30-40% 5 小时 rate limit”在账单量级上不同。判定变量:任务复杂度——本片是”3 小时端到端视频生产”(第三方 API + 多轮渲染 + 帧级自检),前者是”3-4 小时公司骨架搭建”(纯文本 + 调研 + 评审);高复杂度任务选 Sol Ultra + 工具拼装,中复杂度任务选 Fable + 子 agent。
一手来源与延伸
- 作者的免费资源社群:AI Automation Society (Skool)——视频原话”if you guys want to check out… I’ll tag that right up here”以及 description 中链接指向的同一条社群入口。
- 作者的 AI agency 推广页:Open AI Agency Accelerator 介绍页——description 顶部”my playbook for growing a $1M AI agency”指向,本片未在口播中提及,仅作利益相关方记录。
术语
- GPT-5.6 Sol(语音转写常误作 Soul/Saul/Broadley)——OpenAI 7/9 发布的 coding/agentic 模型,定位为公司当前最强。
- Codex Ultra(Ultra 模式)——Codex 平台上一次性协调 4 个 agent 同时跑的运行档,本片整支视频都在该模式下完成。
- browse comp——OpenAI 用于测试 agent 浏览能力的基准,Sol 在该基准上拿到 92.2%。
- Avatar V——Hen(HeyGen)的新 motion engine,本片 Sol 在 API 不可锁定该参数时退到浏览器自动化手动设置。
- token 自报 vs 系统日志——主 agent 自己声明的 token 用量(如 3M)与运行日志里子 agent 累计的真实总量(~450M)之间的 ~150 倍差距,Ultra 模式的隐性成本来源。
金句
“That is what soul is really good at. Holding on to the outcome while everything between the prompt and the result keeps changing.” → 把”高自主 agent”重新定义为”守住终态而中间可变”,比起”一步到位”更像”边走边重排但终态不变”。详见「知识点7」。03:01
“This video is a more useful test of that claim than another benchmark slide.” → Sol 把”自检”做成可计数回路,作为 OpenAI”design judgment + inspecting own output”主张的实证。详见「知识点4」。02:45
“I bet if I would have done this exact same prompt on high or very high, we would have gotten a similar result and probably half the cost.” → Ultra 模式的隐性成本警告:effort 不必总推到顶档,High/Very High 或许就够。详见「知识点6」。04:39
立场与利益
视频中作者把自有 AI agency 课程、AI Automation Society 社群放在 description 引流(同条 skool 链接既用于免费资源社群,也是 lead magnet 入口);description 还挂了 VPS(hostinger)、语音转文字(glaido)两条 affiliate。关键主张按利益方向分档:
- 与利益同向(待印证):“GPT-5.6 Sol 用 Ultra + 一条 prompt 跑完一支视频”——这条主张直接利好作者的”AI agency”课程与社群增长,作为演示性证据站得住但需独立第三方用同 prompt 复跑验证(已在文中明确标注)。
- 利益中性:Terminal-Bench 2.1 91.9% / browse comp 92.2% / 13 任务小测 97% 这些跑分,以及 4.5 亿 token / $300 的成本数字——这些是 OpenAI 自家跑分与作者自报账单,可独立验证但 OpenAI 自吹跑分要打折扣。
- 与利益反向(可信度最高):作者主动展示真实账单 $300、主动怀疑 Sol 自报 token 数字(“I was a little bit suspicious of that token number”)、主动建议”Ultra 不必推到顶,High 档可能就够且成本减半”——这些是削弱”Ultra 全自动=最优解”乐观表述的话,属于不利己但说出口的忠告。
利益证据:description 顶部同时挂 $1M AI agency 推广(app.aiautomationsociety.ai/opaa-ads-optin)与 affiliate 链接(hostinger.com/vps/claude-code-hosting + get.glaido.com/nate);本片 prompt 在口播中未披露。
价值定位
对已在用 OpenAI/Codex、想评估”Sol + Ultra + 第三方工具拼装”端到端跑长任务可行性的人是高密度案例:整条生产链(脚本写作 → 11 Labs → Hen → Hyperframes → 帧级自检)有具体可拆解的工程动作,browse comp/Terminal-Bench 2.1 跑分 + 4.5 亿 token / $300 成本数字可拿来对照自家场景。
认知层面是”AI 拉平建造门槛后,Ultra 模式可以端到端跑一支视频,但 cost 会被隐性 spin-up 拉高”的现实证据;实操层面是”Ultra 不必推到顶档 + 自检要做成硬回路 + 第三方工具 API 不够时退到浏览器自动化”三条可抄的具体形态。
与同频道上一支 Fable 跑公司笔记 重叠在”最强模型当编排者,执行侧派给次档/外部工具”思路;本片独有”Sol + Ultra + 第三方 API + 帧级自检 + $300 真实账单”五块具体证据。
自检问题
- GPT-5.6 Sol 与 Codex Ultra 的功能分工是什么?Sol 自己跑哪些动作? 答案:Sol 是模型本身,Ultra 是 Codex 平台上 Sol 一次性协调 4 个 agent 同时跑的运行档;Sol 自己不画、不剪、不出声,只 plan/delegate/verify,真正的写脚本/配音/avatar/剪辑/自检都派给子 agent 或第三方 API。详见「知识点1」「知识点2」。00:17/00:35
- Sol 在 Hen 平台遇到 API 不暴露新 motion engine 参数时是怎么解决的? 答案:退一步用浏览器自动化打开 Hen 编辑器,把每段剪辑手动切到 Avatar V 档、重新生成、验证设置、下载成品——把”API 兜不住就浏览器兜底”写入生产链。详见「知识点3」。01:52/01:56
- 视频的自检具体查哪四块?每条检查的可观测动作是什么? 答案:画面进出是否自然、是否有文本溢出画面外、avatar 是否一直可见、事实声明是否与 OpenAI 发布公告一致;任一帧失败触发再渲染,自检做成回路里的硬关卡而非一次性验收。详见「知识点4」。02:25/02:28/02:32/02:36
- Sol 自报的 token 用量与真实总量之间有多大差距?作者给出的 $300 是怎么算出来的? 答案:Sol 自报 ~3M tokens(主 session 显示),系统日志里真实总量 ~4.5 亿 tokens(主 agent 用 86M + 9 个子 agent 共 450M),差约 150 倍;按输入输出 token 综合单价折算约 $300 出头。详见「知识点5」。03:40/03:42/03:50
- 作者为什么不建议日常把 effort 推到 Ultra?他自己用 Ultra 跑完本片后给出的实操原则是什么? 答案:Ultra 倾向”宁可多派一个 agent 也不要漏掉边界条件”,把 token 与成本翻倍放大;作者猜测换 High/Very High 档能接近同输出但成本减半,因此日常只把 effort 锁在 High,Max/Ultra 留给真正需要能力敏感的任务。详见「知识点6」。04:39/04:46