李昆謀：把 AI 融入零售業的日常流程

1. 一句話總結

李昆謀用91APP內部「商品上架自動填規格」這個真實案例，示範了正確率與覆蓋率如何互相拉扯，最後歸納出人腦、規則引擎、AI代理三方分工的公式，並把同一套邏輯套用到軟體開發的PRD與團隊組織上。

2. 重點筆記

商品上架：一個被低估的重複性工作

投影片先畫出零售業最基本的一條路徑：商品進到商品主檔，再產出對應各通路（品牌官網、其他通路）的賣場檔，最後才變成消費者看到的商品頁。接著投影片給出一組算式：一百個新品、三十個要填的欄位、五個通路，相乘等於一萬五千個要填的欄位組合。如果每個欄位平均要花十秒鐘填，一萬五千乘以十等於十五萬秒，換算下來是兩千五百分鐘、四十一小時、大約五個工作天。投影片標題直接寫「週週有新品」，暗示這個五工作天的作業量不是一次性的，是每週都要重來一次的常態負擔，也是投影片稱之為「大量人工作業」的原因。

91APP內部把處理這件事的系統稱作IMS，投影片上寫的是「多平台管理系統」與「多平台商品訂單管理系統」兩種說法，功能是把品牌官網（Brand.com）與其他通路的商品資料集中管理、批次匯入或單筆新增。投影片特別標出一個痛點：新增商品規格時「很多欄位要填，還有很多選項」，操作流程要先選「有選項」，再手動填入每個規格的選項內容，相當繁瑣。

神奇的小按鈕，以及第一次踩坑

91APP在賣場管理介面上加了一顆按鈕，投影片稱之為「神奇的小按鈕」，並附了一張後台截圖：查詢結果列表上方多了一顆「自動生成賣場規格」的按鈕。背後的System Prompt寫著：「我需要你從商品敘述，從規格範例中，推論出規格選項。請按照我提供的賣場資訊，以及商品規格要求說明，給我合適的商品規格選項。」輸入是商品主檔，中間經過一個Agent，輸出是賣場檔。

投影片把整個優化過程畫成一個循環圖：商品主檔進到Agent、Agent產出賣場檔、賣場檔拿去跟人工整理好的「正確賣場檔」比對，跑一段評估程式，得出評估結果，再回頭調整Prompt，如此反覆，圖上標題寫「實習生訓練！」，意思是把調Prompt這件事當成訓練一個新人在做。這一頁還丟出一句很有份量的標語：「數據集就是PRD」，把原本軟體工程裡「產品需求文件」的角色，換成了一份標準答案數據集。

第一輪評估結果的長條圖上，總數一百分之下，覆蓋率達到九十八，正確率卻只有四十五。投影片接著秀出一張像是差異比對表的截圖，標題寫「共有七千五百處不同呦」，意思是AI產出的賣場檔跟正確答案之間，有七千五百個地方兜不起來。換句話說，AI幾乎每個規格都給了答案（覆蓋率高），但答對的沒有一半（正確率低）。

AI 到底該不該管：加兩條規則換一次翻轉

投影片用一張「AI do NOT help」的流程圖點出問題：即便AI已經產出賣場檔，中間還是要插入一個人工「檢查賣場檔」的步驟才能上線，等於AI的產出完全沒有省到人力，因為錯誤率太高、每一筆都要重新檢查。

解法是替Prompt加兩條規則：「沒信心的不要答」「沒選項的不要答」。加完之後的評估結果二，正確率從四十五跳到九十，覆蓋率則從九十八掉到五十。投影片用「一半AI寫、一半人寫」來形容這個狀態：AI只回答有把握的一半，放棄回答的另一半留給人工補完。流程圖也跟著改成「AI與人協作」：商品主檔先給AI產生賣場檔，人再補充賣場檔，兩塊各佔百分之五十。

投影片接著問「如何再提高正確率」，又補上第三條規則：「回答請寫理由」。這裡插了一張很生活化的對照截圖：同一道數學梯形相似題丟給ChatGPT4.5，模型一開始給出一個答案，經過使用者追問後修正成另一個答案，投影片用這張圖說明AI給答案時如果附上理由，人在覆核的時候可以直接針對理由去挑錯，而不必每一題都從頭重算。下方接著秀出一張實際的評分表截圖，欄位包括規格名稱、最終分數、討論狀態、AI給的理由、以及PO確認欄——性別、紡織物、版型、鞋面材質、顏色等好幾個規格都被標成「討論」，理由欄寫著像是「商品描述中提到寬鬆版型，故選擇偏大」這類AI自己給的推論過程，PO確認欄則寫「原始資料沒有答案就剔除」之類的裁示。

