Vibe Coding荒诞闭环 AI写崩代码后花一周一万美元请人用AI修复

Vibe Coding 曾一度风靡，但其带来的副作用——堆积如山的“AI 废物代码”——已令不少团队感到棘手。专门针对这一痛点的商业模式应运而生。

由三位资深工程师组成的团队 Slopfix，开始专职承接一项棘手任务：清理那些由 AI 生成、虽能运行但难以维护的代码库。他们的目标客户十分明确：那些借助 AI 快速拼凑产品原型或完成初期开发的项目团队。随着项目规模扩大，他们往往陷入困境：添加新功能难如登天，修改一处代码便会引发一连串 Bug。

该团队做出了精准判断：当 Vibe Coding 项目发展到一定阶段后，几乎都会陷入同一个困境——AI Agent 无法再把握项目的整体架构。于是，AI 不再尝试复用已有代码，而是不断复制粘贴，反复实现相同的逻辑。最终导致代码库像吹气球般膨胀，维护成本急剧攀升。

Slopfix 正是来为这些“气球”放气的。

他们的服务流程清晰且富有特色。首先，提供免费的代码库初步分析。如果评估后认为项目已无药可救，他们会直接告知客户，分文不取。但如果他们认为可以处理，则会给出一个固定报价，并明确承诺具体的代码缩减目标。例如，“在功能完全不变的前提下，将 10 万行代码缩减至 3.5 万行。”

标准服务周期为一周，由三位工程师集中攻坚，基础报价为 1 万美元。最终费用则根据目标完成度来计算。

举例来说，团队承诺减少 50% 的代码量，但最终只减少了 20%。这意味着他们仅完成了目标的 40%，因此客户只需支付 4000 美元。反之，如果达到或超额完成任务，客户才需支付全部 1 万美元。

这里有个细节：代码行数通过 scc 工具统计，仅计算非空行和非注释行。合同中明确禁止“代码高尔夫”式的压缩手法。他们不会通过删除注释或把代码写成故作高深的单行怪来达成目标。

那么，具体是如何操作的呢？在正式动手修改代码之前，Slopfix 会先与客户一起，逐个页面、逐个接口地梳理整个应用的功能，并整理出一份质量保证检查清单。用他们自己的话说：“这份检查清单既是我们的安全网，也是你的安全保障。”

梳理完毕，便进入实质性的重构阶段。他们会将 14 套不同的日期格式化逻辑合并为 1 套；将手写的、脆弱的自制框架替换为成熟、经过验证的开源库；将大量重复的业务逻辑进行整合。对于那些实在无法挽救的代码，他们会先提炼出它实际实现的功能，再用更干净、更清晰的方式重写那个模块。

最后，客户将获得一个更小、更易于维护的代码库，一份质量保证检查清单，以及一套防止代码重新失控的工程护栏——包括 CLAUDE.md、代码检查规则和持续集成检查。这样一来，当团队重新开始开发新功能时，能有效减缓低质量代码再次堆积的速度。当然，所有成果均归客户所有。

此外，他们还提供两周的质保期。如果他们的清理工作破坏了原本正常运行的功能，他们会免费修复。

有意思的是，Slopfix 承认他们自己也会使用 Claude Code 这类工具。但他们强调，会严格限制 AI Agent 的决策权限。真正的差异在于，他们拥有累计 30 年的工程经验，清楚地知道什么样的代码才算得上“可维护”。而且，在最终决策中，AI Agent 没有任何投票权。“我们不是 Agent，”他们这样定义自己。

资深工程师转做“AI 代码返工”

Slopfix 团队的三位成员——Maciej Zieliński、Jakub Płaskonka（Kuba）和 Krzysztof Pobiarżyn——并非临时拼凑的草台班子。他们此前长期共同开发 Rust 智能合约框架 Odra，合作至少已有 4 年。

早在 2022 年 11 月 Odra 发布首个公开版本时，三人就已形成稳定的分工：Maciej 负责技术架构和社区生态，Kuba 与 Krzysztof 负责核心框架和工程实现。此后，他们持续维护 Odra 的核心包、命令行工具、过程宏以及不同区块链后端。直到现在，Odra 核心 Rust 包的所有者名单中，依然有三位的名字。

这段经历与 Slopfix 提供的代码重构服务高度相关。智能合约和 Rust 系统软件，素来强调类型安全、测试、代码复用、接口边界和长期兼容性。而 Slopfix 所批评的 AI 代码问题，恰恰就集中在重复实现、架构失控、缺乏统一抽象和可维护性不足上。

三人中，Maciej Zieliński 的公开履历最为丰富，职务是 Slopfix 的“工程负责人”。他此前长期担任 Odra.dev 的 CTO，曾担任区块链基础设施公司 CasperLabs 的生态负责人，也是 Casper 的核心开发者，主要负责技术路线和框架架构。大约在 2021 年，他离开 CasperLabs，与 Kuba 和 Krzysztof 共同组建了专注智能合约开发的团队，随后推出了 Odra 框架。

Maciej 还研究过零知识证明、Risc Zero、EVM 执行环境和 AI 生成智能合约等方向。2023 年，Odra 官网曾发布他撰写的文章，专门测试 OpenAI 模型是否能利用 Odra 编写 ERC-20 智能合约。

Kuba 是 Slopfix 的“工程主力”。从公开代码来看，他的工作偏向 Rust 工程实现、开发工具和智能合约工具链，是 cargo-odra 项目的主要维护者之一。

Krzysztof 是 Slopfix 的“工程骨干”，将自己定义为 Rust/AI 开发者。从他的 GitHub 项目可以看出，早期曾参与 Android、Java 和 Kotlin 项目，包括移动端日期选择器、列表滑动删除组件等。之后，他的重心逐渐转向 Rust、智能合约和 WebAssembly。在 Odra 中，他主要参与核心框架、代码生成、过程宏以及不同区块链平台的适配，2023 年还负责将 Odra 框架接入 CosmWasm。

