PoC 上線交接範本:驗收準則、護欄設定與交付清單(可下載)

PoC 跑通那天,大家最容易做錯一件事:把「模型答對了」當成「專案可以上線了」。這兩件事之間,隔著一整個交接環節。而多數 PoC 之所以死在抽屜裡,不是技術不行,是交接沒人做——沒有人把驗收準則、護欄、責任歸屬白紙黑字地交出去。

PoC 上線交接範本,就是把這段最容易被跳過的環節,變成一份可以照著填、照著簽的文件。它回答三個問題:這套系統在什麼條件下算「驗收通過」?它被允許做什麼、禁止做什麼?上線後誰負責看、誰負責修?把這三題寫清楚,PoC 才有資格談上線。

為什麼交接是 PoC 最脆弱的一段

我們接過一個製造業的案子。RAG 知識系統在 PoC 階段回答準確率漂亮,客戶很滿意,原廠也交了一份 30 頁的技術報告。三個月後我們回訪,系統幾乎沒人用。

問題出在交接。那份報告寫滿了模型指標,卻沒寫「當文件更新後,誰負責重建索引」;沒寫「回答引用到過期規範時,系統該擋還是該放」;也沒寫「現場工程師發現答錯,回報給誰」。於是第一次答錯之後,沒有人知道該找誰,信任崩了,大家默默改回翻紙本。

Demo 很美不算數,上線且有人在用才算數。交接文件的作用,就是把「有人在用」需要的所有前提,從工程師的腦袋裡搬到紙上。

「準確度要高」不是驗收準則,是願望。可驗收的準則長這樣:在 200 題黃金測試集上,答案正確率 ≥ 85%,引用來源正確率 ≥ 95%,單次回應 P95 延遲 ≤ 4 秒,幻覺率(無來源杜撰)≤ 2%。

關鍵是這組數字要在交接前雙方簽字確認,而且測試集由客戶的業務專家出題,不是工程團隊自己出。我們的做法是把驗收拆成兩層:功能層(答得對不對)和營運層(壞了看不看得到)。營運層常被忽略,但它決定系統能不能活過第一個月。

護欄比功能更能決定上線信任。一套沒有護欄的 Agentic 工作流,能力越強越危險。交接時至少要明確以下幾類邊界。

每一條護欄都要對應一個「觸發時的處置」和「負責人」。護欄沒有負責人,等於沒有護欄。

交接不是開個會口頭說明,是交出一份可被稽核的清單。以下是我們每個 FDE 專案上線前必到齊的項目。

這份清單的精神是:每一項都要「當場驗一次」,而不是「文件裡有寫」。文件裡有寫,和現場真的能跑,是兩回事——這條界線,就是 PoC 死亡率的分水嶺。

一份好的交接範本,不會讓專案上線那天變輕鬆,它只是把後面三個月會踩的雷,提前攤在桌上。真正的採用曲線,是從交接後第一次答錯、第一次資料更新、第一次有人回報開始長出來的。

我們在 Tenten 做 FDE,把工程師派進客戶現場,很大一部分工作就是盯著這份清單一項一項驗完,再把系統交到會用它的人手上。範本可以下載、可以照抄,但那句話始終沒變:上線且有人在用,才算數。