YT 学习笔记

用 Fable 5 + 双 Loop 一周 75 PR：Master Loop 与可中断关卡

32分钟阅读下载 MD

封面

Ras Mic · 17:29 · 发布 2026-07-09 · 340次观看(截至抓取) · 观看原视频

主旨

作者把”修 bug / 加 feature”拆成两个串接的自动闭环——Loop 1 让 cloud agent 写完代码后用 computer use 自测并录像直到行为达标,Loop 2 让 Greptile 评审 PR 直到 5/5,中间用一支内嵌成功视频的 PR 衔接,自己只扮演工单撰写与最终签字,以此解释自己怎样用 Fable 5 在 Fable 复活窗口内合并 75 个 PR。

核心论点

  1. “Loop” 不是一个口号,是要写出可观测的成功状态——成功的判定必须写在 ticket 里、能被 computer use 截图确认,否则就是烧 token。(→ 详解1)
  2. 工程起点的 spec 必须足够结构化：summary / 复现步骤 / 期望行为 / 实际行为 / 影响分析 / 建议下一步,否则 cloud agent 没有可对齐的判定标准。(→ 详解2)
  3. 用 cloud agent 的关键不是要它”聪明”,是要它”有完整电脑”——既能在隔离环境里 reproduce bug,又能跑 computer use 自测、还能录 video,这三件事本地机扛不住。(→ 详解3)
  4. Loop 1 的退出条件是”含成功视频的 PR”：agent 写完代码后必须用 computer use 操作自家软件、录下成功回放,失败就回炉,而非以代码能跑为准。(→ 详解4)
  5. Loop 2 把 PR 评审本身做成自动闭环:Greptile 打分 <5/5 时,agent 读 review、生成修复 commit、再交评审,循环到 5/5 才出关;这条 skill 才是真正”取代自己”的部分。(→ 详解5)
  6. 主循环被刻意切成多层,任何一层都能人为中断:Loop 1 录的视频是坏的 / Loop 2 没拿到 5/5 / 人 review 发现函数签名不对,任一关都能停;多层 gate 才是”扛得住”的根因。(→ 详解6)

知识点详解

1. Loop 的精确定义与作者的反转态度 00:03

作者开场先把量级数据压出来:00:03”I shipped over 75 PRs using Fable 5 and Loops”——不是因为囤了 prompt 模板,而是把单条 PR 的路径改成了 machine-runnable。Fable 5 自己的窗口被算力天花板给卡了一次(他自己因此订阅烧光在等重置),但只要 loop 模式立住了,模型换了也能复用同一套骨架。

他对 loop 的态度是有过反转的。00:36 原话 “originally I wasn’t really a big fan of loops, especially the way it was explained. But after building out my own loops and areas that make sense and combining them with other loops, I finally have a workflow where I can literally go to bed with a defined loop and wake up with a finished PR ready to get shipped”——反对的不是”loop”这个概念,而是市面讲解把它讲成了抽象口号;自己动手拼出适合场景的 loop 后,睡眠时间也成了产能。

作者把 loop 钉死成一个可观测的闭环模型。09:24 关键约束原话 “the desired state is not only easy to check but easy to identify and easy to state. I have it in my linear ticket and it has computer used to confirm this”——成功状态必须能被一句话写在 ticket 里、被 computer use 截图证实,这两条任一缺位,loop 就退化成”烧 token 直到 refusal”。

这套定义与 Agentic Engineering 的本质同源:把 PRD 用作判定门槛、把 spec 当硬约束、用自动 eval 决定是否续跑。但本片的 loop 走得更具体——它绑定在 ticket / desktop / PR / Greptile score 这些可观测信号上,而不是抽象的”测试通过”。

2. 工程起点:Linear 写清 spec → MCP 把工单丢给 cloud agent 01:21

工单系统是整个循环的”指令面”。作者用的是 01:21 Linear——他甚至吐槽 “the way the ticket is explained is pretty bad cuz I hand wrote this. I would use AI to make this better. Forgive me for that” 04:39,但承认 Linear 是他和合伙人 Muso 集中放 feature request 和 bug 报告的地方,替代 GitHub Issues 是因为 “it’s GitHub”。

