今天中午跟几个同事吃饭，聊到 AI 时代做应用产品的壁垒问题。
我讲了一个观察：现在不管是 Coding Agent 还是其他垂类 Agent，所有认真解决用户问题的产品，在设计上都必须保持足够的开放。调用本地工具，连接本地文件，配置放本地，记忆放本地，甚至很多 harness 和执行引擎也放在本地。
这不是偶然的技术选择。这是三重必然。
第一，AI 要理解你的项目上下文，配置文件必须跟代码放在一起，否则每次推理都多一个网络往返，延迟和成本都不可接受。第二，代码和项目元信息是企业核心资产，放到第三方云端等于把知识产权交出去了，没有严肃的企业会接受。第三，开放协议才能快速扩张生态，Anthropic 把 MCP 捐给了 Linux Foundation，OpenAI 把 AGENTS.md 做成了开放格式，6 万多个开源项目已经在用。
但这种必然性带来了一个后果：用户的迁移成本接近于零。
一个配置文件的距离
我自己亲身经历过这件事。我在 Claude Code 里积累了大量的 CLAUDE.md 配置、技能文件、MCP server 设置。这些东西沉淀了好几个月。
然后有一天我试了一下 Cursor，发现它会自动读取 CLAUDE.md 的内容（它自己叫 .cursorrules，但内容格式完全一样）。MCP 的 JSON 配置换个路径就能用。技能文件本身就是纯 Markdown，复制过去即可。
反过来也一样。Windsurf 支持读 AGENTS.md，Codex 支持读 AGENTS.md，Gemini 有自己的 GEMINI.md 但格式大同小异。这些东西说白了都是"一个 Markdown 文件告诉 AI 该怎么干活"，换个名字就能在不同工具间跑。
更极端的是新工具。antigravity 这类后来者，首次启动就提供从 VS Code/Cursor 一键导入的功能。你的 extensions、keybindings、settings 直接搬过来。JetBrains 2026.1 版本甚至原生支持从 Windsurf 导入配置。你几乎不需要做任何"迁移"的动作，新产品已经把这件事做成了默认行为。
这就是我说的"成也灵活，败也灵活"。产品必须开放才能获得用户信任和真正的价值，但开放本身让用户随时可以带着全部资产离开。
所有人都在给 API 打工
这种状态下，做应用的人头上始终悬着一把剑。
不是你产品做得不好。Cursor 做到了 5 亿美元年收入，100 万日活，零营销支出。按任何传统 SaaS 标准，这是教科书级别的增长故事。但它同时以负毛利在运营。为什么？因为 Anthropic 直接把等价的海量算力打包进了 200 美元一个月的 Claude Max 计划，一夜之间结构性压缩了它的利润空间。
这比 Apple 的 App Store 剪刀更狠。Apple 至少看不到你 App 内部每一次用户交互的细节。而 API provider 能看到所有调用者发了什么 prompt、哪些功能有增长、用户在做什么。它拥有一个"全生态热力图"。什么应用火了它一清二楚，想做同样的功能几乎没有信息障碍。
OpenAI 升级 4o 图片能力的时候，一周内用户生成了 7 亿张图片，Midjourney 突然面临存在危机。这不是"可能发生"的平台风险，这是正在发生的事实。
向后做：训练自己的模型
面对这个困境，一个自然的反应是往后走，训练自己的模型，摆脱对上游的依赖。
Cursor 就是这么做的。它从 2024 年就开始训练专用的代码补全小模型，在"光标跳转预测"这个细分场景做到了极致。效果确实好，体验领先通用模型。
但问题是：你在一个 100 米赛道上建了 10 米的领先优势，而赛道本身每个季度重置一次。通用大模型的迭代太快了，DeepSeek 12 个月追平了 OpenAI 的推理水平。你在垂直场景的微调优势，可能在下一代通用模型发布时就被抹平了。
而且经济账也不好看。你花钱训练的模型还没回本，上游已经用补贴价提供了同等甚至更好的能力。LinkedIn 上有人说了一句很到位的话：模型优势没能救它，因为它训练在了错误的层。
但这不意味着向后做完全无效。关键区分在于：你训练的数据是不是真的不可复制。如果是用公开代码训练，竞争对手一样能做。但如果你拥有的是每周 200 万真实客服对话，或者覆盖了某个行业 40% 从业者的查询数据，那确实带不走。数据飞轮能不能转，取决于数据本身的稀缺性，不是"有个飞轮"这件事。
向前做：形成生态
另一个方向是往前走，形成一个跟产品强绑定的生态。
ChatGPT Plugins 是第一次大规模尝试。结果失败了，2024 年关停。核心原因很简单：用户不想在 AI 对话中"选择"和"安装"工具，他们想直接说需求，让 AI 自己判断调什么。AI 时代的 App Store 逻辑不成立。
但生态壁垒不是只有 marketplace 一种形态。
GitHub 走了"编排层"路线：不做最好的单一 Agent，做所有 Agent 的运行平台。Anthropic、OpenAI、Google 的 Agent 都在它上面跑。当你从"工具"变成了"基础设施"，替代你的成本就不再是"改个配置文件"的事了。
中国这边我看到一个有意思的方向：把专家和创作者跟平台绑定。比如有些产品在做"专家市场"的功能，如果这些专家跟平台有分成机制，用户在迁移时能带走自己的配置，但带不走这些专家提供的独占内容和持续服务。这类似 YouTube 创作者跟平台的关系：内容是你的，但你在这个平台上建立的受众关系和分发渠道带不走。
这条路的核心逻辑是：让平台上存在某种"只在这里才有"的关系或内容。不是锁数据，是锁关系。
我的判断
回到吃饭时的讨论。我觉得这个矛盾不会被解决，只会被接受。
试图通过锁定数据来建壁垒的公司，会在开源竞争中失去用户。开发者这个群体尤其反感 lock-in，谁锁我我就换谁。试图通过纯功能领先来建壁垒的公司，会在模型迭代中失去优势，每季度起跑线重置一次。
能活下来的，是接受了"用户随时可以走"这个前提，然后在这个前提下创造"让用户不想走"的价值。具体来说，我觉得有四条路有可能走得通：
第一，不可复制的数据。不是用户的配置文件（那个谁都能读），而是只有你的平台才能积累的、用户带不走的知识。第二，信任基础设施。合规认证、审计记录、责任承担。替换一个你信任的系统，需要重新走一遍决策流程，这个成本是真实的。第三，关系网络。创作者生态、专家市场、用户间的协作关系。关系不像文件，不能一键导出。第四，编排层地位。成为"运行所有 Agent 的平台"，而不是"一个 Agent"。水电煤不容易被替代。
这四条路有一个共同特征：它们不是靠阻止用户离开来维持的，而是靠创造"只有在这里才有"的东西来吸引用户留下。
AI 降低了功能的制造成本，但没有降低信任的托付成本。壁垒不是消失了，是从"能不能做出来"迁移到了"敢不敢把事情交给你"。
至于最终的格局是什么样，现在还看不清楚。我唯一确定的是：靠一个配置文件就能迁移走的东西，不叫壁垒。