谁说AI可以把程序员失业

DDD888

一切照旧

我遇到CLAUDE这个错误Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row. A file being read or a tool output is likely too large for the context window. Try reading in smaller chunks, or use /clear to
  start fresh.


GOOGLE一下，找到这连接，说是DUPLICATE，点上原始连接，因为INACTIVE，被关了

改错太方便了，就是不做事

https://github.com/anthropics/claude-code/issues/60485

yrqin

ChatGPT回答：

这个帖子很短，但其实包含了几个值得分析的点。

### 帖子在说什么

作者的逻辑大概是：

1. 使用 Claude Code。
2. 遇到一个错误：

> Autocompact is thrashing...

3. 去 Google 搜索。
4. 找到 GitHub Issue，但发现该 Issue 被标记为 **Duplicate（重复问题）**，原始 Issue 又因为 Inactive 被关闭。
5. 得出的感受是：

> **"改错太方便了，就是不做事。"**

也就是说，他是在吐槽 Anthropic 的 issue 管理流程，而不是 AI 写代码能力本身。

---

## 这个错误到底是什么？

错误内容：

> Autocompact is thrashing: the context refilled to the limit within 3 turns...

意思并不是：

> Claude 不会写代码。

而是：

> Claude Code 在自动压缩上下文（Auto Compact）之后，很快又因为上下文爆满，不得不再次压缩，于是连续发生几次，最后直接停止工作。

官方提示也说得很明确：

> 很可能是某个文件、工具输出或者日志太大，建议分块读取，或者 `/clear` 开一个新会话。([GitHub][1])

---

## 作者说"Google一下"

这一点其实说明：

AI Coding Agent 目前仍然需要开发者具备传统开发能力。

很多时候流程还是：

```
Claude报错
      ↓
Google
      ↓
GitHub Issues
      ↓
Reddit
      ↓
自己判断
```

这和以前 IDE 报错并没有本质区别。

---

## "Duplicate + Inactive" 是什么意思？

GitHub 很多大型项目都是这样管理 Issue。

例如：

```
Issue A
Issue B
Issue C
Issue D
```

管理员发现：

其实都是同一个 Bug。

于是：

```
Issue B
Closed as duplicate

Issue C
Closed as duplicate

Issue D
Closed as duplicate
```

所有讨论集中到：

```
Issue A
```

如果 Issue A 长时间没人更新：

```
Closed as inactive
```

这并**不代表 Bug 已经修复**。

很多大型开源项目（包括 Kubernetes、VS Code、React）都会这样管理 Issue。

---

## 作者为什么觉得"就是不做事"

因为用户心理通常是：

```
我提交Bug

↓

GitHub说 Duplicate

↓

去原Issue

↓

原Issue又关了

↓

那到底修没修？
```

这种体验会让人觉得：

> "你们只是把 Issue 关掉，没有真正解决问题。"

但实际上：

GitHub 的关闭状态更多是**项目管理行为**，并不等于 Bug 已修复。

事实上，这个错误在 Claude Code 社区确实出现过多次，有不同版本、不同场景的报告，有的被标记为 duplicate，有的被关闭为 not planned，也有官方后来修复了其他相关的 auto-compact 问题。([GitHub][1])

---

## 标题"谁说AI可以把程序员失业"

其实正文和标题关系不大。

正文真正表达的是：

> AI 工具自己也有 Bug。

很多论坛都会出现这种标题党：

> AI 都这样了，还能替代程序员？

但实际上：

* AI 模型能力（Claude、GPT）
* Claude Code 这个产品
* Claude Code CLI
* GitHub Issue 管理

这是四件不同的事情。

Claude Code 出 Bug，并不能说明 AI 不会编程。

---

## 我的看法

如果从软件工程角度来看，这个帖子反而说明了一件事：

AI Coding 工具已经复杂到和 IDE、数据库、中间件一样，会有自己的 Bug、版本回归（regression）、上下文管理问题等。例如，这个问题就被报告为在某个版本出现的回归，并且与自动压缩上下文机制有关。([GitHub][1])

因此，**"AI 能不能替代程序员"** 和 **"AI 编程工具是否有 Bug"** 是两个不同的问题。

更合理的结论应该是：

* AI 的确显著提高了程序员的生产力（包括自动修 Bug、生成代码、重构、解释代码等）。
* 但 AI 编程工具本身也是软件，也会有 Bug，也需要不断迭代和修复。
* 因此，目前更准确的说法是：**AI 正在改变程序员的工作方式，而不是因为某个工具出现 Bug，就说明 AI 无法胜任编程。**