投影片最後用一張91APP後台的規格選擇介面截圖，配上一件粉色運動套裝與一雙皮革工作靴的商品圖，具體示範AI要作答的規格長什麼樣子：像「鞋面材質」要在牛皮、羊皮、豚皮、人造皮革等一長串選項裡挑，商品描述寫的是「鞋面採用優質防水皮革製成，含有至少百分之五十再生塑膠的ReBOTL織物內裡」，AI必須從這段文字推論出正確的材質選項。

三方協作定案：Rule Engine、AI Agent、Human

最後的解法定案是三方分工：客戶規則套用（Rule Engine）先過濾掉有明確規則可判斷的部分，AI Agent負責產生賣場檔，人（Human）負責檢查與補充。投影片配的長條圖把總量一百拆成規則引擎四十、AI代理五十、人工十，也就是說最後真正需要人工介入的比例壓到了一成。這一頁的結尾用了一條等式收束整場前半段：人腦、規則引擎、AI代理，分別對應人腦、CPU、GPU三種運算資源的分工。

軟體業也是同一題：AI Driven Development 與 PRD 該寫給誰看

投影片接著把場景從零售業切到軟體業本身，標題故意把「用AI開發產品」跟「開發AI產品」兩句話對調著放，暗示這兩件事其實是一體兩面。軟體業的日常流程被畫成：需求（Requirement）先變成PRD（Product Requirements Document），PRD再拆成多個Story，Story再變成Code，最後組合成Product。投影片用同一張圖反覆變形：先是「大量人工作業」版本，每個節點都站著一個人；接著是「AI Can Help」的提問版本；再來是「Vibe coding」的極簡版本，直接從AI跳到Function/Product，沒有中間產物。

投影片用兩組對照圖問了一個問題：「寫給誰看的PRD？」左邊畫PO直接用Prompt對AI下指令做出功能，右邊畫PO寫PRD交給RD（工程師）做出功能。意思是如果PRD最終是要餵給AI讀，那麼PRD的寫法可能得跟著改變。投影片接著端出一張NFR（Non-Function Requirements，非功能性需求）表，列出六種類型與對應的量化說明：性能要求每秒可處理一千筆請求；可用性要求系統每年上線時間達百分之九十九點九；安全性要求使用HTTPS並需登入驗證；可維護性要求程式碼單元測試覆蓋率百分之八十以上；可擴展性要求系統能應對使用者數量十倍增長；容錯性要求任一服務失效不得導致整體停擺。投影片標題把這種規格要求歸類為「Enterprise-Level Software」等級的需求，意思是這些非功能性需求也得寫進一份「AI Readable」的PRD裡，才能讓AI在規劃階段就把這些限制考慮進去。

完整版的AI Driven Development流程圖分成規劃階段與開發階段：規劃階段由PO、UX、TL三個角色共同產出PRD與Story；開發階段則把Story分派給B2E、F2E、QA（投影片只寫縮寫，沒有進一步展開全名），最後合併成Release。

300 人團隊配 300 個 AI 助手

最後一段回到組織規模。投影片畫出一個三百人開發團隊的組織圖，分成產品線部門甲乙丙，每個部門底下都有PM、UX、RD、QA的分工。下一張投影片把同一張組織圖複製一份，變成「三百人開發團隊加三百個AI assistants」，也就是每一個人力配一個AI助手。緊接著的算式是：二十美元乘以三百，等於六千美元，暗示每個AI assistant的訂閱成本抓二十美元一個月，三百個相加就是一個月六千美元的整體投入。

投影片接著把組織拆得更細，畫出二十二個feature team，每隊七到十五人，每隊底下再細分RD1、RD2、QA、UX、PO等專業領域小組。最後一段用「Agile」收尾：先畫出Agile作為「把人連起來一起工作的方法」，再畫出現實中「AI Agile」的樣子——一堆加號疊在Agile旁邊，暗示現在的做法是把很多零散的AI工具硬塞進原本的敏捷流程裡，並不是真正重新設計過的方法。投影片把這個現況跟未來的理想版本並列：未來的新日常應該是「軟體工業化（機器生產，人類監管）」，同一張Agile產出Function/Product的圖，換了一個標題。

3. 關鍵數據與案例

