AI 原生建構的三個迴圈

資料來源#

• AI accelerates output, not innovation
• Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think
• Thread by @AndrewYNg

摘要#

Andrew Ng 在 2026 年 6 月的《The Batch》專欄一開頭便指出，「迴圈工程」成了熱門詞，這股風潮來自 Boris Cherny 與 Peter Steinberger——wiki 的 迴圈工程 頁面正是以這兩位實作者命名。Ng 的看法是，他們談的都是一個迴圈，但產品建構其實由三個迴圈構成，彼此巢狀，運作於不同時間尺度。「這些迴圈不只引導我如何打造軟體，也影響我如何決定要打造什麼軟體。」（practitioner-opinion——這是一套分類加上個人建構經驗，不是測量。）

這套分類對這個 wiki 的價值在於糾正視角。語料中幾乎所有關於迴圈的內容——Agent Loop Pattern、迴圈工程、/goal、Ralph 迴圈、maker/checker 子代理程式——都在最佳化最內層的迴圈，也就是代理程式能自行收尾的那一個。Ng 所說的外側兩個迴圈仍有人的參與，而且正是它們決定正在打造的東西值不值得打造。

三個迴圈#

迴圈	誰來收尾	頻率	消耗什麼	產出什麼
代理式程式設計迴圈	代理程式自行收尾	「每隔幾分鐘」	規格，可選擇加入 evals	通過自身測試的程式碼
開發者回饋迴圈	人類	「數十分鐘到數小時」	可運作的建置版本	修訂後的規格／引導
外部回饋迴圈	市場	「數小時……數天甚至數週」	已推出的產品	修訂後的願景

這些迴圈嚴格巢狀：外部迴圈影響開發者的願景，願景決定規格，規格引導程式設計代理程式。回饋會沿著同一條鏈反向流動。每個外部迴圈的運作速度都比它所包含的迴圈慢約 1 到 2 個數量級，因此內層迴圈的加速才會如此關鍵，也如此有限——你可以讓最內層的迴圈瞬間完成，但產品仍以最外層迴圈的速度前進。

1. 代理式程式設計迴圈#

「提供產品規格，並可選擇提供一組 evals……讓 AI 代理程式撰寫程式碼、測試成果，並持續反覆修改，直到程式碼沒有錯誤且符合規格。」Ng 將這個迴圈的閉合時間定在「去年年底左右」，並稱它是「促成程式設計代理程式在無須人類介入的情況下，長時間有效工作的重大變革」。他自己的例子是為女兒打造一款打字練習應用程式：「我的程式設計代理程式輕易就能連續工作約一小時，期間多次使用網頁瀏覽器檢查自己的成果，之後才回來找我。」（這是軼聞，不是測量；可參照 Task Time-Horizon Scaling，了解這個例子位於哪條曲線上。）

「這仍是個活躍的發明領域！」——這正是 迴圈工程 與 Agent Loop Pattern 的全部內容。

2. 開發者回饋迴圈#

變化最大、也是這篇文章最值得一讀的迴圈。Ng 描述人類過去的工作方式：

「去年，許多開發者（包括我）都在替程式設計代理程式擔任 QA，手動找出錯誤，再要求代理程式修復。但隨著程式設計代理程式越來越能自行測試程式碼，我們花在這項工作上的時間已大幅減少。這讓我們能做更高層次的產品決策。」

人類並沒有從迴圈中被移除；而是從 QA 升任更高職務。請留意，這與 wiki 主流的論述相左。驗證成為新的瓶頸主張，程式設計變得便宜後，驗證就成了稀缺資源；Ng 描述的方向卻相反——代理程式自行測試，減輕了人類的驗證負擔，讓人能把注意力往上移。兩者可以並存（Ng 打造的是 0 到 1 的個人產品，錯誤建置的代價低；Fung 談的是生產環境中的組織，代價則高），但這確實是觀點分歧，值得清楚呈現，而不是取平均值帶過。Faros 的遙測資料——PR 審查中的時間中位數增加 441.5%——是證據力較高的來源，在組織情境上不支持 Ng 的說法。

Ng 在這個迴圈中點出兩種機制：

