GitHub Spark 停服与代码所有权：AI 应用构建中的 Vendor Lock-in 警示
在 AI 应用开发领域，"快速构建"固然重要，但"拥有项目"（Code Ownership）才是长期发展的基石。当构建平台、提供商或运行时环境发生变更时，开发者是否具备将产品完整带走的能力？这是评估任何 AI App Builder 最核心的问题。
2026 年 8 月，GitHub Spark 的停服事件为这一理论问题提供了残酷的现实案例。GitHub 宣布停止接受新的 Spark 用户和新应用创建，现有用户需在 8 月 31 日前导出应用以保留编辑权限。更关键的是，支撑 Spark 的底层模型服务 GitHub Models 已于 7 月 30 日停服，这意味着依赖 llm() 函数的应用必须寻找新的推理提供商、凭证及计费方案。
为什么代码所有权不等于可移植性
GitHub Spark 的退出揭示了 AI 应用构建中的一个核心误区：代码所有权（Code Ownership）并不等同于可移植性（Portability）。
一个平台可能允许你下载源代码文件，但留下的应用仍深度依赖难以在其他地方复现的服务。真正的可移植性需要跨越七个层级：
- 可见性 (Visibility)：能否查看生成的文件？
- 导出 (Export)：能否下载或克隆 Git 仓库？
- 本地执行 (Local Execution)：项目能否在构建器之外安装依赖并运行？
- 数据可移植性 (Data Portability)：能否导出 Schema 和生产数据？
- 服务可移植性 (Service Portability)：能否迁移认证、存储、支付及 AI 提供商？
- 部署可移植性 (Deployment Portability)：能否部署到你控制的基础设施上？
- 维护可移植性 (Maintenance Portability)：未参与开发的开发者能否理解并修改它？
许多工具仅满足前两层便宣称拥有"所有权"，但这对于严肃团队而言远远不够。
AI 应用构建的退出测试清单
在将产品提交给任何 AI 应用构建器之前，建议执行以下"退出测试"：
- 能否导出仓库？ 结果是否是一个包含源码、配置、迁移脚本、测试用例及构建指令的真实 Git 仓库？
- 能否本地运行？ 新开发者是否能通过安装依赖、配置环境变量启动应用并运行关键流程？
- 后端是否绑定供应商？ 识别哪些数据库、认证服务、存储、队列、Cron 任务或专有 API 仍受限于特定平台。
- 能否迁移认证与数据库？ 用户、角色、会话、记录及密钥是否有文档化的导出与导入路径？
- 能否切换推理提供商？ 是否清楚所有模型调用、SDK、响应假设、工具权限及计费关系？
- 他人能否维护？ 让未参与首版开发的同事尝试运行、调试和部署。
若对上述任一问题的回答为"否"，即便你拥有代码，仍可能被锁定在平台的运行时或工作流中。
GitHub Spark 迁移指南：工程化思维
对于现有的 Spark 应用，迁移不应被视为简单的文件下载，而是一项工程任务。
1. 在截止日期前导出应用
在 8 月 31 日前，通过 Spark 工作台的选项菜单选择 Create repository 保存应用代码。确认你能独立于 Spark 编辑器克隆该仓库。
2. 全面记录依赖与环境
不要止步于获取仓库 URL。请在干净的机器或新目录中克隆仓库，并详细记录：
- 默认分支与包管理器锁文件（Lockfile）
- 构建与启动命令
- 环境变量配置
- 生成的数据及 Schema 文件
- 认证配置与 AI 调用假设
- 部署配置
3. 处理退化的 llm() 依赖
由于 GitHub Models 已停服，所有使用 llm() 的应用必须立即寻找替代的推理服务。这需要重新配置 API 密钥、更新 SDK 并处理潜在的响应格式差异。
结语
GitHub Spark 的停服并非证据表明所有 Spark 应用都无法使用，而是证明了应用所有权具有多层性。从源代码到运行时，从数据到运维知识，每一层都需要主动规划与迁移。在 AI 原生开发时代，掌握代码主权意味着掌握未来的主动权。
