> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# GitHub上的「AI屎山」
- URL: https://www.hubwiz.com/blog/ai-shitcode-on-github/
- Published: 2026-02-09T17:10:44.000Z
- Updated: 2026-02-09T17:10:44.000Z
- Description: 如果说3D打印社区是被AI模型淹没，那程序员社区就是被AI代码埋葬。
- Author: admin
- Tags: AI, AI SLOP, #Import 2026-10-14 14:41

第一篇文章发出去后，有个做后端的朋友私信我："你以为3D打印社区的AI垃圾很糟？来我们GitHub仓库看看，那才叫真正的噩梦。"

于是我又去Reddit的程序员社区潜伏了一圈，然后我发现——**如果说3D打印社区是被AI模型淹没，那程序员社区就是被AI代码埋葬**。

## 1、那个让Copilot通过代码审查的PR，删掉了全部用户数据

有个故事在Hacker News上传疯了。

一个团队用了GitHub Copilot六个月，一切看起来很美好：代码产出速度提升了30%，工程师们很满意，管理层更满意。直到那个命运般的周五下午。

一个看似无害的PR通过了代码审查。Copilot生成的代码，语法正确、风格统一、注释清晰。审查者草草看了一眼，点了通过。毕竟，**AI写的代码能有什么问题呢？**

结果？这段代码在生产环境执行后，**删掉了全平台的用户数据**。

恢复数据花了14个小时，紧急响应团队全员上阵，最终账单是**47,000美元**。而那个"帮助团队节省30%开发时间"的AI助手，只用一行代码就让团队赔上了三倍的时间成本和无法挽回的数据损失。

发帖的工程师说："没人告诉你，信任AI生成的代码会付出什么代价。"

## 2、代码都能跑，但没人知道为什么

另一个更普遍的故事是关于**可维护性**的。

有个创业团队，为了赶进度，决定让ChatGPT帮他们写整个代码库。500个commit，20,000行代码，全部AI生成。开发速度确实起飞了，产品按时上线，投资人很满意。

六个月后，他们想加一个功能。然后发现——**没人能理解这个代码库**。

不是夸张，是真的看不懂。变量命名看起来合理但又说不出的诡异，函数之间的调用关系像意大利面条，明明能跑，但改一行就崩。原帖的标题写得特别心酸：*"ChatGPT Wrote Our Entire Codebase. 6 Months Later, We Can't Debug Anything."*

最讽刺的是，当他们试图让ChatGPT解释这段代码时，AI给出的解释和实际代码行为**完全对不上**。原来当时生成代码的时候，ChatGPT就偷偷"优化"了一些逻辑，现在连它自己都忘了。

这就是"AI屎山"的可怕之处：**代码不是给人看的，是给机器跑的**——前提是机器真的能跑对。

## 3、API幻觉：AI会做梦，而且梦见了一些不存在的函数

如果你以为AI代码的问题只是"难维护"，那还是太天真了。真正致命的，是AI会**一本正经地编造API**。

学术圈给这个现象起了个名字叫 **"API Hallucination"**（API幻觉）。研究人员发现，LLM在生成代码时，会频繁地调用根本不存在的API函数、传递错误的参数、使用已经被废弃的版本。

有个开发者在Reddit上分享了他的遭遇。他用ChatGPT写了一段处理JSON的Python代码，看起来完美无缺：

```python
data = json.load_with_encoding(file, encoding='utf-8-sig', strict=False)

```

你发现问题了吗？`json.load_with_encoding`这个函数**根本不存在**。Python的json模块里从来没有这个函数。但ChatGPT非常自信地编写了它，还煞有介事地解释了每个参数的作用。

这种错误，编译器检查不出来（因为Python是动态类型），单元测试可能也检查不出来（如果你没覆盖这个分支），但一到生产环境，**boom**。

更可怕的是，这种幻觉具有**传染性**。当AI生成的代码被上传到GitHub、被Stack Overflow收录、被其他AI爬取训练，错误就变成了"常识"。就像那个经典的段子：如果足够多的AI都在说地球是平的，下一个AI就会"学习"到这个"知识"。

## 4、代码审查变成噩梦

现在的GitHub上，有个让资深工程师集体崩溃的现象：**AI生成的PR像洪水一样涌来**。

有个技术负责人在Hacker News上吐槽："我们的中级工程师最近几个月提交的PR质量明显下降了。代码都能编译通过，但：

- 缺少边界情况处理（那些没写在ticket里但之前口头讨论过的细节）
- 经常出现完全没用的代码路径——if语句和函数调用通向 nowhere
- 不遵守团队为了代码安全制定的特定模式

最气人的是，这些问题不是初级工程师犯的，而是**本来挺靠谱的中级工程师**犯的。"

问题出在哪？**审查疲劳**。

人类写代码的时候，是一边写一边检查的。但AI生成代码的速度，是人类阅读速度的十倍。当一个工程师用Cursor或者Copilot在10分钟生成了500行代码，他不可能逐行理解。他只能"大概看看"，然后点提交。

结果就变成了：**代码审查者在帮AI擦屁股，而且擦得越来越累**。

有个工程师算了一笔账："审查AI生成的代码花的时间，比我自己重写还多20%。"

## 5、Vibe Coding：不会编程的人，正在用AI"编程"

