黃仁勛：Prompt正在過時，Loop才是新范式

Prompt已死，loop當立

這就是最近網上熱傳熱議，然后老黃黃仁勛給AI新趨勢畫的新重點：

• Nobody writes prompts anymore. The new job is to write and handle loops.（現在根本沒有人寫Prompt了，新時代的核心工作是編寫和管理loop。）

啥是loop？這個詞直譯過來是“循環”，換成AI圈的說法就是：

你不再親手給AI下指令，而是設計一個系統，讓系統替你下指令、替你驗收、不合格自己重來，直到活干完

嗯？這不就是如今Agent那一套嗎？為啥又搞個新概念出來？

暫且按下此疑惑不表，待我環顧一圈后發現，這個“loop”還真挺火——

除了老黃，“龍蝦之父”Peter、“Claude Code之父”Boris Cherny、吳恩達等一眾大佬全都在談、在大力推loop。

• （Peter）別再給編程Agent寫提示詞了，去設計循環，讓循環替你提示Agent。

• （Boris）我已經不給Claude寫提示詞了。我有一堆循環在跑，是它們在給Claude下指令、決定下一步做什么。我的工作，就是寫循環。

而當“寫loop”取代“寫prompt”成為大佬們新的日常，loop顯然已經越過了“又一個新概念”的階段。

剩下的問題就只有：

loop具體是指什么？它怎么就突然火起來了？

loop到底是什么

要理解loop這個新東西，我們得先回顧一下之前的那套舊范式。

過去兩年AI編程的標準動作是這樣的：

你寫一條prompt，AI吐一段代碼，你看了不滿意，再寫一條，AI再改，你再看……

反正就是來回拉鋸，人全程盯著。

卡帕西之前還側面吐槽了“人就是瓶頸”這件事，而且勸告大家：

• 你不能坐在那里等著給每一步寫prompt，你得把自己從流程中抽離出來

把人從流程中抽離出來，這正是loop要解決的事。

其核心邏輯只有一句話：

你定義一個目標，AI自己跑，跑完自己驗收，不合格帶著報錯再來一輪，直到通過或者撞上預算上限才停。

此時人的角色就從“傳話人”變成了“規則設計者”。

所以回到開頭的疑問：這跟Agent有什么區別？

顯而易見，Agent是干活的那個人，而loop是讓這個人不用你盯著也能持續干活的那套管理機制。

沒有loop的Agent，你提一句它動一下，本質上還是個聽話的工具。

套上loop的Agent，才真正變成了一個能自轉的系統。

原理聽起來確實不復雜，但貌似仍有點抽象。

別急，我又去翻了下當前loop的實際落地情況，結果發現它其實已經藏在了我們熟悉的系統里。

圍繞loop，產品落地層目前已經形成了“雙雄對峙”格局

一個就是大家天天都在用的Claude Code，它圍繞loop做了三件套：

/loop負責定時循環，/goal負責目標驅動（跑到驗收條件滿足為止），/schedule負責云端定時任務（合上電腦也能跑）

其中最精妙的設計是/goal，它背后藏著loop最關鍵的一條原則——自己不能判自己的卷子。

Claude Code把這條原則直接寫進了產品架構：

寫代碼的是大模型，驗收的是另一個獨立的小模型Haiku，兩個模型各司其職。

這樣一來，Agent不會自己給自己打高分，驗收才有真實的約束力。

另一個就是OpenAI Codex。

Codex的玩法更接近“自動化流水線+目標驅動+多個子Agent”的組合，在一些開發者的實際體驗中，能看到最多8個Agent同時跑在各自的云端沙箱里，各干各的活，最后把結果匯總回來。

有意思的是，雖然兩家的實現路徑不太一樣，但最終長出來的形態高度相似——

都是把復雜任務拆碎，分給多個Agent并行去跑，再統一匯總。

在公開評測和社區口碑里，兩者的表現也已經非常接近。

這也說明一個問題，模型本身已經卷不出太大差別了，真正的差距在上層的loop編排

說到這兒，咱們直接看看“Claude Code之父”Boris Cherny每天怎么工作的就全明白了。

