一次 AI 請求只是開始。

在模型執行之前

使用者提供提示詞和一個別名，如 cheap、fast 或 smart。生產服務端在接受任務之前檢查認證、工作區歸屬與許可權。供應商模型 ID 與金鑰留在這條邊界之後——友好的別名是客戶端唯一需要的模型詞彙，因為到真實供應商模型的對映是配置，而不是契約。

持久的任務記錄在後臺執行開始前就給請求一個身份。這個身份把提交、worker、用量記錄與結果串起來，也讓使用者在離開頁面後能找回這項工作。

順序很重要：昂貴的工作只在便宜的檢查通過之後才開始。在任何任務入隊之前先驗證認證、歸屬與許可權，能讓未認證或未付費的請求永遠到不了供應商——也讓失敗對使用者可解釋。AI 模組指南記錄了這些檢查住在哪裡；工作區邊界一文解釋了為什麼歸屬在服務端推導，而不是信任客戶端。

決定用誰的金鑰、誰的上限

AI 功能是一個花錢的決定。supastack 允許工作區自帶供應商金鑰——加密儲存、絕不暴露給客戶端——或跑在平臺金鑰上，並按模型價格目錄執行每個工作區的預算。無論你怎麼實現，問題都一樣：誰付錢，上限在哪裡執行？

執行屬於服務端工作流，而不是瀏覽器側的估算。生成之後才檢查的預算只是記錄超支；派發之前檢查才能阻止超支。供應商金鑰設定講了配置那一側。

讓執行顯式化

Trigger.dev 執行 ai.generate 工作流。能力感知路由器根據已配置策略與請求要求選擇模型。把該策略當作運維輸入：不可用的別名不應在介面上顯示為可用選項。

提交過程中的網路故障會讓客戶端不確定任務是否已入隊。生產路徑使用任務級冪等鍵與已儲存的提交，使恢復可以複用原始請求。每次超時後都新建任務，會有重複工作與重複扣費的風險。

永續性也是讓介面保持簡單的東西：介面讀取任務狀態並渲染，而不是編排重試。當生成跨模型呼叫、工具步驟或排程時，顯式的工作流契約——enqueue、status、cancel——才是讓“進行中”保持誠實的機制。

給失敗模式點名

在請求與結果之間，會出錯的是一個具體而有限的集合。按名字逐個設計，而不是為籠統的“錯誤”設計——每個任務都應該落到可解釋的狀態：已入隊、執行中、帶原因的失敗、或帶結果的完成。任務恢復是套件在恢復一側的參考。

底下對介面的要求是：任何狀態都不能撒謊。比工作活得更久的轉圈，或是為從未執行的任務亮出的成功訊息，都是一張等著發生的客服工單和計費糾紛。

• 提交超時——通過已儲存的提交與任務級冪等鍵恢復，而不是重新入隊。
• 供應商在任務中途失敗——把任務標記為失敗，並給出介面能展示的原因。
• 預算耗盡——在派發之前拒絕，而不是在花完之後。
• 使用者離開了頁面——持久記錄與恢復 URL 能找回狀態和結果。

追蹤發生了什麼

生成產生的不只是文本。應用會記錄用量與任務結果，介面通過已認證的 API 讀取狀態。正是用量記錄讓預算可以執行——它在結果返回之前寫入，而不是事後估算。

完成郵件是獨立的步驟，有獨立的投遞記錄。模型響應成功並不能證明郵件已送達。把這些結果分開，讓失敗更容易解釋與重試，而不必無謂地重跑模型。

結果還需要一個使用者可以回訪的家：任務頁、歷史列表、或隨完成郵件送達的恢復 URL。只存在於轉瞬即逝的通知裡的生成，是你遲早被要求再做一遍的工作。

驗證每一條邊界

先用確定性的 fake 介面卡測試應用的決策：拒絕訪問、停用別名、重複提交、結果恢復與通用錯誤。這些測試應在沒有供應商憑證的情況下執行。

然後使用明確 opt-in 的供應商冒煙流程驗證真實整合。它要求檔案化的沙箱配置以及對外呼叫的批准。這種區分讓日常開發保持快速，也讓生產證據具體且可追溯。

產品變化時保持這種劃分穩定：在每個邊界決定附近都有確定性覆蓋，這樣換供應商、改路由策略或新增別名只會讓測試失敗，而不是讓客戶失敗。

關於 SaaS 中 AI 功能的常見問題

每次談到把 AI 放到付費牆後面，總會冒出這幾個問題。

• AI 功能的授權應該放在哪裡？ —— 在任何任務入隊之前：認證、解析工作區、檢查權益，然後才建立任務。生成之後才跑的檢查只是在給濫用做記錄。
• 我需要支援 BYOK 嗎？ —— 如果你的客戶有自己的供應商關係，就需要：它決定誰付錢、誰擁有速率上限。金鑰要加密儲存、遠離客戶端——AI 配置指南講了這個模型。
• 怎麼防止重試造成重複計費？ —— 把冪等鍵限定在任務上，並在恢復時複用已儲存的提交，這樣一次超時就造不出第二次計費執行。
• 應該記錄哪些用量資料？ —— 按任務記錄：模型、消耗的單位、對照價格目錄算出的成本，以及所屬工作區——足夠執行預算、也足夠回答支出問題，而無需重跑任務。
• 什麼時候生成該放進後臺任務？ —— 只要它可能比一次請求活得久。模型延遲、重試和多步工作都要求持久執行；只有即時且便宜的呼叫才適合內聯。