Ng 的三环模型为 AI 代理开发提供了清晰的工程框架，强调人机协作中的角色分工。
「循環工程」在 Boris Cherny（Claude Code 的創作者）和 Peter Steinberger（OpenClaw 的創作者）的提及在社交媒體上爆紅後成為了一個熱門術語。循環現在是我們讓 AI 代理程式長時間迭代以建立軟體的關鍵部分。在這封信中，我想分享我用於打造 0 到 1 產品的三個關鍵循環（如下圖所示）。這些循環不僅指導我如何建立軟體，也指導我如何決定要建立什麼軟體。
代理程式編碼循環：給定產品規格，以及可選的一組評估（也就是用來衡量效能的資料集），我們可以讓 AI 代理程式編寫程式碼、測試其成果，並不斷迭代直到程式碼無錯且符合規格。這種閉合循環的概念在去年年底開始流行，並且成為讓編碼代理程式能夠在不需要人工介入的情況下長時間有效工作的遊戲規則改變者。例如，上週末我為女兒打造一個練習打字的應用程式時，我的編碼代理程式能夠輕鬆地工作約一小時，使用網頁瀏覽器多次檢查其所建立的成果，然後再回報給我，而無需我的介入。
工程循環執行得非常迅速。每隔幾分鐘，編碼代理程式可能會建立和測試新版本的軟體。我經常聽到開發人員們正在尋找新的方法來設計更有效的工程循環。這是一個活躍的創新領域！
開發人員反饋循環：在這個循環中，開發人員檢視當前產品並引導編碼代理程式改進它。去年，許多開發人員（包括我自己）都扮演著我們編碼代理程式的品質保證功能，手動尋找錯誤然後要求代理程式修復它們。但隨著編碼代理程式越來越能夠測試自己的程式碼，我們需要在此功能上花費的時間已大幅減少。這讓我們能夠做出更高層次的產品決策，例如提供哪些關鍵功能、UI 在哪裡需要改進等等。
開發人員反饋循環在幾十分鐘到數小時的時間間隔內運作——這就是開發人員可能檢視產品並提供反饋的頻率。在打字應用程式的案例中，我幾次改變了對視覺設計的想法，以及女兒在學習過程中可以解鎖哪些貓咪服裝（她很喜歡貓咪），以及成人登入並引導孩子學習體驗的使用流程。
當開發人員對要建立的產品有清晰的願景時，將這個願景轉化為編碼代理程式實現的規格仍然是一項艱苦的工作。此外，在開發人員看到實現後，他們可能會更新（或澄清）規格以引導其走向所需的方向。如果您發現系統一再遇到某些問題，為代理程式建立一組評估就變得有用。
AI 原生團隊越來越多地使用 AI 來幫助塑造產品方向，例如自動收集和分析使用數據、總結書面和口頭的客戶反饋，或進行競爭分析。然而，對我參與的幾乎所有產品來說，我認為人類在當前 AI 系統面前擁有顯著的上下文優勢——我們對使用者和產品必須運作的環境瞭解得遠多於 AI 系統——因此人類在其中扮演著關鍵角色。許多人將這種人類貢獻描述為「品味」，但我更願意將其視為人類擁有上下文優勢，因為這給了我們一個更清晰的路徑來幫助 AI 系統變得更好。這也說明了為什麼這一步驟不能自動化：只要人類知道 AI 不知道的事情，人在循環中的必要性就在於將這些知識注入系統。
外部反饋循璋：這包括請幾個朋友提供反饋、向 alpha 測試者推出、或將程式碼投入生產環境進行 A/B 測試等多種策略。這些策略通常很慢，很少在幾小時內完成，有時需要數天甚至數週。這些數據會告知開發人員的願景，進而繼續推動詳細的產品規格，進而驅動編碼代理程式。
隨著編碼代理程式加速軟體開發，越來越多的工程師開始扮演部分產品管理角色。對許多正在成長為此角色的工程師來說，最困難的部分是塑造產品願景，並在建立（彌合願景與規格之間的差距）和獲取用戶反饋以演進願景之間找到平衡。做這兩件事都很重要！
我將在未來的文章中寫更多關於如何做到這一點的內容，但就目前而言，我發現工程師扮演著擴展角色（正如產品經理和設計師現在所做的更多工程工作一樣）是一件令人鼓舞的事。
[原始文字：The Batch]
代理程式編碼循環：給定產品規格，以及可選的一組評估（也就是用來衡量效能的資料集），我們可以讓 AI 代理程式編寫程式碼、測試其成果，並不斷迭代直到程式碼無錯且符合規格。這種閉合循環的概念在去年年底開始流行，並且成為讓編碼代理程式能夠在不需要人工介入的情況下長時間有效工作的遊戲規則改變者。例如，上週末我為女兒打造一個練習打字的應用程式時，我的編碼代理程式能夠輕鬆地工作約一小時，使用網頁瀏覽器多次檢查其所建立的成果，然後再回報給我，而無需我的介入。
工程循環執行得非常迅速。每隔幾分鐘，編碼代理程式可能會建立和測試新版本的軟體。我經常聽到開發人員們正在尋找新的方法來設計更有效的工程循環。這是一個活躍的創新領域！
開發人員反饋循環：在這個循環中，開發人員檢視當前產品並引導編碼代理程式改進它。去年，許多開發人員（包括我自己）都扮演著我們編碼代理程式的品質保證功能，手動尋找錯誤然後要求代理程式修復它們。但隨著編碼代理程式越來越能夠測試自己的程式碼，我們需要在此功能上花費的時間已大幅減少。這讓我們能夠做出更高層次的產品決策，例如提供哪些關鍵功能、UI 在哪裡需要改進等等。
開發人員反饋循環在幾十分鐘到數小時的時間間隔內運作——這就是開發人員可能檢視產品並提供反饋的頻率。在打字應用程式的案例中，我幾次改變了對視覺設計的想法，以及女兒在學習過程中可以解鎖哪些貓咪服裝（她很喜歡貓咪），以及成人登入並引導孩子學習體驗的使用流程。
當開發人員對要建立的產品有清晰的願景時，將這個願景轉化為編碼代理程式實現的規格仍然是一項艱苦的工作。此外，在開發人員看到實現後，他們可能會更新（或澄清）規格以引導其走向所需的方向。如果您發現系統一再遇到某些問題，為代理程式建立一組評估就變得有用。
AI 原生團隊越來越多地使用 AI 來幫助塑造產品方向，例如自動收集和分析使用數據、總結書面和口頭的客戶反饋，或進行競爭分析。然而，對我參與的幾乎所有產品來說，我認為人類在當前 AI 系統面前擁有顯著的上下文優勢——我們對使用者和產品必須運作的環境瞭解得遠多於 AI 系統——因此人類在其中扮演著關鍵角色。許多人將這種人類貢獻描述為「品味」，但我更願意將其視為人類擁有上下文優勢，因為這給了我們一個更清晰的路徑來幫助 AI 系統變得更好。這也說明了為什麼這一步驟不能自動化：只要人類知道 AI 不知道的事情，人在循環中的必要性就在於將這些知識注入系統。
外部反饋循璋：這包括請幾個朋友提供反饋、向 alpha 測試者推出、或將程式碼投入生產環境進行 A/B 測試等多種策略。這些策略通常很慢，很少在幾小時內完成，有時需要數天甚至數週。這些數據會告知開發人員的願景，進而繼續推動詳細的產品規格，進而驅動編碼代理程式。
隨著編碼代理程式加速軟體開發，越來越多的工程師開始扮演部分產品管理角色。對許多正在成長為此角色的工程師來說，最困難的部分是塑造產品願景，並在建立（彌合願景與規格之間的差距）和獲取用戶反饋以演進願景之間找到平衡。做這兩件事都很重要！
我將在未來的文章中寫更多關於如何做到這一點的內容，但就目前而言，我發現工程師扮演著擴展角色（正如產品經理和設計師現在所做的更多工程工作一樣）是一件令人鼓舞的事。
[原始文字：The Batch]
展开原文
“Loop engineering” is a hot buzzphrase after mentions of it by Boris Cherny (Claude Code’s creator) and Peter Steinberger (OpenClaw's creator) went viral on social media. Loops are now a key part of how we get AI agents to iterate at length to build software. In this letter, I’d like to share my 3 key loops, shown in the image below, for building 0-to-1 products. These loops guide not just how I build software, but also how I decide what software to build.
Agentic coding loop: Given a product specification and optionally a set of evals (that is, a dataset against which to measure performance), we can have an AI agent write code, test its work, and keep iterating until the code is bug-free and meets its specification. This idea of closing the loop took off around the end of last year, and it has been a game changer in enabling coding agents to work longer productively without human intervention. For example, over the weekend, I was building an app for my daughter to practice typing, and my coding agent could easily work for around an hour, using a web browser to check what it had built multiple times before getting back to me, without needing my intervention.
The engineering loop executes quickly. Every few minutes, the coding agent might build and test a new version of the software. I hear frequently from developers who are finding new ways to engineer more effective engineering loops. This is an active area of invention!
Developer feedback loop: In this loop, a developer examines the current product and steers the coding agent to improve it. Last year, a lot of developers (including me) were acting as the QA (quality assurance) function for our coding agents, manually finding bugs and then asking the agent to fix them. But with coding agents much more able to test their own code, the amount of time we need to spend on this function has decreased significantly. This allows us to make higher-level product decisions, such as what key features to offer, where the UI needs improvement, and so on.
The developer-feedback loop operates over time intervals between tens of minutes and hours — that's how frequently a developer might review a product and give feedback. In the case of the typing app, I changed my mind a few times about the visual design, what cat costumes she can unlock as she learns (she loves cats), and the user flow for a grown-up to log in and steer the child's learning experience.
When a developer has a clear vision for what to build, it is still a lot of work to translate that vision into a specification for a coding agent to implement. Further, after the developer has seen an implementation, they might update (or perhaps clarify) the spec to steer it toward what they want. If you find that the system repeatedly runs into certain problems, building a set of evals for the agent becomes useful.
AI-native teams are increasingly using AI to help shape product direction, for example, automating the gathering and analysis of usage data, summarizing written and verbal customer feedback, or carrying out competitive analysis. However, for pretty much all the products I’m involved in, I see humans as having a significant context advantage over current AI systems — we know a lot more than the AI system about the users and the context the product has to operate in — and thus humans play a critical role. Many people describe this human contribution as “taste,” but I prefer to think of it as humans having a context advantage, since that gives us a clearer path to helping AI systems get better. This also speaks to why this step can’t be automated: So long as the human knows something the AI does not, human-in-the-loop is needed to to inject that knowledge into the system.
External feedback loop: This includes a wide range of tactics like asking a few friends for feedback, launching to alpha testers, or putting the code into production with A/B testing. These tactics are usually slow, rarely taking less than hours and sometimes taking days or even weeks. This data informs the developer vision, which in turn continues to drive the detailed product spec, which in turn drives the coding agent.
With coding agents speeding up software development, more engineers are starting to play a partial product management role. For many engineers who are growing into this role, the hardest part is shaping the product vision and striking a balance between building (bridging the gap between vision and spec) and getting user feedback to evolve the vision. It is important to do both!
I will write more about how to do this in future posts, but for now, I find it encouraging that engineers are playing an expanded role (just as product managers and designers now do more engineering).
[Original text: The Batch]
Agentic coding loop: Given a product specification and optionally a set of evals (that is, a dataset against which to measure performance), we can have an AI agent write code, test its work, and keep iterating until the code is bug-free and meets its specification. This idea of closing the loop took off around the end of last year, and it has been a game changer in enabling coding agents to work longer productively without human intervention. For example, over the weekend, I was building an app for my daughter to practice typing, and my coding agent could easily work for around an hour, using a web browser to check what it had built multiple times before getting back to me, without needing my intervention.
The engineering loop executes quickly. Every few minutes, the coding agent might build and test a new version of the software. I hear frequently from developers who are finding new ways to engineer more effective engineering loops. This is an active area of invention!
Developer feedback loop: In this loop, a developer examines the current product and steers the coding agent to improve it. Last year, a lot of developers (including me) were acting as the QA (quality assurance) function for our coding agents, manually finding bugs and then asking the agent to fix them. But with coding agents much more able to test their own code, the amount of time we need to spend on this function has decreased significantly. This allows us to make higher-level product decisions, such as what key features to offer, where the UI needs improvement, and so on.
The developer-feedback loop operates over time intervals between tens of minutes and hours — that's how frequently a developer might review a product and give feedback. In the case of the typing app, I changed my mind a few times about the visual design, what cat costumes she can unlock as she learns (she loves cats), and the user flow for a grown-up to log in and steer the child's learning experience.
When a developer has a clear vision for what to build, it is still a lot of work to translate that vision into a specification for a coding agent to implement. Further, after the developer has seen an implementation, they might update (or perhaps clarify) the spec to steer it toward what they want. If you find that the system repeatedly runs into certain problems, building a set of evals for the agent becomes useful.
AI-native teams are increasingly using AI to help shape product direction, for example, automating the gathering and analysis of usage data, summarizing written and verbal customer feedback, or carrying out competitive analysis. However, for pretty much all the products I’m involved in, I see humans as having a significant context advantage over current AI systems — we know a lot more than the AI system about the users and the context the product has to operate in — and thus humans play a critical role. Many people describe this human contribution as “taste,” but I prefer to think of it as humans having a context advantage, since that gives us a clearer path to helping AI systems get better. This also speaks to why this step can’t be automated: So long as the human knows something the AI does not, human-in-the-loop is needed to to inject that knowledge into the system.
External feedback loop: This includes a wide range of tactics like asking a few friends for feedback, launching to alpha testers, or putting the code into production with A/B testing. These tactics are usually slow, rarely taking less than hours and sometimes taking days or even weeks. This data informs the developer vision, which in turn continues to drive the detailed product spec, which in turn drives the coding agent.
With coding agents speeding up software development, more engineers are starting to play a partial product management role. For many engineers who are growing into this role, the hardest part is shaping the product vision and striking a balance between building (bridging the gap between vision and spec) and getting user feedback to evolve the vision. It is important to do both!
I will write more about how to do this in future posts, but for now, I find it encouraging that engineers are playing an expanded role (just as product managers and designers now do more engineering).
[Original text: The Batch]
❤ 8.2k · 🔁 1.6k · 💬 353 · 👁 56.9w
热门回复 4
@AvaGrace_AI @AndrewYNg 智能循环释放产品创造力和动量。
@AndrewYNg Smart loops unlock product craft and momentum.
@ElleiraGF @AndrewYNg 我觉得这解释得太过了。为什么要将开发者循环和外部反馈循环放到循环工程的背景下？难道这两个循环不是在"循环工程"之前就已经存在的吗？我们只是不特别称呼它为"循环"而已。把它们放在一起并不能提供更多见解。
@AndrewYNg I feel it is over explained. Why putting the developer loop and external feedback loop into the loop engineering context? Isn’t that we have these two loops before the “loop engineering”? We just don’t call it specifically as “loop”. Put them together doesn’t give more insight.
@JiangL17208 @AndrewYNg 老实说，大部分的魔法（和计算费用）都发生在内循环中。大家都关注外层的反思步骤，但正是开发者循环将随意编码的玩具与真正可以投入生产的东西分开。
@AndrewYNg honestly the inner loop is where most of the magic (and most of the compute bill) happens. everyone focuses on the outer reflection step but the developer loop is what separates vibe-coded toys from stuff that actually ships
@HypermanicAl @AndrewYNg 循环工程正是将演示质量的代理与生产系统区分开来的关键。大多数人忽略的关键见解是：这不是关于循环的长度，而是关于循环内部的反馈信号。干净的评估数据比更长的循环更重要。
@AndrewYNg Loop engineering is exactly what separates demo-quality agents from production systems. The key insight most miss: it's not about the loop length, but the feedback signals inside the loop. Clean eval data > longer loops.
