交付工作區(Delivery Workspace)怎麼運作?把 AI PoC 推上生產線的協作模式拆解

交付工作區(Delivery Workspace)是 Tenten AI 的一種協作交付模式:把交付工程師、客戶的領域專家與資料擁有者放進同一個共享空間,以雙週為節奏,把一個 AI PoC 從「Demo 好看」逐步推進到「跑在生產環境、被真人天天用、而且維運得起來」。

它不是一個工具,也不是一份專案計畫書。它是一種讓交接這個動作消失的方式。

為什麼「交接」這一步會殺死 PoC

我們統計過自己手上失敗的案子,九成不是死在模型不夠準,是死在交接。

流程通常長這樣:顧問或供應商做出一個 PoC,準確率漂亮,Demo 那天客戶點頭。接著雙方簽了驗收,供應商把程式碼、一份部署文件、一組 API 金鑰丟給客戶的 IT 團隊,說「接下來上線就交給你們了」。三個月後你回去看,系統躺在測試環境裡,沒有人敢接到正式流程上。

問題出在,PoC 到生產線之間那段路,恰好是最沒人負責的一段。做 PoC 的人不懂客戶的權限系統、不知道法遵要什麼欄位留痕、不清楚現場的人到底怎麼工作;客戶的 IT 懂這些,但看不懂那包程式碼裡的 prompt 為什麼要那樣寫、retrieval 為什麼會漏。兩邊各自握著一半的知識,中間隔著一份永遠寫不完整的交接文件。

交付工作區的設計目的很單純:讓這份文件不需要存在。因為知道答案的人,本來就在同一個房間裡。

交付工作區 delivery workspace 是一個房間,不是一份文件

具體來說,一個交付工作區包含四種角色被綁在一起工作:我們的交付工程師(FDE)、客戶方一位能拍板的領域負責人、一位真的會用這套系統的第一線使用者、以及一位握有資料與權限的 IT 或資安窗口。這四個人共用同一個看板、同一條 Slack 頻道、同一個部署環境。

關鍵在於,使用者從第一週就在裡面。不是等系統做完才拉進來驗收,而是每一次迭代他都在現場罵。上個月一個製造業的案子,我們原本設計讓 AI 生成整份品質異常報告,工程師試用第三天就說:「我不要它幫我寫結論,我要它把過去類似的三筆案例調出來,結論我自己下。」這句話直接改掉了整個產品形態。如果照傳統流程,這個洞見要到上線後三個月的滿意度調查才會浮出來——那時候重做的成本是現在的十倍。

我們把它跟傳統交接模式擺在一起看,差別會更清楚:

四條軌道同時跑,不是排隊

傳統專案是瀑布:先做模型,再做整合,最後做上線。交付工作區則是四條軌道並行推進,因為我們吃過排隊的虧。

第一條是模型與檢索,調 prompt、調 RAG、對答案品質。第二條是資料管線,把客戶真實的、髒的、有權限層級的資料接進來——這條幾乎永遠是最慢的,所以第一週就要動工,不能等。第三條是嵌入現場流程,搞清楚這個 AI 要出現在使用者工作流的哪一格,是一個按鈕、一個側邊欄,還是一封自動草稿。第四條是維運與留痕,誰能看到什麼、出錯怎麼回溯、法遵要的稽核紀錄長怎樣。

這四條裡,團隊最容易只顧第一條。因為調模型最像「在做 AI」,最有成就感,Demo 也最好看。但真正卡住上線的,幾乎都是後面三條。我們的交付工程師有一半時間其實在處理權限、稽核、跟現場動線這些不性感的事。這是刻意的。

一個雙週節奏長什麼樣

我們用兩週一個迭代。第一週週一,四個角色一起訂這兩週要讓哪一個真實使用情境跑通——注意,是「情境」不是「功能」。例如「讓客服在處理退貨工單時,能一鍵調出這個客戶過去的所有互動摘要」。

接下來的日子,工程師在共用環境裡直接改,使用者隨時試。到第二週週五,我們不是做簡報,是讓那位第一線使用者當場用真實資料操作一次,四個人一起看。跑通了,就往生產環境推一小步,開放給一小群真人用;沒跑通,誠實記下卡在哪一條軌道,下個迭代排進去。

我們會盯一個數字,而且從第一個迭代就開始盯:真實使用率。不是登入數,是「在真實工作情境下實際用它完成任務」的比例。這個數字如果連續兩個迭代不動,代表產品形態錯了,要停下來重新想,而不是繼續加功能。開頭那個使用率 4% 的客服系統,就是沒有人盯這個數字,才會一路漂亮地錯到底。

什麼時候該關掉工作區

交付工作區不是要一直開著。它的退場條件寫得很硬:目標情境的真實使用率達標、客戶內部有人能獨立維運、稽核與權限都上線。三個都滿足,我們才把環境的主導權完全交還,自己退到後線支援。

退場條件寫得硬,是因為我們見過太多「顧問走了系統就死」的案子。如果退場的唯一標準是「合約做完」,那交付工作區跟傳統交接沒有兩樣,只是把甩鍋延後了。

在 Tenten,我們把每一個 AI 導入案都放進這樣的交付工作區來跑。原因很現實:對我們來說,一個 Demo 再漂亮都不算數,要等到生產線上真的有人每天在用它,這個案子才算開始有價值。