范式与流量:从外卖大战到Sealos

如题，聊聊最近热火的外卖大战，以及背后的即时零售的新范式之争，最后粗浅谈谈（Sealos）。

写之前

这会是一篇以观察和思考为主的文章，不具备什么实操性。

我以前有个很大的毛病，喜欢提问题，然后给不出解决方案。

我最近给自己立了个原则，提出一个问题，至少要给出一个相对应的解决方案。

细心的读者也可以看到，我最近的几篇文章，都有一个共同的暗线，就是最终一定要拆解为 Action（行动）。

但是我还是把这篇文章写出来了，既是遵从内心，也是觉得这些思考过程挺有意思的，把很多东西串在一起了。

同时，我现在做的另外一件事就是，看更多好的产品，思考他们的发展路径，来学习与启发自己。从这点上，也是和我现阶段的目标相符的。

故事是如何发生的

一直在 Sealos 的 UI/UX ，一款开源的企业级云操作系统。我一直认为他们的技术很美（架构简洁、生态思维），产品也美（UI 美，使用简单而高效），理念也美（开源）。

短期来看，Sealos 的理念就是做好开发相关的事情，例如简化开发流程、简化部署流程；又或者说，让开发者无须关注开发以外的事情。

但思想开阔一些，从更宏大的层面上，是 帮助用户更快更好地构建一个产品 。只是因为现阶段，构建产品时，开发的工作量占据了大部分。长远来看，现在的产品研发路径越来越端到端了，能够从自然语言直接生成用户可访问的产品。

同时，从 AI Proxy 的推出等行动来看，他们是想定义 「新范式」 的。

范式！说到这里我就不困了！（自己把自己讲醒了）

现在的外卖大战，不也是范式吗！！！

外卖大战背后：即时零售

最近外卖大战，消费者可太爽了！

作为高强度刷知乎的我，自然也刷到了相关的分析帖子，里面的观点很有意思。

为什么现在京东、淘宝、美团还要搞外卖大战呢？大概 10 年前不是已经搞过一次了吗？

所以这相差 10 年的外卖大战，本质的区别是什么呢？

10 年前，外卖是新兴行业，战的是外卖；如今，表面战的是外卖，实际战的是 「新范式」——「即时零售」 。

美团从 24 年开始力推小象超市，一种即时零售，能够把商城购物，做到外卖的时效（30 分钟）。

对于消费者来说，很多东西就是想马上就到手；又或者说，如果购买一个东西有两个选择，一个马上到手，一个要次日达，大家会选哪个？

基于此背景下，即时零售开辟了一个新的范式，正在逐渐扭转消费习惯。

所以美团这是在动摇各个电商 APP 的基本盘，自然的，各大电商 APP 也要动摇一下美团的基本盘，也尝尝即时零售的味道。

范式与流量的关系

新的革命式的范式，能够带来「排山倒海」（词穷了）的流量。换句话说，革命性的范式能凭空造流量。

• 从线下店到淘宝的范式：极大地降低了大街购物的次数，流量从线下到了淘宝
• 从淘宝到直播的范式：淘宝一直以来的一个问题是，大家不购物就不会主动打开淘宝。而大家经常刷短视频，刷着刷着不小心刷到了一个带货直播，顺手就买了。这也是范式转变的力量
• Cursor 带来的范式：大部分程序员开发都喜欢用为某个编程语言定制优化的 IDE（例如写 Go 用 Goland）。但是 AI 开发太猛了，虽然 Cursor 是基于 Vscode 的，但是一美遮百丑。（当然，Cursor 带来的不只是 IDE 流量入口的范式。）

回到 Sealos

Sealos 肯定很早就看到了这个范式的转变，在布局 AI，努力参与到新的范式定义中来。确实是一个长期且比较难的事情。

不过从另外一个层面来看，Sealos 其实已经定义了很多新的小范式。

• DevBox：开发环境即运行环境的范式。
• Sealos：云操作系统（使用云的能力而不关心容器细节）的范式。或者说之前官网强调的，一切以应用为中心。

拿 DevBox 而言，以前的开发范式是本地开发、本地搭建编程语言和数据库环境，再打包和部署。这种流程下，由于操作系统差异、网络联通等因素，开发环境的服务依赖和生产环境差异很大，甚至有很多 hack 的逻辑。

DevBox 打造的新范式，就是保证了把开发环境和线上环境的依赖链路一致、网络一致、文件一致。唯一不同的只是环境变量等细节。基于此，兼顾了本地开发与远程开发的优点。（细节的话就不展开了，以后可以认真写一篇）。

Sealos 本身，也是从 DevOps 的老范式，到平台工程化的新范式。从本地操作系统，到云操作系统的新范式。

把别人的范式转换为流量

所有的产品都在挤破头想出新的范式，但是新范式太难了，也可以把别人的范式转变换自己的流量。

例如 DevBox 可以和 Cursor、Windsurf 等打通；例如之前幻兽帕鲁火了，Sealos 能够做到一键部署。这些都做得非常不错。

引领新范式的必要性条件是什么

这是一个开放性的问题，必要条件的意思是，达成目标至少要满足的条件。

是团队规模吗？不一定，Cursor 人挺少的。

是团队技术背景吗，是资金吗，是公司创新文化吗？

甚至，没有必要条件？

其实我一直想在一个问题上找到答案，就是：

Agent 的能力壁垒是什么，做一个 Agent 玩具很简单，落地并生产可用却很难。但 Agent 毕竟是应用层的东西，看起来并没有那么深奥，是什么决定了它能力的涌现的呢？是整个架构的设计（如任务规划流程编排），还是各个环节的处理细节（Browser Use、Web Search、MCP 等），又或是 Agent idea 本身？

抛出问题很简单，行动才是关键。这也是我下个 Q 的目标之一。即，把从 AI 的整体性理论感知，转换为对实践细节的触摸。

又有个新的例子

文章还没来得及发出去，Kimi 就发布了 K2，看到了一个很有意思的观点。

Kimi 在官方 API 配置中，支持了 Anthropic API 格式。既是对自己模型能力的自信，也是一种利用别人范式转换为自己流量的方式。