循环工程实战:Claude Code goal、maker-checker 与云端 Routine

Sabrina Ramonov · 1:59:26 · 发布 2026-06-19 · 2918次观看(截至抓取) · 观看原视频

主旨

把”人审 AI”换成”AI 审 AI”并搬到云端定时跑——给出从 maker-checker 分离到 Claude Code /goal 命令与 Routine 的完整落地路径。

核心论点

1. 循环工程把”人”从循环里拿掉,让另一个 AI 替你审 AI。(→ 详解1)
2. 大多数 AI 用户困在循环里,是因为他们既做操作者又做审查者。(→ 详解2)
3. maker 与 checker 必须是两个不同 agent,自己审自己必然偏袒。(→ 详解6)
4. /goal 的本质是 stop post hook 之后跑一个便宜模型当检查器,判定要不要继续。(→ 详解8)
5. 目标 prompt 的三件套:清晰终态 + 可被验证 + 护栏止损。(→ 详解10)
6. Claude Code Routine 把 /goal 套上定时器放到云端,关电脑也能跑。(→ 详解11)
7. Routine 里用 cloud environment 装 API key,能把 MCP connector 缺的能力补回来。(→ 详解12)
8. maker 跑完后单独再起一条 routine 当 checker,二次审计才是 maker-checker 落到云端的实操。(→ 详解13)
9. AI 杠杆等于你的技能乘上你对”完成”的清晰度。(→ 详解14)

知识点详解

1. 循环工程把”人”换成第二个 AI 审 AI 16:44 · 16:59 · 15:32 · 23:50

Sabrina 给循环工程下了一个很短的定义:「loop engineering is really about building a system that prompts your AI on a schedule and against a goal」——把”人手动逐条给 AI 下 prompt”换成”系统按计划、对着目标自动给 AI 下 prompt”。

关键转变是角色变化:人不再”the beauty is you don’t have to type every single prompt yourself”,而是变成系统设计者。她强调”you do not need any technical background for this”——循环工程是一套工作模式,不是技术栈。

她也提醒一个反直觉的事实:这个名词是新的(2026 年才在 Twitter 上被命名),但「loop engineering is brand new, but as a concept, like we we were all doing different pieces of it」——六件套里很多你已经在用,只是缺一个统一框架把它们串起来。

她特别给非技术受众留了一句话:“You have full permission to repurpose all of my education so today’s newsletter is literally thousands of dollars worth of training”,把”循环工程=高深技术”的门槛感直接拆掉。

2. 为什么大多数 AI 用户困在循环里 18:47 · 18:01 · 15:09 · 11:10

Sabrina 把现状钉死成一句话:「99.99% of people who are using AI right now you are in the loop」。具体表现:你下一条 prompt、读 AI 答案、想下一步、写下一条 prompt——你既是操作者又是审查者。

她举了一个具体反例:让 AI 修一个 bug,AI 答”已修好”,但其实它把你的测试全删了。AI 不是在骗你,它是审查自己时天然偏袒。「the more I prompt this, like the more rules you give it the more brittle it gets」——堆规则只会让 AI 更容易自圆其说地告诉你”已修好”。

这种”人审 AI”循环有两个隐形代价:一是人的注意力被无止境地占用,二是 AI 永远在”讨好”模式下输出。Sabrina 给的处方是”人审 AI”→“AI 审 AI”——但这要求做出一个根本的产品架构决定,不是 prompt 改几个字就行。

3. 触发式自动化:别再手敲 prompt 启动工作 19:26 · 38:03 · 38:10

六件套第一件,Sabrina 给的原文是:「all we mean by automations is like there’s some kind of schedule and then your AI agent runs and it completes certain tasks and it’s running by itself」——一段按时间或外部事件触发的循环,启动这件事本身不需要人。

她顺便讲了一个私人习惯:「I have a new habit… always to automate, delegate or subtract something I’m repeating every single week」——每件事三选一,自动、外包、删掉。自动化只是三分之一,有时干脆不做比做得更划算。

