交付工作區 (Delivery Workspace) 是什麼?前線部署工程如何把 AI 扛上線

交付工作區(Delivery Workspace)是 Tenten AI 前線部署工程(FDE)的核心交付模式:一個由客戶團隊、我們的進場工程師與 AI 系統共用的協作場域,把需求、資料權限、程式碼、上線指標與實際採用數據全部收攏在同一個空間裡,目標只有一個——讓 AI 從 demo 走到生產,並且真的有人天天在用。

它不是一個看板工具,也不是一份專案時程表。它是一種交付方式。

先講一個 demo 之後就消失的案子

去年底我們接手一個製造業的品檢 AI 專案。前一家廠商交付得很漂亮:一個獨立的展示網站、一份 92 頁的技術文件、一組跑在他們雲上的模型 API。驗收那天準確率 96%,主管當場拍板。

三個月後我們進場,那套系統沒有接上產線,一次都沒真正跑過。

原因不玄。展示環境用的是廠商挑過的乾淨照片,產線現場的鏡頭有油污、有逆光、有半夜換班的色溫變化;模型 API 要調用得穿過客戶的內網防火牆,而這件事「不在交付範圍內」。交付物一切齊全,可是交付物和「上線」之間隔著一條沒有人負責的河。

傳統交付的問題,就是交付的邊界畫在 demo 那條線上。跨過去之後的髒活——資料落地、權限、監控、教使用者、扛採用率——被切成另一份合約,或者根本沒人接。

交付工作區 delivery workspace 到底怎麼運作

我們的解法是把邊界往後推,一路推到「有人在用」。交付工作區就是承載這件事的容器。

進場第一週,我們不寫任何模型程式碼。我們做的是把五樣東西搬進同一個空間:客戶的真實資料樣本(不是 demo 資料)、系統要接的上下游權限、我們工程師的 commit 權限、一組講好的上線指標,以及一個能看見「誰用了、用了幾次、在哪一步放棄」的採用儀表板。這五樣東西平常散落在客戶的 IT、資安、業務、法遵四個部門手上,誰都不完整。工作區的第一個作用,就是逼它們在同一張桌子上對齊。

之後每一次迭代,產出的不是文件,是「已經在客戶環境裡跑起來的一段功能」。

差別不在工具先進,在於「完成」的定義被改寫了。

三件事被綁在同一個空間裡

第一是資料與權限的真實性。工作區裡跑的是客戶的髒資料,所以那些 demo 環境永遠碰不到的邊界案例——半夜換班的色溫、客戶自創的行話、跨系統的欄位不一致——會在第一週就爆出來,而不是上線後才變成災難。

第二是工程師與客戶的共同在場。我們的人有 commit 權限,客戶的窗口也在同一個空間裡回問題、給回饋。這消掉了傳統外包最貴的成本:來回等信、規格誤解、「這不是我以為的那樣」。

第三是採用數據的閉環。上線不是終點,是量測的起點。如果一個功能上線兩週使用率只有 4%,工作區的儀表板會立刻讓所有人看見,然後我們回頭改流程、改介面、改教學,而不是把低採用率當成客戶自己的問題。

為什麼這也是一種商業模式

交付工作區逼我們把商業模式也一起改掉。我們不賣模型授權、不按文件頁數計價,因為那會讓我們的利益停在 demo 那條線上。我們賣的是「進場,把它扛到有人用」。

這對雙方都是取捨。客戶要願意把真實資料和權限開進工作區,這需要信任,也需要資安部門提早上桌——通常比客戶預期的更早、更麻煩。我們則要承擔一件外包商最怕的事:採用率不到,我們沒交付完。

我們認為這條線畫對了。一套沒人用的 AI,準確率再高都是零。Tenten 做 FDE,交付工作區就是我們兌現「Demo 很美不算數,上線且有人在用才算數」這句話的地方。