• 規格轉譯才是工作所在。「開發者對要打造什麼有清楚願景時，要把願景轉譯成程式設計代理程式可實作的規格，仍然需要投入許多工作。此外，開發者看過實作成果後，可能會修改（或進一步釐清）規格。」願景 → 規格的過程有資訊損失，也需要反覆迭代；看過建置成果，才能知道規格原本該怎麼寫。這就是以迴圈而非技巧來表述的未知問題。
• 同一種失敗重複兩次後，才是建立 evals 的時機。「如果你發現系統反覆遇到某些問題，為代理程式建立一組 evals 就會很有用。」這是一種挑錯而非預防的紀律——順序正好與把「十個優秀 evals」事先寫成規格相反。Ng 的做法成本較低，也比較隨興；Cat Wu 的做法則適用於功能模糊到「它失敗了」並非顯而易見的情況。

3. 外部回饋迴圈#

「向幾位朋友徵求回饋、向 alpha 測試者推出產品，或把程式碼放進正式環境進行 A/B 測試。」這個迴圈很慢——「很少少於數小時，有時要花數天甚至數週」。它是唯一會更新願景而非規格的迴圈，也是 AI 原生工具最難加速的迴圈。Ng 指出，AI 原生團隊日益自動化其輸入（使用資料分析、回饋摘要、競爭分析），但沒有縮短迴圈本身。

為什麼人類位於中間迴圈#

Ng 對人類貢獻的描述，是他最常被引用的一句話，也有自己的專頁：關鍵不是品味，而是情境優勢。「幾乎對所有我參與的產品而言，我認為人類相較於目前的 AI 系統有顯著的情境優勢——我們比 AI 系統更了解使用者，以及產品必須運作的情境。」由此可直接推得停止條件：「只要人類知道 AI 不知道的事，就需要人在迴圈中，把那些知識注入系統。」

從這套分類來看，這句話有個明確含義：人類位於開發者回饋迴圈，因為只有在這裡，來自外部迴圈（只有人類實際跑過）的知識才能注入程式設計迴圈（由代理程式獨自執行）。人類是連接兩個迴圈的傳遞者：一個了解使用者，另一個負責撰寫程式碼。

對角色的影響#

「程式設計代理程式加快軟體開發後，越來越多工程師開始部分承擔產品管理的角色。對許多逐漸承接這個角色的工程師來說，最難的部分是塑造產品願景，並在建構（彌合願景與規格之間的差距）以及取得使用者回饋以演進願景之間取得平衡。兩者都很重要！」

這是從第三個獨立角度提出的 Engineer PM Convergence（先前還有 Cat Wu 和 Boris Cherny），而 Ng 指出它造成的具體失誤：新近接手中間迴圈的工程師在這方面投入過多。建構是他們熟悉的迴圈，因此慢、不愉快又無法自動化的外部迴圈便遭到跳過。Ng 以對稱的方式作結：「工程師承擔的角色擴大了（正如產品經理和設計師如今也做更多工程工作）。」

張力：這個迴圈是否已經過時？#

Ng 發表專欄的兩天前，負責 OpenAI 桌面應用程式 Codex 的 Andrew Ambrosino 在 Lenny's Podcast 說，「迴圈早就過時了」。他認為，編排好的迴圈只是過渡性鷹架，自主、長時程的模型已經開始超越它（參見氛圍式程式設計與代理式工程）。Ng 卻在同一週發表迴圈分類。

他們可能都沒錯，因為兩人說的是不同的迴圈。Ambrosino 所說的「迴圈」是代理式程式設計迴圈——不斷刺激代理程式直到它收斂的鷹架；他的主張是，模型能力正在吸收這套機制（參見模型進步時的鷹架收縮）。Ng 的外側兩個迴圈並非鷹架，而是產品開發本身的結構；無論模型能力如何進步，都無法消除把產品交付給使用者需要數天這件事。這就是理解這套分類的有效角度：內層迴圈是鷹架，會逐漸縮小；外側迴圈是物理現實，不會消失。

兩個月後的迴圈（2026 年 8 月）#

