这两天进展很不顺利，不仅手头进行的工程不断反复毫无进展，还因为一个疏忽破坏了原本正常运行的工程，经过一天努力都无法恢复，只能想办法重建。
其实，这样的例子在使用cursor的用户中随处可见，当然不仅仅是cursor，用其他vibe coding agent方式的，都会碰到。
所以你无法怪罪给Cursor，作为最早的“套壳”工具之一（另外一个应该是perplexity），上限毕竟就是底层模型，比如现在一直使用的“编程最强”——Claude 3.7。
Agent说的再花哨，在各种实用场景下，能力还是局限在基础模型本身。
但是，即使是同样的基础模型，在当下，“套壳”应用的能力也已经远低于模型原生应用了。
以Cursor为例，同样使用Claude 3.7，处理同样的文档，原生的Claude应用可以在artifacts里生成非常漂亮的可视化效果，而到了Cursor中，经常是各种尝试了半天也难以接近。
一个是绝对的大师级输出：
回到Cursor，同样的提示词，看到的就是不断的失败。
其实，问题一点都不复杂：
- 大概从去年四季度开始，OpenAI、Anthropic、Google都把围绕模型做好应用作为更重要事项，应用与自家模型的融合度当然要比“套壳”的高很多；
- API使用的限制，虽然模型可能是完全一样的，但是API调用还是有很多限制的；
当然，在上面的限制下，类似于Cursor这样的应用依然有其自己的核心竞争力：
- Cursor有自己的训练的模型，更符合代码开发的习惯；
- Agent的流程经过了大量优化，使得在绝大多数时间开发过程很流畅，vibe coding就是基于这种流畅而来的；
可是，终究，它还是会面临巨大的挑战，Google基于Gemini已经推出了Firebase Studio，虽然目前的能力看起来跟Cursor比还是有显著的差距，但是特色也很明显：
- 在线环境下的项目开发，也就是用手机都可以随时进行vibe coding，如今我在公交地铁，路边长椅上进行vibe coding的机会越来越多，在线环境会越来越重要；
- 代码生成速度飞快，token生成速度一直是gemini 2.0后模型的巨大优势，如今到了代码上，这就是妥妥的生产力；
也许，按照Google在大模型上从落后到Gemini 2.5全面反杀的速度，Firebase Studio也许用不了多久就可以至少赶上Cursor。
Cursor团队要好好想想如何应对了，其实，从今年开始，我obsidian使用的比例已经显著下降了，如今的工具环境基本就是三大模型的应用，以及Cursor了，我越来越需要一个All-in-One的IDE。
是的，套壳就是套壳，在基础模型不断深化应用的背景下，生存空间越来越小。
但是，创业公司靠齐更聚焦的能力和灵活性，总还是能获得一些先机的，也许，连续抓到两三次先机就可以至少有立足之本也未可知。
在我边写文章的同时，Cursor终于完成了上面的任务。它只是无法像Claude应用一样跟自己的模型做更好的融合，但是如果给它很多次尝试的时间，再做好“全程辅导”，还是可以得到不错的效果的。
然而， 套壳的终究还是套壳的，模型之上，我们确实需要一个个工具，却成为最好的模型公司与创业公司从相互协作越来越走向竞争的领地。