陳俊毅：91APP AI-Driven Development

1. 一句話總結

91APP 用「PO 做知識萃取產生 PRD → RD 依 arc42 產出規格與程式碼 → QA 依 PRD 產生測試」這條 AI 協作管線，把一個 scrum team 的交付效率提升了三成，而且系統異常數量沒有跟著變差。

2. 重點筆記

講者背景

Levi 陳俊毅在 91APP 待了超過 11 年，目前是產品發展部資深經理，主要負責 SRE、Platform 跟 DBA 團隊。91APP 這家公司本身也是這次年會的贊助商之一。他一開場就先講清楚 91APP 內部用 AI 分成兩塊：一塊是這場要講的「用 AI 開發產品、改善流程與效率」，另一塊是「開發 AI 產品去協助零售業客戶提升網站營運效率」，後面那塊他直接預告是下一場由暱稱 Andrew 的講者接著分享——對照當天議程，下一位上台的正是 91APP 首席架構師吳剛志，這個綽號是議程表上看不到的小細節。

91APP 團隊怎麼長大的

91APP 的產品發展處分成「產品團隊」跟「中心事業群」：產品團隊依不同 domain 拆成多個 Scrum team，各自有 PO 跟 TL；中心事業群負責開發工具、優化流程，讓產品團隊跑得更快；當不同 Scrum team 之間需求排序打架，就拉到「One Team」做最終決策，確保整個部門方向一致。這套跑法他們磨了十年，團隊規模從最初大約 5 個人成長到現在大約 300 人（講者自述，無外部來源佐證）。過去這套模式的擴張邏輯很單純：要提升產能，多開一個 Scrum team 就能做到效率的「scale out」。

為什麼舊模式在 AI 時代卡關

過去他們做案子，找一個 Scrum team 進來、PO 跟 TL 在白板上把流程畫出來，大部分案子這樣跑得又快又順。但去年開始想導入 AI 的時候發現行不通——因為這些 domain 知識全部存在資深 PO 跟 TL 的腦子裡，很難被規模化擴展出去。這推動他們從 2024 年第四季開始找一套「AI 時代的新開發方法」，目標很明確：不是為了用 AI 而用 AI，而是要做到單一 Scrum team 的效率「scale up」——同時要提升速度或品質，效率是目的，AI 只是手段。

三階段策略

他們的策略拆成幾塊：第一階段先讓 PO、QA、RD 三個職能各自「單點突破」，訓練大家善用 AI 工具解決自己職能內的問題；接著透過 AI 跟流程把這些單點串接起來，形成 PRD → SPEC → CODE → TEST 的整合管線；最終目標是打造一條能持續流動的 AI-Driven 開發流程。

PO 這一端：從知識萃取到 PRD

過去的問題是 PO、RD 用 Slides 跟 Sheet 各寫各的，知識沒有有效累積、彼此斷裂。導入後，PO 開始把自己 domain 的知識持續累積到 Google Drive 上；有新專案啟動時，就透過 NotebookLM 做知識萃取，產生一份「Domain Brief」——一份針對這次專案量身打造的知識快照。這套流程不只加速專案本身，對新人 onboard 也很有用，新人遇到不熟的 domain 問題時，可以透過同一套流程快速搞懂產品脈絡。接著把 Domain Brief 加上 PRD Template、再加上專案相關的 input，PO 就跟 AI 一起協作、一步步調整出 PRD（Product Requirement Document）；PRD 完成後再拆解成一則則 User Story 交給 RD。

他特別強調 PRD Template 裡最關鍵的兩塊是「需求變化」跟「驗收準則」——要讓 AI 明確知道要改的東西是什麼、該怎麼改、又要怎麼驗收。整份 PRD Template 分成八大部分：一、專案說明（含專案背景、目標、主要功能、上線時程、預期成效）；二、功能調研；三、專案範圍；四、功能需求說明；五、技術架構說明；六、團隊與時程規劃；七、附錄；八、變更記錄。他也提醒，這份 PRD 不只是寫給 AI 看的，團隊之間互相溝通協作時，也都會直接拿這份文件當共同語言。

RD 這一端：從估時實驗到 SPEC 原則

推動教育訓練前，他們先讓 RD 對同一個練習題（寫一個 Console 版的剪刀、石頭、布、蜥蜴、史波克猜拳程式，要求單元測試覆蓋率 100%、加 RESTful API 與 API Spec、寫完整程式碼註解、並透過 Lint 工具把語法修到 100 分）估時。訓練前，大約七成的 RD 覺得要 4 到 6 小時才能完成；訓練後，四成以上的人兩小時內就能完成，七成以上的人能在 4 小時內完成。他們分析效率落差的根本原因有兩個：一是開發者對該程式語言或領域知識是否熟悉（他舉例有 RD 不熟 Rust 卻被指派用 Rust 寫作業，AI 生出來的程式碼他自己看不懂對錯、也沒辦法 debug，結果反而花更多時間）；二是 Prompt Engineering 的能力差異。

