當 AI 成為產品的一部分時，許多人——包括資深 BA——開始感到困惑：我在這個團隊裡做什麼？ AI 工程師撰寫提示詞，資料科學家建立模型，PO 優先排列待辦事項，PM 管理路線圖⋯⋯那 BA 在哪裡？
本文直接切入重點。
1. AI 產品團隊的角色地圖
首先，讓我們看看開發 AI 功能的團隊全貌：
| 角色 | 核心職責 | 決策範圍 |
|---|---|---|
| BA（業務分析師） | 發現問題、收集需求、撰寫驗收標準、評估解決方案 | 業務需求是否正確？ |
| PO（產品負責人） | 管理待辦清單、優先排列故事、在敏捷團隊中代表業務 | 哪個故事先做？ |
| PM（產品經理） | 產品策略、上市計劃、定價、採用 | 做什麼產品、給誰、為什麼？ |
| AI 工程師 | 設計 AI 流水線、撰寫系統提示詞、整合模型 | 哪個 AI 技術解決方案可行？ |
| ML 工程師 / 資料科學家 | 訓練模型、微調、評估技術指標 | 哪個模型更好？ |
2. AI 功能中 BA 的具體工作
建立前（探索階段）
- 訪談利益相關者，理解真正的問題——不只是聽功能需求
- 撰寫有數據支撐的問題陳述（不是「需要聊天機器人」，而是「首次解決率只有45%，低於目標25%」）
- 提問：這裡真的需要 AI 嗎？還是更簡單的規則型方案就夠了？
建立中（需求定義）
- 為 AI 功能撰寫使用者故事和驗收標準——包含邊緣情況和失敗模式
- 定義防護欄：AI 什麼時候可以回應，什麼時候需要升級給人工處理？
- 與 AI 工程師合作，了解模型的限制，從而撰寫切實可行的需求
上線後（評估）
- 對照原始業務假設評估 AI 功能
- 收集使用者回饋，整理成改善待辦清單
3. 最容易混淆的地方：BA vs PO
許多公司將 BA 和 PO 混用。但從本質上來說：
BA = 深入挖掘問題和需求的人——輸出是分析文件、詳細的使用者故事、驗收標準、資料對應和流程圖。
PO = 管理待辦清單和優先順序的人——輸出是優先排列好的產品待辦清單、衝刺目標和範圍決策。
在許多小型團隊中，一個人身兼兩職。在較大的團隊中，BA 負責深度分析，PO 負責交付優先排序。
4. BA 需要了解多少 AI 知識？
不需要訓練模型。不需要了解梯度下降。但必須知道：
- 幻覺是什麼，以及為什麼它對驗收標準很重要
- RAG vs 微調：各自何時使用，才能撰寫正確類型的需求
- 延遲與成本：AI 不是免費的——每個 token 都要花錢，影響流程設計
- 信心閾值：AI 在什麼程度上變得「不確定」，需要人工審核？
- 資料隱私：使用者輸入會被用來訓練嗎？
BA 不需要回答這些問題，但必須知道向技術團隊提出這些問題。
5. 總結：AI 時代 BA 應如何定位自己
AI 時代的 BA 保留了原有的核心——比團隊中任何人都更深入理解業務問題——並在此基礎上增加：
- 對 AI 能力和限制提出正確的問題
- 為 AI 功能撰寫驗收標準（不只是標準的 CRUD 功能）
- 從業務角度參與 AI 輸出品質評估
- 當 AI 犯錯或造成傷害時，成為保護使用者的人
這個角色不會消失——它正在升級進化。