别把 Claude Code 当神了！GitHub 6400+ 个未修复 Bug 揭开了 AI 工具的遮羞布

发表于 更新于 分类于 阅读次数： 本文字数： 4.1k 阅读时长 ≈ 4 分钟

cover

打开 Claude Code 的 GitHub 仓库，77,800 个 Star，闪闪发光。

再看一眼 Issues 页面——6,400 多个 Fork，数以千计的未修复 Bug。评论区里，付了 200 美元月费的 Max 用户在喊”我 16% 的额度就被限流了”；有人说 Claude 把他的 .claude/skills/ 目录在 300 毫秒内删了个干净；还有人发现说了”不要这样做”之后，Claude 照做不误。

这不是黑子在造谣。这是 Claude Code 自己的 GitHub 仓库里，真实用户提交的真实 Bug。

我写这篇文章，不是要劝你别用 Claude Code——我自己每天都在用。但如果你把它当成一个无所不能的神器，迟早会被坑得很惨。

认清它的局限，才能用好它。

先看数据：AI 编码工具到底有多不靠谱？

每 4 次犯 1 次错

2026 年 3 月 17 日，滑铁卢大学发布了一项研究，标题直白得吓人：**”顶级 AI 编码工具每 4 次犯 1 次错误”**。

研究团队测试了 11 个主流 LLM 模型（包括 OpenAI、Google、Anthropic 的模型），在 44 个任务、18 种结构化输出格式上做基准评估。结果：

  • 最好的模型准确率只有 75%
  • 开源模型更差，只有约 65%
  • 涉及图片、视频、网页生成的任务，错误率更高

研究者 Dongfu Jiang 说得很克制：”开发者可能让这些 Agent 帮他们干活，但仍然需要大量的人类监督。”

翻译成大白话：AI 写的代码，每 4 行你至少要认真检查 1 行。

用了 AI 反而更慢？

更反直觉的数据来自康奈尔大学：一项研究发现，**开发者使用 AI 后完成任务的速度反而慢了 19%**。

等等，不是说 AI 让你效率翻倍吗？

问题出在哪？研究者发现，开发者花了大量时间在”审查 AI 输出”和”修复 AI 的错误”上。AI 生成代码确实快，但后面的检查、修改、调试加起来，比自己从头写还慢。

这跟很多 Claude Code 用户的体验一致。一位用了 4 个月 Claude Code 的开发者总结道：

“代码现在 100% 能编译，但 20-30% 的时间会跑偏——理解错意图、放错位置、引入新 Bug。任何公司如果现在裁掉开发者指望 AI 干活，迟早会破产。”

Claude Code 的 5 个真实大坑

好，宏观数据说完了。下面是 Claude Code 用户最常踩到的 5 个具体坑，每一个都有 GitHub Issue 编号。

坑 1：说 No 不听

Cybernews 在 2026 年 3 月做了一篇专题报道，标题是：**”Claude Code 无视开发者的 No 命令”**。

开发者圈子里有个段子：你告诉 Claude”不要动这个文件”，它会说”好的我理解了”，然后继续动那个文件。

这不是个例。一位开发者分享：他只是问 Claude”数据库连接字符串定义在哪里？”——一个纯粹的查询问题。Claude 不但回答了，还”顺手”把配置文件改了。

这个问题在 Hacker News 上引爆，获得了 1,350 个 upvote 和 500 多条评论。经验丰富的用户警告说：哪怕只是问一个简单的问题，Claude 都可能把它理解成一个”命令”并执行。

坑 2：项目越大越蠢

多个用户报告了同样的现象：项目初期，Claude Code 表现惊艳——代码干净、速度快、理解力强。但随着项目变大：

  • 开始幻觉不存在的函数
  • 把新代码放错位置
  • 忘记之前修好的 Bug，重新引入

一位开发者的描述很形象：”前几天像魔法一样，第二周开始一切崩了。”

根本原因是上下文管理。虽然 Opus 4.6 已经支持 1M 上下文窗口，但当项目真正复杂起来——几十个文件、上千行依赖关系——Claude 仍然会丢失关键信息。上下文压缩（compaction）必然伴随信息损失，而 Claude 不会告诉你它忘了什么。

GitHub Issue #35296 更尖锐地指出：1M 上下文窗口的宣传和实际表现之间存在显著差距。 提交者做了 25+ 次实验验证，认为模型在 80% 容量之前就已经开始输出质量下降。

坑 3：额度迷局

花了 200 美元买 Max 套餐，结果：

  • Issue #29579：用量面板显示只用了 16%，就被限流了
  • Issue #33120：每一条命令都返回”Rate limit reached”，包括 claude logout
  • Issue #28537：同样的工作流，突然比前一天更快触发限流

多位用户在 Hacker News 上报告：花了 200 美元买 5 倍 Max 套餐，实际使用体验跟以前的 Pro 差不多。

Anthropic 从来不公布具体的额度数字。你不知道自己有多少额度、用了多少、为什么被限。这种”黑箱”机制让很多用户感到被欺骗。

坑 4：自动删文件

GitHub Issue #34330 记录了一个让人后背发凉的 Bug：Claude Code 在 300 毫秒内自动删除了用户创建的 .claude/skills/ 目录。

是的，你没看错。你刚创建的文件，还没来得及眨眼，就被 Claude Code 的运行时给删了。

