GitHub Spark 8 月 31 日停用前怎么导出应用：检查 `llm()` 与后续处理

如果你用 GitHub Spark 做过原型，现在要先处理的不是寻找一个“Spark 替代品”，而是把现有 App 的代码和 AI 依赖分开保存。GitHub 已说明：2026 年 8 月 31 日前，已有用户仍可进入 Spark 工作台导出应用代码；而 Spark 使用的 GitHub Models 已在 7 月 30 日退休，llm() 调用已经不能继续依赖 GitHub 提供的推理服务。本文按“先导出、再盘点、后迁移”的顺序整理一份可执行清单，结论核验于 2026 年 8 月 22 日。AI 编程助手的入口、权限与审查成本对比可作为导出后的后续工具背景资料。

先分清三个日期

这次变化不是一个日期对应一个动作。GitHub 社区公告与官方 Changelog 需要合并阅读，才能避免把“不能创建新 App”“llm() 已失效”和“代码导出窗口结束”混成同一件事。

官方还说明，已经部署的 App 在 Spark 退役后会继续运行；但这句话不能推导出“所有功能永久等价”。尤其是依赖 llm() 的 AI 功能，早在 7 月 30 日就需要单独处理。

先把代码导出

1. 登录仍有权限访问 Spark 的 GitHub 账号，打开对应 App 的 Spark 工作台。
2. 打开右上角的“…”菜单，选择“创建存储库”（英文界面为 Create repository）。
3. 完成创建后打开新仓库，检查默认分支、最近提交、源码目录、资源文件和项目说明是否都在。
4. 记录仓库 URL、App 原始访问地址、最后一次正常运行的时间，以及后续准备使用的部署环境。

GitHub 官方文档说明，创建仓库时，创建前对 Spark 所做的更改会写入仓库，并且 Spark 与仓库主分支之间存在双向同步。这个动作解决的是“保存代码并继续编辑”的问题，不等于已经完成数据、鉴权、托管运行时和第三方服务的迁移。

检查 llm 依赖

GitHub 公告给出的最小判断方法，是在 Spark App 中搜索代码里的 llm()。导出到仓库后，建议在仓库根目录再做一次本地盘点。这样做不是为了证明某个 provider 一定兼容，而是先把“有没有 AI 运行时依赖”这件事从猜测变成可复查记录。

rg -n -S --hidden "\bllm\s*\(" . --glob "!node_modules/**" --glob "!dist/**" --glob "!build/**"

如果命令没有结果，可以再扩大一次关键词范围，检查 Spark SDK、旧 endpoint、环境变量名称和文档示例：

rg -n -S --hidden "llm|spark\.llm|spark\.llmPrompt|GitHub Models|inference|MODEL|API_KEY" . --glob "!node_modules/**" --glob "!dist/**" --glob "!build/**"

第二条命令是编辑检查建议，不是 GitHub 公告列出的额外受影响清单。命中后按位置分类：

• 运行时代码：直接调用 llm()、spark.llm 或相关封装，先标记为需要 provider 替换和功能回归测试。
• 配置与环境变量：检查 endpoint、模型名和密钥变量的用途；不要把密钥值提交进仓库，已经暴露的密钥应按提供商规则轮替。
• 文档、测试和示例：它们可能不会影响线上运行，但会让下一位维护者继续照着已退休的流程配置，替换完成后一起更新。

需要注意，Spark 的 AI 能力也可以从“Prompts”入口管理。只看到一个提示卡片，不能说明代码没有推理依赖；同样，只在 README 中看到“AI”字样，也不能直接证明线上请求仍然走 llm()。最终要以运行时代码、配置和实际测试结果共同判断。

按 App 状态分流

没有 llm 依赖的 App

如果确认运行时代码没有 llm()，它不受 GitHub Models 退休这一项变化的影响。仍然要在 8 月 31 日前导出代码，并检查数据存储、GitHub 登录、权限设置、部署地址和外部库；“没有 llm()”只回答了 AI 推理依赖，不代表整个 App 已完成迁移。

