企業 AI Agent POC：兩星期驗證值唔值得做
大部分企業 AI 專案失敗，是因為一開始做得太大。本文說明兩星期 POC 應該怎樣設計：如何揀工序、日程安排、三個量度指標（準確度／節省時間／每次處理成本），以及 POC 後三種結果的處理方式。
文章目錄（點擊展開）
大部分企業 AI 專案失敗，不是模型不夠好，而是一開始就做得太大。與其花半年做一個「全公司 AI 平台」，不如用兩星期驗證一個具體工序值不值得自動化。這篇講清楚 POC 應該怎樣設計。
決策摘要（30 秒）
POC 目標不是「做出一個 AI」，而是用最低成本回答一個問題：這個工序用 AI 做，準確度夠不夠、成本划不划算、同事願不願意用。
時間：2 週。範圍：一個工序、一個部門、真實資料。
唔適合：連工序都未標準化就想 AI 化。
一、揀錯工序，POC 一定失敗
以下四類工序最適合做第一個 POC：
- ▸有大量重複文字處理——報價單比對、合約條款抽取、客服分類
- ▸答案存在於文件裡——內部 SOP、產品規格、過往案例問答
- ▸人手做的判斷有明確標準——例如退貨申請是否符合政策
- ▸錯了可以接受——有覆核步驟，不會直接影響客戶或金錢
相反，以下情況不應做 POC，應該先做流程整理：
- ▸每個同事做法都不同，沒有標準流程
- ▸涉及法定判斷或高風險決策（醫療、法律、信貸審批）
- ▸沒有可用資料，或資料散落在幾十個 Excel
二、兩星期 POC 的實際日程
| 時間 | 做什麼 | 交付 |
|---|---|---|
| 第 1–2 日 | 工序盤點、定義「成功」的可量度標準 | 一頁 POC 規格 |
| 第 3–4 日 | 整理 50–200 個真實樣本作測試集 | 測試集與基準答案 |
| 第 5–8 日 | 建立流程（RAG 或分類），反覆調校 | 可運作的內部工具 |
| 第 9 日 | 用測試集量度準確度、處理時間、成本 | 數據報告 |
| 第 10 日 | 由實際使用者試用，收集意見 | Go / No-Go 建議 |
三、怎樣量度「值不值得做」
三個數字，缺一不可：
- 準確度——在測試集上，AI 的答案與人工基準一致的比例。低於可接受門檻，就不應該上線，只可做輔助。
- 節省時間——同一批工作，AI 輔助 vs 純人手的實際工時差。
- 每次處理成本——模型 API 費用 + 人工覆核時間。很多 POC 在這一項才發現不划算。
四、POC 之後的三種結果
| 結果 | 含義 | 下一步 |
|---|---|---|
| 準確度高、成本低 | 值得正式導入 | 擴展到同類工序，加監控與權限 |
| 準確度高、成本高 | 只適合做輔助 | 改為「AI 建議、人手決定」 |
| 準確度不足 | 資料或流程未準備好 | 先整理資料與標準，不要硬上 |
三、POC 要回答的四條問題
企業做 AI POC 最常見的失敗，是一開始就問「AI 可以做什麼」。正確的問題是：
- 哪一個流程最耗人力、而且規則相對固定？（不是最有趣的那個）
- 目前這個流程一小時的成本是多少？（人力、錯誤率、客戶等待時間）
- AI 要做到幾準確才有價值？（例如八成準確但需人手覆核，是否仍然划算）
- 如果失敗，損失上限是多少？（POC 的預算與時間上限）
這四題答得出來，POC 才有驗收標準。答不出來，通常代表問題本身還未定義清楚。
四、兩星期的 POC 怎樣安排
| 日子 | 工作 | 產出 |
|---|---|---|
| 第 1–2 日 | 選定單一流程、收集 30–50 個真實案例 | 測試集 |
| 第 3–5 日 | 建立基準：先記錄「現時人手做法」的準確度與耗時 | 基準數字 |
| 第 6–9 日 | 建最小可用流程（讀取資料→模型處理→輸出） | 可運行版本 |
| 第 10–12 日 | 在同一批案例上比對 AI 與人手 | 對照結果 |
| 第 13–14 日 | 計算單位成本、寫出「繼續／停止」建議 | 決策備忘 |
關鍵設計：第 3–5 日的基準數字。沒有基準，兩星期後你無法回答「AI 是否比現時做法好」，只會得到一個「看起來不錯」的示範。
五、POC 最常見的三個陷阱
- ▸用精心挑選的案例示範。POC 必須用真實、未經修飾的數據，包括那些「亂」的輸入，否則上線後準確度會大幅下跌。
- ▸只量準確度，不量成本。準確度提升但每次調用成本高於人力節省，商業上仍然不可行。
- ▸跳過人手覆核設計。大部分企業場景在初期都需要人手把關；POC 應該一併設計「AI 建議＋人手確認」的流程，而不是假設全自動。
六、由 POC 到正式上線的差距
POC 成功不等於可以上線。中間通常還需要以下工作，這也是很多企業預算失準的地方：
| 工作 | POC 階段 | 上線階段 |
|---|---|---|
| 權限與登入 | 通常略過 | 必須接入公司帳號系統 |
| 資料來源 | 手動匯出的樣本 | 與內部系統即時同步 |
| 錯誤處理 | 人工觀察 | 重試、告警、降級方案 |
| 監控與記錄 | 幾乎沒有 | 每次調用的成本與品質追蹤 |
| 資料合規 | 常被忽略 | PDPO 相關的處理與保存政策 |
七、什麼情況應該停止
一個健康的 POC 流程，應該有明確的「停止條件」。以下三種情況，繼續投入通常不理智：
- 準確度無法達到可用門檻，而且已嘗試兩種以上的方法（例如調整提示、加入檢索、換模型）。
- 節省的人力不足以抵銷調用成本與維護成本，即使準確度理想。
- 流程本身還沒有共識——各部門對「正確結果」的定義不同，AI 無法解決定義問題。
八、常見問題
Q：一定要用最先進的模型嗎？
不一定。很多企業場景用較小的模型已足夠，成本低、速度快、資料處理更可控。應該先用最簡單的方案測試，達不到才升級。
Q：公司資料可以放入第三方模型嗎？
要先確認合約條款、資料是否用於訓練、存放地區。涉及個人資料時，需按 PDPO 評估並在 POC 階段就設計好處理方式，而不是上線前才補。
Q：POC 需要 IT 部門參與嗎？
需要，至少要處理資料存取與權限。由業務部門單獨推行的 POC，最常見的結局是「示範很好，但接不上正式系統」。
九、POC 的資源配置
兩星期的 POC 不需要一個大團隊，但需要正確的三種角色：
| 角色 | 投入 | 負責 |
|---|---|---|
| 業務負責人 | 每週 2–3 小時 | 定義「正確答案」、提供真實案例、判斷結果是否有用 |
| 工程實作 | 全職 2 週 | 建流程、接資料、跑測試、計成本 |
| IT／資安 | 少量但關鍵 | 資料存取權限、合規要求、能否接上正式系統 |
最常見的失敗配置是：只有工程，沒有業務負責人。結果做出來的東西技術上可行，但沒有人願意用，因為它解決的不是真實痛點。
十、怎樣寫一份高層看得懂的 POC 結論
POC 結束後，如果結論寫成技術報告，管理層看不懂，項目就會自然死亡。建議用以下四段結構：
- 我們原本的問題是什麼（一句話，用業務語言，不用技術詞）。
- 測了什麼、用什麼數據測（案例數量、真實或模擬）。
- 結果與現時做法比較（準確度、時間、成本，三個數字並列）。
- 建議：繼續／調整／停止，並寫出下一步需要的資源與時間。
第 4 段最容易被略過，但它才是管理層真正要的答案。沒有明確建議的 POC 報告，通常會被歸類為「有趣但未ready」，然後被無限期擱置。
ADWire 編輯團隊
ADWire Agency Limited
文章由 ADWire 團隊撰寫及審閱。團隊負責軟件開發、AI 應用與工作流程自動化、SEO／GEO 及數碼營銷項目，內容取材自實際項目經驗及公開的官方資料。
- 軟件及系統開發
- AI 應用及流程自動化
- SEO 及 GEO 搜尋優化
- 數碼營銷及成效量度