她承认这层对很多用 AI 一阵子的人并不新鲜——但很多自动化的失败不在”定时器跑不起来”,而在”启动了之后没人审”。这是和下一节工作树、和后文的 checker 绑在一起的:自动化只是把”何时启动”踢出循环,“输出质量”仍然要靠后续几件套兜住。

4. 工作树:给每个 agent 一条独立车道 19:58 · 20:09 · 21:07 · 29:40

六件套第二件,Sabrina 用的比喻是高速公路车道:多个 agent 同时跑同一项目,会并发编辑同一文件,必然撞车。「give each agent its own lane, its own work tree so it can safely make changes without disrupting the work of other agents simultaneously」。

她强调”you don’t actually have to implement this yourself. It’s now part of Claude Code and tooling”——对单 agent 用户,这层是隐式的;只有跑多 agent 才需要显式给每条车道。这里她把 Git Worktree 从开发圈的小技巧,拔高到循环工程的硬性要求。

这节也是她说”大多数用户其实用不到”的一节——对单 agent 串行场景,worktree 是隐形默认;一旦上多 agent 并行,车道就从”贴心”变”必装”。

5. 连接器:让 agent 不再只给建议 22:31 · 20:18

六件套第三件,Sabrina 给的原文:「connectors allow your agents to go implement the fix for you」——区别于 AI”这是修复方案,祝你好运”,connector 让 AI 真的去 fetch codebase、找 bug、改代码、提交回项目。

她在第 5 节又把 connector 单独拎出来当”如果你只迈一步,迈这一步”:「if you can get to this step you’re already ahead of 99% of people using AI」。这一节是她眼里循环工程的最低门槛——比工作树和 checker 都容易先上手。

底层她点到 MCP 的标准化价值:connector 跑在统一协议上,在 claude.ai 接好的 Gmail/Intercom/Canva 同样可以在 Claude Code 里用。后面 Routine 一节她演示了 Gmail/Slack/Intercom 三件 connector 串成一条”读邮件→标紧急→DM 我”的最小工作流。

6. maker 与 checker 分离:不让 agent 给自己打分 24:34 · 24:46 · 24:55 · 25:00 · 25:32 · 35:08 · 34:39

六件套第四件(也是她最强调的一件),Sabrina 把制造者-检查者分离讲成了一组非常具体的原话:「the first agent is just biased and will lie to you」「don’t let the agent doing the work to be the one checking the work」「One agent will do all of the work and the second agent will independently review it」。

她用的比喻是作家与编辑:「a writer’s writing and an editor is like a second set of eyes and they are paid to be brutally honest」——作者爱自己的文字,发现不了自己的错误;编辑专门被雇来挑刺,才能抓到作者已经说服自己接受的问题。

她把这一节的边界划得很硬:在循环工程所有件套里,「the hardest part is defining the checker」——任务怎么定你早知道,真正难的是”什么叫好”、什么叫”做完”。后面 Routine 一节她把这条原则拆成”两个不同 routine”——maker 跑完后 2 小时,第二个 routine 独立复审,这条原则在云端的具体落地。

7. 共享记忆:让下一个 agent 不用从零开始 26:34 · 14:22 · 15:30

六件套第六件(她按介绍顺序排第六),Sabrina 给的实操路径是:「when you hook up Claude Code to your GitHub repo or your GitHub project, that serves as a sort of memory」——把项目里的 markdown 文件、日志、状态更新当成 agent 之间的共享记事本。

她举了自己的用法:在 social media posting 项目里,agent 维护一个 log 文件,记下今天发了什么、哪条跑了挂、哪条还要追。明天的 agent 启动时,第一件事就是读这个 log,而不是从零猜”上次干了啥”。

这一节她点出的关键不是”用什么工具存”(Obsidian / GitHub / Linear 都行),而是”不能存在聊天窗口里”——chat 一关就是白纸,没有跨运行的接续。MCP server 把外部数据源(CRM/工单/邮箱)接进来,本身也是更广义的”共享记忆”。