• 商品上架基礎案例：一百個新品乘以三十個欄位乘以五個通路，等於一萬五千個要填的欄位組合，且投影片標明是「週週有新品」的常態工作量。
• 人工填寫時間換算：一萬五千個欄位乘以每個十秒，等於十五萬秒，換算為兩千五百分鐘、四十一小時、約五個工作天（講者自述換算，無外部來源佐證）。
• 第一版評估結果（未加規則的Prompt）：正確率百分之四十五，覆蓋率百分之九十八，差異數共七千五百處。
• 加入「沒信心不要答、沒選項不要答」兩條規則後的評估結果：正確率百分之九十，覆蓋率降到百分之五十，AI與人各分擔百分之五十的產出量。
• 最終三方分工比例：規則引擎佔四十、AI代理佔五十、人工僅佔十（以總量一百為基準）。
• NFR六項具體門檻：每秒處理一千筆請求、系統年可用性百分之九十九點九、單元測試覆蓋率百分之八十以上、使用者數量十倍增長的可擴展性要求。
• 組織規模案例：三百人開發團隊配三百個AI assistant，估算成本為每個二十美元乘以三百，等於每月六千美元（講者自述，無外部來源佐證）；團隊進一步拆成二十二個feature team，每隊七到十五人。

4. 金句

以下幾句都是投影片上直接出現的標語或關鍵句，不是現場口白：

• 「數據集就是PRD」
• 「AI do "NOT" help」
• 「一半AI寫／一半人寫」
• 「人腦 X CPU X GPU」（對應人腦、規則引擎、AI代理三方分工的等式）
• 「我們都想成為名詞，卻很少在動詞上下功夫」
• 「把未來式變成進行式」（查證後可見，李昆謀本人寫的參加心得把這句話原封不動當成整篇文章的結尾：「把未來式變成進行式，唯有進行式，AI才會變成你的新日常」，確認這不是投影片單獨的標語，是他自己反覆強調的結論，happylee.blog）

5. 提到的工具與名詞

• IMS：投影片上稱作「多平台管理系統」／「多平台商品訂單管理系統」，91APP內部用來集中管理品牌官網與其他通路商品資料的系統，屬於91APP內部產品名稱。
• Agent：投影片中泛指負責從商品主檔推論規格選項、產出賣場檔的AI流程，沒有進一步指名底層採用哪個模型或框架。
• Rule Engine（規則引擎）：三方分工中負責先行套用客戶既定規則、篩掉明確可判斷案例的元件。
• PRD（Product Requirements Document，產品需求文件）：投影片把它重新定義為「數據集」，也延伸出「AI Readable的PRD」概念。
• NFR（Non-Function Requirements，非功能性需求）：投影片列出性能、可用性、安全性、可維護性、可擴展性、容錯性六類。
• Vibe coding：投影片用來指稱跳過PRD與Story、直接由AI產出功能的極簡開發模式。
• B2E／F2E：投影片開發階段流程圖上的兩個節點縮寫，投影片沒有展開全名，推測對應後端與前端工程產出（本判斷推測，無外部來源佐證）。

6. 延伸觀察

整場最有意思的地方，是正確率跟覆蓋率那組長條圖來回翻轉三次：從覆蓋率九十八、正確率四十五，翻成正確率九十、覆蓋率五十，最後才靠Rule Engine把覆蓋率也拉回來。很多做AI功能的人容易只盯著「AI能不能回答」，卻沒意識到「AI敢回答」跟「AI答對」是兩個要分開衡量的指標，這點跟開發者年會另一場分享（吳剛志那場）用的「正確率、覆蓋率」定義幾乎一模一樣，兩場很可能是同一個91APP內部案例，只是分別從產品長與架構師的角度各講了一次。

軟體業那一段把「用AI開發產品」跟「開發AI產品」倒過來寫的標題設計很有巧思，但NFR那頁的「AI Readable PRD」概念講得有點快，投影片沒有具體示範一份「AI Readable」的PRD實際長什麼樣，如果只看投影片，這塊比較像是提出問題而不是給答案。三百人配三百個AI assistant、每月六千美元那組數字也偏向宣示性質，沒有說明這些assistant實際承擔了多少工作量、跟前面商品上架案例裡「四十比五十比十」的分工比例是否吻合，這部分標成講者自述、留待日後驗證。

91APP在這次年會的能見度其實不小：開發者年會那天91APP就有吳剛志（Andrew）跟陳俊毅（Levi）兩位講者（陳俊毅那場內容由其他筆記整理，這裡不重複寫），加上李昆謀自己這場，兩天合計三位91APP講者。查證後可見，李昆謀自己寫的參加心得也特別提到這件事，說看到「91APP團隊」被社群提及會特別開心（happylee.blog）。至於91APP是否為這次年會的正式贊助商，查無2025年官方公布的具名贊助商名單可以佐證，此處不做裁決。

7. 資料來源