吴恩达犀利解读Loop Engineering

Andrew Ng 对 Loop Engineering 的洞察，这次确实触及了问题的根本。

上午他在 X 上发布了一篇长文，分享了自己近期的判断，读后令人深受启发。

从行业趋势来看，过去大家讨论 Loop Engineering，更多还是局限于工程循环本身——比如 Agent 如何自动编码、如何自我调试、如何修复问题。但 Andrew Ng 把这个概念扩展到了更广阔的层面，格局一下子打开了。

他的核心论断是：当 AI 能够自主生成代码之后，真正发生变化的不是工程效率本身，而是整个软件开发开始变成三种不同时间尺度的循环同时运转。

最内层是 AI 自身持续迭代代码，中间是开发者不断修正产品方向，最外层则是真实用户和市场环境持续修正开发者的判断。这三个循环，一层比一层慢，但也一层比一层关键。

Agentic Coding Loop：AI 自主运行的工程闭环

最内层，就是现在大家最熟悉、也最爱用来演示的那部分：AI Agent 自己编写代码。

实现方式其实并不复杂。给它一份产品需求文档（Spec），再配上一套评测标准（Evals），Agent 就能自主行动了——编写代码、运行测试、发现问题继续修改，改完再测，一圈一圈地迭代，直到基本符合规格、没有明显缺陷为止。

Andrew Ng 举了一个近期的例子。他周末想给女儿做一个练打字的小程序，让 Agent 连续工作了大约一个小时。期间 Agent 还自己打开浏览器，把刚写好的页面反复点开查看了好几遍，确认没问题才回来汇报。整个过程他几乎无需干预，不用像以前那样每隔几分钟就得手动点击重试。

Agent 已经能够独立验证自己的输出结果了。

过去的代码生成更像是单次交互——问一句给一段，人得一直盯着。本质上还是人在掌控方向，AI 负责加速。但当编写代码、运行测试、发现问题、继续修改这个闭环真正运转起来之后，Agent 就从一个问答工具，转变成了一个能够持续自我纠偏的微型系统。

这正是过去一年 AI 编程生产力大幅跃升的重要原因。模型能力当然在进步，但真正拉开差距的，是 Agent 学会了自我检查、自我验证。

而且这一层循环远未定型。如何编写更智能的测试，如何搭建更顺畅的自动调试链路，如何让 Agent 在一小时的持续工作中少走弯路，这些都还是今天大家不断探索的课题。

不过，Loop Engineering 运转得再快，它始终无法回答一个根本问题：究竟应该写什么。Agent 可以不断优化答案，却不知道什么才是真正需要解决的问题。

产品方向、需求边界、哪些功能值得做——这些决策仍然来自人类。这也就是第二层循环存在的理由。

Developer Feedback Loop：开发者负责校正方向

第二层循环的主角重新回到了人身上。

和第一层最大的区别在于：第一层里，人可以离开，Agent 自己能独立运转；第二层里，人不能离开，因为这一层承担的是判断与决策。

开发者在这里已经不是替 AI 查找 Bug 了，那些工作 Agent 自身已经完成得越来越好。人开始做更上层的事情：确定功能范围，调整 UI 与交互，重新构思信息组织方式，看完 Agent 做出来的第一版之后，再回头修改最初的 Spec，甚至完全推翻重来。

Andrew Ng 提到，去年这个时候，包括他自己在内，很多开发者其实都在给 Agent 当 QA——自己测试产品、找 Bug，再让 Agent 去修复。一年过去，Agent 自测和自我修复能力越来越强，人花在挑错上的时间显著减少，精力自然开始向更高层的产品判断转移。

在打字 App 那个案例中，他真正花时间做的是反复调整视觉风格，考虑女儿能解锁哪些猫咪皮肤（她喜欢猫），重新设计家长登录和监督学习进度的完整流程。这些都是方向性的决策。

这一层循环的节奏，大概是几十分钟到几小时。开发者隔一段时间回来审视当前版本，再决定下一步往哪个方向走。

真正困难的地方，在于把脑子里一个模糊的想法，转变成 Agent 能够执行的 Spec。而且很多时候，Spec 并不是一开始就能写好的。越来越普遍的真实过程是：先写一个比较粗糙的 Spec，让 Agent 做出第一版，看完之后才意识到自己真正想要的是另一种东西，于是回头继续修改 Spec，再继续生成。如果某类问题反复出现，这时候再补充一套 Evals，作为后续自动迭代的质量锚点，省得每次都需要人工盯着同一个坑。

这里有一个值得细品的关键判断：Andrew Ng 认为，很多人喜欢说人类在产品上的优势来自“品味”，但他更愿意将其理解为“上下文优势”。因为品味听起来很玄，但上下文可以拆开来看——用户是谁、业务边界在哪里、有哪些约束条件、竞争对手在做什么。这些信息目前仍锁在人脑中，AI 并不知道。

因此，只要人类还掌握着 Agent 不知道的上下文，人就必须留在这个循环里，把这些信息一点一点地补给系统。

不过，开发者的判断再好，也始终有一个局限——它终究还是基于自己的想象。真正的用户会怎么使用，市场会如何变化，竞品昨天是否刚发布了一个新功能？这些情况，只有产品真正进入真实世界之后才能知晓。

于是，就迎来了第三层循环。

External Feedback Loop：来自真实世界的慢反馈

第三层循环发生在产品之外。

例如找几个朋友试用一下，收集真实反馈；邀请一批 Alpha 或 Beta 用户；或者直接上线，通过 A/B 测试和后台数据观察用户行为。这些方法都有一个共同特点：慢。

很少有几小时就能看到结果的，更多时候要等几天，甚至几周。相比前两层以分钟和小时为单位高速运转，这一层几乎像静止一样。

但偏偏，它承担着最重要的纠偏任务。因为前两层都发生在系统内部——Agent 按照 Spec 编写代码，开发者按照自己的理解修改 Spec，但两者都没有真正接触真实用户。

用户能否理解你的设计？市场是否已经发生了变化？竞争环境有没有改变用户预期？这些问题，没有任何人能够坐在办公室里想出来。只能放到真实世界中，才能获得答案。

而且，这一层反馈不会直接修改代码。它会先回到开发者的脑子里，修正开发者对产品的整体判断（Vision）。开发者再根据新的判断调整 Spec，最后交给 Agent 去执行。

三层循环，就是这样串联起来的。最慢的一层提供信号，中间那层负责判断，最快的一层负责执行。

从行业趋势来看，这也是 AI 正在悄然改变工程师角色的地方。随着 Agent 把开发速度不断推高，越来越多的工程师开始承担一部分产品经理的工作——一头要把模糊的 Vision 翻译成 Agent 能执行的 Spec；另一头要不断听取真实用户的反馈，再回过头修正自己的 Vision。

AI 并没有消灭软件开发中的循环，它只是把最里面那层循环压缩到了几分钟。于是，软件开发真正稀缺的能力，开始越来越向外层迁移。

真正困难的是：想清楚究竟要解决什么问题，把一个模糊的想法不断修正成 Agent 能执行的 Spec，再持续从真实世界获取反馈，修正自己的判断。

这三层循环，一层比一层慢，也一层比一层重要。缺少任何一层，一个真正的从 0 到 1 的产品，都很难顺利运转起来。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：吴恩达犀利解读Loop Engineering要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题