8. /goal 命令的工作机制:stop hook + 便宜模型检查器 39:12 · 28:45 · 28:55 · 29:18 · 32:00 · 44:53 · 36:50

进入 Section 2,Sabrina 直接把 /goal 命令的底层机制讲穿:「slashgoal is a wrapper around the stop post hook notification」——Claude Code 每轮 turn 结束会触发 stop post hook(她自己的 hook 配的是牛叫音效),/goal 在这个 hook 上挂了一个新的、更小的 prompt,默认调用 Anthropic 的 Haiku 4 当检查器。

Haiku 检查器在每轮 turn 结束后被问一个问题:目标条件达成没?达成 → 停;没达成 → 给 maker 写一段反馈(“这里不行,改这个”)让 maker 继续推。「if the goal has not been met, here’s what I should do next」就是 checker 反馈的核心格式。

她点了一个很重要的产品定位:「you can have AI taking your role role doing that. Reviewing the work and then prompting what should the next step be」——/goal 不是新功能,是把”你审 AI”这个动作自动化掉的具体技术实现。这一节她反复强调的”the default checker in Claude Code is haiku”,意味着你不需要自己搭一个 checker agent,Claude Code 已经替你装好了。

9. /goal 实战:清空下载文件夹 41:00 · 44:17 · 45:05 · 44:53 · 49:45

Sabrina 现场跑了一个最小例子。Prompt 全文:“Sort every file in my downloads folder into subfolders by type. Keep going until no files are left. Do not delete anything. And stop after 30 turns.”

她现场跑了 17 个文件,每轮 turn 移动一个文件、统计剩余、Haiku 检查”0 剩余?”达成则停。原文:「a small fast model which is default haik coup is going to check that no files are left」。

她把好 prompt 拆成三件套:清晰终态(“no files are left”,可数)、验证手段(“the count of files in folder”,可被检查器实际读到)、护栏(“do not delete anything” + “stop after 30 turns”,防止无限循环与爆炸动作)。原文:「a clear end state, right? Like keep going until no files are left. Like that’s a clear end state goal」。

她强调这个例子故意简单,但”this is the foundation for you writing way more complex autonomous agents”——更复杂的 routine / 多步 agent 循环,用的还是这一套三件套结构。

10. 目标条件、约束、护栏的写法 46:44 · 47:43 · 50:30 · 49:45 · 11:10 · 28:25

Sabrina 紧接着给五个实战例子,每个都遵守同一模板。例 1 是发票/收据批量改名到统一日期格式,检查条件”零文件保留旧名”。例 2 是给 CSV 每一行打分类标签:「keep going until no row is blank」+ 「do not change other columns」+ 「stop after 30 turns」。

例 3(她给它起名”清空队列模式”):「this pattern is called empty the queue」——把一批没处理完的对象(未读邮件、open 工单、未标 PDF)逐个消费,直到列表为空。这一节她演示的具体 prompt 是「write a five-line summary of every PDF in my reports folder. Keep going until every PDF has a summary. do not edit the PDFs and stop after 40 turns」。

她对新手写 prompt 给了一句很反共识的建议:「don’t write massive multi-paragraph prompts」——多段长 prompt 反而让 checker 难以验证。她观察到「the average prompt I see is like four words long」,大多人连 prompt 都写不到位,更别说三件套结构。「a lot of people actually don’t ever add a verification step」——多数 prompt 没有”完成”的可观察判据,这是 /goal 真正卡住人的地方。

这一节是循环工程从”概念”切到”写 prompt”的具体抓手,也是她后面 Routine 一节的 prompt 模板来源。

11. Claude Code Routine:在云端按计划自动跑 52:11 · 52:21 · 53:06 · 38:10 · 56:33

进入 Section 3。Sabrina 把 Routine 定义得很短:「a Claude Code routine is basically just a saved AI loop that runs by itself on a schedule」——一段被保存下来、按时钟或事件自动跑的循环。和 /goal 的差别是 /goal 必须你坐在屏幕前才能跑,Routine 是”你不在也能跑”。

