或者：框架本身是不夠的
更新 - 這篇文章的演講版本已在 YouTube 上線：https://www.youtube.com/watch?v=Ib5GBkD555M
我想我們現在真的要開始循環了
大家都在爭先恐後地將 AI 編碼導入生產環境。關於循環工程已經有很多討論，而普遍的共識是，我們應該寫更多的循環。
StrongDM 寫了關於他們的關燈軟體工廠，在那裡沒有人類閱讀程式碼，也沒有人類撰寫程式碼。
這個論述大致是這樣：
- 你就是瓶頸。
- 模型已經夠好了。
- 程式碼是免費的。
- 只管出貨更多東西。
來自 OpenAI 的 Ryan Lopopolo 在二月寫了關於這個主題，並在四月發表了一場演講，介紹 OpenAI 的軟體工廠 Symphony。
這些人都非常非常聰明，我對他們懷有極大的敬意。但這裡最憤世嫉俗的看法，可能是將這稱為另一種藉口，好讓更多創投資金注入這台內容垃圾砲。
嗯...它正在運作
我們的朋友 Mario 在 AI Engineer Europe 站起來，懇求我們放慢腳步——因為那些本不該因為編碼代理失誤而導致停機的公司，嗯...確實因為編碼代理失誤而導致了停機。
正如 Matt Pocock 所說，程式碼庫比以往任何時候都更快地瓦解。
我一直無法從 StrongDM 找到關於他們那個黑暗工廠運作情況的明確數據或發現。天氣報告從今年二月到六月只有零星幾次更新。編輯註記 - 7 月 23 日在 Hacker News 上與團隊有一些對話 - 聽起來我們可能很快就會收到更正式的更新！
Faros AI 的團隊發布了一份報告：自從我們2 所有人都在今年一月和二月開始使用這些 AI 編碼工具以來，程式碼審查的品質大幅下降。
- 評論更多、評論更長，而且有大量 PR 在完全沒有審查的情況下就被合併。
- 事件數量大幅增加。
- 每位開發者的 Bug 數量也大幅增加。
這份報告與其說是一個可驗證的鐵證（是的，我故意選了這個詞，別讓我開始吐槽 Claude 的文風），不如說是一個相關性信號。而這篇文章的重點就是要警惕垃圾數據，但根據我所見到的情況，它在方向上感覺是正確的。
「你使用的方式錯了」（你沒有錯）
很多人會告訴你，這是個技術問題——如果你沒有得到好的結果，那是你的錯。
但無論你選擇...嗯...以何種方式使用它，我保證你一定聽過這種說法：如果 token 最大化對你不管用，那是你的技術問題。你只需要花費更多 token。放手不去閱讀程式碼。如果你才剛開始，我保證這會是必經的過程。去年夏天我也是這麼想的。
不幸的是，為了我的自尊心，我過去關於「如何更好地使用它」所說的一些蠢話被錄了下來，現在在 YouTube 上累積了約一百萬的觀看次數。我不是想在這裡炫耀，我分享這些只是想證明，我已經在深入探索使用編碼代理的最佳方法上投入了很長一段時間，並且發現了一些對許多人來說真正有用的東西。
總之，所有這些我們被迫忍受的線上「只管用更多 token」的胡扯所承諾的，簡而言之就是：透過足夠的框架工程，我們可以兩全其美：
- 速度快 10 到 100 倍，
- 品質高，而且
- 再也沒有人需要做我們都討厭的那件事：程式碼審查
我們所要做的就是配置更多的 lint 工具，並在一些 PR 審查機器人上灑上一些像「對抗性審查」這樣的魔法詞彙，那麼我們的軟體就能愉快地自行構建，而不會發生任何事故。
這不是技術問題
我想要說服你的是，無論多少框架工程或循環最大化，都無法解決根本上是模型訓練的問題。
為了理解這個問題，我必須深入研究編碼模型實際上是如何訓練和評估的——包括 RLVR 和基準測試這兩個方面。
在這篇文章中，我將探討：
- 軟體工廠可追溯到 1968 年，它們是如何演變的，以及 AI 如何改變了它們
- 為什麼模型能夠在基準測試（即使是全新的「前沿」基準測試）中表現出色，卻仍然能產生大量的垃圾內容
- 儘管如此，你仍然可以在不燒掉程式碼庫的情況下快速前進
我將試圖穿透每天層出不窮的技能插件和 AI 精神病式 token 最大化建議的流行浪潮，並以一般性的術語來討論哪些類型的東西是有效的，而不會特別提及任何特定的技能或框架。
影片版本： 這篇文章基於（並擴展了）我在 2026 年 AI Engineer World's Fair 上的主題演講。
感謝 @addyosmani、@CyrusNewDay、@HamelHusain、@zeeg、@dillon_mulroy、@nayshins 和 @jeffreyhuber 對這篇文章的回饋。
題外話：這與直覺編碼無關
Addy Osmani 釐清了這個值得強調的觀點：
一個開發者用直覺編碼做一個最終只有十幾個人會運行的 side project，和一個團隊為了讓一個十年的企業級系統再撐一季，兩者所面臨的限制幾乎沒有任何值得提及的共同點。而市面上流傳的大部分建議，其實只是這兩種人中的一種在告訴另一種人該怎麼生活。
如果你喜歡直覺編碼，請繼續享受那種感覺。我仍然會用直覺編碼做很多事情，只是我同時也維護著大量的生產級軟體（並透過 HumanLayer 幫助其他數千名工程師做到這一點），所以接下來的內容是針對那些在複雜程式碼庫中解決困難問題的人。
我經常聽到棕地這個詞來描述這種區別。過去，這通常指的是某個十年的 Java 專案，但以我們現在能出貨的速度，感覺一個由代理構建的程式碼庫可能在三到六個月後就會開始出現問題——你開始變慢，添加新功能的方法也必須改變。
軟體工廠簡史
我的整個職業生涯都在構建和研究軟體工廠，但我是最近才學到這個詞：它可以追溯到 1968 年的一次 NATO 會議——就是那次給了我們「軟體工程」這個詞的會議。
從那時起，我唯一覺得非常有趣的事情是，美國國防部寫了一份 31 頁的 PDF，內容大概是關於國防部需要如何更好地使用 Jenkins 之類的。
2022 年的軟體工廠
讓我們將「軟體工廠」的定義錨定在 2022 年左右，也就是 AI 出現之前。在一個典型的軟體工廠中：
- 人們決定要建構什麼——由工程師、產品經理、領導層驅動願景
- 它被放入追蹤系統——Linear、Jira 之類的：一個關於需要做什麼的狀態機
- 有人接了一個票證並開始建構——可能在建構的同時進行一些手動/自動化測試
- 發起 Pull Request——自動化檢查，有人類審查程式碼，也許有人會拉下來測試
- 有任何問題嗎？ 循環回「有人建構東西」的步驟
- 發佈到生產環境——然後與用戶接觸
- 加入監控——整個產業都建立在當東西在凌晨 3 點壞掉時，能 call 工程師起來處理
- 用戶抱怨——要求新功能、發現 Bug、提交功能請求 → 回到團隊，將其加入追蹤系統
就這樣一直循環。我們甚至還沒提到 AI，這個圖景中就已經存在好幾個循環了。
前置對齊
團隊在幾十年前就發現了一件事：建構需要數小時或數天，審查也是如此。
所以我們把工作前置——規劃、架構提案、衝刺規劃——以團隊的形式一起進行。這意味著：
- 減少返工，因為我們在任何人寫程式碼之前就已經對齊了方向
- 減少審查每一行程式碼的時間，如果你曾經讀過一個很長但寫得很好的 PR，你就知道當它接近完美時，審查會有多快
我們稍後會回到這個主題——現在先來看看當你把代理驅動的編碼引入這個圖景時會發生什麼。
代理驅動的軟體工廠
現在，每家公司——包括他們的母公司——
在今年的大部分時間裡都在解釋他們如何建立了一個代理工廠，能夠出貨 約 75% 的程式碼。
代理驅動的工廠看起來主要是將「有人建構東西」→「一個代理建構東西」——這裡有一些東西，像是編排、框架、沙盒、模型、電腦使用等等。我不會深入探討這些細節，因為老實說，我已經厭倦了閱讀這些內容，我相信你也是。
當代理建構東西時：
- 建構時間從數小時或數天下降到數分鐘或數小時。
- 審查仍然需要數小時或數天。人類仍然需要閱讀程式碼並測試變更。所以審查現在成了瓶頸。
所以你也加快了審查速度：
- 代理驅動的程式碼審查，用來捕捉風格、錯誤、安全性問題。
- 代理驅動的回歸測試，用瀏覽器和電腦使用從外部進行測試，完成後也許會發送一個可愛的小影片給你
現在審查更快了，但它可能仍然是瓶頸。但我們可以做更多的循環。
接下來，你可能會將事件路由到工廠中。這樣一來，工程師就不會在凌晨 3 點被 call 起來，而是醒來時發現一個可能已經修復問題的 PR。
我們也可以將用戶回饋路由到工廠中。人們要求東西，然後東西就被建構出來。
此時，工作就只剩下兩個問題：你能塞進佇列多少東西，以及你能多快審查和測試產出的結果？
這就引出了關燈軟體工廠。
關燈軟體工廠
Dan Shapiro 創造了這個詞，Simon Willison 寫了關於 StrongDM 的實現——在那裡我們不再閱讀程式碼。
你看著你美麗的軟體工廠。它被那個煩人的小程式碼審查步驟給毀了，然後你說：你知道嗎？那個必須讓一個人閱讀每一次變更的步驟？算了吧。
所以你放棄了它，並把精力投入到其他地方：
- 投資於測試，讓代理自行測試其工作
- 投資於沙盒和編排
- 投資於自動化審查
- 投資於監控
- 投資於上線發布
- 投資於收集來自用戶的回饋信號
而現在，工作真的只剩下一個問題：我們可以要求代理建構多少東西？我們想要煮沸多少海洋？
這將會非常順利（才怪）
我將提出一個可能具有爭議性的觀點：關燈工廠行不通。
讓我們來探討為什麼軟體工廠會失敗。
我們試過了
在 2025 年 7 月，我們全面進入了關燈模式。只閱讀規格說明和票證，所有中小型任務都由背景代理處理，就是這樣。
如果你認真嘗試過幾個月，你已經知道結局會如何。你會發現至少有一個問題棘手到代理無法解決——即使使用了你最進階的提示和 workflow。
- 你進行深入的上下文感知研究，將所有正確的部分彙整到模型的智慧區域供其分析
- 你讓代理嘗試用 10 種不同的方式重現問題
最終，你不得不硬著頭皮，深入挖掘你三個月前就不再閱讀的程式碼庫，試圖找出問題所在。
而與此同時：
- 你的網站當機了。
- 你的用戶很生氣。
- 而你，如果你跟我一樣，會感到非常痛苦——閱讀所有你讓它溜進系統的垃圾程式碼。
這種情況第一次發生時，我甩甩頭就算了。儘管我剛剛花了將近兩週的時間在 Claude 的義大利麵式程式碼中挖掘，但「承擔風險的代價換來速度是值得的」。到了 11 月大約第三次發生時，我們決定重寫可能更簡單，而我的共同創辦人花了整整兩週在 VS Code（甚至不是 Cursor）裡，用手動方式把所有模式重新搭建出來。
模型會隨著時間推移降低程式碼庫品質
我想要表達的是：模型有一個缺陷。它們無法隨著時間推移維持和改善程式碼庫的品質——如果沒有相當程度的人類引導的話。4
當我說可維護性時，我指的是那種特定情況：修改程式碼庫的一部分變得非常非常困難，而不會破壞另一部分。這就是 Martin Fowler 所說的散彈式修改。
關於可維護性，我不打算多說。有許多書你可以去閱讀：
那麼，為什麼模型不能做軟體可維護性呢？
「但模型從那時起肯定已經變得更好了」
此時你可能會想說：但是 Dex，模型從七月以來肯定已經進步很多了
它們在某些方面確實進步了。在其他方面則差不多。
- 解決一次性問題，或者用直覺編碼做一個新的行銷網站？是的，好多了。
- 隨著時間推移改善程式碼庫品質？就我所知，並沒有好多少。
我無法證明這一點。你也無法證明。目前沒有任何好的基準測試能夠衡量模型維持程式碼庫品質的能力。（關於這方面的進展，稍後會詳細說明。）
目前沒有任何好的基準測試能夠衡量模型維持程式碼庫品質的能力
但如果你使用編碼代理已經有一段時間——而且很多人正在發布關於這個確切問題的貼文——你可能已經有這種感覺了：它們傾向於隨著時間推移讓事情變得更糟，讓程式碼庫更難維護。
所以，為了弄清楚為什麼會發生這種情況，我想放大到第一個偉大的編碼代理。
Claude Code 獲勝是因為框架內的強化學習
Claude Code 在不到一年的時間內，從零成長到約 40 億美元——現在大概是 90 億美元——的收入。
這有點瘋狂，因為市面上已經有很棒的 CLI 代理了。aider、cline、codebuff——它們都早於 Claude Code，都內建了真正優秀的上下文工程，並且都擁有你可能歸功於 Claude Code 的相同工具集：讀取、寫入、編輯、grep、bash。我使用過它們。它們很好。但有時候，工具使用就是會...失敗——你會看著它對同一個編輯操作掙扎三次，然後重新打開你的編輯器自己動手。
2024 年的 SWE-Agent 論文 概述了工具形狀的微小變化如何帶來顯著的差異，例如在 ReadFile 結果中包含行號，或者將編輯工具從查找/替換更改為行範圍編輯。
然後 Claude Code 推出並迅速呈垂直增長。你可以將此歸因於分發優勢，但普遍接受的解釋是，Claude Code 獲勝是因為它更好，而它更好是因為 Anthropic 在框架內部對模型進行了強化學習——這是實驗室第一次針對他們將要出貨的特定工具集來訓練模型。而它在代理循環中調用這些工具的能力變得非常非常出色。
調整工具定義和評估直到找到模型最喜歡的形狀是一回事——我曾經為了各種用例在這上面花了數週時間。但當你擁有權重，並且可以修改模型本身以使其更擅長特定工具集時，情況就完全不同了。
OpenAI 團隊在 11 月發表了一場演講，很好地說明了這一點：如果你構建了一個框架，但你不擁有權重，也無法在框架內對模型進行強化學習，你將永遠處於劣勢，相較於那些同時擁有這兩者的團隊。
60 秒了解編碼代理的強化學習
我對此做了大量研究，並製作了一系列視覺化圖表來解釋關鍵部分，但我發現 Calvin French-Owen（Codex 團隊的 MTS，Segment 的創辦人）在 AI Council 的演講做得更好、更清晰，所以我將直接在這裡展示這個受他投影片啟發的動畫：
要讓模型更擅長編碼，你需要：
- 產生一些編碼代理的軌跡來解決一個問題（例如，修復我的測試）
- 根據某些標準（驗證器）對這些軌跡進行評分
- 更新模型權重，使好的軌跡更有可能出現，壞的軌跡更不可能出現
然後，你需要數百萬次地重複這個過程，持續數週或數月。
然而，這些「評分」部分往往會趨向於令人沮喪的單一維度。
不良設計不會受到懲罰
以 SWE-bench Multilingual 為例。這些任務很小——每個大約十五分鐘的工作量——從像 Redis、jq 和 Django 這樣的開源儲存庫中抓取出來。獎勵是基於以下條件給予 1 或 0：
- FAIL_TO_PASS - 你是否修復了要求你修復的問題？
- PASS_TO_PASS - 你在修復的同時是否沒有破壞其他東西？
這裡有一個真實的案例，fastlane__fastlane-19304，來自 fastlane——一個 Ruby 專案。它的 zip action 抓取了兩個可選參數，並立即對它們調用 .empty? 方法，所以一旦你省略了 include 和 exclude，它就會崩潰：
關閉這個特定 issue 的人類修復是兩行程式碼（將預設的 nil 設為空陣列）：
在評估過程中，模型會
- 從一個基礎提交開始——儲存庫被 checkout 到那個修復剛剛被應用之前的時刻
- 錯誤報告——在這個案例中，是 'zip_command': undefined method 'empty?' for nil:NilClass
代理會根據 issue 去編寫一些程式碼。它看不到 golden patch 或作為評分依據的測試 patch：
然後：
- 我們保留它產生的任何 patch，然後
- 丟棄它對測試檔案所做的任何編輯（我們曾抓到模型悄悄地註解掉失敗的測試，或拼接一個使測試變得無用的 mock）
- 在之上套用基準測試的測試 patch，然後
- 運行整個測試套件：現有的 zip 測試（PASS_TO_PASS）加上新的測試（FAIL_TO_PASS），看看它們是否都通過
題外話 - 基準測試不是驗證器——事實上，它們必須彼此隔離（不要在測試資料上訓練，等等等等）——我主要想藉此傳達「判斷編碼代理軌跡品質」的形狀及其局限性。
模型如何得到正確答案並不重要。只要測試通過，我們就贏了，但是不會因為侵蝕程式碼庫的可維護性而受到懲罰。
不會因為侵蝕程式碼庫的可維護性而受到懲罰
這就是為什麼你會到處看到 try catch：
驗證品質比「測試通過了嗎」還要困難好幾個數量級
運行測試可以在約幾秒鐘內得到一個清晰的通過或失敗結果。這就是為什麼強化學習可以運行數百萬次循環來優化每個模型版本。
但不良架構的成本函數是以數週、數月甚至數年來衡量的。它發生在第一次有人為了做一個一行變更而打開那個檔案，卻發現他們無法在一行內完成——有人對這個檔案進行了過度的直覺編碼，現在我們必須在十一個地方做同樣的編輯，並希望沒有東西悄然破壞三個檔案以外的東西。
測試能在幾秒鐘內給你回饋，但不良架構的成本函數是以數週、數月甚至數年來衡量的
不良設計是今天的基準測試無法評估的一件事情。而且我知道，我知道，強化學習不等於基準測試，但如果這個問題在強化學習中解決了，我很確定它也會開始在我們設計基準測試的方式中顯現出來。
無論如何，我個人不相信今天基準測試上的任何改進，能作為模型突然變得更擅長不搞亂你程式碼庫的指標。
前沿正在緩慢進步
當然，很多聰明人正在致力於此。我的觀點不是說這件事做不到，而是炒作已經超越了紀律。
我認為方向正確的一些努力：
- SWE-Marathon（Abundant AI）：約 400 小時的任務，例如「完整複製整個 Excel，所有功能」——使用複合獎勵通道，而不是單一的通過/失敗位元
- DeepSWE（Datacurve）：針對開源儲存庫的大規模任務，這些任務在現實世界中從未被實際建構過，因此從結構上來說，它們不可能已經存在於訓練集中（解決了資料污染問題，但沒有解決品質問題）
- Frontier Code（Cognition）：多 PR 任務，以及一個巧妙的舉措，即確定性地評估品質——它會懲罰模型編寫那些在 pre-patch 程式碼上不會失敗的測試（如果你從未聽說過突變測試，你將迎來一場有趣的旅程5）。它還運行一個評判模型來檢查差異中的程式碼品質規則。
但由模型來判斷品質只能做到一定程度。
事實上，不難想像，如果一個模型能可靠地分辨程式碼的好壞，它可能一開始就會寫出好的版本。強化學習需要一個快速且可靠的評判標準，而我們目前還沒有針對可維護性的評判標準。
如果一個模型能可靠地分辨程式碼的好壞，它可能一開始就會寫出好的版本，但可維護性沒有快速的評判標準，所以我們無法在強化學習過程中針對它給予獎勵。
當然，更多的審查 Agents 和更多的 tokens 確實有幫助──它們能提升下限，抓出那些愚蠢的錯誤。
但它們無法提升上限，因為上限取決於我們在強化學習中教會模型的東西，而良好的設計正是我們還不知道該如何教導的東西。
所以我仍然不會把我的程式碼庫押注在任何這些方法上。但它們是我見過最早嘗試評估可維護性，而非只停留在通過/失敗的評測。
題外話 也許未來的模型能直接理解這個問題，我們就可以停下來了。如果你想一路瞎試指令直到 GPT-7 問世並看看結果，請便吧──但苦澀的教訓去他的，我們現在就有問題要解決，而我會說明我們該怎麼做。
重新點亮燈光
今天我才發現 Twitter 文章有「媒體限制」，所以這篇的後續內容會放在第二部分──敬請期待。