他自述去年11月卸載了IDE，一個月沒打開過，索性刪了。

現在他手下幾百個小Agent同時跑，有的掃GitHub issue，有的讀Slack上的用戶反饋，有的監控CI失敗。每個Agent在自己隔離的代碼分支里干活，一個寫代碼，另一個跑測試驗收。

搞不定的才進他的收件箱，等他來做判斷。

據他透露，自Opus 4.5以來，其所有代碼都是Claude Code寫的，如今大部分代碼都是直接在他的手機上完成。

• 接下來是循環，Agent之間互相提示，中間無需人工審核。

看到沒，loop的終極形態已經很清晰了：

人不寫代碼，也不寫prompt，只寫規則和判斷，剩下的全交給loop

怎么loop起來

那么，我們該怎么loop起來呢？

X上有個叫Codez的博主已經都替大家總結好了，他發了一份14步實操roadmap，這里我挑了一些干貨。

step 1：先別急著建，先做“4條件測試”

loop不是什么活兒都能往里面塞，瞎建只會虧錢。

在動手之前，先回答四個問題：

• 任務重復發生嗎？
• 有自動化驗收手段嗎？
• Token預算扛得住嗎？
• Agent有“高級工程師”的工具嗎？

圖片由AI生成

四個全過，才值得建loop。

step 2：從最小可行loop開始

第一次別搞花活，就建一個四件套：

• 一個觸發器（Automation）：定時跑、事件觸發跑都行。Claude Code里用/loop，Codex里用Automations面板。
• 一個技能（Skill）：把項目上下文寫進STATE.md，讓每次運行不用重新解釋一遍。
• 一個狀態文件（State File）：用Markdown記下“做到哪了、什么成了、什么掛了”，下次接著跑。
• 一個門禁（Gate）：測試、類型檢查、構建——能自動攔住壞結果的東西。

而且順序很關鍵：先手動跑通一次→寫成Skill→包進loop→最后才上定時。

• 跳步是loop死在生產環境的主要原因。

step 3：做“拆卷子”的人，別做“判卷子”的

整個loop設計里最重要的一條原則前面已經提過了——寫代碼的和驗代碼的，必須分開。

落地到具體操作就是：

用一個模型（或者子Agent）負責寫，用另一個獨立的模型（或者子Agent）負責驗收，驗收的那個不能看到寫代碼的那個的推理過程。

為什么這很重要？因為模型給自己寫的代碼打分時，往往“手太松了”。

所有“看起來不錯”的代碼，在獨立驗收器面前大概率能挑出一堆毛病。

step 4：別人踩過的坑就別再踩了

附幾個避坑指南。

1、沒有硬停止條件。loop跑到你發現賬單或者被限流才停，所以需要設Token上限、迭代次數上限、時間限制。

2、狀態不落地。Agent的記憶是短時的，今天學到的東西明天就忘了，所以需要寫進狀態文件（STATE.md），每次運行接著讀。

3、讓loop碰“需要判斷”的活。架構重寫、鑒權代碼、支付邏輯、產品方向決策，這些別讓loop碰。loop適合干“對錯清晰、機器可驗證、不依賴人的判斷”的活，比如Lint自動修復、依賴更新PR、CI失敗分類、Flaky測試復現。

4、不讀Diff。loop合入代碼越來越快，你對代碼庫的理解越來越淺。這叫“理解力債務”——真正的代價不是Token賬單，而是某天你要調試一個團隊里沒人讀過的系統。所以建議你讀Diff，哪怕只是掃一眼。

step 5：衡量指標就一個

別管燒了多少Token、開了多少PR、跑了多少次任務。

唯一有用的指標是：每個被接受的改動，平均成本是多少

如果你的“被接受率”低于50%，說明你在做loop本該替你省掉的評審工作，即loop在虧錢。

從提示詞到loop，四次范式躍遷

原理和方法搞懂了，最后的問題只有一個：

loop為什么現在火了？

雖然嚴格來說，loop Engineering這個概念只有不到三周的歷史。

但它不是憑空蹦出來的，往回拉一下時間線就能看到一條很清晰的演化路徑。