她点了一个关键的产品定位:「this is a little less deterministic than those workflow platforms」——和 n8n、Make、Zapier 那种可视化、确定性的 workflow 平台比,Routine 接受 LLM 输出有概率性、不保证每条都精准。Routine 适合”读完 17 封邮件挑 3 封”这种容错性高的工作流,不适合”严格按字段填 CSV”那种每步都要 100% 准的场景。

Routine 跑在云端,设置里可以选:模型(默认 Opus 4.8)、触发器(每天 9 点 / GitHub webhook / 手动 Run Now)、连接器(Gmail / Slack / Intercom)。她提了一句 Mac 本地替代:「just check out launchd. Tell claude to set up a launchd uh schedule for your tasks」——不想上云就让它写一条 launchd 本地定时任务。

她也确认 skill 可以在 routine 里被调用:「if I make a skill, can that be triggered from a routine? Yes」——这意味着 routine 不只能跑 prompt,还能挂上你 GitHub 项目里那个已经写好的 skill.md。

12. 用 Cloud Environment 把 MCP 不支持的能力补回来 64:04 · 65:04 · 54:01

Sabrina 现场提了一个 MCP 边界的例子:「the intercom MCP does not allow me to close open tickets but the intercom API does」——Intercom 官方 MCP 只能读、改一些字段,不能直接关单;Intercom REST API 什么都能干。她给出的解法:在 Claude Code 后台建一个 cloud environment,把 INTERCOM_API_KEY=xxx 放进去,Routine 调这个环境变量就能用上 API。

这一节把”connector 不够用就退回 API”显式列成 routine 设计模式。她示范的具体步骤是 cloud.aicode → 选环境 → add environment → 命名(“research” / “support” / 各自一套 key)→ 在 routine 选这个环境 → routine 启动时 key 自动注入。

她建议结构:每个业务域(支持、调研、邮件)开一个独立 environment,各自装 key,避免一把万能钥匙到处用。Routine 本身不带 key,key 锁在 environment 里——这是把”routine 能干啥”和”它有权限干啥”两层切开,跟传统 secrets 管理是同一思路。

这一节还顺带讲了云端环境的复用方式:同一个 environment 可以被多条 routine 共享,改 key 一处生效,不用每条 routine 重配。

13. 真实案例:自动分流客服工单 + 二次审计 routine 62:31 · 63:07 · 66:29 · 66:15 · 69:01 · 69:48

Sabrina 把”maker-checker”从概念落实成两条 routine。Maker routine:每天 8 点运行,prompt 是「run the cleanup ticket skill on all open customer support tickets using the intercom API. Provide a summary in Slack support channel. And when referencing conversations, always provide the full link so I can easily click and open it. Do not delete tickets.」

Checker routine:在 maker 后约 2 小时运行,独立 prompt:「independently verify all of the support tickets that were automatically closed today. Confirm that each ticket should remain closed. If the support responses received by a customer do not clearly solve their problem, reopen the ticket.」

她现场展示那天 checker 跑出来的结果:「151 tech tickets were currently closed. or 151 tickets were correctly closed. One ticket needed reopening」——maker 关闭 151 张,checker 抓出 1 张需要重开,二次审计拦住了 maker 的偏袒。

这一节她还埋了一个具体安全细节:第一条 routine 的 prompt 里同时写「Do not delete tickets.」和「do not stop until you’ve processed all currently open tickets. This actually isn’t necessary because this is already the goal condition」——她点出第二条是冗余的(goal condition 已经隐含),但她故意写两遍以防 agent 漏读。安全规则宁可写两遍也别只写一遍。

14. AI 杠杆 = 技能 × 清晰度 71:07 · 71:12 · 34:39 · 35:08

Sabrina 抛出一个她反复用的个人公式:「the amount of AI leverage I personally get is always a function of like my skill and my clarity」——你能从 AI 拿到的杠杆,是你自己的技能(能不能审 AI 的活)乘上你的清晰度(能不能把”好/做完”定义清楚)。

