我第一次觉得自己有点跟不上 AI，不是因为它写不出代码。
是因为它写得太快。
比如接到一个需求，要做某个活动页。以前我习惯一步步来：先让 agent 搭一版页面，有问题再补一句"这里加个按钮"；按钮出来了，再说"文案换一下"；样式歪了，再让它调样式。它做一版，我看一版，再推它往前走一步。
AI 慢的时候，这种方式还行。可当 agent 能很快搭页面、改组件、跑构建、读报错时，"我推一下，它走一步"就开始别扭了。不是它慢，是我这边的反馈跟不上。我得不断判断：下一步该怎么拆？这句话够不够清楚？要不要让它继续？
瓶颈从"它会不会写"，变成了"我该让它根据什么继续写"。
我对 Loop Engineering 产生兴趣，就是从里开始的。
第一次看到这个词时，我有点焦虑，也有些烦。这两年 AI 圈的新词太密了，从 Prompt Engineering 到 Vibe Coding，再到 Context Engineering、Harness Engineering，一波未平，一波又起。现有的理念还没完全吸收，新的理念就已经迫不及待冲出来。
这两周我看了很多文章，也做了一些尝试。越想越觉得，Loop Engineering 最值得讨论的地方，不是"怎么让 AI 多跑几轮"，而是：这一轮反馈到底能不能改变下一轮行动。。
如果反馈不能改变下一轮行动，它只是一个被拉长的 prompt。
如果反馈能改变下一轮行动，并且知道什么时候该停，它才更接近我理解里的 Loop。
什么是 Loop
现在大家说 loop，很多时候指的是让 AI 自己循环起来：写代码，跑测试，读报错，再修一轮；或者让 agent 围着一个目标持续执行，直到任务完成。
这和以前的"遥控器式协作"不太一样。
过去更像是：
你 → 提示 → Agent → 输出 → 审查 → 重新提示 → 修正 → 重复
loop 更像是：
目标 → 行动 → 反馈 → 调整 → 再行动 → 停止或交回人
你不再逐步下达每一个指令。你先把目标和验收方式说清楚，让 agent 自己重复这个周期：发现问题，想一个小计划，改一轮，验证一下，再根据结果继续。这样一来，一部分重复的观察、规划、执行和验证就交给 Agent 了，我不用每隔几分钟回来按一次"下一步"。
本文说的 Loop，要求再高一点：它要能根据模型外的反馈更新计划、状态或行动方式，并在条件满足或风险升高时停下来。普通的 while-loop 和定时任务不算。
拆开看，它至少需要四件事：
- 触发：什么情况下开始这一轮？
- 行动：agent 可以做什么？
- 反馈：它根据什么判断做得对不对？
- 停止：什么时候继续，什么时候交回给人？
Addy Osmani 在博客里讲到 Loop 有几个常见组件：automation、worktrees、skills、plugins/connectors、sub-agents。每个组件都是必需品，但我更愿意把它们看成搭建 loop 的材料，而不是 loop 本身。
Automation 负责触发，worktree 隔离代码改动，skill 写项目规则，connector 让 agent 接触真实环境，sub-agent 拆分角色，memory 记录状态。它们能让 loop 跑起来，但不能保证方向是对的。
这里也要留一点冷水：worktree 只能隔离文件，隔离不了数据库、缓存和云资源；skill 是指导，不是强制约束；sub-agent 只有在看独立证据时，才可能减少自证；memory 如果不审计，也会把错误假设存下来。
这些组件都重要。但决定一个 loop 靠不靠谱的，还是反馈。
Loop 不难，难的是反馈
最初我以为，Loop Engineering 的难点是怎么让 AI 多跑几轮：没达到目标就继续，直到 Agent 接近目标。
后来发现，让它多跑几轮太容易了。写个脚本，设个 cron，或者给 agent 一句"继续直到完成"，它就能一轮接一轮地跑下去。真正麻烦的是，它每一轮到底在根据什么改变自己。
如果只是根据上一轮它自己写出来的东西，我觉得有些不靠谱。Agent 在缺少模型外反馈的时候反复执行，常常会把一开始的误判包装得越来越完整。它会补计划、补解释，甚至补代码，最后给你一个看起来很努力的错误结果。
这也是我一开始对 loop 最警惕的地方。它听起来很像把"再想想"自动化了。真正有价值的 loop，应该要让模型不断撞到真实世界，再被真实世界推回来。
代码为什么适合先做 loop？因为代码天然有反馈。
测试能不能过，lint 报什么错，构建有没有失败，浏览器里的按钮能不能点，接口返回是不是符合预期，这些反馈都够硬，也够快。它们不需要我坐在旁边一直说"这里不太对""再调一下"。Agent 可以自己跑，自己读，自己修。
但这也带来另一个问题：不是所有反馈都一样可靠。
比如我让 agent 做一个部署日志查看器。接口测试通过了，只能说明查询能返回数据；页面截图正常，只能说明它渲染出来了；筛选条件生效，只能说明逻辑没写反。但是产品好不好用，值班同事能不能更快定位问题，代码级别的反馈就无法做到了。
我后来意识到，反馈是有距离的。
离代码越近，反馈越快越有效。测试过没过，构建报没报错，都是秒级的事。离用户越近，反馈就越慢、越模糊。一个指标涨了，你说不清是因为产品真的更好，还是入口变显眼了。
Loop Engineering 要设计的是一套判断方式：agent 该相信哪一种反馈，相信到什么程度，什么时候继续，什么时候停下来。
判断一个 loop 靠不靠谱，我现在会先问五个问题：
- 这一轮目标是什么？
- 反馈从哪里来？
- 这个反馈离真实结果有多近？
- Agent 能不能读懂并使用这个反馈？
- 什么时候必须停下来交给人？
如果这五个问题答不上来，我就不太愿意把它叫 Loop。它更像是把一个 prompt 拉长成十个 prompt。
反馈其实有三层
吴恩达最近的博客里，把 AI 产品开发里的反馈分成三层：代码反馈、开发者反馈、外部反馈。这与"反馈距离"的想法不谋而合。
第一层是 Agentic coding loop，也就是代码反馈。
给出 spec、测试方法和可执行环境，Agent 从测试、构建、lint、浏览器检查里获得反馈，再开始下一轮修改。这个循环最适合交给 agent 自己跑，因为反馈快、明确、可重复。
这也是 Agentic Coding Loop 的意义。Agent 生成代码，也在一个短反馈循环里逼近规格。
| 过去 | 现在 |
|---|---|
| 手动写大量代码 | 定义清楚规格 |
| 人工反复查低级 bug | 让 Agent 自测、自修 |
| 把 AI 当代码补全 | 把 AI 当能执行循环的工程助手 |
| 重点是会不会写代码 | 重点是会不会设计验收标准 |
这里有一个很重要的词：eval。如果 agent 总在同一类地方犯错，最省力的做法是把"它经常错在哪里"变成可测试、可重复、可反馈的标准，而不是每次骂它一句"你又忘了"。
当然，eval 不是所有反馈。它更像反馈里可重复、可执行、可比较的那部分。单元测试是 eval；值班同事说"字段太多"先是反馈，只有沉淀成"首屏只展示 P0 字段"这类规则后，才更接近 eval。
AI coding 最怕的不是模型不会写。没有规格、没有验收、没有能反复使用的反馈，Agent 跑得越快，偏得也越快。
第二层是 Developer feedback loop，也就是开发者反馈。
这一层比代码慢，但更接近产品判断。测试可以告诉我某个按钮能不能点，却不能告诉我这个按钮该不该存在。测试可以证明字段都展示出来了，却不能证明这些字段是否有用。
当 agent 能测试自己的代码后，人就不该继续只做低级 QA。人的价值要往上挪：判断功能该不该有，UI 该怎么改，产品到底应该长什么样，而不是盯着每个小 bug。
这些不只是代码问题。它们是产品问题，也是人的上下文问题。很喜欢吴恩达提出的 context advantage 理念。人的价值来自那些 AI 不知道的上下文：谁在用，什么时候用，为什么急，真实流程是什么，哪些抱怨值得信，哪些只是因为入口藏得太深。
Human-in-the-loop 如果只是人盯着 AI 干活，那就太浅了。真正重要的是，人要把这些上下文翻译成 Agent 能执行的规格、反馈和 eval。
第三层是 External feedback loop，也就是真实用户反馈。
这一层最慢，周期可能是小时、天，甚至几周。比如找同事试用，上线一小部分流量，看真实使用数据，听客户访谈，做 A/B 测试。这些都不像测试报错一样干净。一个指标涨了，可能是产品真的更好，也可能只是入口变显眼了；同事说某个 tab 没用，可能是真没价值，也可能是他根本没找到正确用法。
这个循环慢，但它最残酷，也最接近真实结果。开发者很容易骗自己，Agent 也很容易骗你，真实用户反馈最混杂，却最难绕过去。页面能跑，不代表用户想用。功能再多，路径不顺，也只是一个更好看的 demo。
三层反馈连起来，大概是这样：
开发者判断 → 产品 spec → coding agent → 可用产品 → 开发者反馈 → 外部反馈 → 更新后的判断
AI 很擅长加速从 spec 到可用产品的代码阶段。但只有在任务边界清楚、改动可回滚、反馈覆盖关键路径、权限受限的时候，Agent 的执行结果才适合交给自动循环处理。工程师的角色也会跟着变：不只是实现者，还要定义目标、判断反馈、最后拍板。
有人把这种协作比作一个 AI 三明治模型：人类是两端的面包，AI 是中间的馅料。面包决定这是什么三明治，馅料只是填充。开始阶段是定义问题、设定边界；结尾阶段是打磨细节、做最终判断；中间大量执行、测试和迭代，可以交给 agent。
什么任务值得做成 Loop
理解了反馈以后，Loop Engineering 的边界也清楚了一些。
简单任务不需要 loop。改一个小函数，写一段普通文案，查一个明确问题，直接 prompt 就够了。硬要做成 loop，就是杀鸡用牛刀。
Loop 更适合目标会变化、过程要验证、结果需要多轮反馈的事情。比如复杂功能开发，需要测试、lint、构建、浏览器检查一起兜底；长期维护任务也可以，因为它会定期发现问题；0 到 1 产品也可以，但前提是你不能只让 agent 在代码里勤奋地打转。
我现在会把边界划得粗一点：
反复让模型"再想想"，不算 loop，因为没有模型外反馈。
只会定时执行的脚本，也不算 loop，因为它不会根据结果改变下一轮行动。
确定性的路由、批处理、表单校验，通常用 workflow 就够了。它们不需要 agent 自己判断，稳定比聪明重要。
一个最小可用的 loop，不需要一上来就集齐全套工具。把前面四件事说清楚就行：什么触发它，它能做什么，它从哪里拿反馈，它什么时候停。
状态也可以先写得很朴素。一个 loop-state.md，一个 issue comment，一段 PR 描述，都比让 agent 把所有状态憋在上下文里可靠。
停止条件尤其要提前写清楚：连续失败两次就停，改动范围扩大就停，成本超过预期就停，问题从"代码是否正确"变成"产品方向该不该这样"也要停。
会停，是 loop 可信的一部分。
Loop 会把错放大
Loop 听起来很美妙，但它既会放大能力，也会放大误判。
最常见的一种失败，是 AI 不收敛。Agent 修完一个报错，又引入两个新报错，再修新的报错。AI 一直在工作，日志也一直在滚，实际上只是换着姿势原地打转。
第二种更麻烦，是反馈本身错了。
如果部署日志查看器的 eval 只检查"字段都展示出来"，agent 就可能把二十个字段全塞到页面上。测试全绿，截图也完整，但值班的人更难用了。系统会稳定地把错误目标做完整，这种失败比直接报错更难排查。
第三种是越跑越忘。Loop 跑久了，早期约束被挤出上下文，错误假设被写进计划、状态文件和下一轮 prompt，最后变成"系统记住了一件错事"。这时候继续循环，就是在给错误加固。
还有一种是 agent 会学会迎合 eval。为了让截图检查通过，把按钮做得更大；为了让测试通过，补一个最窄的分支就收手。反馈如果太表面，agent 就会优化表面。
所以 Loop 需要可观测性。你需要记录为什么继续，为什么停止，为什么相信某个反馈。没有日志、trace、状态记录和每轮决策摘要，失败以后你找不出是哪一次反馈把方向带偏了。
这也是我现在不太相信"让 agent 自己一直跑就好"的原因。一直跑不是能力，知道什么时候停才是。
Prompt 管输入，Loop 管校正
想清楚这些以后，我反而不觉得 Prompt Engineering 过时了。
Prompt 仍然重要。把任务说清楚，给足上下文，定义输出格式，这些都不会消失。只是当 agent 能连续工作更久以后，问题从"一次输入写得好不好"，变成了"整个过程能不能被反馈校正"。
Prompt 更像起点，Loop 更像校正系统。
一个每天早上扫 issue 的脚本只是 automation。更接近 loop 的做法是：读昨晚失败的 CI、最近合并的 commit 和未关闭的 issue，发现登录测试连续失败三次，就把上下文写进状态文件，开一个独立 worktree 让实现 agent 去修；另一个 review agent 只看 diff、测试结果和项目规则，不继承前一个 agent 的自我解释。通过了就开 PR，没通过就把失败原因写回状态。
这套东西听起来复杂，但核心其实很朴素：让反馈进入状态、计划和验收标准，而不是停在聊天记录里。
也正因为如此，loop 不能用来逃避理解。它能替你跑很多步骤，但不能替你决定什么反馈值得信；能把代码问题暴露得更快，也能把产品误判执行得更完整。
当 loop 接管更多执行步骤，工程师的职责也会往上移。很多重复步骤不再需要我频繁操作，但一些关键问题反而更需要我介入：目标怎么定，反馈信不信，默认策略偏向谁，什么时候继续，什么时候停。
更具体地说，工程师要把自己的上下文优势翻译成反馈系统：把模糊目标写成可执行 spec，把常踩的坑变成 eval，把项目规则沉淀成 skill，把工具权限设计到 agent 不容易误用，把用户反馈翻译成下一轮开发方向。
这不是说工程师不再负责实现。只是实现之外的判断变重了。你要知道什么时候放手，什么时候握紧方向盘。
慢下来也有慢下来的位置
回到最开始那个感觉：AI 写代码越来越快以后，慢下来的那个人确实变成了我。
一开始这件事让我有点难受。好像工具越快，人越来越拖后腿。可写着写着我发现，这不一定是坏事。
以前慢在实现，慢在查 API，慢在一行行改文件。现在这些慢正在被 agent 吃掉。新的慢，更核心的时间留给目标、反馈和判断。该不该做，做到什么程度算好，哪类反馈可信，什么时候继续，什么时候停止。
就像三明治模型一样，要学会做这两端的面包，找到属于自己的独特时刻，然后用 agent 去放大它。
现在更愿意这样理解 Loop Engineering：它比 prompt 技巧重得多，是一种把 AI、人和真实用户放进不同时间尺度里持续校正的方式。
AI 快起来以后，人慢在判断上。这不是退步，只是工作重心换了地方。
别急着追 Loop。先想清楚，在当前的系统里，反馈到底能不能进入状态、计划和验收标准。