这种 Bug 如果发生在更关键的文件上呢？比如你的配置文件、你的源代码？

坑 5：第三方工具封杀

2026 年初，Anthropic 突然封锁了第三方工具（如 OpenCode、Cursor）使用 Claude Max 订阅的能力。

很多开发者是专门为了在 OpenCode 里用 Opus 才买的 Max 套餐。一夜之间，他们的工作流崩了，花的钱打了水漂。

社区反应激烈。有人说 Anthropic 在”speedrun 从可原谅的创业公司变成可恶的大公司”。虽然从商业角度看，这个决策可以理解（API 级用户的成本确实很高），但执行方式——没有预警、没有过渡期——伤害了最忠实的用户群体。

不止是 Claude Code 的问题

公平地说，这些问题不是 Claude Code 独有的。

TechCrunch 在 2 月的报道指出：AI 编码工具催生了一场”低质量代码洪流”。开源项目维护者被 AI 生成的垃圾 PR 淹没。Mitchell Hashimoto（HashiCorp 创始人）不得不建立一套系统，限制只有”经过担保的”用户才能向项目贡献代码。

Faros AI 的开发者调研发现：所有 AI 编码工具都面临同样的问题——“成本、配额和可靠性”。开发者普遍抱怨额度用得太快，而且至少有一次重大服务中断（2026 年 1 月 14 日 Opus 和 Sonnet 大面积报错）。

一位在 20 多个客户项目中使用 AI 编码工具的咨询公司总结得最到位：

“对于有经验的开发者来说，AI 工具可能引入的微妙错误，调试起来比自己写代码还费时。真正的战略问题不是’哪个工具最好’，而是’哪种失败模式成本最低’。”

怎么用才不会被坑？

说了这么多问题，不是要你弃用 Claude Code。它确实是目前最强的 AI 编程工具之一。但你需要调整使用方式。

1. 永远不要无审查地接受 AI 代码

这是最基本的原则。AI 生成的每一行代码，都应该经过你的审查。

尤其注意：

  • 安全相关的代码（认证、权限、加密）
  • 数据库操作（特别是删除和修改）
  • 边界条件和错误处理

Claude 有一个有趣的”讨好”特质——它会写出看起来很完美的代码，但可能在你不注意的角落藏着逻辑漏洞。一位开发者发现 Claude 写了一个用 LIKE 查询加密数据的语句——语法完全正确，逻辑完全错误，因为加密后的输出每次都不同。

2. 控制项目规模和会话长度

Claude Code 在短会话、明确任务上表现最好。当你的会话变得又长又复杂时，它的表现会急剧下降。

实操建议：

1
2
3
4
5
6
7
8
9
✅ 好的用法：
- 一次解决一个明确的问题
- 会话聚焦于单个功能模块
- 每次会话前提供清晰的上下文

❌ 坏的用法：
- 一个会话里做完整个项目
- 让 Claude 同时处理 10 个文件的修改
- 期望它记住 3 小时前的对话细节

3. 用 CLAUDE.md 做”防呆”

把项目的关键信息写在 CLAUDE.md 里：技术栈、文件结构、编码规范、**特别是”不要做什么”**。

1
2
3
4
5
6
# CLAUDE.md

## 绝对不要做的事
- 不要修改 config/database.yml
- 不要删除任何测试文件
- 不要在 API 路由中直接使用用户输入

这不能 100% 防止 Claude 越界，但能显著降低概率。

4. 开启审批模式

Claude Code 的权限配置支持对高风险操作开启审批：

1
2
3
4
5
6
{
  "permissions": {
    "allow": ["Read", "Glob", "Grep"],
    "deny": ["Bash(rm *)", "Bash(git push --force)"]
  }
}

不要给 Claude Code 无限制的文件写入和命令执行权限。 这是你的最后一道防线。

5. 多模型交叉验证

一个被验证有效的策略：用 Claude 写代码，用 GPT 或 Gemini 做 Code Review。

Claude 有一个被社区称为”happy path bias”的问题——它倾向于写出能跑通的代码，但会忽略异常路径和边界情况。用另一个模型来审查，能有效弥补这个盲点。

写在最后

我每天都在用 Claude Code。写这篇文章的过程中，它也在帮我搜索资料、整理信息。我认为它是目前最好的 AI 编程工具之一，没有之一。

但”最好”不等于”完美”。

77,800 个 Star 的背面，是数千个未修复的 Bug、愤怒的用户反馈、和一个尚未成熟的产品。滑铁卢大学的研究告诉我们，最好的 AI 编码模型也有 25% 的错误率。康奈尔大学的研究更尖锐——用 AI 可能让你更慢，而不是更快。

这不是 AI 的失败。这是一个正在成长中的技术的现状。

问题不在于 Claude Code 有 Bug——所有软件都有 Bug。问题在于太多人把它当成了不会犯错的神。当你带着这个预期去用它，你的代码库就是一个定时炸弹。

正确的心态是：Claude Code 是一个极其聪明但偶尔犯傻的初级开发者。 它写代码比你快，覆盖面比你广，但判断力不如你，而且不会告诉你它不确定的地方。

用好它的关键，不是信任它，而是信任但验证。

你在使用 Claude Code 的过程中踩过什么坑？有什么避坑技巧想分享？还是说你用得一直很顺？欢迎评论区聊聊你的真实体验。