清理 AI 生成的烂代码，正在成为 2026 年最赚钱的生意
三个工程师开了家公司叫 Slopfix，专门帮人删 AI 生成的代码，收费每周 1 万美元。生意好到接不完。与此同时，代码审核工具厂商发现，AI 编写的代码出现问题的概率，是人工代码的 1.7 倍。当所有人都在炫耀“AI 一天写 1000 行代码”时，真正的行业暗流是：AI 写代码的速度有多快，清理这些代码的生意就有多大。
一、1000 行代码 10 秒写完，但 review 要 1 小时
先看几组数据。
第一组：产出速度。 AI 生成 1000 行代码只需要 10 秒。一家金融服务公司引入 Cursor 后，每月产出的代码行数从 2.5 万行暴增到 25 万行。产出翻了 10 倍。
第二组：审查成本。 同样的 1000 行 AI 代码，如果你想保住项目质量，需要花 1 小时甚至更久去逐行审视逻辑。产出翻了 10 倍，但人脑的审查速度没变。
第三组：Bug 率。 代码审核工具厂商 CodeRabbit 分析开源代码合并请求后发现，AI 编写的代码出现问题的概率，是人工代码的 1.7 倍。逻辑错误多 75%。独立研究也得出相似结论：AI 生成的代码会给实际软件项目埋下长期维护隐患。
第四组：行业影响。 2026 年，开发者的 Bug 数量增加了 54%，事故数量翻了三倍。AI 并没有减少 Bug——它只是把 Bug 的生产速度提高了。
产出快 10 倍，Bug 多 1.7 倍，审查慢 360 倍。 这不是效率提升，这是效率转移。
二、能跑，但 5 个地方迟早要命
2026 年 7 月，一位开发者帮朋友 review 了一份用 Claude Code + Cursor 三天写出来的 React 管理后台。页面能登录、能 CRUD、能导出 Excel，UI 看起来还不错。打开代码一看，发现了 5 个典型问题：
问题一：所有状态都往全局塞
一个巨大的 Context 里塞了 40 多个 state。任何一个 state 变化，整棵组件树都重新渲染。你在表格里勾选一行，侧边栏、导航栏、通知弹窗全部跟着刷新。
AI 为什么这样写？ 因为你告诉它“加一个 XX 功能”，它就在已有的 Context 里加一个 state。它不会主动判断“这个 state 应该放到单独的 Context 里”。
问题二：每个请求都裸奔
没有 loading 状态——用户不知道在加载。没有 error 处理——接口挂了页面空白。没有竞态处理——快速切换页面会把旧数据覆盖新数据。
AI 为什么这样写？ 它实现的是“最显而易见的方案”（用户输入→触发请求），不考虑“如果请求慢怎么办”“如果用户快速切换怎么办”。
问题三：AI 不知道项目里已有的东西
明明项目里已经封装了 Button 组件，AI 却直接从 antd 里引用。命名风格和历史代码不一致，组件 import 五花八门，样式硬编码满天飞。
AI 为什么这样写？ AI 看到的是历史代码里参差不齐的事实，它只能在这些事实里取一个“平均值”。如果一个项目里有三种按钮写法、五种颜色使用方式，AI 很难凭空推断出“当前团队真正希望它怎么写”。
问题四：无障碍属性缺失
AI 生成的模态框和导航菜单常用泛型的 <div> 和 <span>。语义化 HTML、ARIA 角色、焦点管理经常缺失。对视力正常的鼠标用户来说能看能用，但依赖屏幕阅读器或键盘导航的用户完全无法使用。
AI 为什么这样写？ AI 优化的是“浏览器视口中的视觉渲染”，不是“辅助技术生态”。
问题五：响应式设计只在理想断点下工作
AI 生成的布局在常见断点下看起来没问题，但在非常规屏幕尺寸、折叠屏设备上，或者当真实内容超出占位文本长度时，就会出问题。
AI 为什么这样写？ AI 的训练数据里大部分是理想情况下的截图和代码，边缘情况在数据中占比太小，模型学不到。
三、“虚假的完成感”：90% 的工作被压缩到了最后 10% 的时间
如果说 Bug 和审查成本是“显性代价”，那还有一个更隐蔽的代价——认知债务。
ThoughtWorks 技术雷达里专门提到一个概念叫 “codebase cognitive debt”（代码库认知债务） ——当 AI 大量生成代码，开发者采纳了自己并不完全理解的方案，时间一长，对系统怎么运转的理解会越来越模糊。
项目能跑，但没人真正搞懂它为什么能跑。
这和“氛围编码”的教训如出一辙。一位开发者在 Hacker News 上分享了自己的亲身经历：过去两年里，他几乎全面采用 AI 进行编码。AI 写的代码片段单独看都没问题，但完全不考虑整体系统，不重视架构的结构性完整，甚至无视相邻代码的设计模式。直到有一天他打开完整的代码库逐行通读，才发现那些“我们曾以为只是早期模型残留的问题”——杂乱代码（slop），依然存在。
有开发者一针见血地指出：AI 生成的代码如果缺乏概念完整性，它非但没有减少工作量，反而通过制造“虚假的完成感”，将 90% 的工作量（维护、调试、集成）压缩到了最后 10% 的时间里。
AI 给你一个“看起来完成了”的页面。但真正的工程工作——性能优化、无障碍适配、跨端兼容、长期维护——全在后面等着你。
四、三个工程师，每周 1 万美元，专门删 AI 代码
当问题足够大时，市场就会给出回应。
2026 年，三个工程师开了一家公司叫 Slopfix，专门帮人删 AI 生成的代码，收费每周 1 万美元。生意好到接不完。
这个名字本身就是讽刺——“slop”是 2026 年行业里用来形容“能用但毫无灵魂的 AI 生成内容”的术语。而 Slopfix 的生意模式，就是帮那些被“氛围编码”反噬的团队收拾烂摊子。
这不是个例。前文提到的那家金融服务公司，每月代码产出从 2.5 万行暴增到 25 万行后，很快就累积了超过 100 万行待审查代码。协助该公司的安全新创 StackHawk 负责人直言：真正跟不上的，不只是代码审查速度，还包含漏洞数量增加，以及整个公司被迫加快节奏所带来的压力。
当 AI 把开发速度推到极致，也把技术债放到了最大。
五、2026 年，前端应该怎么做？
问题摆在眼前：AI 写代码是不可逆的趋势，但 AI 写的代码质量参差不齐。不能不用，也不能全信。
以下是 2026 年已经验证可行的几条实践：
1. 把规则写进代码仓库，让 AI 能读到
AI 出错的高发区，往往是项目里存在太多“都能用，但只有一种最推荐”的写法。
把团队规范从 iwiki、腾讯文档、README 里搬出来，用结构化的 .mdc 文件沉淀到代码仓库里：编码铁律、样式规范、组件使用约束、第三方库使用边界、反模式清单。再通过同步脚本自动分发到 .cursor/rules/ 等 AI 工具识别的目录。
规则只在一处维护，全员、全工具零漂移。新人 clone 项目后第一次 install，AI 就已经“读过”了所有团队规范。
2. 给 AI 一个收敛的代码出口
把 UI 组件统一收口到 src/components/ui/，作为业务代码访问 UI 的唯一入口。用 ESLint 的 no-restricted-imports 在工具链层强约束，杜绝绕过封装层直接引用底层库的写法。
AI 在“只有一条正确路径”的环境下，准确率显著提升。
3. 建立依赖变更协议
AI 可能会主动建议装包。它会不会选择低质量依赖？会不会安装维护状态很差的包？会不会忽略 lockfile diff？
需要在 CI 层面建立硬门禁：新增依赖必须触发额外检查、lockfile diff 必须被标记、禁止未知 registry、高风险包要求 owner review。
4. AI 参与的 PR 要加“证据链”
AI 参与开发后，Code Review 的重点要变。不只是看代码风格和逻辑正确性，还要看：这段代码是基于什么上下文生成的、AI 是否修改了不该改的文件、是否引入新依赖、是否绕过已有抽象。
从“代码审查”走向“证据链审查” 。
5. 接受“AI 写的只是初稿”
O'Reilly 的分析提出了一个核心观点：把 AI 生成的代码当成起点，而不是终点。AI 生成的组件能在 3 分钟内跑起来，但开发者可能需要 90 分钟来修复它的无障碍、响应式和与现有设计系统的集成。
AI 写代码快不重要，你 review 得快才重要。
写在最后
2026 年的前端圈出现了一个奇特的景象：一边是“AI 一天写 1000 行代码”的炫耀帖，一边是 Slopfix 每周 1 万美元帮人删 AI 代码的生意。
当 AI 把代码生成速度提高了 10 倍，但 Bug 率也高了 1.7 倍，审查速度却一点没变时——效率提升的错觉，正在被维护成本的现实击碎。
真正的效率，不是 AI 写了多少行代码。而是这些代码上线之后，需要多少人花多少时间去维护。
AI 写代码很快。清理 AI 写的代码，正在成为 2026 年最赚钱的生意。
