文章作者、来源：InfoQ

一种新的、因 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 修改过的代码，并建立相应的技术债清理机制。但这个工作是企业自己来做还是雇专门团队来做呢？可能要具体问题具体分析了。