[1]: https://github.com/anthropics/cl ... _source=chatgpt.com "[BUG] Autocompact thrashes within 3 turns on fresh sessions"

yrqin

官方提示也说得很明确：

> 很可能是某个文件、工具输出或者日志太大，建议分块读取，或者 `/clear` 开一个新会话。([GitHub][1])

lz多和AI聊聊天，也行还能借机温习一下逻辑推理的基础

至于你说的这个问题，极大概率就是错误的使用方式，很小概率是claude code用户遇到的并不常见、优先级又特别低的问题

我用了一年claude code了，从来没遇到这个问题。官方的提示也很清楚了：很可能是上下文context窗口管理出了问题，属于一种错误的使用方式。

观察下来，个人感觉lz遇到的很多问题，大多觉得自己都是正确的，自己完全理解了工具的性能、边界、使用技巧了，所以很少从自己身上找问题。

当然，有自信是好事

DDD888

yrqin 发表于 2026-7-14 09:55
ChatGPT回答：

这个帖子很短，但其实包含了几个值得分析的点。

你違反了自己的簽名，去面壁反省吧

yrqin

DDD888 发表于 2026-7-14 10:02
你違反了自己的簽名，去面壁反省吧

我的签名讨论的是网络争论容易变成情绪表达。而且我确实第一时间和ChatGPT聊天了，这点还是非常符合我的签名的吧

回到这个帖子本身，我还是认为：

官方提示已经给出了可能原因；
一个 GitHub issue 不能推出 AI 不行；
如果你有证据说明这是普遍问题，可以贴出来讨论。

关键是你遇到的问题和帖子的标题可以说没有什么必然联系。这个ChatGPT也分析的很好

zhongbingo

接受这个事实吧。 IT 过去三十年， N多职业少了90%的位置， 比如Network admin， Server admin 等等

kawara

这个网友的抱怨有相当道理，但“就是不做事”说得稍微绝对了一点。

他遇到的错误意思是：

Claude Code 自动压缩上下文后，没过三轮上下文又满了；连续发生三次，于是主动停止，防止继续烧 Token、反复压缩却没有进展。

Anthropic 现在的官方文档已经把它当成一种已知运行状态，建议分段读取文件、缩小工具输出、把任务放进 subagent，或者 /compact、/clear。官方解释是这个保护机制为了避免无限循环浪费 API 调用。

但网友不满的关键并不是“为什么有保护机制”，而是：

他认为自己并没有读取超大文件，Claude Code 却错误判断发生了上下文爆炸。

他贴的 #60485 报告很具体：

* Claude Code 2.1.144 升级后开始出现；
* 新会话大约三轮就触发；
* 自动加载内容合计约 41KB；
* 没有大文件读取或超大工具输出；
* 上一个版本同一项目正常。

这显然更像是上下文计数、自动注入内容或者压缩阈值的回归问题，不能简单归咎于用户“文件太大”。

更值得批评的是 GitHub 的处理方式：

1. #60485 被直接标记为 duplicate；
2. 对应的旧问题被标记为 inactive/stale，后来以 not planned 关闭；
3. 没有负责人、没有关联 PR，也没有公开的修复结论；
4. 到 2026年7月还有用户报告，在全新会话里只输入一个单词，也会连续压缩并耗尽上下文，当前 #72857 仍然开放。

所以他说：

“改错太方便了，就是不做事”

情绪化，但并非毫无根据。更准确的说法应该是：

Anthropic 很擅长用自动化把 issue 去重、贴标签、关闭，却没有给用户足够透明的根因分析和修复状态。

不过还不能断言工程师完全没做事。也可能有以下情况：

* 他们认为这是设计上的保护机制，而不是单一 bug；
* 不同用户的根因不同，包括 MCP 输出、插件、CLAUDE.md、memory 和工具定义共同占用上下文；
* 某些服务端修改已经上线，但没有在 GitHub issue 里公开关联；
* 团队选择完善文档和规避方案，而没有重新设计上下文管理。

但从用户视角看，这种处理确实很差：把“错误触发保护机制”和“用户真的读入超大内容”混成一类，然后用 /clear 让用户重新开始。 对于让 Agent 长时间自主工作的人，这不是小毛病，而是直接使任务中断。

