本文来自微信公众号： InfoQ ，作者：褚杏娟
一种新的、因AI代码泛滥而出现的生意来了。
由3名资深工程师组成的团队Slopfix，开始专门从事清理由AI生成、能够运行但难以维护的代码库的工作。其主要服务对象是已经使用AI完成产品原型或初步开发，但随着项目规模扩大，新增功能越来越困难、修改一处却导致多处故障的团队。
该团队认为，当Vibe Coding项目发展到一定规模后，几乎都会遇到这样的情况：Agent无法再看清整个项目的全貌，于是不再寻找和复用已有代码，而是不断复制、重复实现相同逻辑。这会导致项目持续堆积冗余代码，最终增加维护成本。
Slopfix就是在此背景下诞生的。
值得注意的是，Slopfix表示自己同样会使用Claude Code，但强调会严格限制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