這條路徑大佬們也已經替大家總結好了，咱直接抄作業：

從Prompt→Context→Harness→loop，一共四次

簡單來說，從2023~2024年，這是Prompt Engineering的天下。

當時大家都在琢磨一件事：提示詞怎么寫才能讓AI好好干活。

寫得好和寫得不好，出來的東西天差地別，所以那會兒“會不會寫prompt”基本就等于“會不會用AI”。

這一階段，人和AI的關系還停在最表面那層——你說一句，它回一句，細到每一個指令都要人親自敲。

但隨著模型能力增強、上下文窗口變長，以及RAG和代碼庫接入逐漸普及，問題開始發生第一次遷移。

大約在2024到2025年前后，行業開始強調“Context Engineering”的重要性，關注點從“怎么問”變成了“給AI看什么”。

也就是說，AI不再只依賴一句提示詞，而依賴你提供的整個背景。

這一階段，信息組織能力開始比寫prompt更重要，控制粒度從“一句話”上移到了“一堆信息”。

到了2025~2026年，隨著Agent系統逐步進入真實開發流程，問題繼續往外擴展。

這時人們發現，光給信息和上下文也不夠了，AI得能接工具、能跑代碼、能調接口、能走權限審批。

因此，你得給它搭一個能干活、能約束、能調取真實世界資源的運行環境。

“Harness Engineering”正是為此而生。

而在Harness的基礎上，“loop Engineering”成了最新的進化方向。

如果說Harness解決的是“AI能不能在真實環境里干活”的問題，那loop解決的就是“AI能不能在這個環境里持續干活、自己推進任務、不需要人一步步盯著”的問題。

它的核心不再是單次執行能力，而是一個閉環系統的運行能力。

所以從Prompt到Context，再到Harness，再到loop，看起來像是概念的更替，但本質上是一條連續的遷移路徑：

人類對AI的控制粒度不斷上移，從“寫一句話”，變成“提供信息”，再變成“搭建系統”，最終變成“設計循環”

一個逐漸解放人類雙手的過程。

實際上，雖然loop這玩意兒剛在工業界火起來，但學術界其實早就有了類似理念。

而且很多重要工作都和我們今天熟悉的一個人有關：姚順雨（騰訊那個）。

他在大模型Agent方向最具代表性的工作之一，是2022年的ReAct框架（Reason+Act）

這篇工作在ICLR 2023拿到Oral級別，也在后續獲得了上萬引用量。

ReAct做了一件很關鍵的事：把“推理”和“行動”綁定成一個循環過程

大模型不再是一次性輸出答案，而是先進行可解釋的思考，再調用工具執行動作，執行之后再觀察環境反饋，然后進入下一輪推理。抽象出來就是：

• 思考→行動→觀察→再思考→再行動…

這個結構本質上就是一個最早被系統化表達的“agent loop”雛形。

在ReAct之后，這條路線被不斷擴展，比如Reflexion引入“從錯誤中學習”的反饋機制，Tree of Thoughts擴展成多路徑搜索式推理，以及后續一系列tool-use agent工作逐步完善“規劃+執行+反饋”的完整鏈路。

這些學術成果一點一點往前拱，最終才在工程界收斂成今天所說的“loop系統”。

所以從學術視角看，loop不是某一個人的發明，它是一條逐步收斂的技術路徑。

只不過在這條路上，恰好有個我們熟悉的華人站在了一個關鍵節點上。

最后不得不感慨，從Prompt到loop，AI的發展還是太快了。

太快帶來的后果是，有人興奮激動，也有人難掩擔憂。

而loop Engineering的命名者、Google工程主管Addy Osmani，正是后者當中的一員。

他在《loop Engineering》這篇長文里寫得很明白：

• 還很早期。我持保留態度。token成本你必須非常小心。

卡帕西的話更讓人深思，他在紅杉資本AI Ascent 2026大會上引用過一句讓他本人反復回想的話：

• 你可以外包你的思考，但你沒法外包你的理解。

翻譯翻譯，AI可以替你想辦法，但你自己得真懂問題本身。

這大概是整場loop熱潮里最清醒的聲音。