工单字段被当作 loop 的可读规格。他展示的一份 bug ticket 模板包含 02:05:summary · steps to reproduce · expected behavior · actual behavior · impact analysis · suggested next steps。这条模板就是 loop 1 的成功判定书:期望行为与实际行为的差,直接对应 computer use 自测时截图要命中与不要命中的画面。

工单怎么被 agent 看见的?不是人去发链接,而是 02:19 “through MCP what happens is we can assign an agent to work on this specific feature or bug”——Linear 通过 MCP 把工单暴露给 agent,作者只需在 ticket 上 assign 给 Cursor 或 Devon,这两条 channel 就够触发自动化。这条机制与 MCP 的标准定位吻合:把外部数据源(ticket)以统一协议暴露给 agent,而非写定制 webhook。

MCP 通道只解决”agent 看见工单”,不解决”agent 能落地动作”。这一步靠 cloud agent:02:36 “the reason why I need a cloud agent is I want an agent to have full access to a computer”——只有把 agent 推进隔离的云端 Linux 桌面,后续的 reproduce bug、跑 computer use、录 video 才能在同一台机器上闭环,不会把开发者本人的笔记本 CPU/GPU 烧成暖手宝。

3. 为何必须用 cloud agent:完整电脑 + computer use + 录像三件套 02:29

作者明确比较 cloud agent 与本地 agent 的差异点:06:11 “the cool thing about cursor cloud agent is it has access to a desktop and so does Devon. Devon also has access to a desktop”——两家 cloud agent 都带完整虚拟桌面,且这桌面是 agent 自己能操控的电脑,不是 IDE 内嵌的 preview。

cloud agent 必须配齐三件事才能进 loop。第一是 reproduce:14:09 “I wanted you to recreate the bugs experience them so you know exactly what’s the issue” ——auth / 2FA / OAuth 流程都得能在云端桌面里完整跑通,作者现场还演示了必须给 Devon 2FA 权限才能继续;他原话 14:09 “so it reproduced the bug right” 紧跟其后。第二是 test:06:34 “I want once the agent is done writing the code is I wanted to use computer use to actually test out the fix”——写完代码不只看测试通过,要看 agent 自己操作自家软件、截图证明行为正确。第三是 record:10:30 “in the pull request it will post a video”——PR 描述里会附一段操作录像,人 review 时先看视频再决定是否合并。

为什么这套必须上 cloud?作者在演示 onboarding 流程的视频时直接交了底:10:03 “you can only do this with cloud agents because doing this on your own machine, unless you have a very very beefed up machine” + 10:09 “I have a beefy machine, it will burn the heck out of your computer” ——他本机都扛不住循环重跑,更何况冷启 agentic workflow 的人。

4. Loop 1:Agent 写代码 → computer use 自测 → 出 PR 含成功视频 06:04

Loop 1 是双 loop 之一,作者花了一半篇幅把它拆开讲。它的起点不是”写代码”,而是 05:27 “this is the first part of our loop. We haven’t even got to the loop part, but the build phase has begun”——从 Linear 拉工单 → cloud agent 拿走 → start coding 是 loop 的非循环侧(“we haven’t even got to the loop part”)。

真正的循环从 06:04 “once it’s done, it does the following. This is where the looping begins” 开始,流程是:agent 写代码 → 用 computer use 在云端桌面里启自家应用 → 执行 ticket 写的操作步骤 → 截图对比期望行为 → 命中则停、未命中则回炉继续改。

他给的两个例子都强调”循环能 catch 失败”。第一个是 07:28 “the agent actually got it wrong”——把 connector permissions 设成”每次问一次”而不是”always allow”,被 Devon agent 直接打 fail,loop 重跑改回来。第二个是 09:37 “I wanted to build a new onboarding flow for people to create virtual cards for their agent” ——同流程下成功跑出 onboarding 的视频证据,作者原话 09:48 “it’s also showing me the cards that exist. Right. So this is a successful run”,PR 内附的操作视频就在那一段。

Loop 1 的退出条件是 10:21 “once we pass this step, what the agent then will do is it will create a pull request, a PR” + “if this is a merged PR and you can see it has demo videos of success state” 10:36。换言之,带成功视频的 PR 是 loop 1 的”准出证”,而 PR 里的视频充当了”agent 向人交接的凭据”——这是把”video as evidence”模式直接下沉到 PR 描述里。

