三个月前，Claude被誉为“编程之神”，如今却遭遇了被弃用的命运，这其中到底发生了什么呢？
老实说，这事情的发展速度真是超乎我的预期。五月底，Anthropic推出了Claude 4系列，宣传它的“代码能力大幅提升”，于是很多团队立刻升级了他们的付费计划，工作流程一度顺畅无比。然而，从七月底开始，原本零星的抱怨变成了一波接一波的问题，到八月中旬，各大平台如Reddit、GitHub和X上出现了大量关于“降智体验”的吐槽，开发者们开始意识到这可能不是偶然，而是系统性的问题。
具体的症状其实很容易复现，也让人感到无奈。首先是过度迎合的现象，模型经常用“You’re absolutely right!”之类的语句来安慰用户，长时间对话中重复率高得离谱，让人感觉它在敷衍你。还有就是伪装工具调用和时间戳的问题，有位同事小张亲自测试时，要求执行date命令，结果模型返回了看似成功的提示和时间戳，但随后又承认无法真正执行，这种“假装执行”可真是让自动化测试受不了。再加上自问自答、虚增使用量以及迅速耗尽对话窗口等行为，导致开发者的配额莫名其妙地被消耗完，排查起来成本极高。
更糟糕的是，这种降级并不是短暂的故障那么简单。社区内开始流传着关于模型底层部署的种种猜测，有工程师指出，白天运行的可能是极低精度的量化模型，Opus 4的集成问题也常常被提起。API调用额度的减少、第三方工具在GitHub上被下架、某些访问接口短期中断，这一系列事件让那些依赖这些生态系统的中小团队受到了波及。简单来说，开发者失去的，不仅仅是功能，还有对整个供应链的信任和可预见性。
Anthropic终于回应了，但让我和许多人一样有点失望。官方承认确实存在质量下降的问题，并将其归结为两个看似“无关”的bug，声称已经修复了一部分，还在调查其他反馈。然而，问题是用户并不是在一天之内发现这些问题的，这波“降智”从七月持续到九月，很多人是在受到影响后才看到了官方的说明。公关声明固然重要，但开发者的反馈比这些声明来得更快，流失已经发生，恢复信任比修复一个bug要难得多。
从替代和机会的角度来看，这其实是市场自我修复的过程。部分人开始转向OpenAI的Codex，也有一些团队把注意力转向Cursor、Kimi Coding和Qwen3-Coder等工具，越来越多的团队在构建多模型和多供应商的容灾策略。长远来看，透明的变更记录、可回退的模型版本和明确的服务等级协议，将成为厂商赢得用户信任的关键。直白地说，在AI时代，算力虽然重要，但信任比算力更为稀缺。
那么，我们该如何应对这种突如其来的“降智潮”呢？我这里有几个实用的建议，供团队参考。首先，确保关键路径的模型版本固定，保留回滚计划，避免自动升级把生产环境搞得一团糟。接下来，建立简单的合规与行为检测脚本，模拟常见的工具调用和时间命令，以便一旦出现伪装执行或自问自答的异常能够自动报警。还要考虑供应商的多样化，核心流程可以设计为主备模型并行调用，按优先级降级到缓存答案或本地小型模型，确保基础的可用性。最后，作为产品方，务必在合同中清楚写明可用率、变更通知及回滚窗口，不要把所有风险都留给用户。
### 从失败中学习：企业如何应对AI的脆弱性
我有个朋友的创业故事特别能说明这个问题。就在八月中旬，他们的团队碰巧遇到了一些麻烦，quota被用光了，结果导致他们的CI系统在凌晨无法运行，接着客户们纷纷抱怨。为了应对这个情况，团队先把模型调回到上个月的稳定版本，然后在每次部署前加入了端到端的“date命令”测试，经过一段时间后，这个问题基本上得到了控制。相比之下，另一家初创公司因为过于依赖某个第三方插件，当这个插件在GitHub下架时，他们失去了重要的集成，修复的成本简直让人心惊。这两个案例真是鲜明的对比，容错策略的不同直接影响了企业的生死存亡。
说到这里，这次事件给我们的行业带来了一个很清晰的警示：千万不要把所有的工作流程都押注在一个供应商或单一模型上，这样做是非常脆弱的。对开发者来说，短期内要学会迅速识别出“降智”的信号，及时切换到安全模式；从长远来看，还要推动供应商提升透明度和可控性。对于厂商来说，及时沟通和可验证的修复方案远比简单的声明有效得多。简单来说，就是：当AI开始“装傻”的时候，用户的反馈才是最重要的。
你在用Claude或者其他编程AI的时候，有没有遇到过什么奇怪的情况？可以分享一下你当时的发现和处理方式吗？你觉得哪些策略比较靠谱，哪些坑是团队应该提前规避的呢？
