AI 系統做完了然後呢？從 UAT 到 Rollout 的導入實戰紀錄
跨語言社群聲量分析系統的 pipeline 跑通了、報告產出了、品質也驗證了。然後呢？大部分 AI 專案的文章停在這裡，但真正的企業 AI 導入，做完系統才是開始。這篇記錄系統從「我跑通了」到「規劃讓團隊用起來」的過程 — UAT 發現了什麼、不通過的項目怎麼處理、Rollout 怎麼分階段、怎麼衡量有沒有人真的在用。
UAT：不是測 Bug，是測「有沒有用」
系統跑通後，我自己就是第一個 UAT 使用者。我的角色是品牌負責人，測試的不是功能有沒有 bug，而是一個更根本的問題：這份報告能不能幫我做決策？
UAT 結果：
| 測試項目 | 結果 | 說明 |
|---|---|---|
| 社群媒體資料覆蓋率 | ❌ 不通過 | 僅 6 則可信資料，樣本不足以做分析 |
| 商店評論蒐集 | ✅ 通過 | iOS 50 則 + Android 50 則，技術穩定 |
| 產品資訊網站蒐集 | ❌ 不通過 | 有效僅 1 則，93.3% 為網站內容誤抓 |
| 水軍過濾機制 | ✅ 通過 | 24% 過濾率，短評灌水有效識別 |
| 平台差異分析 | ✅ 通過 | 揭露 iOS 負面率 65.2% vs Android 48.7%，有決策價值 |
| 洞察品質 | ⚠️ 有條件通過 | 分析深度足夠，但受限於樣本量，結論代表性不足 |
| 行動建議可用性 | ✅ 通過 | 三條建議有數據支撐，可直接用於策略調整 |
7 個測試項目，4 個通過、1 個有條件通過、2 個不通過。如果這是一個 Go/No-Go 決策，答案是「有條件 Go」— 核心能力驗證了，但資料來源有缺口。
關鍵發現有三個：
分析層和洞察層的品質已驗證。給它足夠的資料，它能產出有價值的報告。這是最重要的結論 — 系統的核心能力是成立的。
瓶頸在蒐集層。社群媒體的搜尋 API 有結構性限制（每次最多 10 則），產品資訊網站的爬蟲需要優化過濾邏輯。這些是已知問題，有明確的解決路徑。
商店評論有先天負面偏差。會去寫評論的多半是不滿的人，55.4% 的負面率不能直接代表全體用戶的態度。這不是系統問題，但需要在報告中標註，並用其他來源平衡。
UAT 的真正價值：如果沒有做這一步，我可能會以為系統已經完成了。UAT 讓我在「覺得做完了」和「真的能用」之間看到了差距。
UAT 之後的迭代決策
不通過的項目不是放著不管，每一個都需要判斷：根因是什麼、怎麼修、什麼時候修。
社群媒體資料量不足。診斷根因：搜尋 API 的結構性限制，不是搜尋策略問題（前一篇已詳述）。研究業界做法後確認：專業工具靠官方 API（$200-5,000/月）或自建爬蟲基礎設施。決策：蒐集層是「buy」的問題，分析層才是「build」的問題。MVP 階段先用現有來源驗證分析層價值，Phase 2 爭取預算升級資料來源。
產品資訊網站雜訊率高。根因：爬蟲把 HTML 結構元素當成評論內容。決策：優化爬蟲的過濾邏輯，或在洞察層降低這個來源的權重。這是工程問題，修復成本低。
商店評論負面偏差。這是資料特性，不是系統問題。決策：報告中明確標註「商店評論有先天負面偏差」，後續版本加入其他來源（深度評測網站、用戶社群）平衡觀點。
Rollout 計畫：怎麼從「我在用」變成「團隊在用」
UAT 驗證了系統的核心價值，但「我自己能用」跟「團隊能用」是兩回事。Rollout 分三個階段，每個階段都有明確的前提和成功標準。
Phase 1：個人驗證（現階段）
使用者只有我自己。每次需要市場情報時手動跑 pipeline，成本 $0（訂閱制內）。
成功標準：至少 1 次基於報告調整宣傳策略。不是「報告好不好看」，而是「有沒有真的改變我的決策」。這個標準看起來很低，但它驗證的是最根本的問題：這份報告有沒有決策價值。
Phase 2：團隊導入
前提：Phase 1 驗證通過。
使用者擴展到同產品線的其他成員 — 當地同事、主管。需要準備的東西：
- 操作 SOP（怎麼跑 pipeline、怎麼看報告）
- 配置修改教學（怎麼切換競品、調整關鍵字）
- 報告解讀指南（各指標代表什麼、行動建議怎麼用）
成功標準：團隊成員能獨立操作並產出報告。
關鍵挑戰：使用者不懂技術。操作門檻要降到最低 — 理想情況是一個指令就能跑完整個 pipeline，報告自動產出到固定位置。
Phase 3：跨產品線擴展
前提：Phase 2 至少一個產品線穩定運作。
使用者擴展到公司其他產品線的品牌團隊。這個階段需要的投入明顯增加：
- 採購專業資料來源（解決社群媒體資料量問題，預算 $200-500/月）
- 配置範本庫（不同產業/產品的預設配置）
- 可能需要簡易
成功標準：2 個以上產品線在用，每月產出報告。
Adoption Metrics：怎麼衡量「有沒有人在用」
系統有沒有在跑不重要，重要的是有沒有改變人的行為。我定了五個指標：
| 指標 | 衡量方式 | Phase 1 目標 | Phase 2 目標 |
|---|---|---|---|
| 使用頻率 | pipeline 執行次數/月 | ≥ 2 次 | ≥ 4 次 |
| 決策採納率 | 行動建議被實際採用的比例 | ≥ 1 條/次 | ≥ 50% |
| 人力節省 | 手動情蒐時間減少 | 每次省 2-3 小時 | 每週省 3-4 小時 |
| 情報覆蓋率 | 系統偵測 vs 事後才知道 | ≥ 50% | ≥ 80% |
| 決策速度 | 從「發生事情」到「做出反應」 | 從數天→當天 | 從數天→數小時 |
五個指標裡，最重要的是「決策採納率」。如果報告產出了但沒有人拿去做決策，那系統就是失敗的，不管技術多好、報告多漂亮。使用頻率和人力節省是效率指標，情報覆蓋率和決策速度是品質指標，但決策採納率才是唯一能證明「這個系統有存在價值」的指標。
操作文件：Phase 2 的前置作業
Phase 2 導入時需要準備五份操作文件：
- 快速入門指南 — 一頁紙，從安裝到跑出第一份報告
- 配置指南 — 怎麼加競品、改關鍵字、調整分析主題
- 報告解讀指南 — 各區塊代表什麼、數字怎麼看、行動建議怎麼用
- 常見問題 FAQ — 蒐集失敗怎麼辦、報告品質不好怎麼調、怎麼新增資料來源
- 異常處理 SOP — 某個來源掛了怎麼辦、水軍過濾率異常怎麼判斷
五份文件的共同原則：假設讀者不懂技術。不是寫給工程師的 API 文件，而是寫給品牌團隊的操作手冊。能截圖就截圖，能用「按這個按鈕」就不要說「執行這個指令」。
我的觀點
做完這個專案的 Rollout 規劃，我有一個很深的體會：做出 prototype 只是整個旅程的 30%，讓人用起來才是剩下的 70%。
回顧整個 Act 3 的旅程 — 需求拆解、架構設計、實測驗證、Rollout 規劃 — 技術開發只佔了其中一小部分。更多的時間花在：定義問題（什麼才是真正的痛點）、做 trade-off（什麼先做什麼不做）、診斷失敗（為什麼只有 6 則）、規劃落地（怎麼讓不懂技術的人用起來）。
這也是我對企業 AI 導入最大的觀察：大部分 AI 專案死在導入階段，不是死在技術階段。技術上能跑通的系統很多，但能改變使用者行為的很少。原因通常不是系統不好用，而是沒有人認真規劃「怎麼從 prototype 走到 production」。
四個從這個專案提煉出的通用原則：
UAT 不是上線前的最後一關，而是迭代的起點。很多 AI 專案把 UAT 當成打勾確認，但真正有價值的 UAT 是發現「你以為做完了但其實沒有的部分」。
Rollout 的成功不是看技術部署，是看行為改變。系統部署完成不等於導入成功。如果沒有人改變原本的工作方式，系統就是擺設。
分階段導入，先證明價值再擴展規模。不要一開始就想做全公司導入。先讓一個人用、證明有價值，再逐步擴展。每個階段都有成功標準，不通過就不進入下一階段。
操作門檻是 adoption 的最大敵人。對非技術使用者來說，command line 就是天花板。Phase 2 之後如果要擴展，降低操作門檻比增加功能更重要。
常見問題 FAQ
UAT 不通過的項目，系統還能上線嗎？
看哪些不通過。如果核心能力（分析、洞察、行動建議）驗證通過，但某些資料來源有問題，那是「有條件上線」— 先用可用的來源跑起來，同時排期修復不通過的項目。但如果是核心能力不通過（例如行動建議完全不可用），那就不該上線。UAT 的價值就是幫你做這個判斷。
Phase 1 的成功標準「至少 1 次基於報告調整策略」會不會太低？
不會。Phase 1 驗證的是「這份報告有沒有決策價值」這個根本問題。如果連一次都沒有被採納，代表系統產出的洞察跟實際決策需求脫節，需要回去重新理解需求。如果至少一次被採納了，代表方向對了，接下來的工作是提升品質和頻率。起步標準要低到「能明確判斷 go 或 no-go」，不需要一開始就追求完美。
企業內推 AI 工具，最常見的阻力是什麼？
不是「不好用」，是「沒有動機改變」。使用者已經有一套工作方式了（即使效率不高），要他換成新工具意味著學習成本和不確定性。解法不是做更好的功能，而是讓他親眼看到「用了之後省了多少時間」或「做出了之前做不出的決策」。所以 Phase 1 的個人驗證最重要 — 你需要一個成功案例去說服其他人。