AI 写代码越来越快 慢下来的那个人变成了我
一次协作中的卡顿让我意识到，瓶颈已从代码能力转向反馈速度——AI的生成速度远快于人类的指令调整节奏。
它用远超预期的速度完成了页面搭建。
例如接到活动页需求时，过去我习惯逐步推进：先让 agent 搭出基础版，再补一句“这里加个按钮”；按钮出现后，又要求“文案换一下”；样式偏移时再让它调整。它做一版，我看一版，再推它向前一步。
当 AI 能够快速搭建页面、修改组件、执行构建并读取报错时，“我推一下，它走一步”的模式开始失效。并非它变慢，而是我的反馈速度跟不上。我需要持续判断：下一步该如何拆分？指令是否足够清晰？是否该让它继续？
瓶颈从“它能否编写代码”转变为“我该依据什么让它继续编写”。
我对 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 连接真实环境，sub-agent 拆分角色，memory 记录状态。它们能让 Loop 运行起来，但无法保证方向正确。
这些组件都很重要，但决定 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的深层价值。