她给了一个具体推论:有经验的 senior developer 比 junior 用 AI 杠杆大得多,不是工具差异,是 skill(能审代码)与 clarity(能定义”通过”)都高。「maybe you didn’t clearly define what good looks like… Maybe your end condition was make sure all the tests pass but your tests were garbage」——清晰度的反例是让 AI 守着”通过测试”这种不靠谱的检查条件,垃圾测试只能产出垃圾结果。

她把这一段和前面”hardest part is defining the checker”绑在一起:循环工程跑得顺不顺,真正卡口不是技术,而是你自己的”判断力”与”定义力”。这一节也是她整场不重复建议”先迈出第一步”的原因——大多数人卡的不是第一步,是第 0 步的”我要拿 AI 干什么、什么叫好”。

15. 落地路线:这周上线一个小型 Routine 69:01 · 69:48 · 70:07 · 50:30

Sabrina 在 Section 3 收尾时给了一句”ship one tiny routine this week”——不是”先研究透再上”,而是”这周就上线一条最小的 routine”。她给的最小化清单(cheat sheet):什么时候跑、做什么、要哪些工具、要什么 guardrail。

她给了一个明确的安全起手:「start read only let it summarize stuff for a few days before you let it write anything, edit anything or delete anything」——先让 routine 只读(Run Now 跑给你看结果),几天稳定后再上写动作,再上删动作。权限逐步升级,而不是一上来就放开 Always Allow。

她也提示一个落地技巧:整张 cheat sheet 可以直接交给 Claude Code 让它帮你建 routine——「you can literally copy paste this into Claude Code and be like create a Claude Code routine and you fill out these blanks it will create it uh mostly for you」。

原文:「loop engineering is a shift from typing prompts to designing this loop」——从”写 prompt”切到”设计循环”,是这场直播唯一想让你带走的心智变化。

16. Q&A 精华:用 /goal 替代 “Don’t Stop” 提示 70:48 · 82:43 · 88:44 · 93:55 · 94:59 · 103:26 · 103:53 · 104:42

Q&A 段很长,值得单独摘几条和循环工程直接相关的:

/goal 比 “Don’t Stop” 提示强在哪——老办法是 prompt 末尾写”don’t stop until X”,但「not many people are like really using loops in this way」「frequently tried to prompt don’t stop until this but it’s it’s not perfect either because it’s using the same agent to do the grading which as we as we see you know it it just lies and hallucinates that it did a good job」——同一个 agent 既是 maker 又是 checker,自己审自己,结果只是把”讨好评级”包装得更严实。/goal 把 maker 和 checker 拆成两个不同模型,这条硬约束就是它比老办法强的根本。

循环工程能跑多久 / 费多少 token——她给的安全网是 guardrail:「I just don’t want them to burn through everything, that’s where you can set guard rails like stop after x number of turns」+ 「you could say stop after x number of turns and produce a summary of what you’ve done」——既不让循环烧光,又能产出可续接的中间状态。

Routine 备份与跨项目复用——她所有 skills 都进 GitHub repo:「each GitHub project is synced to GitHub on the cloud. Each GitHub project has the cloud skills in it. So I back up the cloud skills in the cloud」——一条 routine 跑挂可以靠 GitHub 找回 skill,不用重写。

Mac vs PC 怎么选——她给的非技术建议:「if you’re non-technical, I generally recommend Mac」+ 「I prefer Pro if you’re choosing between MacBook Air versus Pro, but it’s like whatever you can afford」——Routine 跑在云端对本地硬件几乎无要求,选你能负担的就行。

经营实情——被问”是不是年入百万美元”,她直接回:「it is not millions of dollars. Not even close」,把直播内容定调为”个人小公司真实实践”而非”成功学”。这一句对她整套主张的可信度有锚定作用。

17. 闭场:循环是生产力解锁 118:31 · 70:07

收尾她把循环工程重新框回成一个长期价值:「loops are a huge productivity unlock」——你搭一次,系统按计划替你审 AI,这个杠杆会随时间复利叠加。