这条退出条件极其关键,因为它把 loop 1 做成”自我证伪”型而非”自我宣告”型。代码能编译、单元测试能过、甚至部分功能能跑,都不构成退出;只有”agent 实际操作后命中 ticket 写的画面”才算。

5. Loop 2:Greptile 评审自动闭环到 5/5 + PR 内嵌视频承接 Loop 1 10:52

Loop 2 接 Loop 1 的准出证(PR + 视频)继续干活。作者原话 10:52 “this is where loop number two happens”——loop 2 的形态是从 PR 平台读 review,反馈给 coding agent,直到分数达标。

review 这件事他用的是 11:00 “the tool that I use for this is GPile”——口播里的 “GPile” / “GP loop” / “Grapile” 等都是 ASR 对 Greptile 的不同转写,品牌名是同一个;前作 ras-mic·Skill 按需加载 也用过 Greptile 当评审方。这条选型上有伙伴关系偏向,但本片用作 loop 2 的”硬判定”角色没有替代品——评审分低于阈值就回炉,这是机制层选择。

Greptile 的功能被压缩成两件事:打分(0-5)+ 留下 review 评论。loop 2 的运转路径是 11:08 “the GP loop skill which allows your agent to loop against its feedback until you get a perfect score” ——sketch 一句话:agent 等 Greptile 评分 → 若 <5/5 就读 review 评论 → 改代码 → push → 再评审。

关键阈值是 11:18 “the confidence score is a five out of five” + 11:39 “wait for the PR review from GPile. Once you’ve received the PR review, if it’s a three out of five, a four out of five, read the feedback you get”——5/5 是退出阈值,3/5 4/5 触发自动修复,这套阈值在 Fable 5 下基本一次就走;他特意补了一句:“if you’re using Fable, it’s always a four out of five or a five out of five. But let’s say you’re using GBD 5.5 or Opus 48, you might get a three out of five or a four out of five”——为不同模型保留不同基线是这段的隐性建议。

Loop 2 与 Loop 1 的衔接点是 PR 里的视频。Loop 1 的成功视频在 PR 描述里看得到,人 review 13:37 “the human review is me reviewing the entire PR the video and I might look at the function signatures of the code but I’m not reviewing the entire code”——人 Review 看的是 video + 函数签名,而不是逐行审代码。这条”人不再逐行审”的边界意义大于”自动化变彻底”,是 vibe coder 把责任切成”agent 写 + agent 审 + agent 自测 + 人定夺”四段的关键拐点。

6. 从手动跑流程到 skill 化:“先手动再固化”原则 15:28

整套 loop 其实最初不是 skill。作者在演示了一个具体例子——13:53 的 bug ticket “Chat stream and calling connectors is slow and breaks”——后说:15:17 “before I turn this into a loop, before I created a skill for this, it’s called testing Pluto PRs”。skill 名字里出现 “Pluto”——他把那个 product 名作为命名 token。

把流程从手动变成 skill 的具体步骤他讲了四条。第一条 15:28 “I built this loop myself. Meaning I manually walked through these steps”——必须先用非自动的方式把每一步自己走一遍,确认哪一步断、哪一步错,否则抽象的 skill 写不出来。第二条 16:01 “Do not stop until you have a successful run and a recording to show me”——这是给 agent 的 prompt 截断,他原话 16:03 “Boom. You just built your first loop”。

第三条是承认 PR 阶段必须配 Greptile 才能上 loop 2——他原话”please push to GitHub. Have Gravile. You got to set up Gravile on GitHub”。第四条是把 skill 标成可名化的资产——“use the GP loop skill. You can pull it up from the internet”——这是 Claude Skills 的标准用法,作者把整条流水线压缩成一个 slash 命令。

这一节呼应前作 ras-mic·Skill 按需加载 的元原则:skill 不是 prompt 模板,而是把已验证的手动流程压缩成可复触发的工作流。两片合看就拼出 harness 上下文管理这条腿(skill / agents.md 怎么按需加载)与 master loop 这条腿(整套工程闭环怎么跑)——前者管单个 skill 何时被拉起,后者管多个 skill 如何串成流水线。

7. Master Loop 与多层可中断关卡 16:51

