# B2B 服務的 AI Agent 產品設計原則 - 李昆謀

{%hackmd o8oUosN0QnqMSkF1_6kH7g %}

#### 📚 議程介紹

{%preview https://webconf.tw/agenda/1 %}

###### ▼▼▼ 開始筆記 ▼▼▼

講者有 podcast: https://podcasts.apple.com/tw/podcast/%E6%90%9E%E4%BB%80%E9%BA%BC%E9%AC%BC/id1806939706

> 四個公司內部成功或失敗的故事，給大家啟示或火花

從「取代」到「賦能」的 AI 開發思維
演講者強調，AI 開發不應只是想著用 AI 取代現有功能（Replacement），而應該思考如何透過 AI 增強現有能力（Enhancement）或解決過去無法解決的商業問題。

Embedding model: text to vector

把一堆字弄成向量會變成一個向量空間
兩個相似的向量空間（例如兩篇暗黑破壞神的文章）
就可以做搜尋（用相似度來找）

於是就重新設計了商品搜尋

LLM 的超強語意理解

像錯字、標點等等都可以涵蓋
其實就是 RAG 這個東西

embedding的缺陷：模糊擴展很強，但精準度不高

例如顏色標籤不能忽略

所以後來改成 hybrid
新的結果就可以是 精準＋擴展

人機協作
背鍋的人很重要 (HPU, Human Process Unit) x CPU x 檢核幫手(GPU)

## Ch1 - 傳統搜尋變成AI搜尋，後來發現其實要hybrid: replacement -> enchancement
想介入，干預排序 （HPU）有需商業需求、規則 → 老闆想要看到最前面的就要在最前面

搜尋引擎的進化：從向量模型到混合搜尋 (Search)
起點與挑戰： 團隊最初使用 Embedding Model（向量模型） 來解決傳統關鍵字搜尋無法處理語意、錯字或空格的問題。雖然解決了語意理解（例如把文字轉為向量找相似度），但卻產生了精準度問題。

案例： 搜尋「某品牌的白色托特包」，AI 可能會因為「托特包」的向量特徵太強，而找出一堆藍色或紅色的托特包，忽略了「白色」或「品牌」的限定。

解決方案： 回歸 Hybrid（混合模式）。結合傳統的關鍵字斷詞（處理精準規格，如顏色、品牌）與 AI 向量搜尋（處理語意模糊），並加上 Re-ranking（重新排序）機制，才能達到最佳搜尋體驗。

## Ch2 - 與其生成，不如檢核

使用手冊 v.s. AI 後台幫手

輸入摘要 -> AI 解析 -> AI 生成 -> HPU 送出

context: Domain knowledge
活動符合品牌規範？
活動重複？
活動會使商品低於毛利？

因為折扣順序太複雜
結果客戶覺得：與其生成，不如檢核

「如果你想解決的問題，不是客戶想解決的問題，
那你就是那個問題」

行銷活動設定：從填表單到 AI Agent (Copilot)
痛點： 電商後台的行銷活動設定（如滿額折、紅配綠）非常複雜，欄位繁多，使用者操作困難。

AI 應用： 開發 AI Agent 讓使用者用「自然語言」說出想要的活動（如「我要做雙11活動...」），由 AI 自動填寫複雜的後台表單。

發現的問題： 使用者的指令通常缺乏 Context（上下文/情境），導致 AI 容易產生幻覺或填錯。

架構優化：

設計 Multi-Agent 架構：包含負責生成的 Composer 和負責檢查邏輯的 Auditor。

Human-in-the-loop：AI 填完表單後，必須由人類最終確認（Submit），確保活動設定無誤，這就是 Copilot 的概念（AI 輔助，人來決策）。

## Ch3 - AI 客服

最一開始希望由 AI 取代客服

消費者 -> 客服
↓
消費者 -> AI Agent

User -> LLM -> 品牌 KM vector DB + MCP + ...
會發生一些災難，因為客戶可能會寫程式什麼的

evaluation
評估之前的對話很重要，幫助改善原本的流程

消費者 -> AI Agent -> 客服

成本考量

那如果是這樣呢（用 AI 輔助客服 客服 Copilot）：
消費者 -> 客服 -> AI Agent

Agent 沒辦法解決所有的客服，沒有減少成本
客服＋人類的成本 會多於本來純用人類的費用 無法說服老闆使用
客服 Agent -> 客服 Copilot
AI 檢核人類客服
> [name=DanSnow] 人類要被 AI 奴役了

理解退貨理由 推薦提供優惠卷等銷售方式

客服系統：從成本中心轉為獲利中心 (CS Copilot)
迷思與轉變： 許多人想用 AI 完全取代客服以節省成本，但風險極高（AI 回答錯誤會導致客訴）。

策略演進：

Copilot 模式： AI 先作為客服人員的助手，提示回答建議，由真人客服過濾後發送。

稽核 (Audit)： 用 AI 來檢查真人客服的回答品質。

轉守為攻 (Sales)： 這是最大的商業價值突破。當消費者詢問「訂單到哪了？」這類例行問題時，AI 可以順便偵測庫存並建議客服：「這雙鞋還有庫存，要不要推薦他買襪子有折扣？」。

商業價值： 透過 AI 將客服從單純的「解決問題（成本中心）」轉變為「創造銷售機會（獲利中心）」。即使 AI 開發有成本，但帶來的額外營收遠大於節省的人力成本。

## Ch4 - 如何與 AI 協作撰寫 PRD
### <年中>
與 AI 協作出 PRD -> 讓 AI 看得懂

結果：模糊的 PRD 產出模糊的產出

### <年底>
從 PRD 到 Product Requirement Prototyping （PRP）
=> 由 PM 以 AI 工具產生一個 prototype

結論：PM 要會 Vibe Coding 嗎？ Yes

開發流程變革：AI 驅動的開發 (AI Driven Development)
傳統 vs. 新流程： 過去是 PM 寫規格書 (PRD) -> 工程師寫 Code。現在提倡 PM 使用 AI 工具（如 Claude, NotebookLM）直接生成 PRP (Product Requirement Prototype)。

V-Model 的應用：

利用 AI 快速建立原型（Prototype），在開發初期就驗證需求是否正確（左側驗證），而非等到開發完才測試。

這讓 PM 不再只是寫文件，而是變成「Prototyping Master」，能更精準地與工程師溝通需求，減少開發後的修改成本。

### 新工作方法：Agile Team / Scrum 的初衷

> 任何人都可以在 Scrum Team 中解任務。

透過 AI 讓這個初衷可以實踐，角色之間的界線變得模糊。

[V Model](https://www.wikiwand.com/en/articles/V-model_(software_development))


這邊有談到同樣的議題:
https://www.facebook.com/share/p/1BNHV2EVSV/

問對問題 > 解決問題

## 結語
> Enhancement > Replacement > Revoliution

最後提到，開發 AI 產品時，不應只關注技術模型（Model），更要關注 Context（情境） 與 商業價值。與其單純追求 AI 自動化，不如設計出能與人類協作（Copilot）、能為商業帶來增值（如客服轉銷售）的系統，這才是 AI 產品落地的關鍵。

## Q&A

1. PM 做完 PRP 之後還要寫文件跟工程師對齊嗎？
Ans: 透過 daily sync 對齊想像，減少文件的撰寫。

2. 如和在公司內導入 AI ？提供 AI 服務時該如何計價與收費？
Ans：
- 以鼓勵為主，撥預算給員工鼓勵大家使用。觀察大家的使用狀況，公司還是會有少部分工程師不使用 AI ：）
- 不是以 token 計價，而是以客戶能理解的價格去計算，如果超過會額外收費。以 AI 客服為例，平均一個問題 10 元（成本保密，有些毛利率空間）。

3. AI 的服務該如何更精準？該如何做 evaluation？
Ans：不能完全的靠 LLM，還有很多工人智慧貼標的部分，才可以讓回覆跟商業邏輯更加的精準。

---
###### 聊天區

議程首頁的方塊好煩
> [name=DanSnow] 真的，剛才正好在截圖，結果看到時，我還以為是我還在截圖模式

=> +1
=> 方塊不見了

{%preview https://www.youtube.com/watch?v=m8NAlDOCG6g %}

chatbot沒弄好就變成免費chatgpt XD
> [name=DanSnow] 這就是 gpt4free 的來源

我打客服，看到是機器人的時候，常常第一句話都是「請幫我接真人客服...」
=>我也是XDD

能不找真人就不找真人的我（茶
> 跟人溝通是最後選項
>>電話語音例外 不然轉來轉去還找不到選項
>>主流電話語音機器人的回應流程根本是製造痛苦，所以直接找真人，不聽機器人跳針最有效率 XD

antigravity 出來真的pm都可以自己先做產品看看了

ＡＩ可以大福降低問問題的成本啊

有人有拍到剛剛水淹上來的那張ppt嗎XD
有(感謝!!看到了!!)

問對問題 > 解決問題
忍不住想補 ~~解決提出問題的人~~ XDD 萬解～

再怎麼樣還是需要工人智慧的存在

請問講者有提供簡報連結嗎？