吴恩达提出构建0到1产品的三个关键循环

“循环工程”（Loop engineering）如今是个热门流行语，起因是 Claude Code 创始人 Boris Cherny 和 OpenClaw 创始人 Peter Steinberger 的相关言论在社交媒体上走红。循环如今已成为我们让 AI 智能体长时间迭代构建软件的关键一环。在这封信中，我想分享我构建 0 到 1 产品的三个关键循环，如下图所示。这些循环不仅指导我如何构建软件，也指导我如何决定构建什么软件。

智能体编码循环：给定一份产品规格说明，以及可选的一组评测（即用于衡量性能的数据集），我们可以让 AI 智能体编写代码、测试其工作成果，并持续迭代，直到代码无 bug 且符合规格说明。这种闭环的想法大约在去年年底开始流行，它彻底改变了局面，使编码智能体能够在无人干预的情况下长时间高效工作。例如，上周末我在为女儿构建一个打字练习应用，我的编码智能体可以轻松工作大约一个小时，多次使用网络浏览器检查它构建的内容，然后才回来找我，全程无需我干预。

工程循环执行得很快。每隔几分钟，编码智能体就可能构建并测试软件的新版本。我经常听到开发者们在寻找新的方法来设计更高效的工程循环。这是一个活跃的创新领域！

开发者反馈循环：在这个循环中，开发者审视当前产品，并引导编码智能体对其进行改进。去年，许多开发者（包括我）都在充当编码智能体的 QA（质量保证）职能，手动查找 bug，然后要求智能体修复。但随着编码智能体测试自身代码的能力大幅提高，我们花在这一职能上的时间已显著减少。这让我们得以做出更高层次的产品决策，比如提供哪些关键功能、UI 哪里需要改进等等。

开发者反馈循环的时间间隔在几十分钟到几小时之间——这就是开发者审视产品并给出反馈的频率。就打字应用而言，我在视觉设计、她随着学习可以解锁哪些猫咪装扮（她很喜欢猫），以及成年人登录并引导孩子学习体验的用户流程上，都改过好几次主意。

当开发者对要构建什么有清晰的愿景时，将这一愿景转化为编码智能体可执行的规格说明仍然是一项繁重的工作。此外，在开发者看到实现之后，他们可能会更新（或澄清）规格说明，以将其引导向自己想要的方向。如果你发现系统反复遇到某些问题，为智能体构建一组评测就会很有用。

AI 原生团队正越来越多地借助 AI 来塑造产品方向，例如自动化地收集和分析使用数据、总结书面和口头的客户反馈，或进行竞品分析。然而，在我参与的几乎所有产品中，我都认为人类相对于当前 AI 系统拥有显著的上下文优势——我们对用户以及产品所处的运行环境的了解远超 AI 系统——因此人类扮演着至关重要的角色。许多人将这种人类贡献称为“品味”（taste），但我更愿意将其理解为人类拥有上下文优势，因为这为我们提供了一条更清晰的路径，帮助 AI 系统变得更好。这也解释了为什么这一步无法被自动化：只要人类掌握着 AI 所不知道的信息，就需要人在回路（human-in-the-loop）中将这些知识注入系统。

外部反馈回路：这包括多种策略，比如向几位朋友征求反馈、向内测（alpha）测试者发布，或将代码投入生产环境进行 A/B 测试。这些策略通常很慢，很少在几小时内完成，有时甚至需要几天甚至几周。这些数据会为开发者的愿景提供信息，进而持续推动详细的产品规格，而产品规格又驱动着编码智能体。

随着编码智能体加速软件开发，越来越多的工程师开始承担部分产品经理的角色。对于许多正在向这一角色成长的工程师来说，最难的部分是塑造产品愿景，并在构建（弥合愿景与规格之间的差距）与获取用户反馈以演进愿景之间取得平衡。两者都至关重要！

我将在未来的文章中更多地探讨如何做到这一点，但目前看来，工程师扮演扩展角色这件事令人鼓舞（正如产品经理和设计师现在也做了更多的工程工作一样）。

[原文来源：The Batch]