GitHub Spark 將停用：8 月 31 日前怎麼匯出 App 與檢查 llm()

Q: 所有 GitHub Spark App 都必須改接新的 AI provider 嗎？

不必。GitHub 明確區分使用與不使用 llm() 的 App。先在匯出的程式碼搜尋 llm()；沒有這個呼叫的 App 不需要為了 GitHub Models 退休而替換 inference。若有 llm()，則必須重新安排 provider、API 金鑰、計費與測試，因為 GitHub Models 的 llm() 已不再提供服務。

2026-08-06

AI

GitHub

/

AI

/

開發工具

/

遷移指南

/

設定管理

如果你曾用 GitHub Spark 做過原型，現在最需要處理的不是重新找一個相似的低程式碼工具，而是先把既有 App 的程式碼與 AI 依賴保存下來。GitHub 在 2026 年 8 月 4 日公告：Spark 從當天起不再接受新使用者或建立新 App，既有使用者可以使用到 2026 年 8 月 31 日，在這之前匯出已建立的 App。

還有一個容易分開的時間點：Spark 使用的 GitHub Models 已在 7 月 30 日退休，llm() 呼叫已經不會繼續運作。因此，匯出 App 和 替換 AI 推論 是兩件不同的工作，應該分開盤點。

先分清楚 Spark 的三個狀態#

狀態	官方目前的說明	你要做的事
新使用者或新 App	2026 年 8 月 4 日起不再接受或建立	不要再把新專案放在 Spark
已建立、尚未匯出的 App	可使用 Spark 到 2026 年 8 月 31 日	優先匯出原始程式碼
已部署的 App	Spark 退休後仍會繼續運作	先確認是否含 `llm()`，再安排替換

這裡的「仍會繼續運作」是 GitHub 公告對已部署 App 的說明，不代表外部 API、資料庫或你自己的金鑰也會永久有效。匯出後仍要把部署環境與第三方依賴納入自己的維護範圍。

8 月 31 日前先匯出程式碼#

GitHub 提供的匯出路徑是在 Spark workbench 開啟 App 的 … 選單，選擇 Create repository。建立 repository 後，至少留下以下資料：

repository URL、建立時間與最後一次可正常執行的版本。
App 使用的環境變數名稱、外部服務 URL 與資料儲存位置；不要把金鑰直接複製進 repository。
一份可以重現主要流程的操作紀錄或測試輸入。
匯出前後的畫面或功能差異，方便之後判斷是 Spark 變動，還是替換服務造成的問題。

如果 App 很重要，不要只確認 repository 建立成功。先在本機或新的部署環境讀過啟動方式，再把可重現的 build、部署與 rollback 步驟寫進 issue。

用搜尋找出 `llm()` 依賴#

匯出後，在 repository 根目錄搜尋 Spark 的 AI 呼叫。最小盤點可以先從 llm() 開始：

1
rg -n -i \
2
  '\bllm\s*\(' \
3
  . \
4
  --glob '!node_modules/**' \
5
  --glob '!dist/**'

再把命中結果分成三類：

命中位置	代表的問題	下一步
App 程式碼	直接呼叫 `llm()`	改接新的推論 provider，並重寫錯誤與 timeout 處理
設定檔或環境變數	仍保存 Spark 或 GitHub Models 的 endpoint／金鑰	確認用途後輪替或移除，不要只改變數名稱
文件、測試與範例	新使用者仍會依照舊流程設定	在替換完成後一起更新，避免日後重新導向已退休入口

官方說明指出，不是每個 Spark App 都使用 AI inference；如果搜尋不到 llm()，就不需要為了 Spark 退休而另外尋找模型 provider。但仍應保留匯出的程式碼，因為 8 月 31 日後要繼續編輯，就不能再把 Spark workbench 當成原始碼來源。

依 App 類型安排交接#

只使用一般 UI 與資料流程#

先完成匯出、建置與部署驗證。這類 App 的主要風險是日後沒有 Spark 編輯入口，而不是 GitHub Models 的呼叫失效。把 repository、部署平台與資料來源交給實際維護者即可。

使用 `llm()` 的智慧功能#

先把 llm() 視為已失效的依賴。GitHub Models 退休後，官方要求改用自己的 inference provider；你需要重新決定 provider、API 金鑰、計費責任、模型輸入輸出格式，以及失敗時要顯示什麼。

這不等於把 llm() 逐字替換成另一個 SDK 就完成。至少要用同一組測試輸入比較回應結構、延遲、錯誤碼與敏感資料處理，再把新金鑰放到部署平台的 secret 管理中。

還需要持續修改的原型#

把匯出的 repository 當成新專案的起點，先建立一個能在本機執行的版本，再決定要使用 VS Code、Copilot CLI、Copilot app 或其他開發流程。GitHub 的 Models 退休盤點清單已整理 endpoint、CI 與環境變數的搜尋方式，可以拿來補查 AI 依賴。

退休前的最小檢查清單#

在 2026 年 8 月 31 日前對每個既有 App 執行 Create repository。
確認 repository 真的包含目前版本，而不是只保存部署 URL 或畫面截圖。
搜尋 llm()、GitHub Models endpoint、舊環境變數與文件範例。
把「匯出完成」與「AI provider 替換完成」分成兩個 issue，不要用一個勾選框掩蓋未完成的推論遷移。
對不含 llm() 的 App 驗證部署仍可運作；對含 llm() 的 App 先測試新的 provider，再安排正式切換。
將 Spark workbench 不再可編輯視為既定條件，保留 repository、部署設定與 rollback 說明。

這次變更的交接重點很明確：先保存程式碼，再判斷 App 是否真的依賴 llm()。沒有 AI 呼叫的 App 可以把工作重心放在維護與部署；有 AI 呼叫的 App 則要另外完成 provider、金鑰與測試流程的替換。

常見問題#

Q: GitHub Spark 停用後，已部署的 App 會立刻下線嗎？#

A: GitHub 的 2026 年 8 月 4 日公告表示，已部署的 App 在 GitHub Spark 退休後仍會繼續運作。不過這只說明 Spark 本身的部署狀態；外部 API、資料庫、網域與你自己的金鑰仍要依各服務的生命週期與帳務設定檢查。若 App 需要持續修改，仍應在 8 月 31 日前建立 repository 保存程式碼。

Q: 所有 GitHub Spark App 都必須改接新的 AI provider 嗎？#

A: 不必。GitHub 明確區分使用與不使用 llm() 的 App。先在匯出的程式碼搜尋 llm()；沒有這個呼叫的 App 不需要為了 GitHub Models 退休而替換 inference。若有 llm()，則必須重新安排 provider、API 金鑰、計費與測試，因為 GitHub Models 的 llm() 已不再提供服務。