GitHub Spark 弃用后应用如何迁移：运行时边界、替代路径与仓库资产盘点

如果你手里还有 GitHub Spark 应用，迁移重点不是立刻重写界面，而是先把代码和 AI 依赖分开盘点。GitHub 官方说明：2026 年 8 月 4 日起不再接受新用户或创建新应用，既有用户可使用到 8 月 31 日导出；已经部署的应用会继续运行，但使用 llm() 的应用需要另接推理服务。

先在 Spark workbench 里用“...”→“Create repository”保存代码，再搜索 llm()。没有这个调用的应用优先做仓库接管；有这个调用的应用还要完成模型服务替换和密钥治理。

先把 Spark 应用分成三种迁移状态

不要看到“弃用”就马上关停线上应用。官方 Changelog 把影响拆成了三个边界：新用户和新应用已经停止；既有应用仍有导出窗口；已经部署的应用在 Spark 退役后仍会继续工作。真正需要优先处理的是未来还要继续编辑的应用，以及包含 llm() 的应用。

用 Create repository 保存可继续维护的代码

登录 GitHub 后打开目标 Spark 应用的 workbench。官方 Docs 给出的入口不是普通的下载按钮，而是应用工作台右上方的“...”菜单，再选择 Create repository。仓库创建完成后，代码才有了可独立维护、审查和部署的落点。

1. 打开需要保留的 Spark 应用，确认预览和最近一次修改都已保存。
2. 在 workbench 中打开“...”菜单，点击“Create repository”。
3. 按页面提示选择仓库归属和可见性，等待首次同步完成。
4. 进入新仓库，检查入口文件、依赖清单、环境变量说明和最近提交。

这里别只看仓库是否出现。至少打开一次提交记录，确认不是空仓库；再把仓库克隆到本地，搜索配置文件和资源目录。Spark 的托管数据存储、认证设置和部署环境不一定等价于普通仓库文件，后续运行前要单独登记。

搜索 llm()，把 AI 依赖单独列账

GitHub 官方文档说明，GitHub Models 曾为 Spark 的 llm() 提供推理能力，相关服务退休后，调用会失效。迁移时在导出的仓库中搜索函数名，不要只搜索“AI”或“模型”这类自然语言。

git clone 
cd 
rg -n "llm\(\)|model|inference" .

如果没有匹配到 llm()，可以把 AI 替换列为非阻塞事项；如果匹配到，就沿着调用点向上追踪输入、提示词、输出格式和错误处理，再选择兼容的推理提供方。API key 只放在部署平台的密钥管理中，不要写回仓库。

迁移后的验收不要只测首页

仓库接管完成后，至少做一次四项验收：第一，冷启动能安装依赖并启动；第二，核心页面不依赖 Spark 专属运行时；第三，原有数据读写路径有替代方案；第四，包含 llm() 的功能在模型超时、限流和无密钥时能给出可理解的失败状态。

已部署应用“还能访问”只能说明旧运行环境暂时存在，不代表代码已经可维护。建议保留一次导出前后的功能清单，给每个页面标记“已迁移、待替换、无需处理”，再安排灰度发布和回退入口。

常见问题

GitHub Spark 已部署的应用会马上下线吗？

官方 Changelog 表示，已经部署的应用在 GitHub Spark 退役后会继续工作，但这不等于后续还能继续编辑或获得原有 AI 服务。

必须在 8 月 31 日前创建仓库吗？

如果还要保留代码并继续维护，应在官方给出的 2026 年 8 月 31 日窗口前完成导出。不要把“网页还能打开”当成资产备份。

没有 llm() 的应用要改模型配置吗？

不需要为不存在的调用额外接模型。先完成仓库接管、启动验证和数据依赖盘点即可。

导出仓库后能直接部署到任意平台吗？

不能直接假设可以。认证、托管数据、环境变量和部署运行时都要逐项替换并回归测试。

最后保留一份迁移清单

每个 Spark 应用都应留下仓库地址、导出时间、部署地址、数据依赖、llm() 搜索结果和下一次验证负责人。这样即使旧应用暂时还能运行，团队也知道哪些资产已经脱离 Spark，哪些功能仍等待替换。