做法還不確定
知道想改善哪個流程，但不確定該用 LLM、傳統模型、規則系統，或其實不需要 AI。
From POC to Production
先證明值得做，
再把系統做成能接手的產品
我們把 AI 專案拆成可判斷、可驗收的階段。先確認資料與風險，再用小範圍 POC 驗證價值，避免一開始就投入完整系統。
Start Small, Learn Fast
什麼情況適合先做 POC？
POC 不是縮小版成品，而是一個有明確問題、資料範圍與通過條件的技術實驗。
資料能不能用未知
已有文件、影像或感測資料，但品質、標註方式與可達成效果仍需要實際驗證。
需要地端驗證
資料不能離開場域，需要同時確認硬體資源、推論速度、權限與整合限制。
需要共同決策依據
希望用可閱讀的報告與測試結果，讓技術、業務和管理端一起判斷下一步。
Before We Build
第一次討論前，先準備這五件事
不必先整理成完整規格。能清楚描述現況與限制，通常比先指定某個模型更有幫助。
- 使用情境誰在什麼時候使用？現在的工作流程是什麼？
- 問題與代價目前最耗時、容易出錯或難以追蹤的是哪一段？
- 資料樣本少量去識別化的文件、影像、表格或感測紀錄即可開始盤點。
- 環境限制是否必須地端部署？可使用的伺服器、GPU、網路與系統介面為何？
- 成功定義準確率之外，還在意誤報、速度、可追溯性或人工作業時間嗎？
Delivery Process
每個階段都有輸入、決策與輸出
實際範圍會依題目調整，但核心原則不變：在風險仍高時先驗證，不把不確定性藏到最後。
- 01
問題定義
確認使用者、現行流程、資料邊界與不可接受的風險。
- 02
資料盤點
檢視樣本品質、代表性、權限、標註成本與缺漏情況。
- 03
POC 驗證
以小範圍原型比較方法，記錄限制、錯誤型態與通過條件。
- 04
系統整合
加入 API、權限、紀錄、人工覆核、部署與異常處理機制。
- 05
驗收交接
完成測試、文件、原始碼與操作說明，讓內部團隊能維護。
Deliverables
交付的不只是一個可以 Demo 的畫面
以下為常見交付物的概念示意；實際項目、深度與格式依專案範圍確認。
VALIDATION SUMMARY
驗收條件與測試結果
指標 A依資料定義指標 B依場域定義指標 C依風險定義
記錄錯誤型態、適用範圍與不建議使用的條件，作為是否進入正式導入的依據。
概念示意｜非真實客戶或專案畫面
技術與評估
- 資料品質與可行性盤點
- 方法比較與模型評估
- 錯誤案例與限制說明
- 驗收報告與後續建議
系統與部署
- 系統架構與資料流
- API 與介接規格
- 部署設定與環境需求
- 監控、備份與復原方式
程式與交接
- 約定範圍內的原始碼
- 安裝、操作與維護文件
- 相依套件與授權清單
- 教育訓練與交接紀錄
Acceptance
驗收指標要在開發前定義
不同題目需要不同指標。準確率只是其中一項，還要把場域真正承受的風險放進來。
面向可觀察指標要回答的問題
效果準確率、召回率、錯誤型態哪些情況可信？哪些必須交給人？
效率處理時間、延遲、吞吐量是否符合現場節奏與硬體限制？
風險誤報、漏報、幻覺與例外率錯誤發生時如何阻擋與復原？
治理來源、操作紀錄、人工覆核率事後能否知道系統為何做出判斷？
維運穩定性、資源占用、更新成本內部團隊是否有能力長期接手？
如果資料條件不足，或規則系統更合適，我們會把「不建議進入正式開發」列為有效結論。
好的 POC 不一定要證明 AI 可行；它更重要的價值，是在成本仍低時找出不能做、暫時不該做，或應該換方法的原因。