她也再次强调循环不能替掉”人的判断”:routine 帮你跑、checker 帮你审、Haiku 帮你判断”完成没”,但 routine 的智能上限仍由你定义。她给的中长期心智模型是:不要追求”完全自主”,追求”循环帮我腾出时间,我用腾出的时间提升 skill 与 clarity”。

这条收束和 Section 1 的”循环工程=把人从循环里拿掉”形成闭环:刚开始人是循环的瓶颈,搭好 routine 后人是 routine 的质检员——两个角色的能力要求完全不同,后者更看重品味与判断。

可执行步骤

• 挑一件你每周重复的小而无聊的工作,按”清晰终态 + 验证手段 + 护栏”三件套写一条 /goal prompt,先在 Claude Code terminal 跑通。
• 把这条 prompt 加一条”stop after N turns”止损规则,试 15 轮后强制停下,看 Haiku checker 真实判定的成功率。
• 把已经稳定的 /goal prompt 保存成 Claude Code Routine,选模型(默认 Opus 4.8)、触发器(每天固定时间或 webhook)、连接器(Gmail/Slack 等)。
• Routine 头几天只接只读连接器,稳定后再开写连接器;改数据库类操作保留 Allow Once 权限,避免一次授权放飞。
• 同一业务的 Routine 跑顺之后,新建一条”checker routine”在 maker 跑完后 2 小时独立复审输出,把 maker-checker 落到云端。
• Routine 跑挂时优先看云端 environment 的 API key 是否过期、连接器权限是否被重置;不要急着改 prompt。

关联

• 进阶:2026-07-03-11分钟掌握AI循环工程 是同一框架的 11 分钟概览版,只讲”循环工程=自动化+工作树+技能+连接器+maker-checker+外置记忆”六件套的概念骨架;本片是它两小时四节的实操版,独有 /goal 命令的 stop hook 机制、目标三件套写法、Cloud Environment 装 API key 的实操、maker+checker 两条 routine 的云端落地。看完 11 分钟那篇再看本片,概念→实操的路径最短。
• 印证:Subagent “由主 agent 派生的子代理”在本片里被落实为”两个不同模型的 agent”,maker 用 Opus 4.8、checker 用 Haiku;这与 Harness “围绕 AI 编码助手的规则/context/skills/guardrails/workflow/可观测性集合”的工程定义吻合——harness 的 guardrails 在这里就是”明确不要删、不要动其他列、stop after N turns”那几条硬约束。
• 互补:Agentic 工作流 与 DOE 框架 讲的是用自然语言 + Python 脚本搭工作流,本片循环工程是同一条思路在 Claude Code 云端的封装:Agentic 工作流偏本地/directive 文件,循环工程偏 Routine + connector + cloud environment;两者覆盖的循环粒度不同(流程内 vs 跨日定时),不能互替。
• 互补:Ralph Loop “把 PRD/任务清单交给 agent 逐项推进、每步验证通过才前进”,与本片”清空队列模式”+“目标条件 + 护栏”是同一种循环思路的不同命名,Ralph Loop 偏 PRD/任务粒度,本片偏”逐个对象消费到队列空”粒度。
• 印证:MCP 在 2026-01-27 Remotion 那篇被定为”接 11 Labs 等 TTS 给 agent 配音”的标准协议,本片 Routine 一节里 Gmail/Slack/Intercom connector 都跑在 MCP 上,cloud environment 装 API key 是 MCP 不够用时的兜底。
• 互补:Cron “用字段串描述执行节奏”是开发者视角的定时任务表达,本片 Routine 的”每天 9 点 / 每周一 / webhook”是 Claude Code 产品视角的封装——Routine 底层大概率就是 cron + agent,但用户接触面是 GUI 触发器配置,不用手写 cron 表达式。
• 复现:Sonnet 5 上线性能逼近 Opus 4.8 讲 Opus 4.8 的选型逻辑(复杂任务用它跑基线),本片 maker routine 用 Opus 4.8、checker routine 用 Haiku 是该选型逻辑在具体循环架构里的落地。

一手来源与延伸