这件事也正好削弱了那些“Agent 可以连续几个小时完全自动干活”的宣传。上下文、工具输出和自动压缩只要有一环失控，所谓自动化就会停在那里，最后仍然需要人去检查、缩小任务和重新喂上下文。

htan564

不是AI取代你的工作， 是一个用AI的人取代了你的工作。

kawara

yrqin 发表于 2026-7-14 10:10
我的签名讨论的是网络争论容易变成情绪表达。而且我确实第一时间和ChatGPT聊天了，这点还是非常符合我的 ...

你用的是免费版吧

Flyingfree

kawara 发表于 2026-7-14 10:49
这个网友的抱怨有相当道理，但“就是不做事”说得稍微绝对了一点。

他遇到的错误意思是：

你用的是哪个AI？

KDS摩斯狗

使用AI，前期要做不少的培训和纠错工作。直到做出最满意的结果。
如果没有前期的铺垫，上来直接让他做，效果不会好

kawara

Flyingfree 发表于 2026-7-14 12:53
你用的是哪个AI？

ChatGPT 5.6 Sol high

KDS摩斯狗

AI如是说：

这个网友吐槽的点，其实比表面上的 **"Claude Code 报错"** 更深一层。

## 第一层：Bug 一直存在

他遇到的是

> Autocompact is thrashing

这是一个真实存在的产品问题。

说明 Claude Code 的 Context Management 在某些场景（大文件、工具输出、Agent 连续调用）下仍然会进入恶性循环。

所以他首先希望的是：

> **官方承认这是一个持续存在的问题。**

---

## 第二层：Issue 被「行政化」处理

真正让他生气的是 GitHub 的流程。

他经历的是：

```
发现 Bug
      ↓
提交 Issue
      ↓
Bot：Duplicate
      ↓
点击原 Issue
      ↓
Original Issue：Closed / Inactive
```

于是整个流程变成

```
Bug
↓
不能开新的
↓
旧的也不能回复
↓
没人真正处理
```

他的感觉就是：

> **不是 Bug 被解决了，而是 Bug 被管理掉了。**

这是很多大型开源项目都会被吐槽的问题。

---

## 第三层：Issue 数量比 Bug 更重要

很多 Maintainer 会追求：

* Open Issues 少
* Duplicate 少
* Dashboard 看起来健康

于是就会：

```
任何类似问题
      ↓
Duplicate
      ↓
Close
```

从项目管理角度，这是：

> 降低维护成本。

但从用户角度，就是：

> **你是在降低 Issue 数，不是在降低 Bug 数。**

这就是他说

> **"改错太方便了，就是不做事。"**

真正的含义。

---

# 第四层：用户失去反馈渠道

这才是最大的问题。

如果 Original Issue 还是 Open：

用户还能：

* +1
* 上传日志
* 补充版本
* 补充复现

Maintainer 还能知道：

```
2025
有人遇到

↓

2026
还有几十个人遇到

↓

说明没修好
```

但是：

Original Close

↓

Duplicate Close

↓

没人能继续说

于是官方得到的信息就是：

> **没有新的 Bug。**

实际上：

> **不是没有，而是没人能报告。**

---

# 为什么会这样？

GitHub 默认没有「Duplicate but still active」这种状态。

Maintainer 一般只有几个选择：

* Open
* Close
* Duplicate

很多项目为了控制 Issue 数量，就会全部 Duplicate。

时间一长：

Original 因为没人更新

↓

Bot 自动 Inactive

↓

Close

↓

形成死循环。

---

# 更合理的解决方案

我觉得至少有三种。

## 方案一：重新打开 Original（最佳）

如果 Bug 仍然存在：

```
Duplicate
↓

Reopen Original
```

保持一个 Tracking Issue。

Linux Kernel、Rust、VS Code 都经常这样做。

优点：

所有讨论都集中。

---

## 方案二：不要关闭新的 Issue

如果 Original 已经一年没人维护：

新的 Issue 应该保留。

例如：

> Duplicate of #12345, but reopening because the problem still exists in v1.2.8.

这样：

旧 Issue 是历史。

新 Issue 代表：

最新版仍然存在。

---

## 方案三：建立 Meta Issue

例如：

```
Memory Management Issues
```

所有：

* Context Overflow
* Autocompact
* Thrashing
* Token Explosion

全部集中进去。

下面持续更新：

```
Known

Investigating

Fixed

Regression
```

很多大型项目都是这样做。

---

# 对 Claude 团队来说，还有一个产品层面的建议

其实这个错误本身也可以做得更友好。

