AI POC 到底該怎麼設計才算及格：跨產業通用驗收指南

上個月幾乎同一時間，我們接觸到兩間規模相近、但完全不同產業的公司，都在評估要不要找廠商做一次「POC」再決定是否正式導入。一間公司在啟動前先列了一張需求訪談清單，把要驗證的場景、要用的資料範圍、驗收的標準都寫進了跟廠商的往來郵件裡，後來順利從眾多報價中篩出真正有能力做整合的對象；另一間公司則是接受了「先免費幫你們測試功能」的提議，雙方口頭講好「做出來再看感覺」，結果三週後拿到一份看起來很厲害的操作畫面，卻說不出這次測試到底驗證了什麼，也不知道下一步該簽多大的合約。

兩間公司花的時間差不多，但一間做出了可以拿去跟主管或股東報告的結論，另一間等於白做了一次。POC（Proof of Concept，概念驗證）會不會「及格」，往往不是看廠商技術強不強，而是看企業主有沒有在一開始就把這場測試的邊界畫清楚。

先問自己：這次 POC 到底要驗證什麼

很多 POC 一開始就注定模糊，因為題目下得太大。「測試 AI 能不能幫我們處理客服」跟「測試 AI 能不能在不漏單的前提下，處理我們最常見的三種客服問題類型」是完全不同等級的驗證範圍。及格的 POC 會先把範圍縮小到一個具體、可觀察、可比對的場景：用哪一批真實資料（或匿名化後的近似資料）、模擬哪幾種最常發生的情境、要排除哪些邊緣案例不在這次測試範圍內。範圍訂得越窄，測試結果才越有參考價值；範圍訂得太寬，就只是一場漂亮的演示，不是驗證。

這個階段也該先決定「誰來主導」這次 POC 的設計——是對接廠商技術規格的 IT，還是最清楚實際流程痛點的業務或現場人員。少了任何一方,訂出來的測試場景很容易脫離真實情況。

驗收標準要在簽約前寫清楚，不是做完才討論

我們看過不少案子,雙方對「POC 成功」的定義完全沒寫進任何文件,只是口頭上有個模糊共識。等測試做完,廠商說「這樣已經算成功了」,企業主卻覺得「這跟我想的不一樣」,雙方各說各話,沒有一個客觀標準可以仲裁。及格的做法是在簽約或啟動前,就用具體數字或可驗證的條件寫下驗收標準：準確率要達到多少、處理時間要縮短到什麼程度、誤判率的上限是多少、哪些情境測試失敗就視為不通過。這份標準不需要寫得像法律合約一樣嚴謹,但至少要讓雙方事後對照時,不會變成各自解讀。

免費 POC 的陷阱：為什麼「不用錢」反而要更小心

「先免費幫你們做個小測試」聽起來很有誠意,但免費往往意味著廠商只投入了最少的資源去做一個討喜的展示,而不是真正貼近企業實際環境的測試。免費 POC 常見的陷阱包括：用廠商準備好的範例資料,而不是企業自己的真實資料;只展示理想情境,刻意避開企業真正頭痛的例外狀況;測試規模小到完全看不出正式上線後的效能表現。免費不是壞事,但企業主應該在接受免費測試前,主動要求把自己的真實資料與痛點情境放進測試範圍,否則這場測試驗證的只是廠商的demo能力,不是這套系統適不適合自己。

POC 通過了,不代表上線後不會卡關

POC 跟正式上線之間,中間還有一段常被低估的落差。測試環境的資料量、使用者數量、例外狀況,通常遠比正式營運時單純。POC 通過後,企業主該接著問：正式上線需要哪些額外的資料整理或系統整合工作、這些工作由誰負責、預估要多久、費用是否已經包含在報價裡,還是後續會追加。這幾個問題問得越早,後面因為「怎麼跟報價差這麼多」而產生的糾紛就會越少。

如果正在評估要不要啟動一場 POC,先別急著問廠商「能不能做」,而是先把這次要驗證的場景寫成一句具體的句子,並確認這份描述廠商看完也認同——這一步做對了,後面的驗收標準才有東西可以對照。