结尾他把整套命名”master loop”:16:51 “let’s call this master loop using two loops” ——Master Loop = Loop 1 (build + computer use self-test) + Loop 2 (Greptile 5/5 review loop)。这是他在 Fable 5 复活窗口内能合并 75 个 PR 的根因:不是单条 prompt 写得巧,而是闭环层层咬合。

他对 Fable 5 的判断是工具级承认:16:59 “I definitely think Fable 5 is the reason why this works” + 17:00 “I’m sure this could work with a GPT55. Hopefully, we get GT56”——模型是这条 master loop 的燃料,但形状不绑死在 Fable 5 上;换成 GPT 5.5 甚至作者期待的下一代模型也能复用同一骨架。

真正让 master loop 值得交出去而不是自己熬夜的原因,是它的多层可中断关卡。任何一层出问题都能停:08:19 “if the recording that you get is bad because the agent hallucinated, you could stop that” + “if you don’t get a five out of five, it doesn’t get merged. You could stop that. Right. So, I believe I’ve built a robust loop”——故意不追求”全自动合并”,而追求”任何关卡都能手动闸断”的 robustness。

这条”故意可中断”对应 复合概率衰减 的反向推论:每步不在前端加人工关口的纯串联 agent,经过 N 步后正确率会按乘法衰减。本片的解法不是把”人工关卡”缩成零,而是把它切成多个独立可触发的 stop button——Loop 1 录坏了停,Loop 2 没 5/5 停,人 review 看函数签名不对停。

可执行步骤

  • 把团队当前的工单模板列一次:summary / 复现步骤 / 期望行为 / 实际行为 / 影响 / 建议下一步,任一字段空着不接 agent。
  • 把”修复 bug / 加 feature”拆成两层:第一层只做”代码 + video evidence”,第二层只做”review 分数达标”,中间用 PR 描述里的视频作为衔接凭证。
  • 接 cloud agent(Cursor Cloud 或 Devon 任一),先手动跑一次完整流程:工单 → agent → reproduce → 修 → computer use 自测 → 录 video → push PR → Greptile 评审,不要先写 skill。
  • 把”成功状态”写成一句可被截图证实的话写进 ticket,并把它写进 prompt:“Do not stop until you have a successful run and a recording to show me”。
  • 在 PR 评审工具接入 Greptile,跑一次 PR review → 分数 <5/5 → 改 → 再评审的完整循环,把退出阈值定位 5/5(若用非 Fable 模型则把基线调整为 4/5)。
  • 故意保留至少三处可中断关卡:Loop 1 录像异常 / Loop 2 分数未达标 / 人 review 看函数签名,任一关都被设计成”按一下就停”。
  • 把上面这套流程固化为一个命名 skill(如 testing Pluto PRs)放进 Claude Code / Cursor,slash 一句话触发整条流水线。

关联

  • 进阶:ras-mic·Skill 按需加载 是同频道链路第二集(harness 上下文管理 + grep loop 雏形),先读它理解 harness 内部如何按需加载 skill,再读本片的”loop 即两个 skill 串接”实战;两片合看才是”skill 内 vs skill 间”两套机制。
  • 进阶:ras-mic·我如何构建应用 是同频道最近作(系统架构层),读它掌握 monorepo / Convex / BaaS 等基建选型后,再回到本片看基建之上”loop 怎么跑”——合看才是”AI 时代做产品”基建到工作流的完整链路。
  • 印证:Agentic Engineering 定义为”用完整 spec、自动化 eval 和 CI 门禁让 agent 自主发现并修正问题”;本片把 eval 钉死成 computer use 自测 + Greptile 5/5 双判据,把 spec 钉死成 Linear 工单的 6 字段,把 CI 门禁锚定在 PR 准入——三者合一就是 Agentic Engineering 的具体形态,与前作抽象定义互补。
  • 印证:复合概率衰减 警告”多步 AI 串联成功率按乘法衰减,无人工关口则整体正确率被前置错误拖垮”;本片的”三层可中断关卡”是对这条警告的工程化回答——不求全自动,而求每层都允许随时按停,与”复合概率衰减”的现实压力同向。
  • 互补:Ralph Loop 把”PRD/任务清单交给 agent 逐项自主推进、每步验证才前进”做成单一长链任务循环;本片的 loop 形态不同——它不是一条长 PRD 全跑完,而是”工单级小循环 × 多个工单”批量化并行,两者的”循环颗粒度”差异恰好互补:Ralph Loop 管整个项目,本片管单个 ticket。

