越來越多企業嘗試將 AI 功能整合到既有產品中，但設計 AI 產品並非單純加入一個「智能生成」，從產品策略、使用者體驗，到後續商務團隊的營運成本，都是產品經理要考慮到的環節，這篇會記錄我在求職平台、電商開店系統、客服系統的 AI 產品設計心得。
一、產品策略：在導入 AI 之前必須思考的問題
⠀⠀
▍（一）為什麼要導入 AI？找到真正的價值主張
在決定為產品加入 AI 功能之前，通常會問到：「為什麼此功能要加入 AI？」，根據不同產業和產品定位，有以下幾種導入動機：求職平台：在使用者日常流程優化使用者體驗
- 功能簡述：以「AI 生成自傳」為例，原本求職者要自行撰寫 500 字自傳，導入 AI 後,只要點擊「AI 生成自傳」按鈕，系統就能根據學歷、工作經驗、技能等資訊，自動產出完整的自傳內容。
- 設計動機：創造行銷話題，吸引新用戶來體驗。
電商系統：在客戶既有痛點上，透過 AI 解決問題
- 功能簡述：以「AI 生成賣場規格」為例，上架人員原本需要人工勾選繁瑣的規格選項，包括產地、洗滌方式、試穿季節、容量、材質等多達數十個選項，導入 AI 後，只需點擊「AI 生成賣場規格」，AI 會根據商品名稱、商品分類、商品描述直接完成勾選。
- 設計動機：解決客戶痛點，優化商品上架流程，創造業務銷售話題。
客服系統：為了創造產品銷售亮點
- 功能簡述：以「AI 自動貼標」為例，客戶可以填寫標籤名稱和描述，讓 AI 根據對話紀錄貼上對應標籤。
- 設計動機：讓客戶能更針對對話內容進行分析。
💡 小結：
1. 每個 AI 功能不一定都是為了解決用戶痛點，有時會以銷售壓力、行銷話題為考量。
2. 但 PM 仍可以從每個場景找到可以運用 AI 並創造賣點的地方。
⠀⠀
▍（二）導入 AI 的核心問題：速度和準度
AI 套用到既有產品時，最常被挑戰的問題是能否為使用者「提高效率」，效率包含兩個維度：
- 速度考量：點擊生成後，AI 多快能返回結果？若超過 3 秒需要設計等待介面，讓使用者知道系統正在處理，或是使用進度條、動畫等視覺回饋。
- 準度考量：若使用者對於 AI 生成結果不滿意怎麼辦？是否需要提供編輯、重新生成等機制，或是提供 Prompt 介面讓使用者可以自訂生成風格。
這兩個問題將直接影響產品的「數據」：若速度太慢，可能滿意度不高、使用率不高；若準度不足，使用者會對 AI 失去信心，減少使用頻率。
💡 小結：
1. 速度和準度讓 QA 驗收難度提高，因為「我覺得準」不代表「客戶覺得準」。
2. 當技術遇到瓶頸，可以嘗試用其他 Workaround 方式解決。
⠀⠀
▍（三）AI 功能要追蹤哪些數據指標
導入 AI 功能後，如何衡量成效是關鍵，但初期在討論規劃時，不一定能直接以最高視角直接看到產品終局，因此以我過往經驗很常是在產品規劃過程中和工程團隊討論可行性時，才慢慢梳理哪些數據可以觀測。
數據指標可以分為三個層面：內部監控指標、客戶可見指標，以及商務推廣指標（以下數據為舉例，非真實數據）。
- 內部監控指標：API 穩定度（預期 95% 以上）、使用率（每月 10,000 次）
- 客戶可見指標：消費者滿意度（平均 80%）、關鍵字頻率（某關鍵字大約占比 10%）
- 商務推廣指標：AI 導單率（5 %）、工作加速比例（原本 10mins 變成 2mins）
上述指標並非都需要提供給使用者，像是：
- 只需內部監控的指標：每週數據變動等細節指標，客戶通常不在意這些波動，只要產品團隊定期監控使用狀況，發現異常時介入處理。
- 需要提供給客戶的指標：滿意度等關鍵指標，客戶需要定期檢查這些數據，確認是否要補充後台資料，幫助客戶主動管理和優化 AI 的表現。
⠀⠀
在 Sales-driven 的開發環境中，產品團隊和商務團隊的溝通尤為重要，現實情況往往是：
- 業務團隊的挑戰：無法保證功能是否會被買單，必須邊賣邊調整賣點，需要快速反應市場需求，但又不能過度承諾。
- 產品團隊的挑戰：沒有太多時間做深入的競品分析，無法在前期精準評估數據效益，只能邊做邊看有哪些數字可用，需要在有限的資源下快速和業務驗證市場反饋。
💡 小結：
1. 重要的不是一開始就找到最完美精準的指標，而是根據客戶反饋，持續梳理最需要的指標。
2. 列出指標要能對產品產生影響，不然就只是一個冰冷冷的數字。
⠀⠀
▍第一章小結
產品策略階段最重要的是釐清導入 AI 的真正目的，建立數據驅動的思維，並找到該功能的定位。
不論是優化使用者體驗、解決客戶痛點，還是創造銷售亮點，都需要清楚的指標來衡量成效。AI 產品的成功往往不在於技術本身有多先進，因為在現在 AI 時代，UI 套件技術已不再是一個壁壘，只要能串接 LLM，多數團隊都可以做出很接近的功能，因此產品價值在於能否解決使用者痛點，以及是否為公司創造商業價值 & 業績轉單。
⠀⠀
二、體驗設計：做功能之後遇到的挑戰
⠀⠀
▍（一）對話流程 vs. 套件流程：互動模式怎麼選
在設計 AI 產品時，最常遇到的關鍵決策是選擇「對話式流程（Chat）」還是「套件式流程（Flow）」。
是不是用 Chat 就比較彈性？其實不一定，以工作中實際遇到的客戶反饋像是：
- 「為什麼我這樣打 AI 沒反應？」、「我應該都有把 Prompt 寫好，為什麼 AI 生成仍這麼差」，客戶輸入的口語說法，和 AI 能完全理解的寫法常常有落差，導致需要教育客戶如何正確地與 AI 下 Prompt，這個溝通成本是一開始被低估的。
- 「我希望 AI 推薦隱眼前，先詢問客戶要日拋/月拋、顏色、度數」，客戶想要很客製化的對話流程，卻不知從何下手，Chat 模式的彈性反而成為設定上的負擔，需要大量的嘗試和調整，才能達到理想效果。
⠀⠀
這些問題的根源，在於 Chat 和 Flow 兩種模式有著本質上的差異：
Chat（對話式流程）的特性：
- 每次都產生不同結果，讓用戶有不同預期（模糊產出）
- 適合需要創意和彈性的場景，用戶會很頻繁使用此功能，優點是靈活
Flow（套件式流程）的特性：
- 結構化流程，預期產出固定結果（清晰產出）
- 適合一致性的場景，用戶期望設定完就減少修改次數，優點是穩定
⠀⠀
在具體應用上，兩種模式各有其適用場景：
Chat 適合的場景：
- 腳本情境：描述當消費者有某意圖時,就回覆相關文字
- 對話風格：描述 AI Agent 回覆的語氣和風格
- 摘要風格：描述 AI Agent 總結對話的方式和重點
- 自動貼標：當符合某意圖就自動貼上相應標籤
- 文字轉換：用一段自然語言直接建立某個折扣活動
Flow 適合的場景：
- 歡迎訊息：設定一段固定的歡迎語
- 規則流程：收到特定關鍵字就觸發指定文字回覆
- 數據報表：提供固定的篩選器和視圖
- 知識管理：上傳和管理 FAQ 的位置
💡 小結：
1. 產品目標要能解決痛點，Chat 或 Flow 都僅是手段，而非目的。
2. 重要的是根據實際使用場景，設計最適合的操作流程。
⠀⠀
▍（二）貼齊前線與產品開發：降低導入成本
在實際產品設計中，我發現單純提供 Chat 或 Flow 的選擇是不夠的。真正的挑戰在於如何降低使用門檻，讓客戶能夠快速上手。
產品設計想要最大彈性，但前線客戶導入想要 SOP 標準化，因此「如何讓 AM/CS 團隊能夠有效地引導客戶使用」，這個問題不僅影響到導入效率，也會影響未來客戶願不願意續約。
⠀⠀
內部協作面臨的核心痛點：
- BD 銷售後，如何更快交接給 AM/CS 進行導入？特別是 AI 功能的設定
- AI 功能究竟能否解決客戶很客製化的情境
⠀⠀
為了解決這個問題，需要建立一套清晰的跨組協作流程：
PM 的核心目標：
- 確保 BD/AM/CS 對於產品的理解都一致
- 避免「業務賣一套，產品做一套客製化」的困境
PM 的具體做法：
- [做法一：功能預告機制]：設計稿（Prototype）完成後，PM 內部進行產品說明會，預告下個月的功能操作流程，並讓 BD 拿著設計稿去向客戶 Demo Pitch，確認業務銷售出去的產品和場景是在產品規劃中的。
- [做法二：框架範圍定義]：明確事前定義每項功能支援什麼與不支援什麼，用清楚的文件列出功能邊界，讓業務知道每項功能的極限和邊界值。
上述會運用到「PR FAQ」的概念（PR 新聞稿加上 FAQ 常見問題集），讓內部可以提前知道未來會有哪些功能上線，減少簽約後的失望和投訴。
💡 小結：
1. AI 產品更看重產品團隊和商務團隊的資訊同步，讓雙方知道 AI 的限制。
2. PM 一邊規劃一邊擴充賣點，Sales 一邊銷售一邊修正賣點。
⠀⠀
▍（三）處理機率性失敗：AI 產品的獨特挑戰
AI 產品與傳統軟體產品最大的差異在於機率性和不確定性，這種特性讓產品設計都需要多想各種 Edge Case，以目前經手過的 AI 功能，大致上都會有以下狀況：
使用者常會抱怨：
- 求職平台：「AI 生成自傳的這句話有幻覺，履歷的工作經驗不是這樣寫」
- 電商系統：「為什麼相似題目，AI 每次的答對率都不同」
- 客服系統：「我覺得 AI 現在回答很冷冰冰，能不能活潑一點」
💡 小結：
1. AI 產品是將命脈依附在 LLM 身上，因此技術許可的話要為自己留備案，例如多串好幾間 LLM。
2. AI 產品需要考量更多機率、Token 成本、錯誤率等問題。
⠀⠀
▍第二章小結
在規劃 AI 產品時，因為有很多不確定性，因此自己總結出以下心得：
- 輕量設計：不要初次就過度設計、過度開發，因為初期無法窮舉所有需求
- 體驗優化：可以善用固定規則，繞過技術限制
- 弱化數據：規劃圖表功能，要考慮到客戶看到數字的反應
- 強化流程：藉由流程讓客戶好設定功能，減少真人教學
⠀⠀
三、PM 與 Designer 的協作模式
⠀⠀
▍（一）團隊組成與協作方式的轉變
在 AI 產品開發的過程中，PM 和 Designer 之間的協作模式正在發生變化，以我目前公司的開發流程，大致是：
- 業務提需求和情境，PM 開始收斂範圍
- PM 開始生成 Protoype (Lovable/Claude)，開始和 Designer / RD 討論可行性（技術評估會議）
- PM 收斂功能範圍，逐步調整 Prototype，看著 Prototype 寫 PRD
- Designer 針對 PRD + Prototype，定案 Final Prototype
- PM 和 Designer 針對 Final Prototype 確認終版流程，並調整 PRD（設計定案會議）
- PM 向 RD 說明最終功能需求（Planning 會議）
⠀⠀
和 Designer 討論的內容，大致仍是以下題目：
- 想法來源：這個樣式來源是參考哪個競品？其他競品都怎麼做？
- 長期迭代：若未來有 OO 迭代，目前的設計是否好迭代？為什麼要重改？
- 設計規範：其他頁面是否套用相同樣式和規範？
- 開發便利：是否有過度設計問題？能否再為開發減少工時？能否減少彈窗或頁面？
⠀⠀
四、總結
雖然目前參與到的 AI 產品仍偏向 SaaS 功能，且比較沒有碰到 LLM 模型設計，但發現在規劃 AI 產品的過程仍遇到很多過往軟體產品沒碰過的問題，最明顯的像是：
- 成本考量：傳統軟體產品可以無限制使用，頂多 API 呼叫速度限制，但 AI 產品有 Token 收費議題。
- 機率問題：傳統軟體產品可以知道產出結果，AI 則無法 100% 知道，充滿各種黑盒子參數。
這篇僅先記錄我在求職平台、電商系統、客服系統的 AI 產品工作心得，不一定仍涵蓋所有產業。
⠀⠀
如對這系列文章有興趣可以再觀看：
