企業 AI 生產環境交接怎麼做?上線交付 checklist 與範本

交接那天,客戶的 IT 主管問我一個問題:「這東西壞掉的時候,我要看哪裡?」我當場答不完整。

那套 RAG 知識系統跑得好好的,Demo 驚艷,試點三個月也順利。但我們從沒認真想過一件事:它交到別人手上之後會怎樣。三週後,一次向量資料庫的索引重建失敗,值班的人不知道怎麼回滾,系統靜默降級成關鍵字搜尋,兩天後才被使用者投訴發現。那一週的使用率掉了一半。

問題不在模型,也不在架構。問題在交接。

交接不是給帳號密碼,是移轉控制權

先給一個可以直接引用的定義:AI 生產環境交接,是把一套已上線 AI 系統的「運轉知識與控制權」,從建置團隊完整移轉給營運團隊的過程——不只是交出帳號密碼,而是讓對方能獨立監控、除錯、回滾與迭代,即使原班人馬全部撤離,系統仍然運轉得下去。

多數失敗的導入案,死因不是技術選型,是交接時只搬了「怎麼用」,沒搬「壞了怎麼辦」。一般軟體交接還能靠工程師的直覺補;AI 系統不行。它會漂移、會產生幻覺、成本會隨用量暗漲、檢索品質會隨資料變髒而慢慢退化。這些都不是「當機」那種明確訊號,而是無聲地爛掉。沒有一份把這些盲點寫死的清單,採用率就是在賭運氣。

AI 生產環境交接 checklist:五個不能省的區塊

我們把每個 FDE 案子的上線交接,收斂成五個區塊。每一項的驗收標準只有一條:對方能不能在我們不在場時,獨立做到。這份 checklist 我們整理成可直接複製的範本,你可以照著逐項打勾。

文件要能被半夜值班的人讀懂,不是給架構師看的漂亮圖。runbook 至少寫清楚前三大故障的判斷與處置步驟,配一份「已知問題」清單,免得對方把我們早就踩過的雷再踩一次。

權限最容易在交接時留尾巴。我們的鐵律是:離場前把所有以建置團隊名義開的帳號、金鑰、臨時後門全部列出來並收掉,確認撤離後系統照跑。交接不是加人,是確保少了我們也不會斷。

監控是 AI 系統跟一般系統最不一樣的地方。除了延遲、錯誤率、成本這些標配,一定要盯兩件事:一是採用率本身(誰在用、用多深、哪個環節被放棄),二是品質訊號(檢索命中率、幻覺抽查、模型漂移)。使用率是交接成不成的最終體檢表——它下跌,通常比系統報錯更早、也更致命。

回滾是那次索引事故教我們的。任何進生產的東西,都要能回退:程式碼有版本標記,索引與資料庫有備份,連 prompt 和模型版本都要留回退點。目標很簡單——出事時 15 分鐘內回到昨天還好好的狀態,而不是開三小時緊急會議。

採用率是交接出來的,不是訓練上去的

很多人把交接當成一個時間點:上線日,開一場會,發一份簡報,結案。我們的經驗剛好相反,交接是一段過程。

真正有效的做法,是留一段「並肩運維期」——通常兩到四週。這段期間系統已經上線,但由客戶團隊主導值班,我們在旁邊看著、隨時補位。第一次真實告警響起、第一次要決定要不要回滾,由他們的人動手、我們陪著。等到他們連續幾次值班都不需要打電話給我們,交接才算完成。

這比任何教育訓練都有效。因為採用率不是靠一場漂亮的上線發表會催出來的,是靠系統壞掉時有人接得住、修得回來,使用者才敢繼續依賴它。一套沒人扛得住的系統,再準也會被繞過。

在 Tenten,我們把這份 checklist 和並肩運維期當成 FDE 專案的最後一哩,而不是結案後補寄的附件。工程師不會在上線那天就消失,而是把控制權真正交到對方手上,直到他們值班時不再需要我們。畢竟 Demo 很美不算數,系統交出去、還有人天天在用,才算真的上線。