转一下，这篇文章非常不错，来自吴恩达老师对 Loop engineering 的解读。

随着 Boris Cherny（Claude Code 作者）和 Peter Steinberger（OpenClaw 作者）在社交媒体上对 Loop engineering 的提及走红，它现在已经成为一个热门的流行词。

循环（Loops）如今是我们让 Agent 进行长时间迭代，来构建软件的关键部分。

我想分享我用于构建“从 0 到 1”产品的 3 个关键循环，这些循环不仅指导我如何构建软件，也指导我决定要构建什么软件。

1、智能体编码循环。

给定一个产品规范以及可选的一套评估标准，我们可以让 Agent 编写代码、测试其工作并不断迭代，直到代码没有漏洞并符合规范。

这种闭环的理念在去年年底左右开始兴起，它彻底改变了游戏规则，使得编码智能体能够在没有人工干预的情况下高效地工作更长时间。

例如，上个周末，我在为我女儿开发一个练习打字的应用程序，我的编码智能体可以轻松地持续工作大约一个小时，期间它多次使用网络浏览器检查自己构建的内容，然后才向我汇报，完全不需要我的干预。

这种工程循环执行得非常快，每隔几分钟，编码智能体可能就会构建并测试一个新版本的软件。

我经常听到开发者们说，他们正在寻找新的方法来设计更高效的工程循环，这是一个非常活跃的创新领域。

2、开发者反馈循环。

在这个循环中，开发者会检查当前的产品，并引导编码智能体对其进行改进。去年，许多开发者都在为编码智能体充当 QA 的角色，手动寻找 bug，然后要求智能体修复它们。

但随着编码智能体测试自身代码的能力大幅提升，我们需要在这项工作上花费的时间已经显著减少。

这让我们能够做出更高层级的产品决策，比如提供哪些关键功能、UI 哪里需要改进等等。

开发者反馈循环的时间间隔，通常在几十分钟到几个小时之间，这大概就是一位开发者审查产品并给出反馈的频率。

在开发那个打字应用的例子中，我多次改变了关于视觉设计的想法：比如她在学习时可以解锁哪些猫咪装扮，以及成年人登录并引导孩子学习体验的用户流程。

当开发者对要构建的产品有清晰的愿景时，将这种愿景转化为编码智能体可以执行的规范仍然需要大量的工作。

此外，在开发者看到实现效果后，他们可能会更新规范，以引导系统朝着他们想要的方向发展。如果你发现系统反复遇到某些特定问题，为智能体构建一套评估标准就会变得很有用。

AI 原生团队正越来越多地使用 AI 来帮助塑造产品方向，例如，自动收集和分析使用数据、总结书面和口头的客户反馈，或者进行竞品分析。

然而，对于我参与的几乎所有产品来说，我认为人类相较于当前的 AI 系统仍具有显著的上下文优势。

我们比 AI 系统更了解用户以及产品必须运行的背景环境，因此人类发挥着至关重要的作用。

许多人将人类的这种贡献描述为品味，但我更愿意将其视为人类拥有上下文优势，因为这为我们提供了一条帮助 AI 系统变得更好的更清晰的路径。

这也解释了为什么这一步无法完全自动化，只要人类知道某些 AI 不知道的事情，就需要“人在环路”将这些知识注入到系统中。

3、外部反馈循环： 这包括广泛的策略，比如向几个朋友寻求反馈、向内测用户发布，或者将代码投入生产环境进行 A/B 测试。

这些策略通常很慢，很少少于几个小时，有时甚至需要几天或几周。这些数据会为开发者的愿景提供信息参考，进而继续驱动详细的产品规范，最终再次驱动编码智能体。

随着编码智能体加速软件开发，越来越多的工程师开始部分地扮演起产品经理的角色。

对于许多正在向这个角色成长的工程师来说，最困难的部分是塑造产品愿景，并在“构建”（弥合愿景和规范之间的差距）与“获取用户反馈以演进愿景”之间取得平衡。兼顾这两者非常重要。

我将在未来的文章中撰写更多关于如何做到这一点的内容，但就目前而言，工程师们正在发挥越来越大的作用（就像产品经理和设计师现在也做更多的工程工作一样），这让我感到十分振奋。

#HOW I AI##科技先锋官#