一手来源与延伸

  • Framer Agent — 视频 description 里的官方 affiliate 链接(代码 MICHAEL1 折扣),视频约 03:00-04:00 的中插广告段介绍 Framer Agent 可基于截图 1:1 还原网站并产出 design system,本片用作”agent 能完整造前端”的反面证据,引出 cloud agent 的工程主导地位。

术语

  • Cloud Agent — 把 agent 跑在云端独立 Linux 桌面的运行形态(本片点名 Cursor Cloud 与 Devon),关键能力是隔离环境 + 完整电脑 + computer use + 录 video,本地 agent 做不到这四点
  • Computer Use — agent 用模型直接操控图形桌面(点击/输入/截图)的能力,本片用作 loop 1 的成功判定机制,不止是”测试通过”,而是”截图命中 ticket 写的画面”
  • Linear — 项目管理 / 工单系统,作者用其替代 GitHub Issues,本片用作 spec 写入与 MCP 暴露的载体
  • MCP — Model Context Protocol,工单系统通过它把 ticket 暴露给 agent,本片用作 Linear ↔ cloud agent 的桥
  • Greptile — AI 代码审查服务,对 PR 评 0-5 分并留下修复评论,本片 loop 2 的评审方(“GPile”是 ASR 对 Greptile 的转写)
  • GP Loop Skill(Greptile 官方) — Greptile 团队的 PR 评审→修复闭环 skill,看 ras-mic·Skill 按需加载 一手链接
  • Testing Pluto PRs Skill(本片命名) — 作者把”手动跑完的修 bug 流程”压缩成的一个 Claude Skill,名以他正在开发的产品 Pluto 命名
  • Master Loop(本片命名) — 两个子 loop 串联的工程闭环:Loop 1 (build + computer use self-test + PR with video) → Loop 2 (Greptile 5/5)
  • Self-annealing 自退火 — self-annealing:本片中”loop 修不对就回炉再写”是这一概念的工程化具象;在 skill 化版本里,失败信息会自动写回 skill 的 instructions 实现自我加固

金句

08:12 “Agent builds, it’s being tested using computer use. We evaluate it. The agent checks the state, checks to see if the desired state is achieved.” — 一句话把 loop 的全部要素钉进 ticket,接下来 08:19 “this ticket does a bad job of explaining how we write it. But you can see here what the expected behavior is and what the actual behavior is” 直接把工单的差值点给 loop 当判定书用。

08:19 “if the recording that you get is bad because the agent hallucinated, you could stop that. If you don’t get a five out of five, it doesn’t get merged. You could stop that. Right? So, I believe I’ve built a robust loop.” — Robustness 的真正定义不是”全自动”,而是”任一层都能按停”。

16:03 “Boom. You just built your first loop.” — 把”手动走一遍 → skill 化”的两步压缩成一句咒语,呼应 Claude Skills 的本质:skill 不是 prompt 模板,而是手动流程的可复用压缩。

立场与利益

视频含明确商业关联:description 里 https://rasmic.link/framer 是 Framer(合作 1:30 - 04:00 的 Framer Agent 中插广告)的 affiliate 链接、附 MICHAEL1 折扣码;其余 rasmic.link/styleui / rasmic.link/site / rasmic.link/x 等都是自有 social 链接,把流量引回自己的 personal brand 与社群,是非第三方 affiliate 的自引流。

  • 与利益同向(待印证):“Cursor Cloud 与 Devon 这两家 cloud agent 是唯二能做完整 loop 的选择”——这条主张与本频道既卖 Cursor-based 工作流、又把 Devon 作为合作方强绑在 loop 例子中的角色有关,采信前需外部印证两家之外是否存在替代选择(Claude Managed Agents / Factory Droid 等)。
  • 利益中性:Linear / MCP / Greptile / Fable 5 的工具选型、工单 6 字段模板、5/5 阈值、computer use 自测标准——这些是公开可独立验证的工程结构,无明显商业偏向。
  • 与利益反向:作者在 00:24 原话自承”我订阅烧光了在等重置”17:23 主动提到 100K 订阅目标 / 16:59 自承”Fable 5 是这条 loop 之所以成立的根因,但换成 GPT 5.5 大概也行”——这些反向信号削弱”必须订 Fable 5 Max”的话术,可信度较高。

