原创 Capihom 2026-06-15 21:27 北京

“除非你有钱可烧，否则别这么干。”“人留在环里，仍然是最好的 loop。”“代码评审能跑 loop，因为它有固定反馈。”

当市场被 Boris、Peter 和各种演示视频带得热血上头时，多数人手里的订阅预算、产品定义能力和反馈机制，其实都还撑不起那种一键放手的闭环。这场访谈的编排很照顾实操顺序：开篇先讲 loop 到底是什么，中段拆解为何 /goal 模式如此烧钱，后半段则拿出一条今天就能跑起来的代码评审链路。其中最值得关注的是，嘉宾 Mic 把 human-in-the-loop、agentic loop 和代码评审 loop 拆成了三种截然不同的工作方法。工程师、产品经理、独立开发者看完，应该能立刻判断自己该在哪一步把手伸回方向盘。

人人都在说 loop，先把两种工作流画清楚

Mic 开篇先画了一张最朴素的图：普通人平时的 AI 开发流程，是在 Cursor、Claude、Codex 里下指令，让袋里想做 landing page，再做登录，再接后端。landing page 做完，你得先看看 waitlist 页面能不能见人；登录接好，再决定要不要继续推进数据库、权限或邮件通知。每一步结果出来，你亲自去看、去测、去改，再决定下一步往哪走。这套节奏里，AI 的速度当然重要，但决定成败的，仍然是那个一直盯着方向、边界和取舍的人。他把这叫作 human in the loop——袋里想在建，但由你来指挥、治理和批准。

另一种被热捧的 agentic loop，则是人只进场一次：你把 spec.md、prd.md 或任务单丢进去，袋里想生成结果，再把结果喂回自己，继续往前跑。Mic 指出，这听上去像未来，因为人像点火的人，机器像自动巡航系统。但两者真正的差别不在于“有没有 AI”，而在于反馈链条由谁持有。这一步没想清楚，后面的争论都会变成各说各话。

spec.md 一交出去，假设也一起外包了

Mic 给了一个很直白的类比：假设你和合伙人正在做创业项目，招了一个很聪明的开发，把产品需求讲完以后，就让对方自己把整套东西做完，中间一句都不回头确认。开发一定会替你补全很多细节——界面怎么摆、流程怎么走、架构怎么选。问题不在于对方不努力，而在于这些补出来的细节，常常对不上你脑子里的产品轮廓。你以为计划文档已经覆盖了一切，但事实是永远不会。

映射到 loop 上：当你把一摞 markdown 文档交给袋里想，让它在结果上继续叠结果，袋里想也会自己“补假设”。产品里最容易偏掉的，恰恰是那些没人写进文档的缝隙：按钮文案、错误路径、权限分层、极端输入、移动端细节。Mic 还提到一个服务团队非常熟悉的场景：哪怕你已经和客户反复开会，最后上线前依然会听到一句“我想的是另一种意思”。一旦 loop 拥有了“自己决定”的空间，速度会上去，但偏航概率也会上去。这也是 Mic 反复提醒的第一层风险。

/goal 热归热，20 美元套餐先别上车

主持人 Greg 追问得很具体：最近最火的 /goal 算不算 loop？Mic 回答得非常干脆：名字再多，本质都一样。你给它一个大任务，附上文档，要求“别停，做完，别出错”，它就会开始自驱工作，并在每一轮把上一次的产物继续当成下一轮输入。但 Mic 首先拦住的是成本账——如果你还在 20 美元或 100 美元档位，光是让它多跑几轮，就可能把当月额度烧穿。他点名提到 Ralph loops、slash loop 之类的玩法，意思都差不多，烧钱速度也差不多。“如果你不在 200 美元月付档，连想都别想。”

更麻烦的是，用户会被“自动完成整个产品”这层叙事迷住，以为自己只差一份更完整的 PRD。Mic 说，现实正相反：你今天觉得完整的文档，明天就会因为设计趋势、用户反馈、业务目标变化而失效。节目里还提到 Peter 一个月烧掉 130 万美元 token 的例子——那更像是前沿实验预算，而不是大多数人该复制的工作方法。预算有限的人最该提防的，就是被自动化的幻觉带进一笔本可避免的 token 账单。

小工具和原型能放手，正式产品别放任

Mic 并没有把 loop 一棍子打死。他举了自己做 Among Us 模型模拟器的小项目：他只想要一个能跑的 benchmark，用来测试哪种模型更会撒谎，不在意交互是否精致，也不在意页面长什么样。于是他把目标交给 loop，放手让它跑了大约一个半小时。很多细部都偏了，但项目依然达成了目的。那次任务里，他根本没打算把产品推给真实用户，也没打算花时间抠视觉和文案。当你只想要一个能用的实验体，而不追求成品感，loop 的确能替你省掉不少机械工。

但只要你开始做有真实用户、有品牌感、有细部取舍的产品，Mic 的态度就立刻收紧。因为用户真正买单的，往往是那些微小的判断：入口顺序、页面密度、动线停顿、描述语气、异常情况的收口方式。这些地方最像手艺活，最依赖人的口味和上下文，也正是 loop 最容易用“差不多”糊过去的地方。所以他承认 loop 有用，但只愿意把它放在失败成本很低的地带。

真能每天跑的闭环，是 GitHub 里的代码评审

