剛剛，一篇阿里聯合中山大學的研究在 X 上爆火了！今天一早，一位微軟產品故事講述者、前Google負責人級布道師 Priyanka Vergadia 分享了一則 X 帖子迅速走火，短短一天內獲8700+點贊、170萬+瀏覽。這篇高贊帖子描述了一項來自阿里巴巴團隊的研究，它是一場 233 天、總消耗達 100 億 token ，在真實生產環境中對主流的 8 家模型廠商提供的 18 個智能體的“耐力”實驗，最終證明了 AI 不會搶走人類開發者的飯碗！Priyanka 總結說：AI 只是編寫了一些遺留程式碼，未來十年你都得忙著修復它們！而一位業內人士對此表示，該項真正的重點在於：阿里團隊做了一個真正有意義的評分體系！小編這就帶大家看下這篇研究。戳破泡沫：一次性修復不叫“程式設計”，那叫“撞大運”該篇論文的名稱是《SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration》，由阿里巴巴集團與中山大學聯合完成。論文拋出了一個業內都有明顯體感，但沒人著手思考解決的“長期軟體評估”問題：現在的AI Agent，在 HumanEval 或 SWE-bench 這種“單向考試”裡刷分刷得飛起。只要給它一個明確的Bug，它就能咔嚓一下修好。但現實開發的現狀是： 程式碼是“活”的。今天你修了一個Bug，明天產品經理改了需求，後天底層依賴庫升了級。這一過程並不能被靜態、一次性的修復範式所刻畫。阿里和中山大學的研究團隊提出來一種新的性能標準： 衡量一個 AI 牛不牛，不看它能不能修好眼前的Bug，而要看它在長達半年的項目演進中，能不能不把程式碼庫搞崩。SWE-CI：233天、耗費百億token的“極限耐力賽”因此，為了測試AI的真實“抗壓能力”，研究團隊祭出了一種基於持續整合（Continuous Integration）流程建構的倉庫級基準：SWE-CI，首次將軟體工程評估從“一次性快照”轉向“長期演化”。該基準包含 100 個真實程式碼庫任務，每個任務平均對應一個真實程式碼倉庫中長達233天、包含71次連續提交的演進歷史。簡單理解，SWE-CL 就是對是一場極為殘酷的“智能體耐力賽”！真實戰場： 選取的任務跨度平均達 233天，涵蓋 71次連續提交。模擬人類： AI不再是修完就跑，而是要像真正的開發者一樣，在 CI（持續整合） 的死循環裡，應對一輪又一輪的需求變更。殘酷規則： 這是一場總消耗超過 100億 Token 的極限耐力賽。這裡列出一些更詳細設定：每個SWE-CI任務都來自GitHub上68個真實Python倉庫（維護≥3年、≥500星、含單元測試和依賴配置檔案）。任務定義為：從“基線提交”（base commit）演化到“目標提交”（oracle commit），平均跨越233天、71次提交、至少500行原始碼變更（不含測試）。代理必須在 Docker 隔離環境中，通過最多20輪迭代，逐步完成需求變更。值得注意的是，雙Agent架構：架構師Agent：分析失敗測試、定位根因，輸出1-5條高層次增量需求文件。程式設計師Agent：遵循TDD（測試驅動開發）流程，實際修改程式碼。整個過程模擬真實CI/CD流水線，每一次變更都會影響後續狀態，前期決策的後果會逐步累積。這正是傳統基準無法模擬的“長期記憶”與“技術債務放大器”。因此，評估指標也從單一通過率升級為兩個核心維度：1、零回歸率（Zero-Regression Rate）：在任務演化過程中，最初通過的測試在後續變更後仍保持通過的比例。2、lEvoScore：一種加權平均指標，公式為 EvoScore = Σ(i=1 to N) γ^i × a(ci) / Σ(i=1 to N) γ^i，其中γ＞1對後期迭代賦予更高權重，強調長期穩定性。當γ=1時退化為普通平均歸一化變更得分。戰況慘烈：75% AI正在瘋狂製造“技術債”實驗結果讓所有人脊背發涼。即便是在2026年這樣一個 Vibe Coding 都顯得落伍的時間點，主流智能體的表現依然像個“只會打補丁的實習生”。第一，“零回歸率”之痛：在模擬真實開發的長期測試中，絕大多數大模型的“零回歸率”竟然不到 25%。這意味著它們每改四次程式碼，至少有三次會搞壞原本正常的功能。第二，程式碼庫雪崩： 隨著項目演進，大多數模型產生的技術債呈指數級增長。前期看似高效，後期改動一下，整個系統直接原地爆炸。那麼，這場耐力賽中，誰是最後贏家呢？如果你對程式設計Agent有關注，相信你已經猜到了，自然是 Claude 4.5/4.6。它是唯一能在長周期維護中保持 50%以上零回歸率的選手，展現出了極強的“架構師思維”。GLM-5： 作為國產大模型的代表，在應對長期程式碼演進時表現搶眼，穩居第一梯隊。驚喜發現：GLM、Kimi是救火隊長，DeepSeek、Minimax是架構大師值得注意的是，論文中還發現了智能體也存在明顯的“AI人格”現象。不同模型廠商之間的偏好差異顯著，而同一廠商旗下的程式設計智能體往往表現出一致的傾向。具體而言：“走一步看一步”型（Kimi, GLM）： 這些模型在修改程式碼時更激進，追求立刻解決當下的 Bug 或需求，但在長遠看來，它們可能較快地耗盡了程式碼庫的演進空間。“長線規劃”型（GPT, DeepSeek, MiniMax）： 這些模型在修改時可能更謹慎，會考慮到程式碼結構對未來的影響，更具有“架構師”潛質。“全能穩健”型（Claude, Doubao，Qwen）： 無論你更看重眼前還是長遠，它們的表現都非常均衡。尤其是 Claude，結合之前的排名看，它是在保持穩定的同時，水平上限也最高的選手。具體怎麼做的呢?團隊通過調整參數 γ 的值，來觀察模型排名隨之產生的變化。當 γ<1 時，EvoScore 會給早期迭代分配更高的權重，這有利於那些優先考慮程式碼修改“即時收益”的模型。相反，當 γ>1 時，後期迭代會獲得更多獎勵，從而讓那些為“長期改進”而最佳化（即優先考慮程式碼可維護性）的模型佔據優勢。對於這個現象，研究人員推測，這反映了不同廠商在訓練策略上的差異；而各廠商內部模型的一致性則表明，其內部訓練流水線（Pipelines）在大體上保持了穩定。為什麼智能體如此容易積累技術債務？論文間接給出兩點原因：首先是短期最優決策：模型傾向於“最快通過當前測試”的方案，而非全域最優架構。上下文遺忘：即使多輪迭代，模型對早期變更的深層影響理解不足。其次，模型有依賴與邊界敏感性：真實倉庫的外部依賴、配置漂移、邊緣案例遠超訓練資料覆蓋範圍。這意味著：現實中，一家公司若大規模採用AI生成程式碼，初期交付速度可能翻倍，但6~12個月後維護成本可能指數級上升——bug修復、重構、遷移難度都會放大。未來方向：從“快修”到“可持續”這篇論文可以說用一場真實大規模實驗，驗證了一點：目前的絕大多數 AI Agent 都是“紙牌屋建築師”。它們追求當下的測試通過率，卻對程式碼的長期生命力一無所知。而 SWE-CI 的意義在於，它把 AI 程式設計的門檻從“跑得通”拉高到了“可維護”的實用層面。SWE-CI更多的意義在於提供“診斷工具”：企業可利用類似基準測試自家 AI 工作流，提前識別那些模型適合“長期駐紮”。他們給出了三個 SWE-CI 的最佳化方向：其一，提高γ權重可鼓勵模型追求長期穩定；其二，雙Agent架構可進一步最佳化（例如加入“回顧Agent”反思歷史決策）；其三，與現有工具鏈結合（如自動生成維護文件、回歸測試優先順序排序）有望緩解問題。智能體有希望在耐力上獲得成功嗎？但研究者的本意，並不是祛魅智能體，“ SWE-CI 本身就是進步的催化劑”。他們認為，智能體在耐力上是有望突破的。首先，Claude 4.5/4.6的領先或許預示著，更強的推理能力（而非單純生成）是突破關鍵。其次，未來模型若能內建“架構意識”“債務評估模組”，或與靜態分析工具深度融合，維護能力或將迎來質變。項目已開源目前，SWE-CI 開源倉庫和 Hugging Face資料集都已上線，大家都可以自行復現、擴展。這意味著，2026年之後，AI編碼競賽的賽道將從“誰寫得快”轉向“誰寫得穩”。SWE-CI 開源地址：https://github.com/SKYLENAGE-AI/SWE-CIhttps://huggingface.co/datasets/skylenage/SWE-CI網友炸了：1000億美元，就是為了自動化技術債務？正如論文中所說：“Agent 的程式碼維護能力只有通過長期演化才能顯現，過去決策的後果會在連續變更中累積。”對此，不少網友表示無語了：AI Coding 的越快，積累債務的速度也就越快！X 評論區也有人諷刺：“AI自動化了遺留程式碼的生產線”、“我們花1000億美元算力，就是為了完美模擬一個‘快速出貨、8個月後棄坑的初級開發’”。HN 討論區甚至有人提問：“當 SWE-CI 成為新標竿後，AI 編碼工具的估值邏輯是否需要重寫？”所以，這麼看，程式設計師的飯碗總算保住了。但網友卻調侃：“現在安全了？但能撐10年？10個月？還是10天？”“寫程式碼 ≠ 維護系統。” 一位名為 Stephen Collins 的 Medium 作者表示：軟體工程從來不只是“寫程式碼”。它更關乎如何管理複雜性、演進系統架構，以及在成千上萬次變更中保持關鍵不變數的穩定。而 SWE-CI 這一基準表明，這些挑戰對當前的AI智能體來說依然是難點。這也意味著，下一代開發者工具的重心，很可能會從“生成程式碼”，轉向“理解系統”。而與此同時，真正高效的開發者，永遠是那些能夠清晰理解系統的人：知道那些部分最關鍵，風險集中在那裡，以及注意力該放在那。 (51CTO技術堆疊)