AI 模型會被停用，工作流不能跟著失憶
距離一個影像模型停用只剩七天。
團隊知道 prompt 放在哪裡，也找得到幾張曾經產出的圖片。可是當工程師開始準備切換，幾個很普通的問題卻沒有人能立刻回答：production 用的是哪個 model ID？走 OAuth 還是 API key？目前的訂閱配額是否涵蓋這條路徑？哪些輸出曾經由人確認可接受？Fallback 實際跑過嗎？
Prompt 還在，工作流卻不完整。它的執行條件散落在環境變數、供應商 dashboard、聊天紀錄，以及某位成員的記憶裡。
這種情況不只發生在規模很大的系統。只要小團隊把模型 API、coding agent、AI 影像或生成式 UI 接進固定流程，停用與改版就已經是日常維運的一部分。模型可以換，團隊不能每次都靠考古重建工作流。
把 changelog 當成 production 相依資訊
AI 產品的 changelog 常把兩種消息放在一起：一邊加入新的 agent、日誌或工具能力，一邊公告舊模型的停用日期。Gemini API 最近就是如此，在持續增加 Interactions API 日誌、Computer Use 與 Managed Agents 等能力的同時，也公告多個影像模型將於 2026 年 8 月 17 日關閉。
如果某個模型已經參與固定產出，停用日期就不是「有空再看」的產品新聞。它和套件安全公告、憑證到期日一樣，會直接影響服務能不能繼續跑。
至少應該有人負責把這些變動對回團隊自己的相依清單：供應商、精確 model ID、endpoint 或 client、已知停用日期，以及哪條產品流程正在使用它。只寫「Gemini 圖片模型」或「目前最穩的模型」不夠，因為幾個月後，這些描述可能已經指向不同東西。
相依清單也不該保存 token。它要記的是認證模式、secret 由哪個系統管理、誰能輪替，以及切換時要去哪裡驗證。文件應該讓接手者找到邊界，而不是把敏感資料複製到更多地方。
Prompt 只保存意圖，沒有保存執行條件
很多遷移計畫從「把同一段 prompt 丟給新模型」開始。這可以當第一個 smoke test，卻不能證明原工作流已經搬完。
OAuth、API key、訂閱配額與模型可用性是不同層次的條件。CLI 能登入，不表示原本使用 API key 的背景工作仍能執行；帳號看得到某個模型，也不表示目前配額足以承接 production 流量。工具權限、狀態位置、response shape、安全設定、延遲與輸出品質，同樣不會被 prompt 自動帶過去。
Gemini CLI 轉向 Antigravity CLI 的官方 GitHub 討論串之所以出現大量往返，正是因為一次看似單純的工具轉換，會同時碰到登入方式、模型可用性、訂閱配額與既有操作習慣。這些摩擦不能全部歸成「認證問題」，也不能用改一個 binary 名稱來處理。
與其期待新工具猜出舊環境，不如把執行條件寫成一份小型 migration contract。內容不用厚重，但要能回答：這條流程依賴什麼、拿什麼比較、差異由誰判斷，以及切換失敗時怎麼回去。
用一小組真實工作比較，而不是看模型總分
遷移不需要先建立龐大的 benchmark。小團隊更適合保留一組很小的 golden work set，直接代表產品每天在做的事。
例如前端流程可以留下一個需要修改互動狀態的 UI 任務，連同 viewport、keyboard 行為與可見輸出的驗收方式。影像流程則保留幾個實際使用過的構圖、含文字圖片、不同長寬比，以及至少一個預期失敗的輸入。比較時看的是新路徑能否完成這些工作，而不是模型在通用排行榜上的位置。
這組樣本還應把穩定輸入與確定性收尾搬出 model-specific session。研究 Generative UI 時，可以把當次使用的生成式 UI 資源、篩選條件與選中項目列成可檢查的輸入，避免替換模型後又靠它重新猜一次研究範圍。AI 圖片完成後，則可把Resize Image for Instagram這類固定尺寸處理列為明確步驟，保留 1:1、4:5 或 9:16 等輸出規格，不必把平台尺寸繼續埋在生成 prompt 裡。
這兩個步驟都不負責解決模型遷移。它們的作用是縮小模型需要臨場推理的範圍，讓同一組輸入與收尾規則可以跟著工作流移動。
Fallback 必須留下身分
切換新模型時，先讓一小部分工作走有界的 canary，比一次把所有流量搬過去容易判斷。Canary 要跑哪組樣本、多久、由誰查看差異，以及什麼情況算未通過，都應在執行前寫清楚。
Fallback 也要接受同樣的要求。它不是一個可以隱形的保險開關。如果主路徑失敗後，系統默默換了另一個 provider 或 model，最後仍只回報「成功」，團隊會失去最重要的遷移資訊：哪條路徑實際完成了工作。
一份可用的紀錄至少要包含 fallback 的觸發條件、實際 executor、跑過的樣本與結果。認證失敗、配額用盡、連線逾時、內容政策阻擋，也不該全部觸發同一種替代行為。這些失敗的處理責任不同，混在一起只會讓事故更難重現。
Rollback 則要保持到新路徑通過約定檢查為止。這不代表所有流程都得長期雙跑，而是切換期間不能先拆掉唯一可回去的路，再用使用者流量替新設定做測試。
每次切換留一張遷移收據
Migration contract 說明團隊打算怎麼搬；遷移收據記錄這次實際搬了什麼。它可以只是 repo 裡的一個短檔案：
changed_at: 2026-08-10
owner: team-or-person
old_dependency:
provider:
model_id:
client:
new_dependency:
provider:
model_id:
client:
reason: scheduled-deprecation
auth_and_quota_checked:
- authentication mode
- quota boundary
golden_work_set:
- ui-task-01
- image-task-02
material_differences:
- pending
fallback:
trigger:
executor:
result:
rollback_status: available
unverified:
- production peak traffic
next_lifecycle_check: 2026-09-10這張收據不替新模型背書，也不宣稱兩條路徑完全等價。它只是把已完成、已觀察與尚未確認的部分分開。下一位接手的人不用先翻完所有 session，便能知道該從哪個狀態繼續。
它和單次任務的驗證紀錄也有不同用途。任務紀錄回答「這次修改是否完成」；遷移收據回答「更換模型、API、認證路徑或 agent client 之後，同一條產品流程是否仍能被接受」。兩者會共用一些測試，但處理的是不同風險。
可以匯出，不等於可以重建
Managed workspace、可恢復狀態與 project export 都能降低搬動成本。Google 對 Managed Agents 的介紹提到隔離的 Linux 環境、可恢復狀態與 custom skills，也支援將 AI Studio 專案匯出至 Antigravity。這些能力對交接有幫助，卻不能直接證明跨供應商可攜。
匯出檔存在，只能表示某些資料離開了原介面。團隊仍要實際驗證必要檔案、skills、狀態與決策能否在目標環境重建，並完成同一組 golden work。若匯出後還得靠原帳號、未記錄的權限或某段 session 才能運作，那份檔案比較像備份線索，還不是可搬動的工作流。
追新模型是一個選擇，面對停用不是。下一次 lifecycle 通知到來時，團隊不需要保證切換毫無差異；需要的是說得清楚換了什麼、用哪些真實工作驗過、還有哪些未知，以及必要時怎麼回到上一條路徑。
模型終究會被停用，因此把這些答案留在團隊手上，工作流才不會跟著失憶。