已部署但含 llm 的 App

这类 App 最容易出现“首页能打开、核心功能失效”。先保留当前线上 URL 和故障表现，再在导出的代码中定位调用链：输入从哪里来、提示词在哪里组装、返回值如何解析、错误如何显示。随后接入新的推理 provider，在隔离环境中验证成功、超时、空结果和上游错误，最后才切换线上流量。

尚未部署或只存在于工作台的 App

优先级是导出代码和保存可复现的运行说明。不要因为“还没有公开 URL”就把它视为低风险：工作台关闭后，最难恢复的可能是提示词、配置、数据结构和迭代历史，而不只是几个前端文件。

替换推理的最小清单

GitHub 官方公告要求含 llm() 的 App 改用自己的推理提供商，并由用户提供 API 密钥、管理账单。它没有承诺一个适用于所有 Spark App 的一键迁移器，因此可以先按下面顺序拆任务：

1. 抽出 provider 接口：让页面或业务逻辑调用自己的 generateText() / summarize() 适配层，不要把某家 SDK 调用散落在多个组件里。
2. 迁移配置：把 provider 基地址、模型名和密钥放到部署平台的环境变量或密钥存储中；代码仓库只保留变量名和示例文件。
3. 对齐输入输出：核对系统提示、用户输入、上下文长度、结构化输出、流式响应和错误格式。旧 App 能显示文字，不代表新接口返回的数据结构完全一样。
4. 补足失败处理：至少测试超时、限流、鉴权失败、空响应、模型拒答和上游不可用时的用户提示。
5. 重新检查数据边界：Spark 的托管键值存储、GitHub 登录和 Azure Container Apps 运行时是平台能力；导出代码后，数据、用户身份、权限和部署位置要分别确认，不能默认自动带走。
6. 保留回滚点：在替换前给仓库打 tag 或建立分支，记录旧线上 URL、环境变量名称、测试输入和恢复步骤。不要在唯一生产分支上直接覆盖。

GitHub Models 退休公告提到 Microsoft Foundry 和 GitHub Copilot 是新的模型访问方向，但这不是针对每个 Spark App 的完整迁移方案。具体 provider 应根据 App 的输出格式、部署位置、预算、地区与数据要求选择；本文不把任一家服务写成无条件推荐。

导出后怎么验收

• 仓库中有最新源码、资源、配置说明和能说明启动方式的文档。
• 已保存 App URL、仓库 URL、最后一次正常版本和当前故障现场。
• 已记录数据存储位置、数据导出方式、GitHub 登录与访问权限的后续责任人。
• 已搜索 llm() 及相关配置，并将运行时代码与文档/测试命中分开。
• 含 AI 功能的 App 已在隔离环境测试成功、失败、超时和空结果；无 AI 功能的 App 也完成了主要用户路径回归。
• 新的 API 密钥没有写入 Git 历史；旧密钥如曾暴露，已按 provider 规则轮替。
• 已经知道如何回到替换前版本，或者如何关闭入口而不继续向失效服务发送请求。

截止前的执行顺序

如果你管理多个 Spark App，可以按这个顺序处理：第一，列出所有 App 及其“已部署/未部署、含 AI/不含 AI、是否有外部用户”状态；第二，在 8 月 31 日前逐个执行“…”→“创建存储库”，并打开仓库确认内容；第三，对每个仓库搜索 llm() 和相关配置；第四，把 provider 替换、数据迁移、鉴权复核和部署切换拆成独立任务；第五，保留测试结果和回滚点。

最终要记住两条边界：导出代码是资产保全，不是完整迁移；已部署 App 继续运行是 GitHub 当前公告的状态说明，不是对数据、鉴权、AI 推理和未来运行成本的长期保证。先把代码拿到自己能控制的仓库，再决定哪些能力值得继续维护，风险最低。

官方资料

• GitHub Spark 退役公告
• 关于 GitHub Spark
• 使用 GitHub Spark 生成和部署 AI 驱动的应用
• GitHub Models 退休公告