Claude Code 正经历从'AI 圈白月光'到开发者集体逃离的戏剧性转折。当模型能力不再碾压对手，其额度算法混乱、推理链断裂、安全边界模糊等产品缺陷被彻底暴露。本文通过真实用户反馈与量化数据，揭示这颗坠落新星如何将技术优势败给产品设计。
一个开发者最崩溃的时刻，不是 AI 写错代码。
而是它刚刚读完仓库、刚刚理清 bug、刚刚准备动手修改，屏幕突然弹出一句话：
你已达到当前会话的使用限制。
上下文断了，推理链没了，刚才那一大段排查过程像没发生过一样。你只能重新开一个会话，把问题从头再说一遍，然后看着它像失忆的实习生一样重新摸索项目结构。
这就是很多开发者过去几个月使用 Claude Code 的真实体验。
曾经，它几乎是 AI 圈的白月光。模型聪明，代码能力强，Agent 雏形，能钻进复杂项目里一点点推理，很多人愿意忍受它极客、昂贵、额度算法奇怪，因为它确实比别人能干。
但现在，白月光开始塌房了。
据 TickerTrends 统计，截至 5 月 3 日的一周，Codex 的 npm 下载量达到 8610 万次，Claude Code 则跌至 720 万次。前者是后者的 12 倍，这个差距，几乎完全来自 4 月 30 日到 5 月 3 日这 4 天的暴涨。
Claude Code 的地位怎么就被 Codex 取代了？不是 Codex 突然开窍了，而是 Claude Code 一次又一次把用户往外推。
“Claude Code 你就作吧，我换 Codex 了”，这样的表达在开发者中变得多了起来。
Claude Code 的麻烦，不是从 Codex 追上来才开始的。2026 年 4 月，Anthropic 发布 Opus 4.7，原本用户期待的是一次升级，等来的却是一场”叛变”。
用户发现，Opus 4.7 连”strawberry 里有几个 r”这种基础测试都能答错，修改简历时会凭空编造学校名，甚至还会承认自己”有点懒”，所以没有做交叉验证。
更魔幻的是，有用户质疑 Claude 某个措辞的来源，Claude 回答说”我搜索过了，但没找到”。Anthropic 倒也没借此宣传 Opus 自我意识觉醒了。
这已经不是简单的幻觉问题，而是信任问题。
AMD 的 AI 总监 Stella Laurenzo 随后做了一次量化分析。她统计了 6852 个会话、23.5 万次工具调用，结论是：Claude Code 的思考深度骤降 67%，代码修改前的文件读取率下降 70%，不良行为触发次数飙升 173%。一个写代码的 Agent，就这样失去了被托付终端的资格。
Anthropic 后来发了一份“检讨书”，承认这轮”降智”由三个 Bug 叠加造成：3 月 4 日，他们悄悄把默认推理强度从 high 改成了 medium。3 月 26 日，缓存 Bug 导致历史推理每次都被清除。4 月 16 日，系统提示又限制了响应长度，让编码质量再降约 3%。
按照 Anthropic 的说法，这些问题在 4 月 20 日已经全部修复。
但检讨书不是罪己诏，你 Dario 不是上帝，用户有别的选择。
麻烦不只来自产品降智，还有比浇了汽油的柴火更容易烧光的 Tokens。
2026 年 3 月 23 日，Reddit 上一条帖子引爆了投诉潮。一位 Pro 用户说，自己 3 分钟就用掉了 5 小时会话配额的 60%。另一位 Max 20x 用户，月付 200 美元，记录下自己的使用率在一条提示之后，从 21% 直接跳到 100%。
按照正常的 token 计费逻辑，这几乎说不通。
Anthropic 员工后来解释，工作日太平洋时间上午 5 点到 11 点之间，额度会加速消耗。翻译一下就是：你花的是同样的钱，但如果在高峰时段干活，服务会更快用完。
这对开发者来说非常别扭。编程不是刷短视频，不是今天没额度了，明天再看也无所谓。
开发任务经常会卡在某个关键节点上。一旦上下文断掉，损失的不只是几次调用，而是整个节奏，甚至是整个项目进度。从开发者的精神健康角度看，项目卡在一半，比便秘还难受。
双重暴击之后，还有坏消息：Claude Code 和 Claude.ai 网页聊天共享同一个额度池。模型升级后，tokenizer 的变化还可能让同样的输入消耗更多 token，等于用户在无感状态下被动涨价。
Anthropic 看似是在弥补，实则很懂用户心理。
它推出了按量付费的溢出机制：订阅额度用完之后，用户可以继续用，但要额外付费。问题是，用户已经花 20 美元买了订阅，却仍然可能在高强度开发场景下很快触发限流。项目要继续推进，就只能再掏一次钱。
这套逻辑很像国产游戏里的体力值系统。区别在于，国产游戏往往免费入场，Claude Code 却是先买月卡，再买体力。
开发者不是不愿意为好工具付费，而是讨厌不可预测的付费。你可以贵，但不能玄学；你可以限额，但不能让用户不知道自己到底什么时候会被踢下线。
Claude Code 把一个生产力工具的付费模式，做成了心理学实验。不知道是跟谁学的。
Claude Code 和 Codex 的差距，不是某一天突然拉开的，而是 OpenAI 用半年时间一步一步追上的。
2026 年 2 月，OpenAI 连续出手：2 月 2 日发布 Codex 桌面应用，3 天后发布 GPT-5.3-Codex，速度比上代快 25%，同时整合了编程与推理能力。
这是 Codex 从”终端工具”走向”完整产品”的节点。
4 月 16 日，Codex 又完成了一次升级：后台 computer use 上线，支持在用户工作的同时并行跑多个 Agent，新增内置浏览器，可以直接对页面批注给出指令，插件生态扩展到 90 个以上，涵盖 Jira、CircleCI、GitLab、Slack 等开发者日常工具链，同期上线的还有 Automations 功能，Codex 可以不等指令，自动处理 issue 分类、CI/CD 监控、告警响应这类重复工作。
而此时，Claude Code 正在忙着叠 Bug。
产品架构上，Codex 和 Claude Code 走的是两条相反的路。
Codex 把控制权收进云端沙箱。每个任务在独立环境里运行，预加载用户仓库，结束后交还结果。这带来三个好处：安全边界清楚，任务可以并行，执行过程可追踪。用户还可以用 AGENTS.md 写清项目规则、测试命令和代码规范，相当于给 Agent 配一份上岗说明书。
Claude Code 则更像本地终端里的高级工程助理。它贴近真实开发环境，能直接调用本地文件、命令行、MCP 和 hooks，灵活度很高。但灵活也意味着边界更模糊，一旦 MCP 配置、权限或工具链出问题，本地 Agent 就可能从效率工具变成攻击入口。
上下文管理上，差异也很明显。有用户测试发现，同一个 Express.js 重构任务，Codex 用了约 150 万 token，Claude Code 用了约 620 万，是前者的 4 倍多。原因不只是模型效率，也和 harness 设计有关：Codex 更适合把任务拆开并行跑，上下文不容易互相污染；Claude Code 一旦任务拉长，就容易在同一个上下文里反复探索、纠错、重试，把 token 烧在过程里。
所以两者的体感完全不同。
Codex 像是“把任务派出去”：边界清楚，结果可审查，更接近工程流程。Claude Code 像是“和一个聪明同事共享终端”，离现场更近，也更依赖用户自己控制权限、上下文和成本。
Claude Code 不是不强，而是强得更像一套高自由度工具箱。Codex 的优势则在于，它把 Agent 包进了一个更可控的生产力产品里。
也许 10 年后，Codex 会被吐槽老土，Claude Code 才是真理，但现在是现在。
其实仔细想想，上面这些问题，Claude Code 一直都有。只是以前 Claude 模型太强，替它遮住了太多东西。
UI 太极客，额度策略难以预判，安全边界靠用户自己摸索。这些问题放在早期并不致命，因为那时候 Claude 确实强。
当一个工具明显领先时，用户会主动替它找理由。开发者对 Claude Code 的宽容，本质上不是来自产品体验，而是来自模型红利。
但 Codex 在关键基准上追上来，Claude Code 原来被遮住的问题就会全部浮出水面。这时候竞争逻辑变了：不再是”Claude 明显更聪明，所以我忍它”，而是”既然 Codex 也够聪明，我为什么还要忍 Claude Code？”
过去是体验瑕疵，现在变成了决策风险。额度不透明影响团队预算，产品不稳定影响工程节奏，安全边界模糊影响企业接入。个人开发者可以凭感觉用一个工具，但组织不行。
这也是 Agent 竞争进入下一阶段的标志。第一阶段拼模型智力，第二阶段拼产品系统，谁能把模型装进一个可靠、透明、可控的工作环境里。
Claude Code 曾经拿到几乎最好的牌：最强的模型口碑，最早的开发者心智，最狂热的用户群。它本来有机会把模型优势沉淀成一个真正稳定的开发者平台。但它没有把窗口期用来补产品债，而是继续消耗用户的忍耐。
但故事还没结束。Anthropic 显然意识到了这一点，过去几个月，Claude Code 的迭代节奏明显加快，权限管理、多智能体协作、企业级部署能力都在快速补齐。模型底座的优势还在，开发者社区的积累还在，那批最早相信它的人也还在。
Claude Code 有足够的条件打一场漂亮的翻身仗。它需要的，只是把”聪明”之外的事情也做对。
作者｜董道力
本文由人人都是产品经理作者【硅星人】，微信公众号：【硅星人Pro】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。