目前只有一句：

> Try reading smaller chunks.

但用户其实不知道：

到底是谁导致 Context 爆炸？

Claude 完全可以告诉用户：

例如：

```
Context Usage

tool output
74%

README.md
18%

logs.txt
6%

conversation
2%
```

或者：

```
Recent context refill

✔ read src/app.ts
✔ read package-lock.json (420KB)
✔ grep output (19000 lines)

This likely caused autocompact thrashing.
```

这样用户马上知道：

> **不是 Claude 坏了，而是哪个操作把 Context 塞满了。**

这比一句：

> Try reading smaller chunks

有用得多。

---

## 总结

这个网友真正的不满，并不是一句错误提示，而是三个问题叠加：

1. **产品问题仍然存在**——`Autocompact is thrashing` 在实际使用中仍会频繁出现。
2. **Issue 管理流程割裂**——新 Issue 被标记为 Duplicate，但指向的原 Issue 已经因 Inactive 被关闭，用户失去了继续反馈的入口。
3. **缺乏透明度**——无论是 GitHub 的处理流程，还是 Claude Code 的错误提示，都没有告诉用户“为什么发生”和“现在该怎么办”。

从用户视角看，这会形成一种印象：

> **Bug 并没有消失，只是从 Issue 列表里消失了。**

如果官方希望减少这种挫败感，除了改进底层的 Context 管理，更重要的是保留一个**持续开放的追踪 Issue（tracking issue）**，并让错误信息能够指出是哪一个文件、哪一个工具输出或哪一次操作导致了上下文反复溢出。这样既方便开发者定位问题，也能让用户感受到自己的反馈真正进入了修复流程，而不是被简单归类后结束。

xxxxyyyy

大师，你天天说AI不好，但是往往用AI用的最多最狠的人就是你这样的，
而且发现AI特别有帮助以后，在网络上面吹嘘AI没啥用，让别人不要去用

你把RTX 5090免费发给我，我接到Macbook pro M5 Max上面加强AI算力，
我就相信你说的

DDD888

xxxxyyyy 发表于 2026-7-14 18:41
大师，你天天说AI不好，但是往往用AI用的最多最狠的人就是你这样的，
而且发现AI特别有帮助以后，在网络上 ...

你這樣快就對你的Macbook pro M5 Max的算力有需求增加了？？？

DDD888

KDS摩斯狗 发表于 2026-7-14 14:51
AI如是说：

这个网友吐槽的点，其实比表面上的 **"Claude Code 报错"** 更深一层。

嗯，错都在客户，那个程序员，嘻嘻

eguan88

https://news.qq.com/rain/a/20260714A05JTQ00

北京副局长10亿Token手搓防汛应用, 本来可以拿到预算4000万的防汛APP结果被傻批副局的10亿token干没了, 本来最后是由几个程序员承接外包的现在也没机会了。

Flyingfree

eguan88 发表于 2026-7-15 14:55
https://news.qq.com/rain/a/20260714A05JTQ00

北京副局长10亿Token手搓防汛应用, 本来可以拿到预算4000万 ...

北京市规划和自然资源委员会密云分局副局长谢陨石自掏腰包买了10亿token，凭借自己的编程基础，同时借助腾讯云代码助手CodeBuddy和智能工作台WorkBuddy等AI工具，花近一个月时间“手搓”防汛小程序“叫应”，把全区的隐患点、受威胁险户、包保人员全部装进手机。

我想知道他这10亿token要花多少钱？

DDD888

Flyingfree 发表于 2026-7-15 15:53
北京市规划和自然资源委员会密云分局副局长谢陨石自掏腰包买了10亿token，凭借自己的编程基础，同时借助 ...

我帮你问了GOOGLE AI， 腾讯云代码助手CodeBuddy和智能工作台WorkBuddy 10亿token要多少人民币？

这是回答，4.6万元人民币不贵呀