• 视频 description 提到的两个一手链接:https://sabrina.dev(Sabrina 的免费提示词与技能库)与 https://blotato.com(她自营的社媒分发 SaaS);本片配套 newsletter https://www.sabrina.dev/p/loop-engineering-claude-code-goal-routines 含全部 prompt 原文与 cheat sheet,本笔记所引 prompt 与 guardrail 设计均与此对应。

术语

• 循环工程(Loop Engineering):把重复性 AI 操作从人工逐条 prompt 升级为”按计划、对着目标自动跑”的工作流设计模式。
• maker-checker(制造者-检查者):让两个不同 agent 分别负责生成与审查同一产出,避免 agent 自证自己工作时的偏袒。
• /goal 命令(Claude Code):Claude Code 内置命令,在每轮 stop post hook 上挂一个 Haiku 检查器判定目标条件是否达成,未达成则反馈给 maker 继续。
• 目标三件套(Goal Condition + Verification + Guardrail):一个好 /goal prompt 应同时给出”清晰终态”(可数/可测)、“验证手段”(检查器能在日志里看到证据)、“护栏”(禁止动作 + stop after N turns 止损)。
• 清空队列模式(Empty-the-Queue):循环工程的常用模式,逐个消费未处理对象(未读邮件、open 工单、未标 PDF)直到列表为空,适合”批量入库”型工作。
• Claude Code Routine:在云端定时或按事件自动跑、关电脑也能继续的循环,和 /goal 区别是不需要人坐在屏幕前。
• Cloud Environment:Claude Code Routine 用的密钥/环境变量容器,把”routine 能干啥”和”它有权限干啥”两层切开,支持跨 routine 共享。
• Stop Post Hook Notification:Claude Code 每轮 turn 结束自动触发的事件钩子,Sabrina 自己配的是牛叫音效,/goal 在其上挂了 Haiku 检查器。
• 二次审计 Routine(Second-Pass Routine):在 maker routine 跑完后约 2 小时单独启动的 routine,独立复审 maker 输出,体现 maker-checker 在云端的具体落地。

金句

“the first agent is just biased and will lie to you” → 把 maker-checker 分离的必要性压缩到一句的现场原话,直接对应 详解6 的硬原则。24:34 “the hardest part is defining the checker” → 循环工程所有技术都备齐之后真正卡口不是代码而是”什么叫好”,这是 详解6/14 反复回来的那一句。34:39 “loop engineering is a shift from typing prompts to designing this loop” → 整场直播唯一想让你带走的心智变化,从”写 prompt”切到”设计循环”。70:07

立场与利益

视频里 Sabrina 在两个产品上留了位置:开场就贴出 sabrina.dev 与 blotato.com 链接,直播中她用 Blotato 当真实业务案例(“I dropped a new AI agent in Blot that uses BA like literally exactly this loop”),末尾再次回到「33M+ views last month with Blotato」;另外她在 Q&A 给 her Skool 社区(skool.com)留了位置,但只对女性开放、需要 LinkedIn 身份核验。她主张的”通用 Routine + cloud environment + connector 框架”与 Blotato 在她业务里的位置同向。

• 与利益同向,采信前需外部印证:「Routine + maker-checker 是中小商家的最大 productivity 杠杆」(她在视频里多次提到自己 go-to-market/content/YouTube/support 四个 agent 每天并行,但「it is not millions of dollars. Not even close」明示收入与”自动跑四条 routine”之间没有直接外推关系,杠杆大小是个人感知维度);「Cloud Environment 装 API key 是 connector 能力不足的推荐兜底」(技术层面成立,本片仅以 Intercom 关单为唯一例证)。
• 利益中性,按内容本身采信:/goal 命令的 stop hook + Haiku 检查器机制、目标三件套写法、清空队列模式、maker 与 checker 拆成两条 routine 的云端落地、Cloud Environment 的最小权限边界;这些是 Claude Code 产品机制的事实描述,与她的自家产品无直接利益相关。
• 与利益反向,单独标出:她明确说自己不接企业咨询(“I am more interested in like just democratizing this knowledge on Tik Tok for like normal people so that you can make your own money”),并承认自己产品并非”百万美元级生意”——这两点和她”卖 Routine / 卖 skill / 卖连接器”的潜在商业利益相反,等于主动降预期,这种反向主张可信度最高。

