demo 與上線之間的落差
看 AI 廠商 demo 的時候，幾乎每次都會留下好印象。流程順、回答準、體驗完整，台上跑得漂亮，台下看了會想「這個我們也要」。等到真的導入自己的環境、開放給全公司用之後，那種落差才會浮現出來——同一套東西，感受卻差很多。
這幾年做過幾個 AI 導入案，我們把這個落差拆成三塊。理解這三塊，比評估「哪個 model 比較強」更接近導入會不會成功的關鍵。
落差一：資料
Demo 用的是整理好的資料：格式統一、欄位完整、沒有雜訊。那是為了讓示範跑順、刻意準備的版本。
真實環境裡的資料是另一回事——資料跨好幾個系統倒進來，格式不一、欄位缺漏是常態，同一個客戶的名字可能有三種打法（全名、簡稱、多了空格的版本）。AI 拿到這種資料，輸出品質立刻往下掉。
demo 看不出這件事，因為 demo 的資料是先洗過的。上線後第一個爆出來的問題，幾乎都跟資料品質有關。
落差二：使用者
Demo 通常是工程師或廠商在示範：知道從哪裡點、欄位怎麼填、該問什麼問題，每一步都踩在設計好的路徑上。
上線之後是整個部門、甚至整間公司在用。有人問超出範圍的問題、有人跳過步驟、有人把 AI 當成搜尋引擎在用。沒有人會照著當初設計的流程操作，因為他們沒看過那份流程。
這不是使用者的問題，是 demo 本來就只展示了「正確使用」的版本。真實使用是發散的，系統要能接住各種沒被預期到的操作方式。
落差三：例外狀況
Demo 跑的是 happy path——所有輸入都符合預期、每個判斷點都有明確答案、外部系統都正常回應。
真實流程裡有大量例外：model 碰到沒見過的輸入、API 回傳空值、邏輯卡在某個沒定義清楚的判斷點、上游系統當機。這些 demo 階段都不會出現，上線之後一個一個浮上來。
處理例外不是 AI 的工作，是系統設計的工作。error handling、fallback、重試策略、人工介入的接口——這些決定了系統在現實裡能不能穩定跑，而它們不會出現在 demo 裡。
差距的根源：理想路徑 vs 真實環境
把這三塊放在一起看，會發現它們其實是同一件事的不同切面：demo 展示的是理想路徑，真實環境是充滿摩擦的路徑。
demo 的目的是讓人看懂「這個東西能做什麼」，所以它必須乾淨、必須順。但「能做什麼」和「能在你的環境裡穩定做下去」中間，隔著一層工作——資料清理、邊界處理、流程接合、例外接管。這層工作不上鏡，不會出現在任何示範影片裡，卻是導入成本的大部分。
integration layer 才是真正的工作
讓 demo 好看，門檻其實不高。現在的工具和 model 都夠強，組一個會動的展示版本不難。
讓它在真實環境裡穩定運作，才是難的部分。差距不在 model，在 integration layer——錯誤處理、fallback、資料清理、邊界情境。這部分不上鏡，卻是上線後系統能不能用的關鍵。
導入 AI 不等於買一套工具讓員工自己摸。把 AI 接進既有流程、處理掉那些不上鏡的例外、讓它長期穩定跑——這一段需要有人真的做過、知道坑在哪。接不進流程，才是導入 AI 真正的難題，那也是我們在做的事。