Ng 面向大眾再次闡述的版本（Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think，Silicon Valley Girl，2026-08-28，practitioner-opinion）把這套分類濃縮成一句口號——「學 AI、快速建構、與客戶交談」——並再次印證上述解讀：外部迴圈是物理現實。內層迴圈如今成了週末習慣（「我發現自己每週、每個週末都在建構東西……因為我或團隊裡的某個人……遇到了問題，而我想到可以打造某種 AI 產品」；上週末，他讓一個前沿模型分析公司的指標，因為*「我沒時間去找資料科學家」）。他說外部迴圈仍需「數月……或許數年」：「深入了解客戶……和人們交談、閱讀面部表情、做問卷，一再重複，直到我們弄清楚要打造什麼。」他現在明確稱中間迴圈為「產品管理瓶頸」，其內容仍是情境優勢，這次稱為「長期優勢」。另外還有兩點小更新。六月專欄中代表代理式執行的一小時打字應用程式，原來有個與學習爭論相關的目的：他打造它，是因為「我不喜歡那些……免費的線上打字學習之類的東西」，希望女兒能自己學會一項技能——用低成本實作打造一個不會替孩子代勞的工具；同一場訪談中，他還說 LLM 不適合學習（參見生成式 AI 對學習成果的影響）。至於 KPI 的問題，答案則來自外部迴圈：「AI 對業務成果的影響，更多取決於業務本身，而不是 AI」*，所以唯一的 KPI 就是業務 KPI——沒有任何內層迴圈指標能衡量這項產品值不值得打造。

相關連結#

• 迴圈工程——Ng 正在定位的這門學科：Osmani 的五個基本要素都位於這三個迴圈中最內層；這套分類畫出迴圈工程尚未觸及的部分
• Agent Loop Pattern——收尾代理式程式設計迴圈的基本模式
• 情境優勢，而非品味——Ng 對人類貢獻的重新詮釋，也說明人類為何特別位於中間迴圈
• 未知，是代理式工作的瓶頸——願景→規格的資訊損失就是未知問題；開發者回饋迴圈是實作完成後，未知浮現的地方
• 工程師與產品經理的角色融合——第三份獨立報告指出相同的角色融合，並命名其失誤模式：工程師在自己喜歡的迴圈上跑過頭
• Evals 即產品規格——這場有益的分歧：把 evals 當成對重複失敗的回應（Ng），或事先撰寫好的規格（Cat Wu）
• 氛圍式程式設計與代理式工程——Andrew Ambrosino 在同一週發表「迴圈早就過時了」；區分鷹架迴圈與產品迴圈後，這個張力便迎刃而解
• Agent-Generated Test Quality——第一份以 empirical 角度檢視 Ng 主張所依據的產物。代理程式撰寫的測試確實比人類撰寫的涵蓋面更廣（邊界案例多樣性為 0.62，比起 0.32），支持他所述自行測試的部分；但這些測試未經模擬的檔案 I/O 和非決定性問題，發生率約為人類測試的 1.4 倍，因此它們從開發者身上減掉的 QA 負擔，有一部分只是轉移到 CI runner，而非真正消失
• 驗證成為新的瓶頸——直接的觀點分歧：Ng 說代理程式自行測試減輕了人類 QA 負擔，Fiona Fung 則認為驗證成了稀缺資源；可能的調和方式是範圍不同（0 到 1 的個人建置與正式環境組織），而 Faros 的遙測資料 的證據力勝過兩者
• Task Time-Horizon Scaling——無人看管執行約一小時，是這條曲線上的一個軼聞觀測點
• 模型進步時的鷹架收縮——說明內層迴圈為何縮小，而外側兩個不會
• AI Native Product Cadence——外側迴圈所決定的組織節奏；外部迴圈是所有工具都未能突破的下限
• Andrew Ng——作者
• Boris Cherny／Peter Steinberger——Ng 認為這兩位實作者讓「迴圈工程」成為熱門詞
• AI 撰寫程式碼的人類審查，是真正的控制措施，還是已淪為蓋章？——化解 Ng 與 Faros 之間非此即彼的疑問：範圍差異說明 QA 負擔可能真的會在 0 到 1 建置中下降，而有據可查的樂觀偏誤則說明自陳資料無法量化這種下降
• Implementation Abundance Inverts Product Work——從實驗室的角度指出同一個瓶頸；Ng 所說的「產品管理瓶頸」就是外側兩個迴圈，而他為這種反轉所設的限制是：它們仍需數月

尚待解答的問題#