Mic 自己每天真正在用的 loop，不在产品生成，而在代码评审。他用 Cursor 做主工作台，用 GitHub 做版本控制，再在 GitHub 里装一个代码评审 agent。他选的是 Greptile，也顺口提到了 Code Rabbit、Microscope 这类同类工具。每次 feature push 上去，评审 agent 都会回一轮 review，指出安全边界、遗漏的 edge case、潜在 bug。Mic 说他最喜欢的并非长篇评论，而是那个 5 分制打分——它把“代码到底能不能放行”变成了一个更清晰的判断。和一键做产品相比，这一层天然多了一个外部评分器。

Mic 给自己定的上线门槛很直白：分数不到 4/5，代码就不进生产。于是 loop 的目标不再抽象——它只需要读懂 review、修掉问题、重新 push、等待新一轮打分。当目标被压缩成“把分数拉高”这类可衡量任务时，loop 不再像一辆没人看路的列车，更像一个围着明确信号灯打转的自动工位。

Greptile 打分以后，Cursor 才知道下一轮改什么

Mic 把这套流程包进了一个叫 grep loop 的 skill。它做的事情并不玄：去 GitHub 读 Greptile 的 review，把缺陷拉回 Cursor，根据建议修代码，再 push 回 GitHub。只要分数还停在 2/5、3/5 或 4/5，它就继续转，最多五轮，或者一路修到 5/5 为止。每一轮的目标都很窄，袋里想不用重新理解整个产品愿景，只需要盯着 review 里指出的那几条问题去修补。这里的闭环更像袋里想在返修：它围着别人已经给出的反馈“补作业”。

这也是 Mic 判断 loop 能否落地的标准：它有没有固定反馈引擎。代码评审里，GitHub review 就是那个引擎；SEO 批量页里，公式和模板也能承担类似的职责。可一旦任务变成“做一个用户愿意留下来的新产品”，反馈源就会从一个分数器变成一堆模糊的人类感受。用户会不会在 onboarding 第三步流失？付费墙是不是出现得太早？按钮文案会不会把人劝退？这些都要靠真实使用和回访才能知道。没有外部信号给方向，loop 跑得越勤，返工概率往往越高。

超过 1000 行，连好用的 loop 也会失真

Mic 还专门补了一句让人很清醒的话：哪怕是他最认可的代码评审 loop，也不是无上限好用。只要一次提交超过 1000 行，Greptile 往往就很难把上下文吃透，他几乎拿不到 5/5。回到工程现场这很好理解：改动面一大，依赖关系、边界条件、回归影响都会暴涨，任何评审 agent 都会开始抓不稳重点。Mic 自己也承认，这时候哪怕模型还在认真工作，review 的噪声也会上升。闭环体积越大，误差越容易堆起来；很多场景收小以后反而更准。

所以 Mic 的做法也很工程化：把大的改动拆成多个 PR，让 Cursor 分批推，给 Greptile 留出足够可读的粒度。一个登录改动是一批，一个账单改动是一批，必要时连数据库迁移都单独拆出去。这里能看出一个很实际的判断：你没必要追求“一个 loop 干完所有事”，更成熟的用法是给不同环节配不同大小的循环。loop 可以是生产力工具，前提是它先服从你的拆分策略，你的工作节奏也要围着可验证粒度来设计。

全自动做产品还太早，先把人放回驾驶位

主持人 Greg 在后半段给了一个很形象的比喻：很多创业者想像的 loop，就像从迈阿密一路开到查尔斯顿的全自动驾驶，中途没有机会临时靠边、进去一家小餐馆、跟用户聊几句，再根据反馈改路线。产品开发恰恰需要这些“中途停车时刻”：把东西发给人看，收回吐槽，改掉误判，再决定还往不往前冲。少了这些回头看的站点，loop 很容易把你送到一个“代码完成、产品没成”的终点。

Mic 并不否认未来。他明确说，长期看，完全自治的 loop 很可能会到来；Boris 和 Peter 这些站在模型一线的人，本来就在替全行业试错自愈 agent 和大规模 harness。站在 2026 年 6 月 9 日这个时间点，他愿意给出的结论只有一句：人留在环里，依然是现在最好用的 loop。对创业者来说，这是一种更现实的资源分配。无论你做的是 app、website、SaaS、micro SaaS，还是 agent-first startup，都绕不开同一件事：把有限 token 用在最值钱的地方，把用户反馈放在最前面，把方向判断握在自己手里。

写在最后

如果今天就想把 agent loop 用起来，更稳妥的落点，是先把它关进边界清楚、反馈明确、失败成本可控的环里。先把代码评审、测试、批量页面这类工作跑顺，再考虑要不要把产品方向盘交出去。一个很实用的自检方法是看三件事：有没有外部评分器，有没有明确停止条件，有没有你愿意承担的 token 上限。三样都没有，先别把它当生产流程。也可以给自己设一条更硬的线：凡是需要真实用户审美、业务优先级排序、模糊需求澄清的环节，都先别追求全自动；凡是结果能被打分、能被比对、能被回滚的环节，才值得让 loop 多跑几圈。哪怕只是把“先给 5 个用户试用、收回 10 条吐槽、再改第二版”这种人工检查点写进流程，项目最后跑偏的概率都会低很多。等把这些护栏装好，再谈无人值守，顺序会健康得多，也更省钱，团队心态也更稳，返工也更少，推进节奏通常更稳。很多时候，克制比炫技更接近交付。

内容来源："WTF Is an "AI Agent Loop"? Genius or Hype?"丨Greg Isenberg（嘉宾：Ras Mic）