“AI 代码清理”生意引争议

Slopfix 团队上线后，在开发者社区中激起了不小的讨论。

有网友表示，自己已经在做类似的事情。一位开发者说，他正在为一位没有技术背景、但大量使用 Claude Code 的创业公司 CEO 提供支持，工作主要就是运行代码审查流程、维护 Claude.md，并持续引导 AI 采用正确的架构，避免重复犯错。

另一位拥有 20 年经验的工程师也认同这种模式。他将 AI 代码项目分为三类：完全不懂软件的人纯粹靠提示词生成；了解开发流程但不会编程的人使用 AI；以及能审查代码、约束结构的工程师用 AI。他认为，三类项目的代码质量差距极大，让第三类工程师去接手第一类项目，价值非常明确。

“这种细分业务的出现只是时间问题。”有开发者评价道。

他的观点是：AI 本质上是一种不精确的“编程语言”，它试图用充满歧义的自然语言（英语）去表达精确的代码关系。在小规模、模块化、像搭积木一样的任务上，它确实好用。但随着项目复杂度增加，组件变多，还要与异构系统交互，并且需要从上到下理解整个系统到底在做什么时，AI 的表现就会急剧恶化。

“这让我想起当年 xUML 被宣传成万能方案。AI 现在失败的原因其实差不多。至少 xUML 还有一套精确的定义，而用 AI 时，你往往只是靠 Vibe Coding 的方式，一路摸索出一个定义。”

但并非所有人都买账。

“挺有意思的，迎合了某种既有偏见，但所谓的‘细分市场’其实并不存在。除了博眼球，我看不出它有什么真实需求。如果他们能找到哪怕一个愿意付费的客户，我都会非常惊讶。”有网友直言不讳。

“我明白，对那些已经深度依赖 AI 的公司，想向他们推销完全不借助 AI 的方案，可能不太现实，哪怕他们现在的问题就是 AI 造成的。但‘拿一个被 AI 撑大的代码库，再用 AI 给它减肥’这个想法，让我感觉像连续做两轮有损转码。两次误差非但不会抵消，反而会叠加放大。”

“问题是真实的，解决方案是幻想。”有网友说得更尖刻。

很多开发者从自身经验出发，指出了这种模式下的实际操作难点。

“你真的指望客户把所有细节都解释清楚吗？如果他们有能力把这些讲明白，可能一开始就不会有那种混乱的代码库。再退一步，接下了项目，清理完后呢？你觉得光靠一份 Claude.md 文件，就能保证项目从此不乱吗？”

Slopfix 宣称会逐个页面、逐个接口梳理应用行为。但不少网友认为，真正的难点不是识别重复代码，而是理解隐藏在旧代码里的业务规则、边界条件和历史兼容逻辑。

“对于有复杂业务约束的软件，一周时间未必能完成理解和重构。”还有开发者觉得两周质保期太短，某些缺陷可能几个月后才暴露。如果客户本身没有完整的自动化测试，很难确认重构是否破坏了原有行为。

还有网友提出，与其花 1 万美元整理旧代码，不如定期用更先进的模型，在保留数据库结构和 API 等不可变部分的前提下，重新生成整个系统。

不过，反对这一观点的人认为，完全重写并非正确选择。已经运行的代码里通常藏着大量没写进文档的隐含规则，即使实现方式不理想，也经过了真实使用的检验。更可靠的做法是先建立测试和行为基线，再逐步替换危险实现，而不是一把推倒重来。

这场讨论也引向了另一个焦点：AI 在大型项目中的表现到底如何？

有人将 Vibe Coding 的典型风险总结为：系统最初能跑，但结构脆弱；出错了，模型往往接着打补丁，让功能恢复，而不是从架构层面解决根本原因。项目越大，后续重新识别模块边界、接口关系和业务规则的成本就越高。

但也有开发者认为，大型项目未必超出模型能力。如果代码库有清晰的模块划分、关注点分离和明确接口，AI 在复杂项目中也能带来较高生产力。

“模型会倾向于找局部最快的方案，可能暗中把原本独立的系统连在一起，让结构慢慢退化。要维持模块边界和架构一致性，工程师必须主动施加约束，而一句笼统的‘遵循最佳实践’通常不够。”一位开发者表示。

另一项争论集中在自动化测试上。开发者 Simonw 认为，如果新增功能会破坏两个已有功能，说明在生成阶段没让 Agent 执行红绿测试驱动开发，也没建立可靠的测试套件。

“如果客户已经有完善的测试和验收体系，可能不需要外部团队代为清理；如果客户没有测试，外部团队也很难在短时间内证明重构没造成回归。”有开发者指出。但也有人质疑，测试只能证明部分行为没回归，没法保证整个代码库的模块化和可维护性。

“我分享这些，是因为在拥有 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 五种 AI 编程工具。数据显示，每一种工具都有超过 15% 的提交引入了至少一个可检测问题。

具体来看，GitHub Copilot 提交中引入问题的比例为 17.4%，Claude 是 24.4%，Cursor 是 25.7%，Gemini 是 29.1%，Devin 是 23.8%。研究还计算了每次提交平均引入的问题数量，Claude 平均每次提交引入约 1.95 个，Devin 约 0.89 个，其他工具介于两者之间。

在识别出的 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 改过的代码，并建立相应的技术债清理机制。这件事是由企业自己来做，还是聘请专门的团队来完成？恐怕需要具体问题具体分析。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Vibe Coding荒诞闭环 AI写崩代码后花一周一万美元请人用AI修复要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题