![]()
![]()
作者 | 褚杏娟
一種新的、因 AI 代碼泛濫而出現的生意來了。
由 3 名資深工程師組成的團隊 Slopfix,開始專門從事清理由 AI 生成、能夠運行但難以維護的代碼庫的工作。其主要服務對象是已經使用 AI 完成產品原型或初步開發,但隨著項目規模擴大,新增功能越來越困難、修改一處卻導致多處故障的團隊。
該團隊認為,當 Vibe Coding 項目發展到一定規模后,幾乎都會遇到這樣的情況:Agent 無法再看清整個項目的全貌,于是不再尋找和復用已有代碼,而是不斷復制、重復實現相同邏輯。這會導致項目持續堆積冗余代碼,最終增加維護成本。
Slopfix 就是在此背景下誕生的。
具體來說,Slopfix 首先會提供免費的代碼庫初步分析。如果團隊判斷無法有效改善項目,會直接終止評估,不向客戶收費;如果認為項目適合重構,則會給出固定報價,并明確承諾一個代碼縮減目標,例如,“在功能完全不變的前提下,把 10 萬行代碼縮減到 3.5 萬行。”
其標準服務周期為一周,由 3 名資深工程師集中完成,基礎報價為 1 萬美元,最終費用則根據代碼縮減目標的實際完成比例計算。
例如,團隊承諾將代碼量減少 50%,但最終只減少了 20%。這意味著其只完成了目標的 40%,因此客戶只需要支付 4000 美元。如果達到或超過承諾目標,則支付全部費用。
其中,代碼行數通過 scc 工具統計,只計算非空行和非注釋行。同時,合同明確禁止“代碼高爾夫式”壓縮。團隊不會通過刪除注釋,或者把代碼壓縮成看似聰明、實際上難以閱讀的形式來完成目標。
Slopfix 團隊的具體服務流程是:在正式修改代碼前,Slopfix 會先和客戶一起把應用的全部功能逐項梳理清楚,包括每一個頁面、接口分別做什么,并形成一份質量保證檢查清單。“這份檢查清單既是我們的安全網,也是你的安全保障。”該團隊表示。
接著,團隊開始精簡代碼。Slopfix 會把 14 套日期格式化邏輯合并成一套;把手寫的自制框架替換成成熟的現有庫;把大量重復的業務邏輯整合起來。對于那些已經無法挽救的代碼,團隊會先提煉出它實際實現的功能,再用更干凈、清晰的方式重寫對應模塊。
最后,客戶會得到一個更小、更易維護的代碼庫、一份質量保證檢查清單,以及一套防止代碼重新失控的工程護欄,包括 CLAUDE.md、代碼檢查規則和持續集成檢查。這樣,客戶重新開始開發新功能時,可以減緩低質量代碼再次堆積的速度。所有成果都歸客戶。
此外,Slopfix 還提供兩周質保。如果其團隊破壞了原本正常運行的功能,會提供免費修復。
值得注意的是,Slopfix 表示自己同樣會使用 Claude Code,但強調會嚴格限制 Agent 的決策權限。
“真正的區別在于,我們 3 個人擁有合計 30 年的工程經驗,清楚什么樣的代碼才算真正可維護。而且,在最終決策中,Agent 沒有投票權。”該團隊強調,“我們不是 Agent。”
資深工程師轉做“AI 代碼返工”
Slopfix 官網顯示,團隊成員分別為 Maciej Zieliński、Jakub P?askonka(Kuba)和 Krzysztof Pobiar?yn。三人此前長期共同開發 Rust 智能合約框架 Odra,至少從 2021 年至 2022 年前后開始一起工作,合作至少有 4 年。
![]()
2022 年 11 月,Odra 發布首個公開版本時,三人已經形成穩定分工:Maciej 負責技術架構和社區生態,Kuba 與 Krzysztof 負責核心框架和工程實現。此后,三人持續維護 Odra 核心包、命令行工具、過程宏和不同區塊鏈后端。
截至目前,Odra 核心 Rust 軟件包的所有者名單仍包括 Maciej、Kuba 和 Krzysztof,說明三人仍共同維護該框架。
這些經歷與 Slopfix 所提供的代碼重構服務存在一定關聯。智能合約和 Rust 系統軟件通常強調類型安全、測試、代碼復用、接口邊界和長期兼容性,而 Slopfix 所批評的 AI 代碼問題,恰恰集中在重復實現、架構失控、缺乏統一抽象和可維護性不足等方面。
Maciej Zieliński 是三人中公開履歷相對豐富的一位,頭銜是 Slopfix 的“工程負責人”,此前長期擔任 Odra.dev CTO。Maciej 還曾在區塊鏈基礎設施公司 CasperLabs 擔任生態負責人,并且是 Casper 的核心開發者,主要承擔技術路線和框架架構工作。
大約在 2021 年前后,他離開 CasperLabs,并與 Kuba、Krzysztof 共同組建了一支專注智能合約開發的工程團隊,隨后推出 Odra 框架。
公開技術文章顯示,Maciej 還曾研究零知識證明、Risc Zero、EVM 執行環境以及 AI 生成智能合約等方向。2023 年,Odra 官網曾發布由他撰寫的文章,測試 OpenAI 模型能否使用 Odra 編寫 ERC-20 智能合約。
Kuba 是 Slopfix 的“工程主力”。從其公開代碼項目看,Kuba 的工作更偏向 Rust 工程實現、開發工具和智能合約工具鏈。他是 cargo-odra 項目的主要維護者之一。
Krzysztof 則為 Slopfix 的“工程骨干”,他把自己 Rust/AI 開發者。從 GitHub 公開項目看,Krzysztof 早期曾參與 Android、Java 和 Kotlin 相關項目,包括移動端日期選擇器、列表滑動刪除組件和應用開發項目。此后,他的技術重心逐漸轉向 Rust、智能合約和 WebAssembly。
在 Odra 框架中,Krzysztof 主要參與核心框架、代碼生成、過程宏和不同區塊鏈平臺的適配工作。2023 年,他曾負責將 Odra 框架接入 CosmWasm。此外,他還開發過用于 Rust 類型轉換的過程宏工具try_from_ref。其公開項目橫跨 Rust、Kotlin、Java 和 JavaScript。
“AI 代碼清理”生意引爭議
Slopfix 團隊官宣后,引發了很多開發者討論。
有網友表示,自己已經在從事類似工作。一名開發者稱,他正在為一位沒有技術背景、但大量使用 Claude Code 的創業公司 CEO 提供支持,其大部分工作是運行代碼審查流程、維護 Claude.md,并持續引導智能體采用正確的架構,避免重復過去的錯誤。
另一名擁有 20 年經驗的工程師也認同這種模式。他將 AI 代碼項目分成三類:完全不懂軟件的人純粹靠提示詞生成;了解軟件開發流程但不會編程的人使用 AI;以及能夠審查代碼、約束結構的工程師使用 AI。他認為,三類項目的代碼質量差距非常大,讓第三類工程師接手第一類項目,可能有明確價值。
“這種細分業務的出現只是時間問題。”有開發者評價道。
在其看來,AI 本質上是一種不精確的“編程語言”,它試圖用充滿歧義的自然語言,也就是英語,去表達不同概念之間精確的關系。在小規模、模塊化、像搭積木一樣的任務上,它確實非常好用。但隨著項目復雜度不斷增加,組件越來越多,還要與使用其他語言或 API 的異構系統交互,并且需要從上到下真正理解整個系統到底在做什么時,AI 的表現就會變得非常糟糕。
“這讓我想起當年 xUML 被宣傳成可以取代編程的萬能解決方案。AI 現在失敗的原因其實也差不多。至少 xUML 還有一套精確的定義,而使用 AI 時,你往往只是靠 Vibe Coding 的方式,一路摸索出一個定義。”
但并非所有人都認可這種模式。
“挺有意思的,也迎合了某種既有偏見,但所謂的“細分市場”其實并不存在。除了博眼球、讓大家點個贊外,我看不出它還有什么真實需求。如果他們能找到哪怕一個愿意付費的客戶,我都會非常驚訝。”有網友直言。
“我明白,對于那些已經深度依賴 AI 的公司來說,想向它們出售完全不借助 AI 的解決方案,可能幾乎不現實,哪怕它們現在遇到的問題,本身就是 AI 造成的。但我看到‘拿一個被 AI 膨脹出來的代碼庫,再用 AI 給它做瘦身’這種說法時,第一反應是這有點像連續做兩輪有損轉碼。前后兩次產生的誤差不會相互抵消,反而會彼此疊加、成倍放大。”
“問題是真實的,解決方案是幻想。”有網友更為犀利地說道。
很多開發者從自己的實踐經驗出發,指出了這個模式下的一些問題。
“你真的指望客戶坐下來,把所有細節都逐一解釋清楚嗎?如果他們有能力把這些事情講明白,可能一開始就不會擁有帖子里描述的那種混亂代碼庫。再假設你們已經接下了這個項目,清理完成之后又怎么辦?你認為只靠一份 Claude.md 文件,就足以讓項目從那一刻起繼續正常推進嗎?”上述開發者說道。
Slopfix 宣稱在正式修改代碼前,會逐個頁面、逐個接口梳理應用行為。但不少網友認為,真正困難的并不是識別重復代碼,而是理解隱藏在舊代碼中的業務規則、邊界條件和歷史兼容邏輯。
“對于包含復雜業務約束的軟件,一周時間未必足以完成理解和重構。”還有開發者認為,兩周質保也可能過短,因為某些缺陷可能數月后才會暴露。如果客戶本身沒有完整的自動化測試,就很難迅速確認重構是否破壞了原有行為。
也有網友認為,與其花費 1 萬美元整理舊代碼,不如定期使用更新的前沿模型,在保留數據庫結構和 API 等不可變部分的前提下,重新生成整個系統。
不過,反對者則認為,完全重寫并非正確選擇。已經運行的舊代碼往往包含大量沒有寫進文檔的隱含規則,即便實現方式不理想,也經過了真實使用的檢驗。更可靠的方法通常是先建立測試和行為基線,再逐步替換危險實現,而不是一次性推倒重來。
與此同時,這門生意也引起了大家對 AI 在大型項目中的表現到底如何的討論。
有人將 Vibe Coding 的典型風險概括為:系統最初可以運行,但結構脆弱;當出現錯誤時,模型往往繼續打補丁,使功能恢復,而不是回到架構層面解決根因。項目規模越大,后續重新識別模塊邊界、接口關系和業務規則的成本就越高。
但有開發者認為,大型項目并不必然超出模型能力。如果代碼庫具備清晰的模塊劃分、關注點分離和明確接口,AI 可以在復雜項目中帶來較高生產力。
“模型會傾向于尋找局部最快的解決方法,可能暗中連接原本相互獨立的系統,使結構逐漸退化。要維持模塊邊界和架構一致性,工程師必須主動施加約束,而一句籠統的“遵循最佳實踐”通常不夠。 ”有開發者表示。
另一項爭論集中在自動化測試。開發者 Simonw 認為,如果新增功能會破壞兩個已有功能,說明項目在生成階段沒有讓 Agent 執行紅綠測試驅動開發,并建立可靠測試套件。
“如果客戶已經擁有覆蓋完善的測試和驗收體系,那么它可能并不需要外部團隊代為調用 Claude 完成清理;而如果客戶沒有測試,外部團隊也難以在短時間內充分證明重構沒有造成回歸。”有開發這說道。但也有人質疑,測試只能證明部分行為沒有回歸,無法自動保證整個代碼庫具有良好的模塊化和可維護性。
“我分享這些,是因為在擁有 100 萬 token 上下文的智能體之后,替它們清理代碼,正在成為一門真實存在的工程師生意。”Slopfix 創始人在社區中表示。他也很好奇社區怎么看待這件事。
顯而易見,從大家的反饋看,如果“AI 代碼清理”要發展成一門長期生意的話,很多執行細節都有待商榷。不過,這確實也是一個新興職業剛發展時通常會面臨的問題。
AI 代碼持續積累技術債,22.7% 相關問題長期未解決
Slopfix 將自身定位為 AI 代碼治理團隊,而不是自動化 Coding Agent。其業務模式也反映出,在 AI 顯著降低代碼生成門檻后,如何控制代碼冗余、技術債和長期維護成本,正在成為新的工程需求。
AI 編程工具在幫助開發者修復部分代碼問題的同時,也會引入新的正確性和安全問題。
在一項研究中,研究團隊追蹤了 6299 個 GitHub 倉庫中的 302579 次已驗證 AI 提交,發現約 22.7% 的 AI 引入問題在項目最新版本中仍然存在,其中部分問題持續時間超過 9 個月。該論文題為“Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild”。
![]()
研究樣本覆蓋 GitHub Copilot、Claude、Cursor、Gemini 和 Devin 等 5 類 AI 編程工具。論文顯示,每一種 AI 編程工具都有超過 15% 的提交引入了至少一個可檢測問題。
具體來看,GitHub Copilot 相關提交中,引入問題的比例為 17.4%,Claude 為 24.4%,Cursor 為 25.7%,Gemini 為 29.1%,Devin 為 23.8%。研究還統計了每次提交平均引入的問題數量,其中,Claude 平均每次提交引入約 1.95 個問題,Devin 約 0.89 個,其他工具位于兩者之間。
![]()
各類 AI 編程助手中,存在問題的提交占比及提交總量
在識別出的 484366 個由 AI 提交引入的問題中,代碼異味占 89.3%,正確性問題占 6.0%,安全問題占 4.7%。常見代碼異味包括過于寬泛的異常捕獲、未使用參數、未使用變量或導入、作用域錯誤,以及重復或冗余代碼。
![]()
研究還指出,不同編程語言中常見問題類型也存在差異。Python 代碼中較常見的問題包括寬泛異常處理、未使用參數、未定義變量和動態類型相關問題;JavaScript 和 TypeScript 代碼中則更容易出現未使用變量、變量遮蔽和塊級作用域誤用等問題。
研究同時統計了 AI 提交修復和引入的問題數量。結果顯示,AI 編程工具在處理模式明確、重復性較強的代碼問題時,可以修復部分已有代碼異味。但在涉及程序邏輯、狀態和安全的問題上,引入的問題數量高于修復數量。
![]()
研究團隊成功追蹤了 464900 個由 AI 提交引入的問題,其中 105364 個在項目最新版本中仍然存在,整體存活率為 22.7%。從問題存在時間來看,超過 9 個月的問題中,22.8% 仍未解決;存在 6-9 個月的問題中,19.4% 仍然存在;存在 3-6 個月的問題中,28.2% 仍然存在;存在時間少于 3 個月的問題中,21.3% 仍然存在。
這表明,AI 引入的問題并不會隨著時間自動消失。即使是 9 個月前引入的問題,仍有超過五分之一留在代碼庫中。
由于部分問題會長期存在于代碼庫中,項目團隊需要持續追蹤 AI 修改過的代碼,并建立相應的技術債清理機制。但這個工作是企業自己來做還是雇專門團隊來做呢?可能要具體問題具體分析了。
https://odra.dev/slopfix/
https://arxiv.org/pdf/2603.28592
聲明:本文為 InfoQ 原創,不代表平臺觀點,也不構成投資建議,未經許可禁止轉載。
![]()
![]()
會議推薦
大會限時早鳥票享 8 折專屬優惠,現在報名立減 1160,更多詳情可掃碼或聯系票務經理 13269078023 進行咨詢。
![]()
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.