如何設計一個真的會上線的 AI PoC:範圍、驗收標準與 8 週時程

大部分 AI PoC 死在成功的那一刻。Demo 跑通了,會議室裡的人鼓掌,然後這個東西被裝進一份簡報,再也沒有人碰。我們看過太多這種「技術上成功、業務上陣亡」的案子:模型準確率漂亮,但沒有一條資料流真的接進客戶的系統,沒有一個真實使用者每天靠它做事。

問題不在技術。問題在於這個 PoC 從第一天起,終點就設錯了。

AI PoC 怎麼設計:先把終點釘死在生產線上

要回答「AI PoC 怎麼設計」這個問題,最有用的一句話是:PoC 的目的不是證明技術可行,而是證明這條工作流可以被搬上生產線、而且有人願意每天用它。 技術可行性在 2026 年幾乎是預設值——大型語言模型能不能讀你的合約、能不能分類你的工單,答案通常是「能」。真正會殺死專案的,是資料權限、系統整合、稽核合規、以及最容易被忽略的一件事:第一線員工到底肯不肯改變自己的工作習慣。

所以我們的做法是逆推。不要問「這個模型能做什麼」,而是問「六個月後,這個東西要在哪個部門、由誰、用什麼系統、處理哪一批真實資料、每天跑幾次」。把那個生產狀態當作終點,再往回砍出 PoC 的範圍。凡是無法通往那個終點的炫技,一律不做。

舉個具體的例子。一家製造業客戶原本想做「AI 幫我們讀所有技術文件」。範圍太大,永遠做不完。逆推之後我們把終點釘死成:「品保工程師在處理客訴時,能在 30 秒內從歷史案例庫找到三筆相似案例並附出處。」一個角色、一個場景、一批資料、一個可量測的動作。PoC 範圍瞬間清楚了。

範圍怎麼砍:一個使用者、一條工作流、一批真資料

砍範圍的三條紀律,我們每個案子都用。

第一,只選一個真實使用者角色,不做「給所有人用」的通用平台。通用系統的採用率通常是個位數,因為它不對任何人的具體痛點負責。第二,只打通一條端到端的工作流,寧可窄而深,不要寬而淺——一條完整跑通、有出處、能被稽核的流程,勝過十個半成品功能。第三,用客戶的真實資料,不用乾淨的示範資料。示範資料會騙過所有人,包括你自己。真資料裡的髒亂、缺漏、權限邊界,才是上線時真正會爆炸的地方,越早碰到越好。

有一個反直覺的取捨值得講:PoC 階段我們刻意不追求最高準確率,而追求「錯了之後看得見、可回溯、可修正」。一個 85% 準確但每個答案都有出處、錯誤可被人工攔截的系統,比一個 95% 準確但像黑盒子的系統更容易上線。因為生產環境需要的是信任機制,不是漂亮的分數。

驗收標準:寫成能被打勾的句子

「做出來看看效果」不是驗收標準,那是免死金牌。真正的驗收標準必須在 PoC 開始前就寫死,而且每一條都要能被明確地打勾或打叉。我們把它分成三層:

• 功能驗收——具體到可執行。例如「輸入一張客訴工單,系統回傳三筆相似歷史案例,每筆附文件連結與段落,人工抽檢 50 筆的相關性命中率 ≥ 80%」。
• 整合驗收——證明它接得進生產環境。例如「透過現有 SSO 登入,資料權限與原系統一致,單次查詢延遲 < 3 秒,並寫入稽核日誌」。
• 採用驗收——證明有人真的會用。例如「三位品保工程師連續使用兩週,週活躍 ≥ 3 次,並在退場訪談中表示願意繼續使用」。

第三層是最多人漏掉、卻最能預測上線成敗的一層。技術驗收全過、採用驗收掛掉的 PoC,上線後幾乎必然變成那個 4% 使用率的擺設。

8 週時程:每一週都有可交付、可驗收的產出

為什麼是 8 週?短於 6 週,碰不到真資料與整合的硬骨頭,驗收會失真;長於 10 週,團隊會不自覺地把 PoC 做成產品,失去「快速驗證再決定」的意義。8 週是我們反覆調校後的節奏,每兩週一個明確關卡。

注意最後一週的產出不是「一個 demo」,而是一份上線決策書:三層驗收各過了幾條、還差什麼、要真正推上生產線需要多少工程量、風險在哪。這份文件讓決策者能做出負責任的 Go/No-Go,而不是被一場漂亮的演示情緒綁架。

別讓 PoC 變成一次性的煙火

會失敗的 PoC 和會上線的 PoC,差別往往不在第八週,而在第一週有沒有把終點釘在生產線上。範圍逆推、真資料、三層驗收、8 週節奏——這四件事扣在一起,才能杜絕「做完就丟」。

我們在 Tenten 做前線部署,信念很簡單:Demo 很美不算數,上線且有人在用才算數。所以我們的 PoC 從第一天就派工程師進客戶現場,碰真資料、接真系統、盯真使用者——因為能不能上線這件事,從來不是最後一週才該問的問題。