由此他們在 RD 內部發展出一套「SPEC 原則」（本身是 RD 的諧音梗，由 91APP iOS Team Lead Justin 提出）：Specific 問題要明確、避免模糊；Precise 語言要精準、不含糊；Explain 要補足背景與邏輯；Clarify 要列出限制與要求。他舉了一個加入購物車 API 的完整示範：Specific 講清楚要做一支 POST /api/cart/add 的 RESTful API；Precise 講清楚 input／output 的 JSON 結構、驗證邏輯（例如 productId／skuId 必須存在資料庫、quantity 不得小於 1 或超過庫存）、商業邏輯（同商品同 SKU 就累加數量、新商品就新增項目）；Explain 講清楚這支 API 是給前台商品頁「加入購物車」按鈕用的，購物車服務採分散式快取架構，要基於他們的 Redis-based Cart Service 操作資料結構；Clarify 講清楚不用處理促銷與優惠券邏輯、不用做登入驗證（假設已取得 userId）、商品資料異常時要回傳固定格式的錯誤訊息、要遵循 91APP 現行的 C# + .NET Core coding style，並可以參考特定既有檔案當結構範本。

arc42：借用一套開源架構文件模板

依循 SPEC 原則討論到後來，他們發現有一套現成的開源文件模板剛好符合需求，叫 arc42——官方模板原本有 12 個章節，用來詳細描述大型軟體專案該寫哪些文件。他們沒有全部照搬，挑了其中 6 個他們認為最需要的：一、簡介和目標（描述系統目標，說明各階段功能對應的 FR／NFR）；二、上下文和範圍（用 C4 Model 的 System Context diagram 說明系統層級的對外串接邏輯，以及 Container diagram 說明系統內各元件的串接狀況）；三、建構塊視圖（Swagger API Spec、DB Schema）；四、運行時視圖（用 Sequence Diagram 說明各 User Story 執行時系統怎麼運作，例如建立、更新、停用、註銷 API Key／Token 的流程）；五、設計決策；六、詞彙表。他半開玩笑地說，一開始有 RD 擔心寫這些文件反而更花時間，但這些文件本身也是跟 AI 協作生出來的——「用魔法打敗魔法」。

實作階段的三個心法

他歸納了幾條跟 AI 協作時的心法（由 91APP Payments Sr. Manager Ken 整理）：有規劃地逐步下指令，不求一次到位，而是先想好流程或跟 AI 規劃好順序再逐步下達；明確指定「改哪裡」跟「產出落在哪」（例如「請在 CartService.cs 中新增 AddToCart 方法，輸入為 productId 與 quantity」）；一旦方向偏了就趕快停下來，直接重做或手動修正通常比硬改更有效率；把目標設定在 80 分而不是 100 分，因為 AI 是幫你加速、不是幫你完美收尾，要有意識地安排 Review 跟 Refactor 的時間。

從 Sprint 的角度看，RD 拿到 Story 之後，走的是 Generate Code → Unit Test → Code Review → Debug／Fix 這條線，跟 AI 反覆協作產出，最後才接到 Git Commit／Push 跟 Pull Request（由 91APP VP Alan 整理的流程圖）。

QA 這一端：PRD 跟 API Spec 直接餵出測試案例

QA 這塊他們發現只要把 PRD 跟 API Spec 餵給 AI，加上清楚描述需求，AI 很大程度就能直接產生 test case——因為 PRD 裡本來就詳細寫了驗收規則與測試情境，Swagger Spec 又已經提供完整的資料欄位、型別與結構，AI 可以進一步把這些 test case 產成 Cypress 的測試程式碼。他的結論很直白：PRD 跟 Spec 寫得越完整，AI 測得就越準確；PRD 寫得模糊，AI 也只能亂猜。

持續面對的挑戰

他坦承還有兩層挑戰沒解決：深度上，PRD 目前主要是 PO 單獨寫，但其實有些內容應該由 RD、QA 一起參與定義規格，這件事該怎麼協作還在討論；廣度上，目前大概只有 3 到 5 個 pilot 團隊跑得順，但整個部門有 20 幾個 Scrum team，怎麼把這套知識有效擴散出去，他們打算靠 Template 跟分享會慢慢推廣。他也補了一句，91APP 不只產品處在用 AI 解決問題——營運部門用 AI 做素材、HR 團隊用 AI 做面試，連主管自己都要重新學習怎麼帶領懂 AI 的新型態人才。