Framer Agent 段本身就是广告,与笔记主线无关,已从核心论点剔除;后续若做 cite 应只引作为”agent 能造前端”的对照,不引其设计系统能力。

价值定位

适合已经在用 Claude Code / Cursor / Devon 这类编程 agent、希望把”修 bug / 加 feature”的路径真正自动化而不是堆 prompt 模板的工程师与产品 owner。提供一套可直接复用的两 loop 骨架(工单 → cloud agent → computer use 自测 → 带视频 PR → Greptile 5/5 → 人签字)与可中断关卡的设计原则,而不是泛泛的”用 AI 写代码”。

实操价值在三处可立即搬用:工单 6 字段模板能把”接受标准”显式化让 agent 看得见;cloud agent 必须配齐的 reproduce + computer use + record 三件套清单;“先手动跑一遍再固化为 skill”的原则能把 skill 抽象的”试错成本”显式化。

认知价值大于纯实操的是:把 loop 的 robustness 重新定义为”任一层可中断”,而不是”全自动无人值守”——这与 复合概率衰减 的现实压力相容,比”全自动工程师”叙事更可信。

与ras-mic·Skill 按需加载 重叠在”skill 怎么用”这层;本片独有的:工单字段到 PR 视频再到 5/5 评审的完整衔接链、“先手动后 skill 化”的具体操作顺序、Master Loop 故意保留多层可中断关卡的方法论原则。

自检问题

  1. 作者把”loop”压成的两条硬约束是什么?为什么缺一就退化成烧 token? 答案:成功状态必须能被一句话写在 ticket 里,且能被 computer use 截图证实;两者缺一,loop 退化为”烧 token 直到 refusal”。详解1 09:24
  2. 工单模板的 6 字段分别是什么?为什么这 6 字段不是”写得详细一点”而是”loop 的判定书”? 答案:summary · steps to reproduce · expected behavior · actual behavior · impact analysis · suggested next steps;期望行为 vs 实际行为的差就是 loop 1 自测时截图要命中 vs 不要命中的画面,所以它是判定书而非描述书。详解2 02:05
  3. 为什么作者坚持用 cloud agent 而不是本机 agent?三件套分别是什么? 答案:因为本机 agent 做不到”完整电脑 + computer use + 录 video”三件套连续运行不烧机;三件套是 reproduce bug、computer use 自测、录操作 video。详解3 10:05 14:09 10:30
  4. Loop 1 的退出条件不是”代码能跑 / 测试通过”,而是什么?为什么这样设? 答案:PR 描述里附带的”操作成功视频”;agent 写完代码 → computer use 跑 ticket 写的操作 → 截图/录像命中 ticket 写的期望画面。自我证伪型而非自我宣告型,避免”代码能跑但行为不对”的伪通过。详解4 10:21 10:36
  5. Loop 2 的”自动闭环到 5/5”具体怎么走?基线阈值在不同模型下会有什么变化? 答案:agent 等 Greptile 评审分 → 若 <5/5 读 review 评论 → 改代码 → push → 再评审;Fable 5 下基本一次就到 5/5,GPT 5.5 或 Opus 4.8 等基线低一档常见 3/5 4/5,需要多轮修复。详解5 11:00 11:18 11:39
  6. 作者”先手动再固化为 skill”的具体步骤是什么?为什么要先手动? 答案:先用非自动方式把 Linear 工单 → 写代码 → 自测 → 出 PR → Greptile 5/5 → 人 review 的全链自己走一遍,确认每一步顺畅;然后给 agent 一条 prompt”do not stop until you have a successful run and a recording to show me”,再把 GP loop skill 接上,整体打包成 testing Pluto PRs skill。先手动是因为未走过的流程无法抽象为可复用 skill。详解6 15:28 16:01 16:03
  7. Master Loop 的 robustness 真正来源是什么?为什么故意保留”可中断关卡”而不是追求全自动? 答案:robustness 不是”全自动合并”,而是每层都有手动闸断——Loop 1 录像异常停、Loop 2 分数未达标停、人 review 看函数签名不对停;多层 gate 抵消串联 agent 的复合概率衰减,而全自动反而把每层失败放大成下游错误。详解7 08:19 16:51

关系图谱

反向链接