如果您是看到“北京密云副局长自费买10亿token用WorkBuddy和CodeBuddy手搓防汛小程序”的热搜新闻 后来询问价格，这里为您提供准确的账单拆解：这位局长实际使用的并不是通过直接购买 API 原始 Token 的方式，而是购买了腾讯云针对这两个产品推出的 “加量包积分（Credits）”，折算下来其自费金额约为 4.6万元至4.8万元人民币。以下是具体的计费方式与价格换算：1. 腾讯云 CodeBuddy & WorkBuddy 的计费逻辑腾讯云的这两款 AI 工具（CodeBuddy 代码助手与 WorkBuddy 智能工作台）并不直接面向个人用户按“多少钱/每百万 Token”零散售卖。计费载体：产品内部统一使用 “积分（Credits）” 扣费。兑换比例：在腾讯云的底层扣费标准中，根据模型不同（如混元大模型），通常 1 个 Credits 积分 ＝ 2 万余个 Token 额度。换算结果：因此，用户想要在软件里消耗完 10 亿 Token，大约需要购买并消耗 50,000 个 Credits 积分。2. 10 亿 Token 对应的官方价格（人民币）根据腾讯云官方发布的最新计费方案公告，企业或个人在消耗完版本自带的基础额度后，可以通过购买“企业加量包”来扩容积分，其价格如下：50,000 Credits（约合 10 亿 Token）加量包：官方原价：2,375 元 / 个 / 月活动/续费折扣价：1,900 元 / 个 / 月⚠️ 关键误区提示（新闻中的时间跨度）：新闻中明确提到，该局长“手搓代码花了近一个月时间”。而在 WorkBuddy 这种多智能体（Multi-Agent）高频并发、自动跑任务的真实工作流场景中，AI 需要在后台不断地帮人类阅读代码、调错、执行自动化操作，每秒都在高频产生 Token 消耗。如果是一个人一个月内并发调用高频消耗了 10 亿 Token，他需要一次性顶格购买极高规格的加量包（例如购买多套最高规格的 200,000 Credits 组合包，折合人民币约 4.6 万 ~ 4.8 万元）。如果是如果是通过腾讯云底层的 API 资源包直接调用，10亿 Token 的标准官方预付费资源包价格则在 1,800 元至 11,100 元 之间（具体取决于调用的是基础混元轻量模型、还是最新的 Hy3 高级推理/代码模型）。3. 热搜后续由于该系统在汛期实战中效果极好，帮助基层省去了繁琐的人工统计，腾讯官方已于 2026 年 7 月 13 日公开回应，决定再免费赠送该团队 10 亿 token（价值数万元的 Credits 积分），并提供后续的专业产品和技术团队支持，助力其数字化防汛工作。如果您正准备为团队部署这两款工具，目前两款产品已实现账号互通。您可以根据需要购买：SaaS 企业版：198 元 / 人 / 月（每人每月自带 2000 积分）。专有云企业版：316 元 / 人 / 月。如果您需要了解如何为您的团队配置这两款工具的成本预算，可以告诉我您团队的 开发人数 或 预计的日常使用频率，我为您做个精确的年化费用测算。

gifox

Flyingfree 发表于 2026-7-15 15:53
北京市规划和自然资源委员会密云分局副局长谢陨石自掏腰包买了10亿token，凭借自己的编程基础，同时借助 ...

input和output不同，大概几千人民币。

Flyingfree

gifox 发表于 2026-7-15 16:39
input和output不同，大概几千人民币。

他有编程基础，还要花一个月时间，看来他用的模型应该不咋地。

superdigua

https://x.com/PalmerLuckey/status/2077216959930728889

所有认为 AI 垃圾会毁掉代码效率/性能的人，到时候看到一切都变成约翰·卡马克风格的、荒谬高效的机器码时，会惊讶得不得了的。

DDD888

superdigua 发表于 2026-7-15 16:59
https://x.com/PalmerLuckey/status/2077216959930728889

所有认为 AI 垃圾会毁掉代码效率/性能的人，到时 ...

不必说将来啦，我记得以前的教育是共产主义必然将来是战胜资本主义啦，我们有千千万万同胞都受到这个洗脑，你现在也来给我们洗脑？？？大家都出国了，我是不信的啦

superdigua

DDD888 发表于 2026-7-15 18:46
不必说将来啦，我记得以前的教育是共产主义必然将来是战胜资本主义啦，我们有千千万万同胞都受到这个洗脑 ...

目前 AI 公司内部使用的模型也比向外部用户提供的最强模型，要强得多。

DDD888

superdigua 发表于 2026-7-15 19:21
目前 AI 公司内部使用的模型也比向外部用户提供的最强模型，要强得多。

得不到的就是最美好的

yrqin

kawara 发表于 2026-7-14 10:53
你用的是免费版吧

我长期使用claude code/codex，付费AI一直都是没有断的。

不知有哪些地方是我的ChatGPT回复说错了的呢？或许只是讨论的焦点不同而已？

f221644

ai会导致厉害的更厉害，菜的更菜