【AI 代码清理新生意诞生】一种新的、因 AI 代码泛滥而出现的生意来了。由 3 名资深工程师组成的团队 Slopfix开始专门从事清理由 AI 生成、能够运行但难以维护的代码库的工作。其主要服务对象是已经使用 AI 完成产品原型或初步开发但随着项目规模扩大新增功能越来越困难、修改一处却导致多处故障的团队。【Slopfix 诞生背景与服务模式】该团队认为当 Vibe Coding 项目发展到一定规模后几乎都会遇到这样的情况Agent 无法再看清整个项目的全貌于是不再寻找和复用已有代码而是不断复制、重复实现相同逻辑。这会导致项目持续堆积冗余代码最终增加维护成本。Slopfix 就是在此背景下诞生的。具体来说Slopfix 首先会提供免费的代码库初步分析。如果团队判断无法有效改善项目会直接终止评估不向客户收费如果认为项目适合重构则会给出固定报价并明确承诺一个代码缩减目标例如“在功能完全不变的前提下把 10 万行代码缩减到 3.5 万行。”其标准服务周期为一周由 3 名资深工程师集中完成基础报价为 1 万美元最终费用则根据代码缩减目标的实际完成比例计算。例如团队承诺将代码量减少 50%但最终只减少了 20%。这意味着其只完成了目标的 40%因此客户只需要支付 4000 美元。如果达到或超过承诺目标则支付全部费用。其中代码行数通过 scc 工具统计只计算非空行和非注释行。同时合同明确禁止“代码高尔夫式”压缩。团队不会通过删除注释或者把代码压缩成看似聪明、实际上难以阅读的形式来完成目标。【Slopfix 服务流程与成果】Slopfix 团队的具体服务流程是在正式修改代码前Slopfix 会先和客户一起把应用的全部功能逐项梳理清楚包括每一个页面、接口分别做什么并形成一份质量保证检查清单。“这份检查清单既是我们的安全网也是你的安全保障。”该团队表示。接着团队开始精简代码。Slopfix 会把 14 套日期格式化逻辑合并成一套把手写的自制框架替换成成熟的现有库把大量重复的业务逻辑整合起来。对于那些已经无法挽救的代码团队会先提炼出它实际实现的功能再用更干净、清晰的方式重写对应模块。最后客户会得到一个更小、更易维护的代码库、一份质量保证检查清单以及一套防止代码重新失控的工程护栏包括 CLAUDE.md、代码检查规则和持续集成检查。这样客户重新开始开发新功能时可以减缓低质量代码再次堆积的速度。所有成果都归客户。此外Slopfix 还提供两周质保。如果其团队破坏了原本正常运行的功能会提供免费修复。值得注意的是Slopfix 表示自己同样会使用 Claude Code但强调会严格限制 Agent 的决策权限。“真正的区别在于我们 3 个人拥有合计 30 年的工程经验清楚什么样的代码才算真正可维护。而且在最终决策中Agent 没有投票权。”该团队强调“我们不是 Agent。”【资深工程师转做“AI 代码返工”】Slopfix 官网显示团队成员分别为 Maciej Zieliński、Jakub PłaskonkaKuba和 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 个其他工具位于两者之间。在识别出的 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 代码泛滥催生新生意：Slopfix 清理代码库，“AI 代码清理”引争议
【AI 代码清理新生意诞生】一种新的、因 AI 代码泛滥而出现的生意来了。由 3 名资深工程师组成的团队 Slopfix开始专门从事清理由 AI 生成、能够运行但难以维护的代码库的工作。其主要服务对象是已经使用 AI 完成产品原型或初步开发但随着项目规模扩大新增功能越来越困难、修改一处却导致多处故障的团队。【Slopfix 诞生背景与服务模式】该团队认为当 Vibe Coding 项目发展到一定规模后几乎都会遇到这样的情况Agent 无法再看清整个项目的全貌于是不再寻找和复用已有代码而是不断复制、重复实现相同逻辑。这会导致项目持续堆积冗余代码最终增加维护成本。Slopfix 就是在此背景下诞生的。具体来说Slopfix 首先会提供免费的代码库初步分析。如果团队判断无法有效改善项目会直接终止评估不向客户收费如果认为项目适合重构则会给出固定报价并明确承诺一个代码缩减目标例如“在功能完全不变的前提下把 10 万行代码缩减到 3.5 万行。”其标准服务周期为一周由 3 名资深工程师集中完成基础报价为 1 万美元最终费用则根据代码缩减目标的实际完成比例计算。例如团队承诺将代码量减少 50%但最终只减少了 20%。这意味着其只完成了目标的 40%因此客户只需要支付 4000 美元。如果达到或超过承诺目标则支付全部费用。其中代码行数通过 scc 工具统计只计算非空行和非注释行。同时合同明确禁止“代码高尔夫式”压缩。团队不会通过删除注释或者把代码压缩成看似聪明、实际上难以阅读的形式来完成目标。【Slopfix 服务流程与成果】Slopfix 团队的具体服务流程是在正式修改代码前Slopfix 会先和客户一起把应用的全部功能逐项梳理清楚包括每一个页面、接口分别做什么并形成一份质量保证检查清单。“这份检查清单既是我们的安全网也是你的安全保障。”该团队表示。接着团队开始精简代码。Slopfix 会把 14 套日期格式化逻辑合并成一套把手写的自制框架替换成成熟的现有库把大量重复的业务逻辑整合起来。对于那些已经无法挽救的代码团队会先提炼出它实际实现的功能再用更干净、清晰的方式重写对应模块。最后客户会得到一个更小、更易维护的代码库、一份质量保证检查清单以及一套防止代码重新失控的工程护栏包括 CLAUDE.md、代码检查规则和持续集成检查。这样客户重新开始开发新功能时可以减缓低质量代码再次堆积的速度。所有成果都归客户。此外Slopfix 还提供两周质保。如果其团队破坏了原本正常运行的功能会提供免费修复。值得注意的是Slopfix 表示自己同样会使用 Claude Code但强调会严格限制 Agent 的决策权限。“真正的区别在于我们 3 个人拥有合计 30 年的工程经验清楚什么样的代码才算真正可维护。而且在最终决策中Agent 没有投票权。”该团队强调“我们不是 Agent。”【资深工程师转做“AI 代码返工”】Slopfix 官网显示团队成员分别为 Maciej Zieliński、Jakub PłaskonkaKuba和 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 个其他工具位于两者之间。在识别出的 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 修改过的代码并建立相应的技术债清理机制。但这个工作是企业自己来做还是雇专门团队来做呢可能要具体问题具体分析了。
