从 Cursor 到生产：部署无供应商锁定的 AI 功能

你构建了真正有用的东西。也许你用了 Cursor，也许用了 Copilot，也许你只是在 VS Code 中借助 AI 助手编写代码。无论你怎么走到这一步，你的应用能用了，它有用户喜欢的 AI 功能。只有一个问题——每次 AI 调用都通过 OpenAI 的 API，而你对此毫无控制。

这就是 vibe coder 的陷阱。原型阶段的体验如此顺畅，以至于你在依赖关系真正产生影响之前都不会注意到它。然后你的 API 密钥在流量高峰时被限流，或者 OpenAI 弃用了你微调过的模型，或者因为他们调整定价导致你的月度账单翻倍。突然间，你产品的基础是一个你完全无法控制的服务。

让我们来解决这个问题。

Vibe 编码的应用如何被锁定

锁定是逐渐发生的，而且发生在多个层面。理解这些层次是摆脱它们的第一步。

当你使用 Cursor 或类似的 AI 编码工具构建应用时，生成的代码自然使用 OpenAI SDK。它是默认建议、文档最多的路径，也是 Stack Overflow 上答案最多的方案。几次会话后，你的代码库就将 openai 作为核心依赖，你的提示词针对 GPT-4 的特定行为进行了调优，你的错误处理围绕 OpenAI 的响应格式构建。

这都不是恶意的。它只是阻力最小的路径。但随着每次提交，解除这种依赖的代价越来越高。

三种类型的供应商锁定

1. API 格式锁定

你的代码围绕特定的 API 契约构建——请求格式、响应模式、错误代码、流式协议。切换提供商意味着重写每个集成点、更新错误处理，以及测试你从未想过的边界情况。

这是最可见的锁定形式，幸运的是，也是最容易解决的。

2. 模型行为锁定

这是最隐蔽的一种。你的提示词、few-shot 示例、输出解析逻辑——所有这些都针对特定模型的响应方式进行了调优。GPT-4 在输出格式、处理歧义和遵循指令方面有特定倾向。切换到 Claude 或 Gemini，你精心制作的提示词会产生不同的结果。

每写一个不考虑可移植性的提示词，这道沟就会加深一层。

3. 定价锁定

你已经围绕某个每次查询成本假设设计了产品架构。你的免费层、定价页面、单元经济学都假设了 OpenAI 当前的定价。当他们改变价格时——他们一定会改，无论涨跌——你的商业模式就任由他们摆布。

这是杀死企业的锁定。不是因为技术失败，而是因为经济基础在你脚下发生了变化。

拥有自己的模型如何消除所有三种锁定

当你运行自己的微调模型时，三种锁定都会消失。

API 格式： 你选择推理服务器。Ollama、vLLM、llama.cpp——都支持 OpenAI 兼容的 API 格式。你现有的代码只需最小改动即可工作。你控制 API 契约，除非你自己改动，否则它永远不会变。

模型行为： 微调模型是在你的数据上、为你的特定任务训练的。它的行为是确定性的，在你的控制之下。不会有提供商更新模型带来的意外变化。不会因为新版本"在基准测试上更好"但对你的用例更差而出现退化。

定价： 你的成本就是你的基础设施成本。GPU 服务器的费用无论你每天运行 1,000 还是 100,000 次推理都一样。你的单元经济学是可预测的，完全在你的控制之中。

从 OpenAI 依赖到自托管的迁移路径

以下是将现有应用从 OpenAI 迁移到自托管模型的实际路径。

第一步：审计你的 AI 集成点

列出代码中调用 OpenAI API 的每个地方。记录每次调用的功能——分类、生成、提取、嵌入。大多数应用的独立 AI 任务比你想象的要少，通常只有三到五个核心操作。

第二步：收集训练数据

应用中每次成功的 AI 交互都是训练数据。导出你的提示词-完成对，过滤质量，并格式化用于微调。如果你一直在记录 API 调用（你应该这样做的），你已经有了一个数据集。

第三步：微调基础模型

选择一个有能力的开源基础模型——Llama 3.3 8B 或 Qwen 2.5 7B 都是优秀的起点——在你收集的数据上进行微调。该模型不需要是通才。它只需要在你的应用所需的特定任务上表现出色。

第四步：使用 OpenAI SDK 兼容性部署

这是使迁移无痛的关键洞察。Ollama 和类似的推理服务器暴露了 OpenAI 兼容的 API 端点。你只需更改 OpenAI SDK 配置中的基础 URL，将其指向你的本地服务器。你现有的代码——提示词、响应解析、错误处理——无需修改即可工作。

// 之前：锁定到 OpenAI
const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

// 之后：你自己的模型，相同的代码
const openai = new OpenAI({
  baseURL: "http://localhost:11434/v1",
  apiKey: "not-needed",
});

这就是 SDK 层面的全部迁移。剩下的是确保你的微调模型处理特定任务的能力与云模型相当或更好。

第五步：验证和切换

对自托管模型运行测试套件。比较输出。对于大多数领域特定任务，一个调优良好的 8B 模型因为专业化而非通用性，能匹配或超过 GPT-4 的性能。

Ollama 的 OpenAI SDK 兼容性

OpenAI SDK 兼容层值得特别强调，因为它使这次迁移对独立开发者来说切实可行。你不需要重写应用。你不需要新的 SDK。你只需更改一个 URL 和一个可选的 API 密钥。

Ollama 支持聊天补全、嵌入和流式——这三个端点覆盖了 99% 的独立应用 AI 使用。响应格式匹配 OpenAI 规范，所以你现有的解析代码无需更改即可工作。

这种兼容性不是偶然的。开源推理生态系统有意采用 OpenAI API 格式作为标准，专门为了使迁移无摩擦。

使用 Ertas 实现

Ertas 简化了从云依赖到模型所有权的路径。使用 Ertas Studio 在你应用的特定任务上微调模型，导出优化的 GGUF 文件，并使用 Ollama 或任何兼容的推理服务器部署。