3. 關鍵數據與案例

• 導入團隊端到端（接到需求、開發、測試到上線）交付效率至少提升 30%（講者自述，無外部來源佐證）。
• 系統異常數量與去年同期持平，效率提升沒有伴隨品質下降（講者自述，無外部來源佐證）。
• 產品發展處團隊規模十年間從約 5 人成長到約 300 人（講者自述，無外部來源佐證）。
• RD 估時訓練前後對照：訓練前 16% 的人估 2 小時內完成、41% 估 4 小時、33% 估 6 小時、8% 估 8 小時；訓練後 41% 的人 2 小時內完成、25% 在 4 小時內、8% 在 6 小時內、20% 完全不需要額外時間（講者自述的內部訓練數據，無外部來源佐證，口頭說的「七成 4-6 小時」「四成兩小時內」是這組數字的概略講法）。
• arc42 官方模板共 12 個章節，91APP 選用其中 6 個導入（arc42.org 官方章節列表 可查證 12 章節，選用比例為講者自述）。
• 目前約 3 到 5 個 pilot Scrum team 已順利運作，全部門共約 20 幾個 Scrum team 待擴散（講者自述，無外部來源佐證）。

4. 金句

• 「效率是目的，AI 是手段。」
• 「這些知識都存在人腦中，難以擴展。」
• 「你怎麼樣跟 AI 有效去做溝通，它其實就是一個 RD 的諧音梗。」
• 「AI 做到 80 分，還是透過人跟 AI 去協作，讓人去 review AI 的產生物，確保它的正確性之後才會上線。」
• 「這些文件你都會跟 AI 去協作，就是用魔法打敗魔法。」
• 「偏掉就停，不要浪費時間硬改。」
• 「AI 已成為 91APPer 的標配。」

5. 提到的工具與名詞

• **91APP, Inc.**（股票代號 6741）：以 AI 與洞察分析為底層能力，提供品牌與零售業全通路解決方案的公司，這場的講者服務單位。
• arc42：一套開源軟體架構文件模板，官方版本有 12 個章節，91APP 選用其中 6 個導入內部流程。
• **C4 Model**：一套分層描述軟體架構的視覺化方法，這裡用到 System Context diagram 與 Container diagram 兩層。
• **NotebookLM**：Google 出的 AI 筆記／知識萃取工具，91APP 用它把 Google Drive 上的 domain 知識萃取成 Domain Brief。
• PRD（Product Requirement Document，產品需求文件）：91APP 內部從 Domain Brief 產生、給 AI 與團隊共用的需求規格文件。
• **Swagger／OpenAPI Spec**：描述 API 資料欄位、型別與結構的規格格式，作為 arc42 建構塊視圖與 QA 產測試的依據。
• **Redis**：91APP 購物車服務採用的分散式快取資料庫，SPEC 範例裡指定要基於 Redis-based Cart Service 開發。
• **Cypress**：AI 依 PRD 與 API Spec 產生測試案例後，進一步產出的端對端測試程式碼框架。
• SPEC 原則（Specific／Precise／Explain／Clarify）：91APP RD 團隊內部自創、給 AI 下 prompt 的四字訣，由 91APP iOS Team Lead Justin 提出。

6. 延伸觀察

這場最值得記下來的是「知識沒有累積，只存在資深 PO、RD 腦子裡」這個痛點的描述——這其實不是 AI 時代才有的問題，是任何組織擴張到一定規模都會撞上的老問題，AI 只是把「沒有把知識文件化」這件事的代價放大了：以前資深人員憑經驗口耳相傳還能撐著跑，現在要讓 AI 接手，知識不寫下來就真的完全用不上。arc42 那段特別務實——不是照抄一套方法論，而是先想清楚 AI 需要什麼樣的輸入（結構化、可驗證、能對應到程式碼落點的規格），再回頭挑一套現成模板裡剛好夠用的六個章節，而不是為了完整而硬套十二個章節全上。SPEC 原則也是同樣的務實態度：不追求一套放諸四海皆準的 prompt 工程理論，而是先讓 RD 團隊自己踩過雷，再萃取成四個好記的字。

91APP 這次同時是年會的贊助商，兩天議程裡一共有三位講者來自這家公司（李昆謀、吳剛志，加上這場的陳俊毅），另外兩位的分享內容各自有獨立的筆記，這裡就不重複寫了。

7. 資料來源