• Ng 說開發者的 QA 負擔「大幅」下降。Faros 2026 年的遙測資料卻測得正式環境組織的情況恰好相反。這種差異真的來自 0 到 1 與正式環境的區別嗎？還是 Ng 的自陳也受到調查文獻一再發現的樂觀偏誤影響？部分已有答案：AI 撰寫程式碼的人類審查，是真正的控制措施，還是已淪為蓋章？——兩者可以同時成立，而非非此即彼。範圍差異確實存在，且解釋了大部分情況（0 到 1 的建置沒有讓正式環境驗證成本高昂的審查職能：沒有待處理佇列、沒有事故預算，也沒有需要理解程式碼的未來維護者），所以 Ng 的負擔確實可能下降；與此同時，他的證據是主觀感受到的負擔，而這種測量方式被證實落後於系統現況，也容易偏向樂觀（自動化與樂觀的關聯中，受訪者自陳沒有缺失，與 Contractor 和 Reyes 隨機研究中測得的收益消失形成對照），因此「大幅」是感受，不是幅度。Faros 的證據在組織情境中勝過兩者，這個判斷仍然成立。缺少的證據是：0 到 1 建構者的實測 QA 時間序列。後果這一端在 2026-08-12 有了數據——DX 的 2026 年第二季調查（vendor-claim，500 多個組織）指出，AI 使用者估計每週省下4 至 6 小時，但創新比率（投入新功能的時間占維護與管理開銷的比例）仍然持平。這部分認同了 Ng 的說法，卻反駁了他據此得出的結論：省下的時間確實空出來了，但在調查樣本的整體尺度上，這些時間沒有像他的說法那樣用於更高層次的產品決策。請留意這份資料並非什麼：它來自廠商自行挑選的客戶樣本，方法論詳載於需取得權限才能閱讀的報告；測量的是時間分配而非 QA 負擔本身；而比率持平，也可能代表省下的時間被 Faros 測得的審查與事故負荷消耗，而非這些時間從未存在。這並未影響 0 到 1 的範圍差異，因為個人建構者沒有可供變動的創新比率。時間省下來的量翻倍，仍未流向創新，2026-09-22：AI accelerates output, not innovation（DX，vendor-claim，相同客戶群）將數據更新為2026 年第二季每週省下 6.1 小時，2025 年第三季則是 3.0 小時；並以 15 項工作流程指標迴歸分析創新比率：AI 產出可解釋節省時間變異的 63%，但對創新比率的標準化 β 只有 0.16，而該模型僅能解釋創新比率變異的 13%。這讓上述「認同與反駁」更為明確，但沒有改變結論——省下時間的效果比一季前更大，而將時間轉化為新功能工作的效果可測得很弱——同時仍受相同限制（兩方面都靠自陳、廠商客戶樣本、方法論未公開），並多了一項發現：最能預測比率下降的因素，是資訊搜尋摩擦（β −0.19），這是情境問題而非 QA 問題，因此 DX 自己的資料也沒有說省下的時間用於 QA。模型只能解釋八分之一的結果，Ng 所說的升任高層角色與 Whiplash 機制都仍成立。
• 外部迴圈是唯一尚未縮短的迴圈。這是物理現實（使用者需要時間回應），還是尚未自動化的前沿（合成使用者、將部署模擬用於產品而非模型）？
• 如果人類在中間迴圈的必要性來自可被消除的情境優勢，那麼中間迴圈便是過渡性結構。兩個迴圈的世界會是什麼樣子？到那時，又由誰來轉譯外部迴圈的訊號？

資料來源#

• Thread by @AndrewYNg — Andrew Ng，《The Batch》，於 2026-06-30 發表，內容取自 X（practitioner-opinion）。三迴圈圖示是張託管於 X 的圖片，未轉錄。
• Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think — Andrew Ng 接受 Marina Mogilko 訪問，Silicon Valley Girl（2026-08-28，practitioner-opinion）：學 AI、快速建構、與客戶交談；週末建構習慣；需要數月至數年的外部迴圈；打字應用程式的用途；以及業務而非 AI 的 KPI 答案
• AI accelerates output, not innovation — Grace Fu，AI accelerates output, not innovation（DX 電子報，2026-09-09；vendor-claim）。僅在第一個尚待解答的問題中引用：每週省下時間由 3.0 增至 6.1 小時、AI 產出對創新比率的 β 為 0.16、資訊搜尋的 β 為 −0.19、模型 R² 為 0.13。取自原始資料的轉述摘要；數字保留，未直接引用原文