上周 Hacker News 上火了一个帖子：三个工程师开了家公司叫 Slopfix，专门帮人删 AI 生成的代码，收费每周 1 万美元。生意好到接不完。
AI debug 的死亡循环
你一定经历过这个场景：
代码报错了。你把报错信息丢给 AI。AI 给你改了。跑了一下，原来的错没了，但出了一个新错。你又丢给 AI。AI 又改了。又出了一个新错。
三轮下来，你的代码从 1 个 bug 变成了 5 个 bug，而且你已经完全不知道 AI 到底改了什么。
这不是你的问题。Shiplight 对数千个 PR 的数据分析显示：AI 生成的代码比人写的多 1.7 倍 Bug，逻辑错误多 75%。 也就是说，AI 在"修 bug"的过程中，大概率在制造新的 bug。
更扎心的是------Sonar 的调查说 96% 的开发者不会完整审查 AI 生成的代码。AI 改了三轮，你看都没仔细看就跑了，然后发现又炸了。
现在有人靠清理 AI 代码每周赚 1 万美元。这说明 AI debug 的"售后成本"已经大到可以撑起一门生意了。
以下 5 种 bug，你越让 AI 修，就越烂。
第 1 种：CSS 和样式问题
AI 修 CSS 最大的问题：它看不到级联。
你说"这个按钮的边距不对"。AI 加了一个 margin-top: 20px。
但这个按钮在另一个页面也用到了，那边的边距本来是对的，现在也被影响了。
你再告诉 AI。AI 怎么修？加一个更高优先级的选择器覆盖。
两轮下来，样式表里多了两层覆盖，一堆 !important，和一个完全看不懂的选择器优先级链。
为什么 AI 修不好 CSS： CSS 是全局作用域的，改一处影响多处。AI 每次只看你指给它的那一处。它的修法永远是"在上面再叠一层"，而不是找到根因。越叠越多，最后只有重写能理清。
自己修： 打开 DevTools，看 Computed Styles 找到实际生效的规则，改根因，一次改对。
第 2 种：跨组件的状态 bug
列表页和详情页共享一个全局状态。用户在详情页做了修改，回到列表页没更新。
你把 bug 丢给 AI。AI 在列表页加了一个 useEffect 重新请求数据。
好了，数据更新了。但现在每次从任何页面回到列表，都会重新请求------包括从搜索页、设置页回来。接口被打爆了。
你再跟 AI 说"请求太频繁了"。AI 加了一个防抖。现在数据有时候更新有时候不更新，取决于你切页面的速度够不够快。
两轮修复 = 一个 bug 变三个 bug。
为什么 AI 修不好状态 bug： 状态 bug 的根因通常不在报错的那个组件里，而在数据流的上游。AI 看到的是"这个组件数据不对"，修法是"让这个组件自己拿数据"------治标不治本。每治一次标，就多一条数据流路径，系统复杂度指数级上升。
自己修： 先画出数据流向------哪个组件读、哪个组件写、经过几层传递。状态 bug 的修复点在数据源头，不在展示末端。
第 3 种：只在特定环境出现的 bug
线上报了一个 bug，本地复现不了。
你把报错日志丢给 AI。AI 说"可能是没做空值判断"，给你加了个 ?.。
部署上去，线上还是报错。因为问题根本不是空值------是某个环境变量在生产环境的值和开发环境不一样。
你又把新的报错丢给 AI。AI 又猜了一个原因，又改了一处。
这是 AI debug 最危险的场景：它在猜。
AI 没有你的生产环境，没有你的日志系统，没有你的监控面板。它只能根据你给它的那几行报错信息"推测"原因。而环境类 bug 的根因通常在配置、网络、权限这些层面------不在代码层面。
AI 的每次"猜测性修复"都在往代码里塞不必要的防御逻辑。三轮下来，代码里全是 ?.、try-catch、if (!x) return------真正的问题一个没解决。
自己修： 先确认是不是代码 bug。看日志、看监控、比较环境差异。如果确认是代码问题，给 AI 完整的上下文（报错日志 + 环境信息 + 复现步骤）再让它帮忙。
第 4 种：依赖冲突
某个包升级后，项目跑不起来了。
你告诉 AI。AI 说"试试降级到 X 版本"。降了，那个包好了，另一个包又报错了------因为它依赖更高版本。
你又告诉 AI。AI 说"那把另一个包也降级"。降了，TypeScript 报了一屏的类型错误。
这就是依赖地狱，AI 不但解决不了，还会让你陷得更深。
为什么 AI 修不好依赖冲突： 依赖关系是一张网，不是一条线。改一个版本号可能影响几十个包。AI 的修法永远是"改版本号"------它不会帮你看 changelog，不会帮你判断哪个大版本有 breaking change。每改一次版本号，可能性空间都在指数膨胀。
自己修： 先看报错包的 changelog 和 peer dependencies。依赖冲突不是"试版本号"能解决的，是"理解兼容性矩阵"的问题。
第 5 种：异步时序和竞态条件
两个接口同时请求，后发的先回来，页面显示了旧数据。
你告诉 AI。AI 加了一个 loading 状态。现在页面不闪了，但数据还是错的------因为竞态的根因不在渲染层面，在请求层面。
你再告诉 AI。AI 加了一个 AbortController。但位置不对，有时候把正常请求也取消了。
你再告诉 AI。AI 加了一个请求计数器。但计数器在组件卸载时没清理，内存泄漏了。
三轮下来：一个竞态 bug → 变成竞态 + 请求取消异常 + 内存泄漏。
为什么 AI 修不好时序 bug： AI 的思维是"逐行执行"的，它天生不擅长推理"两件事同时发生会怎样"。竞态条件的修复需要理解整个异步流的时序关系，不是在某个点加一行代码。AI 的每次修复都是局部的，但时序问题本质上是全局的。
自己修： 先用 Network 面板理清请求的实际时序。竞态问题的方案通常是架构层面的（请求取消策略、乐观更新、版本号比对），不是在单个函数里打补丁。
速查表：这个 bug 该自己修还是让 AI 修？
| bug 类型 | 让 AI 修？ | 理由 |
|---|---|---|
| CSS/样式 | ❌ 自己修 | AI 看不到级联，只会叠覆盖 |
| 跨组件状态 | ❌ 自己修 | AI 治标不治本，越修数据流越乱 |
| 环境差异 | ❌ 自己修 | AI 无法访问你的环境，只能猜 |
| 依赖冲突 | ❌ 自己修 | AI 不理解兼容性矩阵 |
| 异步时序 | ❌ 自己修 | AI 不擅长推理并发 |
| 语法错误 | ✅ 让 AI 修 | AI 的强项，秒修 |
| 类型报错 | ✅ 让 AI 修 | AI 很擅长 TS 类型修复 |
| 单函数逻辑 | ✅ 让 AI 修 | 输入输出明确，修得又快又好 |
| 写测试用例 | ✅ 让 AI 写 | AI 很擅长生成边界测试 |
| 报错信息翻译 | ✅ 让 AI 查 | 比 Google 快 |
收藏这张表。下次 debug 前先看一眼------有些 bug 你自己 30 分钟搞定，丢给 AI 折腾半天还越修越多。
不是 AI 不好，是 debug 不是它擅长的事
AI 最擅长的是生成------给它一个清晰的需求，它写代码又快又好。
AI 最不擅长的是诊断------给它一个模糊的症状，让它找根因，它只会猜。猜错了就在猜错的方向上继续修，越修越远。
Slopfix 每周 1 万美元帮人清理 AI 代码，说明这已经不是个别现象了------AI 代码的"售后成本"正在变成一个真实的行业问题。
与其让 AI 修三轮越修越烂，不如花 30 分钟自己找到根因一次改对。
你经历过最离谱的"AI 越修越烂"是什么场景？评论区说说。