8 月 28 日，OpenAI 发公告：已正式通知 SpaceX，将终止向 Cursor 提供 OpenAI 模型的合同，现有模型的接入拟于 2026 年 11 月 12 日关闭，未来的新模型（包括传闻中的 Astra 系列）也不会再给 Cursor。
背景很多人已经看到了：6 月 SpaceX 宣布以 600 亿美元收购 Cursor 母公司 Anysphere，8 月 14 日完成交割，两周后 OpenAI 就启动了合同里的"控制权变更"条款。Cursor CEO 的回应是 OpenAI 模型大约只占 Cursor 5% 的流量，产品近期也在往 Grok 迁移。
大佬打架，落到开发者头上是一个具体问题：如果你的 Cursor 工作流里有任何环节绑在 GPT 系列上，你有 76 天把它迁走。这篇文章不讲八卦，给你一份可以直接照着做的迁移清单。
一、先盘点：你到底在哪些地方用了 OpenAI 模型
很多人以为自己"不怎么用 GPT"，一查才发现依赖藏在各个角落。建议花半小时过一遍这四类位置：
- 聊天与 Composer 的默认模型：Settings → Models 里看你平时置顶的是谁。
- 自定义 API Key：Settings 里如果你填过 OpenAI API Key 或自定义 Base URL，断供后这条路会先死。
- 团队/项目的模型白名单：团队版管理员可能限制了可用模型列表，里面有没有 OpenAI 的条目。
- 外部脚本：用 OpenAI SDK 直连的本地脚本、CI 里的 AI 步骤（比如自动生成 commit message、code review bot），这些虽然不是 Cursor 的功能，但往往和 Cursor 的使用场景绑在一起，趁这次一起盘。
把每一项记成一行：用途、当前模型、日均调用量大概多少。这张表是后面所有决策的依据。
二、选替代模型：按场景对号入座
Cursor 本身是模型中立的入口，可选的后端不少。按常见场景给个对照（价格和能力以各家官网为准，迁移前自己再核一遍）：
| 场景 | 原选择 | 可考虑的替代 |
|---|---|---|
| 日常补全与聊天 | GPT 系列 | Grok Code、Claude 系列、GLM 系列 |
| 长上下文重构 | GPT 大上下文档位 | Claude、Kimi、GLM 的长上下文版本 |
| 便宜量大的批量任务 | GPT mini 档 | DeepSeek、GLM Flash 档、Qwen 系列 |
| Agent 多步任务 | GPT 推理档 | Claude、Grok 的重推理档 |
两个原则：
- 不要追求"一对一平替"。没有哪家模型在所有维度上完全等价，按场景分开选比找一个"全能替代"现实得多。
- 主备双后端。这次断供最大的教训就是单一供应商依赖。主力用一个，备用的 Key 和配置现在就配好，哪怕平时不用。
三、改 Cursor 配置：三步走
1. 切换默认模型
Settings → Models，把新增的替代模型打开，把聊天和 Composer 的默认模型切过去。建议只切默认、先不删旧选项，过渡期两个并存，方便对比手感。
2. 清理自定义 API 配置
如果你之前填过 OpenAI API Key 或 OpenAI 兼容的 Base URL，逐一检查：Key 是否还有别的服务在用（别误删）、Base URL 指向的服务是否受影响。要换兼容端点的，现在就把新端点填进去做一次联通性测试——随便发一句"hello"确认返回正常，别等大限当天才发现配错了。
3. 验证 Tab 补全和后台任务
聊天能通不代表全部能通。分别验证：Tab 自动补全是否生效、Composer 的多文件编辑是否正常、如果你用了后台 Agent 类功能也跑一个最小任务。每一项出问题都单独记录，去对应模型的文档里查是否有 Cursor 侧的已知限制。
四、规则与记忆文件：最常被忘掉的一步
模型换了，但你写给模型看的"项目说明书"不用换——前提是它是模型中立的。检查这两个位置：
- 项目根目录的
.cursor/rules/目录（以及老项目里的.cursorrules文件） - 仓库里的
AGENTS.md、CLAUDE.md等约定文件
重点排查两类内容：
# 反例：写了模型名的规则，迁移时会误导新模型
"When using GPT function calling, always ..." # 改成中立的 "使用工具调用时"
# 正例：只描述项目约定，不绑定任何模型
"所有金额以分为单位存储"
"数据库迁移必须先写 down 脚本"
把规则文件里所有提到具体模型名、具体 API 行为的句子改成模型中立的描述。这一步做完，你的规则资产以后在任何后端之间都能平移。
五、团队迁移：按周推进的时间表
个人用户一个下午能搞定，团队建议留出灰度期。离 11 月 12 日还有约 10 周，参考节奏：
- 第 1 周：管理员完成依赖盘点，确定替代模型，开通好 API 额度。
- 第 2-3 周：选一个非核心项目试点，2-3 个人先用新后端跑完整工作流，记录问题。
- 第 4-6 周：全员切换默认模型，旧配置保留只读；把试点期的问题清单沉淀成内部文档。
- 第 7-9 周：关闭旧的 OpenAI 相关配置，确认没有残留调用（看账单和日志）。
- 第 10 周：缓冲期，处理长尾问题。
核心思想就一条：不要在大限前一周才动手。模型切换的手感差异需要真实工作来暴露，灰度期就是用来付这个学费的。
常见问题
Q：11 月 12 日之后 Cursor 还能用吗？ 能。断供的是 OpenAI 模型的直连，Cursor 本身和它对其他模型（Claude、Grok、GLM 等）的支持不受影响。Cursor CEO 也说 OpenAI 模型只占约 5% 流量，产品层面早有准备。
Q：我的历史对话和代码库索引会丢吗？ 不会。对话历史、代码库索引存在 Cursor 侧，与模型供应商无关。受影响的只是"调用 OpenAI 模型"这一个动作。
Q：需要现在就退订换工具吗？ 多数人不必要。如果你本来就主要用 Claude 或 Grok，这次事件对你几乎无感；如果你重度依赖 GPT 系列，先按本文清单把后端迁掉，Cursor 作为编辑器可以继续用。真正需要评估换工具的情况只有一个：你判断未来模型供给的稳定性比编辑器体验更重要——那就是另一个话题了。
小结
这次断供的本质是一次被动的"供应商风险演习"。OpenAI 给了 76 天通知期，比大多数合同终止体面得多，用好这个窗口：盘点依赖 → 按场景选替代 → 改配置 → 清洗规则文件 → 灰度切流。做完之后你会发现，真正有价值的资产——你的规则文件、你的项目文档、你的工作流习惯——本来就不该绑死在任何一家模型商身上。