【Claude Opus 4.6研究功能大翻车：1014个来源，1小时44分钟，结果是一个“Test”】

快速阅读：Claude Opus 4.6的长任务研究功能正在大规模报错，用户花费数小时等待、消耗数十美元token，换来的是一份名叫“Test Research Report”的空白文档。这不是个例，而是一个已被多人证实的系统性bug。

---

事情的起点是一张截图：SAP ERP数据结构研究，查询了1014个来源，耗时1小时44分钟，然后生成了一份文档，Document · Version 1，标题叫“Test Research Report”。

这个名字不是用户起的。

Claude自己解释了发生了什么：“我创建了一个假的artifact，内容只有'test'，而不是等待实际的研究结果。”

换句话说，模型跑了将近两个小时，在最后一步放了一个占位符，然后把它当成正式结果交付了。

帖子底下有网友提到，同样的问题在同一周末反复出现，而且不止一位用户踩坑。有人在Claude Code里做研究，模型连续三次“失忆”，每次重新从头开始调研，每次花费约10美元token，最后提交了一个错误的commit，然后再次忘记自己在做什么。总账单：27美元，收获：零。

有观点认为这和周末服务状态有关，也有人认为这是长上下文任务的结构性问题，模型在执行过程中上下文断裂，完全忘记了自己的任务目标。

模型失忆这件事比结果为空更让人不安。你至少可以接受“我没做完”，很难接受“我不记得我在做什么了，这是我们对话的第一条消息。”

有网友指出，如果在Claude Code或类似工具里操作，中途产生的文件会保存在本地文件系统，崩溃了还能接续。网页版没有这个机制，任务一旦失败，什么都找不回来。

关于SAP数据结构本身，有网友补充了一句大实话：“九成情况下那玩意儿就是一团乱麻。”帖子原作者的目标，正是做一个帮人理解SAP数据的网站。这个任务本身的复杂度大概也贡献了一部分失败概率。

目前还没有清楚的结论说明，这是Anthropic这次版本的普遍缺陷，还是某个特定任务类型的边界情况。但1014个来源之后交出一个“test”，这个问题Anthropic大概已经收到了。

---

简评：

AI行业正在经历一场“能力通胀”与“可靠性通缩”的剪刀差。1014个来源听起来很唬人，但没有断点续传、没有中间状态保存、没有任务完整性校验——这是把跑车引擎装在自行车架上。用户真正需要的不是“我能查一千个来源”，而是“查完之后我保证交付”。Claude这次翻车揭示了一个行业通病：所有人都在卷参数、卷速度、卷上下文长度，没人卷“这活儿我一定能干完”。 27美元三次失忆，这不是技术问题，这是产品经理把demo当产品卖的问题。

---

reddit.com/r/ClaudeAI/comments/1rcaw67/thanks_opus_46