AI把代码写崩，再花1周1万美元请人用AI修：Vibe Coding的荒诞闭环出现了

InfoQ 报道了一个因 AI 代码泛滥而催生的新生意——专门清理由 AI 生成、能运行但难以维护的代码库。

Slopfix 的商业模式

3名资深工程师组成团队 Slopfix，服务对象是已用 AI 完成原型开发、但随着规模扩大出现"改一处崩多处"的团队。Slopfix 认为 Vibe Coding 项目发展到一定规模后，Agent 无法再看清整个项目全貌，不再复用已有代码，而是不断重复实现相同逻辑，导致冗余代码持续堆积。

服务流程关键点：

• 免费初步分析：判断项目是否适合重构，不适合则终止评估不收费。
• 固定报价 + 缩减目标承诺：例如"在功能不变前提下，把 10 万行代码缩减到 3.5 万行"。
• 基础报价 1 万美元，周期一周，3名工程师集中完成。最终费用按实际完成比例计算（承诺减 50% 实际减 20% → 完成度 40% → 收 4000 美元）。
• 代码行数用 scc 工具统计，只计非空行和非注释行，合同禁止"代码高尔夫式"压缩。
• 流程：先和客户逐页面、逐接口梳理功能，形成质量保证检查清单 → 精简代码（合并重复逻辑如 14 套日期格式化合 1 套、替换自制框架为成熟库、重写不可挽救模块）→ 交付更小代码库 + 检查清单 + 工程护栏（CLAUDE.md、代码检查规则、CI 检查）。
• 两周质保：如破坏正常功能免费修复。
• Slopfix 自己也用 Claude Code，但强调Agent 在最终决策中没有投票权，3人合计 30 年工程经验是核心壁垒。

团队背景

三名成员 Maciej Zieliński、Jakub Płaskonka（Kuba）、Krzysztof Pobiarżyn 此前长期共同开发 Rust 智能合约框架 Odra，合作至少 4 年。Maciej 曾任 CasperLabs 生态负责人、Odra.dev CTO，研究过零知识证明和 AI 生成智能合约。Kuba 负责 Rust 工程实现和工具链（cargo-odra 维护者），Krzysztof 横跨 Rust/Kotlin/Java/WebAssembly，做过过程宏工具 try_from_ref。智能合约背景强调的类型安全、测试、代码复用和接口边界，正是 AI 代码最欠缺的。

社区争议

支持方认为这是时间问题——有人已在做类似工作，为大量使用 Claude Code 但无技术背景的 CEO 维护代码审查流程和架构约束。一名 20 年经验工程师将 AI 代码项目分三类：纯提示词生成、懂流程但不会编程、能审查约束的工程师使用。让第三类工程师接手第一类项目有明确价值。

反对方核心论点：

• "细传市场不存在"，质疑是否有真实付费客户。
• "有损转码"比喻：拿 AI 膨胀的代码库再用 AI 瘦身，像连续两轮有损转码，误差不会抵消反而叠加放大。
• 理解旧代码才是真正难点：不是识别重复代码，而是理解隐藏的业务规则、边界条件和历史兼容逻辑。一周时间未必够，两周质保也可能过短（缺陷可能数月后才暴露）。
• 测试悖论：有完善测试的客户不需要外部团队；没测试的外部团队也难以证明无回归。
• 关于完全重写 vs 渐进替换的争论：旧代码含大量未文档化的隐含规则，更可靠的做法是先建测试基线再逐步替换。

开发者 Simonw 指出，如果新增功能会破坏已有功能，说明生成阶段没有让 Agent 执行红绿 TDD。Slopfix 创始人回应称："在拥有 100 万 token 上下文的智能体之后，替它们清理代码，正在成为一门真实存在的工程师生意。"

AI 代码技术债的实证数据

论文《Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild》追踪了 6299 个 GitHub 仓库中的 302579 次已验证 AI 提交，覆盖 GitHub Copilot、Claude、Cursor、Gemini、Devin 五类工具。

关键数据：

每类工具均有超 15% 的提交引入至少一个可检测问题。

在识别出的 484366 个 AI 引入问题中：

• 代码异味 89.3%（宽泛异常捕获、未使用参数/变量/导入、作用域错误、重复冗余代码）
• 正确性问题 6.0%
• 安全问题 4.7%

语言差异：Python 多见宽泛异常处理和动态类型问题；JS/TS 多见未使用变量、变量遮蔽和块级作用域误用。

AI 在模式明确、重复性强的代码异味上能修复部分已有问题，但在涉及程序逻辑、状态和安全的问题上引入数高于修复数。

问题存活率：22.7% 长期未解决

研究团队追踪了 464900 个 AI 引入问题，其中 105364 个在项目最新版本中仍存在，整体存活率 22.7%：

核心结论：AI 引入的问题不会随时间自动消失，9 个月前引入的问题仍有超 1/5 留在代码库中。项目团队需持续追踪 AI 修改过的代码并建立技术债清理机制——企业自己做还是雇专门团队，需具体分析。

参考链接

• Slopfix 官网：https://odra.dev/slopfix/
• 论文：https://arxiv.org/pdf/2603.28592

My Take

作为前端工程师，我对 Slopfix 的模式持审慎乐观态度。核心洞察是对的——Vibe Coding 的本质问题是 Agent 缺乏全局架构视野后退化成"局部最优复制粘贴机"，这在 React 项目中尤其常见：组件重复实现、状态管理碎片化、hook 滥用导致重复渲染。交付 CLAUDE.md + CI 检查作为"工程护栏"的思路值得借鉴。

但两轮有损转码的担忧切中要害。用 AI 清理 AI 代码，如果清理者本身没有深度理解业务逻辑，只是做表面去重，相当于把一种代码异味换成另一种更隐蔽的。论文数据也佐证：AI 在逻辑/状态/安全问题上引入多于修复。真正可靠的路径可能不是"一周速效瘦身"，而是将 AI 代码治理内化为持续工程实践——红绿 TDD 驱动 Agent、严格的模块边界约束、自动化代码异味检测纳入 CI。与其花 1 万美元事后清理，不如在生成阶段就建立约束机制。

那 22.7% 的长期存活率数据尤其值得警惕——这意味着技术债一旦积累就不容易自然消解，需要有意识的偿还计划。