AI 代码生成技术的门槛持续降低，然而，这也催生了一门全新的业务模式。

一个由三位资深工程师组成的团队，命名为 Slopfix，专注于清理那些“虽然能运行但根本无法高效维护”的 AI 生成代码库。他们的目标客户画像非常清晰——那些借助 AI 快速搭建产品原型或完成初期开发的团队。这些团队在项目规模扩大后，会发现添加新功能越来越困难，修改一处代码就可能引发多处连锁故障。

据该团队介绍，Vibe Coding 项目在发展到一定阶段后，几乎都会遇到同一个瓶颈：AI Agent 无法再全面理解项目的整体架构，因此不再致力于寻找和复用已有的代码，而是开始不断地复制和重写相同的逻辑。最终导致项目充斥大量冗余代码，维护成本急剧上升。

Slopfix 正是瞄准了这一市场空白而成立的。

其服务流程如下：Slopfix 首先会免费对代码库进行初步评估。如果认为该项目无法有效修复，便会直接终止评估，不收取任何费用；如果判断有重构的潜力，则会给出一个固定的报价，并明确承诺一个代码缩减比例。例如，“在保持功能完全不变的情况下，将 10 万行代码精简至 3.5 万行。”

标准的服务周期为一周，由三名资深工程师集中完成。基础报价为 1 万美元，最终费用则根据代码缩减目标的实际完成比例来计算。举例来说，如果团队承诺减少 50% 的代码量，但最终只减少了 20%，这意味着只完成了目标的 40%，客户仅需支付 4000 美元。如果达到或超越了承诺的目标，客户则需支付全款。

代码行数的统计使用 scc 工具，只计算非空行和非注释行。合同中还明确规定了底线：禁止“代码高尔夫式”的压缩。团队不会为了凑齐指标而删除注释或将代码写成看似巧妙、实则难以理解的风格。

在具体操作上，Slopfix 在正式动手前，会与客户一起将应用的所有功能逐一梳理清楚，包括每个页面、每个接口的具体作用，并形成一份质量保证检查清单。“这份清单既是我们的安全网，也是客户的保障。”团队这样解释。

随后，精简工作才正式开始。Slopfix 会将 14 套不同的日期格式化逻辑合并为一套；将手写的自制框架替换为成熟的现有库；并整合大量重复的业务逻辑。对于那些确实无法保留的代码，团队会先提炼其实际功能，再以更干净、更清晰的方式重写对应模块。

最终，客户会获得一个更精简、更易于维护的代码库，一份质量保证检查清单，以及一套防止代码质量再次恶化的工程规范，包括 CLAUDE.md、代码检查规则和持续集成检查。这样，客户在后续开发新功能时，可以有效减缓低质量代码再次堆积的速度。所有工作成果都归客户所有。

此外，Slopfix 还提供两周的质保服务。如果他们的团队破坏了原本正常运行的功能，会提供免费的修复服务。

值得关注的是，Slopfix 表示他们自身也会使用 Claude Code，但会严格限制 Agent 的决策权限。“真正的区别在于，我们三个人拥有合计 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，并持续引导 AI 采用正确的架构，避免重蹈覆辙。

另一位拥有 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 编程工具在帮助开发者修复部分代码问题的同时，也会引入新的正确性和安全性问题。

在一项题为“Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild”的研究中，研究团队追踪了 6299 个 GitHub 仓库中的 302579 次已验证的 AI 提交，发现有大约 22.7% 的 AI 引入问题在项目的最新版本中依然存在，其中部分问题持续时间超过了 9 个月。

研究样本覆盖了 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