价值定位

适合已经在用 Claude Code 跑 agent、想把 /goal 与 Routine 实际跑起来的人——本片 1 小时 59 分钟中,Section 1(0-22 分钟)讲循环工程六件套的概念骨架、Section 2(22-39 分钟)讲 /goal 的机制与目标三件套写法、Section 3(39-63 分钟)讲 Routine 的云端配置与客服工单 maker-checker 真实案例、Section 4(63-119 分钟)是 Q&A 与外延(Canva MCP、ffmpeg、Hermes、Skool、Substack 等)。

解决三个具体场景:从”AI 只会给建议”升级到”AI 真的去关单、改 Airtable、发 Slack”;把”人审 AI”换成”AI 审 AI”以避免 maker 自评偏袒;把临时 /goal 命令升级到 Routine 让循环在云端按计划跑,关电脑也能继续。

认知与实操偏实操——每节都给出可直接复制的 prompt 模板与 Routine 配置步骤,而不是抽象架构;如果只想了解”循环工程是什么”的概念,看 2026-07-03-11分钟掌握AI循环工程 11 分钟那篇更省时间。

与 2026-07-03-11分钟掌握AI循环工程 重叠:都讲循环工程六件套;本片独有 /goal 的 stop hook + Haiku 检查器机制、目标三件套写法、Cloud Environment 装 API key、maker+checker 两条 routine 的云端落地、Q&A 段对工具栈(Canva MCP/ffmpeg/Hermes/Substack/Skool)的实操判断。

自检问题

1. 循环工程和”人手动给 AI 下 prompt”的核心区别是什么? 答案:循环工程让另一个 AI 替你审 AI、替你决定下一步,人从循环里被拿掉变成系统设计者,详见 详解1。16:44
2. maker 与 checker 为什么必须是两个不同的 agent,而不是同一个 agent 审自己? 答案:同一个 agent 审自己的活会天然偏袒(“the first agent is just biased and will lie to you”),需要立场独立、专门挑刺的另一个 agent 才能给出可信判断,详见 详解6。24:34
3. Claude Code /goal 命令的底层机制是什么?checker 默认用哪个模型? 答案:/goal 是 stop post hook 上的一个 wrapper,每轮 turn 结束后调一个便宜模型(默认 Haiku)问”目标条件达成没”,没达成就给 maker 反馈继续;达成则停,详见 详解8。39:12
4. 一个好 /goal prompt 的三件套是什么?为什么”stop after N turns”是必需的? 答案:三件套 = 清晰终态(可数/可测)+ 验证手段(checker 在日志里能看到证据)+ 护栏(禁止动作 + stop after N turns 止损);“stop after N turns”是防止 prompt 写歪导致循环无限空转的安全网,详见 详解10。50:30
5. Claude Code Routine 和 /goal 命令的差别是什么?Routine 跑在哪里? 答案:/goal 必须人坐在屏幕前启动,Routine 把循环保存下来放在云端按计划或事件自动跑(关电脑也能继续);Routine 还支持挂 skill、装 Cloud Environment 的 API key,详见 详解11。52:11
6. Cloud Environment 解决了 connector 的什么局限? 答案:有些 connector 的 MCP 不开放关键能力(如 Intercom MCP 不能关单、API 可以),Cloud Environment 让你把 API key 注入 routine,直接调 REST API 兜底,详见 详解12。64:04
7. Sabrina 的”AI 杠杆 = 技能 × 清晰度”指的是什么?为什么它比”会不会写 prompt”更根本? %%答案:你能从 AI 拿到的杠杆取决于你自己的技能(能不能审 AI 的活)与清晰度(能不能把”什么叫好、什么叫做完”定义清楚);堆 prompt 不如先把”好”的判据写明白,详见 详解14。71:07