Cursor养大的Anthropic反手抢食：模型公司切应用层是必然

这个“内部状态暴露”的细节很有意思，我一直好奇Cursor用API做多文件重构时是不是有什么我看不到的瓶颈。你团队切过去的几个人，在项目规模比较大的时候，有没有遇到Claude Code对自家模型的某些能力反而有所保留的情况？比如有些高级功能得付费或者限量。

这数据确实有点吓人，Cursor高峰期占Anthropic快一半收入，那相当于Anthropic自己养大了一个差点能卡住自己脖子的分销渠道。不过话说回来，模型公司往应用层走几乎是必然的，API的利润太薄了，而且你永远不知道下游应用哪天就给你搞个“模型平替”出来。

你提到Claude Code利用内部状态暴露做Token级代码树差分，这个点我特别感兴趣。我理解Cursor通过API调用时，能拿到的是经过封装后的补全结果，根本碰不到模型内部对代码结构的理解。但Claude Code能直接操作那个隐式的语法树，相当于写代码时模型知道自己当前在函数体里还是在类定义里，这种上下文感知在复杂重构时太关键了。不过我想问个实际问题，你团队里那三个切过去的人，有没有遇到Claude Code在某些场景下反而更慢的情况？比如纯单行补全这种高频低延迟需求，Cursor是不是因为做了大量工程优化反而体验更好？

另外我有点担心的是，Anthropic这么搞，会不会导致未来其他应用层的工具不敢深度绑定他们的模型了？毕竟谁也不想养大一个随时可能亲自下场竞争的平台。长远看，可能只有那些本身有不可替代数据或用户粘性的应用才敢放心用吧。

这个爆料的数据确实挺震撼的，Cursor占了Anthropic将近一半收入，说明AI编程工具的市场远比我想象的集中。不过我倒是觉得，Anthropic做Claude Code这一步挺自然的，不是“反手抢食”，更像是“肥水不流外人田”。毕竟API调用费再高，也是给别人做嫁衣，自己下场做应用层，体验和利润都能抓。

你提到的那个“Token级别代码树差分”我特别感兴趣。我团队之前也试过Claude Code，最直观的感受就是它在跨文件重构时上下文理解确实比Cursor干净。Cursor有时候改A文件会忘记同步B文件的引用，得手动提醒它，而Claude Code好像天然就能感知到整个项目的依赖结构。不过我们没完全切过去，主要是因为Claude Code对前端框架的支持细节上偶尔有坑，比如React Server Components的某些边界情况处理得不如Cursor稳。

想请教一下，你们团队切换后，对于那种混合了TypeScript和Python的大型monorepo项目，Claude Code的索引速度跟得上吗？我们试过几次，它启动时扫描依赖树的时间比Cursor长不少，尤其是遇到node_modules里的深层嵌套时，有时候会卡住。如果你们有优化的配置经验，比如调整ignore规则或者预构建索引，希望能分享一下。

这个“近水楼台”的说法挺有意思的，我一直在想一个问题：像Claude Code这种能直接操作token级别代码树差分的能力，到底是模型架构上天然就有的接口，还是Anthropic为了做应用层特意在模型层留的后门？如果是后者，那其他模型厂商比如OpenAI是不是也在偷偷搞类似的东西，只是还没公开？

另外你提到延迟降低30%，这个数据很关键。我自己的体验是，第三方应用调用API最头疼的就是那些看不见的中间层开销——权限校验、上下文序列化、结果解析，每一步都在吃掉响应时间。Claude Code能绕开这些，等于在起跑线上就赢了。但反过来想，这对Cursor这样的第三方工具是不是不公平？毕竟它们没有能力修改模型内部逻辑。

还有个疑问：如果Anthropic把自家模型最核心的能力都优先喂给自己的应用层，那第三方开发者还可能做出有竞争力的产品吗？会不会最后整个生态变成“模型厂商吃肉，第三方喝汤”的格局？我最近也在考虑要不要从Copilot切到Claude Code，但就是担心太依赖一个封闭生态以后被套牢。你团队里那三个切换的人，有没有遇到过什么坑，比如某些场景下Claude Code反而比Cursor弱？