2025年最可怕的新词出现了：**Vibe Coding**（氛围编程）。

意思是不用理解代码逻辑，不用学习编程基础，只要"有感觉"地让AI生成代码就行。有个Stack Overflow的文章标题说得很直接：《A new worst coder has entered the chat: vibe coding without code knowledge》。

Reddit上有个前端工程师分享了他的困惑。他带的一个初级开发者，用Cursor写了三个月代码，产出量惊人。但他渐渐发现不对劲：

"我问他为什么在这个组件里用useEffect而不是直接计算，他答不上来。我问他这个状态管理为什么选zustand而不是context，他说'Cursor建议的'。我问他这个API调用为什么没加错误处理，他愣了一下，然后说'我忘了检查AI生成的代码'。"

最恐怖的是当这个初级开发者遇到bug时的反应：**他不会调试**。

不是不想，是真的不会。因为过去三个月，他从来没有真正理解过代码是怎么工作的。当AI生成的代码出错时，他不知道从哪里开始排查。他只能把错误信息复制粘贴给AI，然后祈祷AI这次能给个对的答案。

这就是"cargo cult programming"（货物崇拜编程）的AI升级版——**不是理解原理，而是迷信咒语**。

## 6、技术债务的复利效应

老一辈程序员都知道，技术债务就像信用卡欠款，迟早要还。但AI代码让这个问题恶化了一个数量级。

GitClear在2024年发布的研究显示，使用GitHub Copilot的代码库出现了明显的\*\*"向下压力"（downward pressure on code quality）\*\*：

- 代码重复率（code duplication）上升了
- 代码复杂度（cyclomatic complexity）上升了
- 测试覆盖率（test coverage）下降了
- 注释质量（comment quality）下降了

为什么？因为AI最擅长的是**生成看起来对的代码**，而不是**生成对的代码**。

它会给你生成一个极其复杂的函数，用五种设计模式解决一个本来用if-else就能搞定的问题。它会给你生成一堆try-catch块，但每个catch块里只有`pass`或者`console.log(e)`。它会给你生成看起来专业的文档字符串，但参数描述和实际函数签名对不上。

短期看，feature交付很快。长期看，**你得到了一座屎山，而且这座屎山每天都在长高**。

有个工程师在Reddit上发了个帖子，标题是《TODO: Fix the Mess Gemini Created》。这不是笑话，这是真实代码库里的注释。研究团队分析了6,540个提到AI的代码注释，发现越来越多开发者被迫留下这种"自白"——承认这段代码是AI写的，而且**他们知道这很烂，但暂时没时间修**。

## 7、那Stack Overflow怎么办？

说到AI对编程社区的侵蚀，就不得不提Stack Overflow的困境。

以前程序员遇到问题是这样的：报错 → 谷歌 → Stack Overflow → 找到答案 → 理解答案 → 修改代码 → 解决问题。这个过程虽然慢，但**你在学习**。

现在呢？报错 → 复制粘贴给ChatGPT → 得到答案 → 复制粘贴到代码 → 可能解决，可能没解决，反正不知道为啥。

Stack Overflow的流量在 plummet（ plummeting ）。但有趣的是，越来越多的开发者开始怀念它。

有个帖子说得好："AI可能能给你答案，但Stack Overflow能**教会**你。那些高票答案里的解释、那些评论区的辩论、那些'这已经被废弃了，应该用xxx'的更新，才是真正有价值的学习材料。"

现在的问题是：**当AI生成的答案充斥着网络，当AI生成的代码污染着代码库，我们还能相信什么？**

## 8、我们不是在反对AI，我们是在反对懒惰

写到这里，我想澄清一点：我写这些不是为了唱衰AI。我自己也用Copilot，也用ChatGPT。它们确实是强大的工具。

但工具是把双刃剑。当你用AI辅助你理解问题、帮你写测试、帮你优化代码时，它是神器。当你用AI**代替**你思考、代替你学习、代替你承担责任时，它就是定时炸弹。

Reddit上有个评论让我印象深刻：

> AI疲劳让我受不了了。领导因为AI的存在而期待工程师产出更多，但写代码从来就不是主要瓶颈。初级开发者盲目信任AI，产出质量低下的工作，然后 senior 工程师得花更多时间审查和重构AI生成的代码。我不禁怀疑，要是当初我自己写，会不会更快。

这才是问题的核心。**AI没有让我们变成更好的程序员，它让我们变成了更懒的程序员**——而懒惰的代价，最终还是要整个团队来承担。

## 9、写在最后

如果你读完这篇文章，记得**不要**去跟你的团队说"我们要禁用AI工具"。那不是解决方案。

真正的解决方案是：**把AI当作助手，而不是替身**。

每次AI给你生成代码时，问自己三个问题：

1. 我理解这段代码在做什么吗？
2. 如果这段代码在生产环境出问题了，我能debug吗？
3. 这段代码符合我们团队的规范和最佳实践吗？

如果任何一个答案是否定的，**不要提交这段代码**。

AI可以帮你写得更快，但只有你能决定**写得好不好**。

在这个AI代码即将淹没一切的时代，也许**保持清醒，拒绝懒惰**，就是我们最后的防线。

---

汇智网策划整理，转载请标明出处