TL;DR · 2026 年 6 月，多位 AI 程式設計實踐者幾乎同時提出 Loop Engineering，Stripe 已用 Minions 每週合併 1300 多個 AI 生成 PR。 · 這套方法不再依賴人類逐次提示，而是讓系統自動發現任務、交接、驗證、保存狀態並進入下一輪。 · 可靠性仍取決於獨立評估器、硬性門控和人工審查，驗證債務與理解力衰退可能反向放大風險。
近日，一位 Anthropic 工程師發布了一份關於「智能體系統的循環工程」的 11 頁資料，把 Loop Engineering 放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之後，視為 AI 程式設計進入下一階段的關鍵方法。
這份資料之所以引發關注，是因為它剛好踩中了 2026 年 6 月 AI 程式設計討論的轉折點。Addy Osmani、Boris Cherny 和 Peter Steinberger 幾乎在同一週把 AI 程式設計的新階段稱為 Loop Engineering，而 Stripe 的 Minions 管道已經用類似思路每週合併 1300 多個 AI 生成 Pull Request。
這個數字之所以重要，不是因為 AI 又多寫了幾行程式碼，而是因為軟體開發的重心正在從「人類告訴模型寫什麼」，轉向「人類設計一個會自己排隊、取任務、寫程式碼、檢查結果、儲存狀態並繼續運行的系統」。
過去一年，AI 程式設計工具的敘事大多圍繞模型能力：程式碼補全更準、上下文視窗更長、代理能一次性完成更複雜任務。但 Loop Engineering 討論的是另一件事：當生成程式碼本身越來越便宜，工程師真正要設計的，變成一個可持續運轉的循環。機器可以不斷產出候選方案，人類要決定哪些結果可信、哪些必須擋下、哪些長期成本正在被隱藏。
近日，一位 Anthropic 工程師發布了一份關於「智能體系統的循環工程」的 11 頁資料，把 Loop Engineering 放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之後，視為 AI 程式設計進入下一階段的關鍵方法。這篇文章正是以這份資料為切口，結合 Boris Cherny、Addy Osmani 等人的公開討論，以及 Stripe Minions 每週合併 1300 多個 AI 生成 PR 的案例，解釋 Loop Engineering 到底是什麼、為什麼突然被全網討論，以及它真正改變的不是寫程式碼，而是軟體開發中的驗證、排程和判斷。
Loop Engineering 被放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之後，作為 AI 工程棧的第四層。
Prompt Engineering 解決的是「怎麼問」；Context Engineering 解決的是「給模型看什麼」；Harness Engineering 解決的是「如何把一次模型運行接入工具、測試和工作流」。Loop Engineering 往前多走一步：系統不只執行一次任務，而是能在固定時間或觸發條件下重新啟動，把上一次結果作為下一輪輸入。
一個完整循環通常包含五個動作。
第一步是發現工作，例如掃描 CI 失敗、開放 Issue、程式碼提交或待處理任務；第二步是任務交接，把任務整理成模型可以處理的上下文；第三步是獨立驗證，檢查模型產出的程式碼是否真的執行、是否通過測試、是否引入副作用；第四步是結果持久化，把狀態、判斷和未完成事項寫入檔案或系統；第五步是排程循環，讓下一輪在合適時間繼續運行。
這裡最關鍵的並不是「生成」，而是「驗證」。如果一個循環只是不斷讓模型寫程式碼、再讓同一個模型誇自己的結果，它很容易變成「點頭循環」：每一輪都看似前進，實際只是把錯誤包裝得更完整。
Osmani 自己的晨間 triage 循環是一個個人版例子：系統每天自動讀取前一天的 CI 失敗測試、開放 Issue 和最近提交，生成狀態檔案，把無法處理的事項放進人工收件箱。它的價值不是替工程師做所有決定，而是在工程師醒來之前完成初篩，把注意力留給真正需要判斷的部分。
Stripe 的 Minions 管道是這輪討論中最具衝擊力的企業案例：每週合併超過 1300 個 AI 生成 Pull Request，且程式碼本身沒有人工逐行編寫。
但這並不等於 Stripe 把生產系統交給一個大模型自由發揮。相反，Minions 的關鍵在於高度受控的流程：確定性編排器先組裝上下文，從 Jira、程式碼搜尋和內部工具中提取任務資訊；LLM 負責生成程式碼；之後透過硬編碼 linter、提交門控和最終人工審查決定能否合併。
換句話說，可靠性不是來自「模型突然足夠聰明」，而是來自一連串約束。模型負責提出候選改動，系統負責限制它能碰什麼、必須通過哪些檢查，人類負責最後判斷是否進入主幹。
這也是 Loop Engineering 與普通 AI 程式設計腳本的差別。普通腳本往往把重點放在「讓模型完成任務」；循環系統必須考慮任務從哪裡來、失敗後如何處理、狀態如何保留、預算如何控制、誰來阻止錯誤進入生產環境。
如果沒有這些約束，每週 1300 個 PR 不是效率躍升，而可能是技術債務製造機。
Loop Engineering 的一個核心設計，是把生成器和評估器分開。
生成器負責寫程式碼、改檔案、提交候選結果。評估器負責挑錯，而且最好預設假設程式碼有問題。兩者不能由同一個「樂觀代理」完成，因為模型在自我評分時往往傾向於認可自己的輸出，尤其是在任務描述模糊、測試覆蓋不足或上下文不完整時。
獨立評估器可以更簡單、更懷疑，也更容易調優。它不需要創造性地解決問題，只需要驗證頁面能不能打開、測試能不能通過、邊界條件有沒有破、程式碼是否符合既定規則。有些實踐會讓評估器透過瀏覽器自動化工具實際點擊頁面，而不是只讀程式碼後給出判斷。
這解釋了為什麼「驗證」是五步循環中最難的一環。程式碼生成已經越來越便宜，但證明一段程式碼真的正確，仍然昂貴。尤其是在大型程式碼庫中，錯誤不一定馬上暴露，測試也不一定覆蓋真實業務路徑。循環跑得越快，未被驗證的假設累積得也越快。
Loop Engineering 的風險不在於它會不會寫錯程式碼，而在於它可能讓團隊更難發現自己已經失去理解。
第一類成本是驗證債務。沒有被測試覆蓋的錯誤會在循環中不斷累積，直到某次合併或上線才集中爆發。第二類是理解力衰退。程式碼庫持續膨脹，但工程師沒有親手經歷關鍵設計選擇，心智地圖停留在舊版本。第三類是認知投降。人類開始預設接受機器輸出，只做形式上的批准。第四類是 token 消耗爆炸。重試、子代理、長上下文和多輪驗證會讓帳單迅速上升。
這四項成本會彼此餵養：測試不夠導致驗證債務，驗證債務增加後工程師更不願深入理解，理解下降又讓人工審查變成橡皮圖章，橡皮圖章式審查再推動更多自動重試和更高成本。
因此，同樣一套循環元件，在不同工程師手裡可能產生完全相反的結果。判斷力強、邊界清楚的人，可以用循環放大自己對系統的理解，把機器當作不知疲倦的執行層；判斷力弱或過度依賴自動化的人，可能在數月後變成自己系統的「守門人」，只會批准或拒絕，卻無法解釋系統為什麼這樣運行。
Loop Engineering 把一個長期趨勢推到更清楚的位置：程式碼、計劃、PR 和任務拆解正在變得接近免費，但「什麼是真正正確」沒有變便宜。
對企業來說，這意味著 AI 程式設計的投資重點可能從購買更強模型，轉向設計更穩的流程：任務邊界、上下文組裝、獨立評估、狀態持久化、預算上限、人工審查點，以及出現異常時如何停止循環。模型能力仍重要，但它只是系統的一部分。
對工程師來說，角色也在變化。過去的核心勞動是寫程式碼，現在越來越多的勞動變成審查機器產出的候選答案：它是否符合需求、是否破壞架構、是否只是看起來合理、是否把複雜性推給未來的維護者。
這並不等於程式設計師已經被取代。相反，Loop Engineering 更像是一台判斷力放大器。它能讓一名工程師產出過去小團隊才能完成的改動量，也能把懶惰、盲信和缺乏驗證的習慣放大成生產事故。
真正的分叉在於，人類是否還保留足夠強的判斷和否決權。AI 可以不斷提交 PR，但能不能合併、該不該上線、長期會不會拖垮系統，仍然取決於人。
點擊了解律動 BlockBeats 在招崗位
歡迎加入律動 BlockBeats 官方社群：
Telegram 訂閱群：https://t.me/theblockbeats
Telegram 交流群：https://t.me/BlockBeats_App
Twitter 官方帳號：https://twitter.com/BlockBeatsAsia
149.49萬 熱度
3.78億 熱度
31.04萬 熱度
220.09萬 熱度
97.03萬 熱度
全網都在聊的Loop Engineering，到底改變了什麼？
近日，一位 Anthropic 工程師發布了一份關於「智能體系統的循環工程」的 11 頁資料，把 Loop Engineering 放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之後，視為 AI 程式設計進入下一階段的關鍵方法。
這份資料之所以引發關注，是因為它剛好踩中了 2026 年 6 月 AI 程式設計討論的轉折點。Addy Osmani、Boris Cherny 和 Peter Steinberger 幾乎在同一週把 AI 程式設計的新階段稱為 Loop Engineering，而 Stripe 的 Minions 管道已經用類似思路每週合併 1300 多個 AI 生成 Pull Request。
這個數字之所以重要，不是因為 AI 又多寫了幾行程式碼，而是因為軟體開發的重心正在從「人類告訴模型寫什麼」，轉向「人類設計一個會自己排隊、取任務、寫程式碼、檢查結果、儲存狀態並繼續運行的系統」。
過去一年，AI 程式設計工具的敘事大多圍繞模型能力：程式碼補全更準、上下文視窗更長、代理能一次性完成更複雜任務。但 Loop Engineering 討論的是另一件事：當生成程式碼本身越來越便宜，工程師真正要設計的，變成一個可持續運轉的循環。機器可以不斷產出候選方案，人類要決定哪些結果可信、哪些必須擋下、哪些長期成本正在被隱藏。
近日，一位 Anthropic 工程師發布了一份關於「智能體系統的循環工程」的 11 頁資料，把 Loop Engineering 放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之後，視為 AI 程式設計進入下一階段的關鍵方法。這篇文章正是以這份資料為切口，結合 Boris Cherny、Addy Osmani 等人的公開討論，以及 Stripe Minions 每週合併 1300 多個 AI 生成 PR 的案例，解釋 Loop Engineering 到底是什麼、為什麼突然被全網討論，以及它真正改變的不是寫程式碼，而是軟體開發中的驗證、排程和判斷。
AI 程式設計從「一次提示」走向「持續循環」
Loop Engineering 被放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之後，作為 AI 工程棧的第四層。
Prompt Engineering 解決的是「怎麼問」；Context Engineering 解決的是「給模型看什麼」；Harness Engineering 解決的是「如何把一次模型運行接入工具、測試和工作流」。Loop Engineering 往前多走一步：系統不只執行一次任務，而是能在固定時間或觸發條件下重新啟動，把上一次結果作為下一輪輸入。
一個完整循環通常包含五個動作。
第一步是發現工作，例如掃描 CI 失敗、開放 Issue、程式碼提交或待處理任務；第二步是任務交接，把任務整理成模型可以處理的上下文；第三步是獨立驗證，檢查模型產出的程式碼是否真的執行、是否通過測試、是否引入副作用；第四步是結果持久化，把狀態、判斷和未完成事項寫入檔案或系統；第五步是排程循環，讓下一輪在合適時間繼續運行。
這裡最關鍵的並不是「生成」，而是「驗證」。如果一個循環只是不斷讓模型寫程式碼、再讓同一個模型誇自己的結果，它很容易變成「點頭循環」：每一輪都看似前進，實際只是把錯誤包裝得更完整。
Osmani 自己的晨間 triage 循環是一個個人版例子：系統每天自動讀取前一天的 CI 失敗測試、開放 Issue 和最近提交，生成狀態檔案，把無法處理的事項放進人工收件箱。它的價值不是替工程師做所有決定，而是在工程師醒來之前完成初篩，把注意力留給真正需要判斷的部分。
Stripe 的 1300 個 PR：可靠性來自約束，不是模型
Stripe 的 Minions 管道是這輪討論中最具衝擊力的企業案例：每週合併超過 1300 個 AI 生成 Pull Request，且程式碼本身沒有人工逐行編寫。
但這並不等於 Stripe 把生產系統交給一個大模型自由發揮。相反，Minions 的關鍵在於高度受控的流程：確定性編排器先組裝上下文，從 Jira、程式碼搜尋和內部工具中提取任務資訊；LLM 負責生成程式碼；之後透過硬編碼 linter、提交門控和最終人工審查決定能否合併。
換句話說，可靠性不是來自「模型突然足夠聰明」，而是來自一連串約束。模型負責提出候選改動，系統負責限制它能碰什麼、必須通過哪些檢查，人類負責最後判斷是否進入主幹。
這也是 Loop Engineering 與普通 AI 程式設計腳本的差別。普通腳本往往把重點放在「讓模型完成任務」；循環系統必須考慮任務從哪裡來、失敗後如何處理、狀態如何保留、預算如何控制、誰來阻止錯誤進入生產環境。
如果沒有這些約束，每週 1300 個 PR 不是效率躍升，而可能是技術債務製造機。
生成器和評估器必須分開
Loop Engineering 的一個核心設計，是把生成器和評估器分開。
生成器負責寫程式碼、改檔案、提交候選結果。評估器負責挑錯，而且最好預設假設程式碼有問題。兩者不能由同一個「樂觀代理」完成，因為模型在自我評分時往往傾向於認可自己的輸出，尤其是在任務描述模糊、測試覆蓋不足或上下文不完整時。
獨立評估器可以更簡單、更懷疑，也更容易調優。它不需要創造性地解決問題，只需要驗證頁面能不能打開、測試能不能通過、邊界條件有沒有破、程式碼是否符合既定規則。有些實踐會讓評估器透過瀏覽器自動化工具實際點擊頁面，而不是只讀程式碼後給出判斷。
這解釋了為什麼「驗證」是五步循環中最難的一環。程式碼生成已經越來越便宜，但證明一段程式碼真的正確，仍然昂貴。尤其是在大型程式碼庫中，錯誤不一定馬上暴露，測試也不一定覆蓋真實業務路徑。循環跑得越快，未被驗證的假設累積得也越快。
隱性成本會互相強化
Loop Engineering 的風險不在於它會不會寫錯程式碼，而在於它可能讓團隊更難發現自己已經失去理解。
第一類成本是驗證債務。沒有被測試覆蓋的錯誤會在循環中不斷累積，直到某次合併或上線才集中爆發。第二類是理解力衰退。程式碼庫持續膨脹，但工程師沒有親手經歷關鍵設計選擇，心智地圖停留在舊版本。第三類是認知投降。人類開始預設接受機器輸出，只做形式上的批准。第四類是 token 消耗爆炸。重試、子代理、長上下文和多輪驗證會讓帳單迅速上升。
這四項成本會彼此餵養：測試不夠導致驗證債務，驗證債務增加後工程師更不願深入理解，理解下降又讓人工審查變成橡皮圖章，橡皮圖章式審查再推動更多自動重試和更高成本。
因此，同樣一套循環元件，在不同工程師手裡可能產生完全相反的結果。判斷力強、邊界清楚的人，可以用循環放大自己對系統的理解，把機器當作不知疲倦的執行層；判斷力弱或過度依賴自動化的人，可能在數月後變成自己系統的「守門人」，只會批准或拒絕，卻無法解釋系統為什麼這樣運行。
程式碼變便宜後，貴的是判斷
Loop Engineering 把一個長期趨勢推到更清楚的位置：程式碼、計劃、PR 和任務拆解正在變得接近免費，但「什麼是真正正確」沒有變便宜。
對企業來說，這意味著 AI 程式設計的投資重點可能從購買更強模型，轉向設計更穩的流程：任務邊界、上下文組裝、獨立評估、狀態持久化、預算上限、人工審查點，以及出現異常時如何停止循環。模型能力仍重要，但它只是系統的一部分。
對工程師來說，角色也在變化。過去的核心勞動是寫程式碼，現在越來越多的勞動變成審查機器產出的候選答案：它是否符合需求、是否破壞架構、是否只是看起來合理、是否把複雜性推給未來的維護者。
這並不等於程式設計師已經被取代。相反，Loop Engineering 更像是一台判斷力放大器。它能讓一名工程師產出過去小團隊才能完成的改動量，也能把懶惰、盲信和缺乏驗證的習慣放大成生產事故。
真正的分叉在於，人類是否還保留足夠強的判斷和否決權。AI 可以不斷提交 PR，但能不能合併、該不該上線、長期會不會拖垮系統，仍然取決於人。
點擊了解律動 BlockBeats 在招崗位
歡迎加入律動 BlockBeats 官方社群：
Telegram 訂閱群：https://t.me/theblockbeats
Telegram 交流群：https://t.me/BlockBeats_App
Twitter 官方帳號：https://twitter.com/BlockBeatsAsia