吳剛志：從Prompt到Product，掌控AI APP的正確率

1. 一句話總結

吳剛志用91APP一個商品規格自動填寫的真實專案，示範架構師如何用「正確率」與「覆蓋率」兩個量化指標，帶著團隊跑數十輪Prompt改善循環，把一個70%正確率、看起來能用其實不能用的功能，調整到90%正確率、50%覆蓋率、且能持續迭代的可上線狀態。

2. 重點筆記

91APP在哪些地方用AI：藍與紅兩種心態

開場先畫出91APP用AI的兩個象限：一邊是「用AI開發產品、改善流程與效率」，也就是用AI強化開發團隊自己的產能，受惠的是軟體產業的人；另一邊是「開發AI產品服務」，也就是用AI強化產品本身的能力，做給消費端與客戶端用，受惠的是非軟體產業的人。投影片把這兩種情境標成藍色的「prompt」心態與紅色的「product」心態，對照得很清楚：藍色情境裡是自己下prompt、期待AI給出想不到的答案、自己review AI的回應，重複的次數大概是一百次等級，能夠一筆一筆review；紅色情境裡客戶不一定懂prompt、只看得到結果，客戶期待行為是可預期的、不想要被要求大量review，而這類prompt可能被執行到百萬次等級，不可能逐筆檢查。這個「內部用prompt、外部做product」的分類，是整場後面所有評估方法論的出發點。

案例登場：一個小模組，不到90%正確率跟亂猜沒兩樣

投影片挑的案例不是熱門的對話型Agent，而是一個「不大的小模組」：用商品的描述資訊，自動替客戶填寫規格與分類選項。背景是賣場上架需要補填許多資料庫裡原本沒有的欄位，91APP希望用Gen AI批次代替客戶完成，藉此提升客戶的作業效率、節省人力。投影片強調這是「核心產品的核心功能」，因為商品上架是每個客戶都要用的主要功能；同時也點出量級：一個商品上架，平均要從約兩百個選項裡挑出二十個。

投影片接著攤開一個真實的輸入輸出範例：一件「浪漫蕾絲口袋緞面A字裙」的商品描述文字（含顏色、尺寸、材質等一長串資訊），System Prompt要求AI依照單選、複選、輸入框三種欄位限制去填規格，答不出來就留空。這一段特別標出三個用「（誤）」自嘲的做法：反正AI都看得懂，直接使用原生格式；為了方便，直接讓AI生成原本的匯入格式；Prompt都在處理RD在意的「格式」，而不是處理客戶在意的「原則」。投影片點出關鍵：這段Prompt真正重要的部分只佔了一句話的份量，剩下九成的token其實是在解決工程師自己的問題（讓後續程式碼好處理），而不是客戶的問題，而這段Prompt會被執行到百萬次等級，等於每一次都在為了RD的方便多付一次token費用。經查INSIDE對這場的專訪，吳剛志受訪時把這個問題講得更直白：「做在消費者產品裡面的prompt可能一年被用100萬次，你會想要花這麼多token嗎？而且可能每次結果都有落差？」跟投影片上的論點互相呼應。

為什麼正確率比覆蓋率重要

投影片丟出一個選擇題：客戶會希望哪一種結果？A是每個規格選項都有答案，但正確率只有約70%；B是只有50%的商品有答案、正確率九成以上，另外30%的商品雖然沒答案，但有提示告訴使用者商品資訊缺了什麼。結論是B對客戶比較有幫助——因為A即使UI設計得再好，客戶還是得逐一確認每一題，等於沒有省到時間；B的部分只要正確率夠高，有經驗或沒經驗的人都能放心用，先省下50%的工作量，另外30%有提示的部分本來就得補資料，等於再省一半、多省15%，理想狀況下能替客戶省下超過一半的時間。這裡明確定義了兩個指標：覆蓋率是「AI有回答的規格數除以規格總數」；正確率是「AI答對的規格數除以AI有回答的規格數」。目標訂為：正確率必須先達到九成以上的門檻，覆蓋率才有意義去追。

投影片接著秀出量化這兩個指標的方式：一個「商品A、B、C」的示範表格，每個商品列出五個規格選項（紅橙黃綠藍色）分別對照「預期答案」與「AI的答案」，用對、錯、棄三種狀態去標記每一格，藉此把抽象的正確率、覆蓋率變成可以逐筆核對的資料表。

第一次跑出分數之後：52.3%正確率、87%覆蓋率

投影片直接秀出一組真實的初期評估數字：正確率52.3%、覆蓋率87%，然後拋出問題「接下來我該改什麼」，帶出整場的第二段主題：怎麼從一個分數，回推出具體的改善方向。

改善的做法分三步：第一步是看數據分布，猜測可能出問題的範圍，大範圍去調整Prompt寫法、調整像信心指數這類參數的threshold數值；第二步是把每一筆商品的處理結果攤開來逐筆看，歸納出處理原則去修正Prompt，遇到特例就直接排除、改用規則庫（Rulebase）處理，而不是硬塞進Prompt裡解；第三步是建立技術專家（架構師本人）與領域專家（投影片稱為「大PO」）的協作機制，初期由架構師跟大PO一起訂處理原則，後期則交棒給Tech Lead跟Product Owner持續優化。

投影片把最後要處理的規格分成三類，各自對應不同的處理方式：用規則處理（Rule）——凡是有淺規則可循、各種不適合AI處理的情況，都盡量用規則先排除掉，排除得越多越好；提示客戶補充資訊（Hint）——各種原因無法作答的區塊，附上清楚的註記；給客戶建議答案（Autofill）——AI能回答的區塊，目標是把答錯的數量壓到最低，盡量把「wrong」的部分移轉走。這裡也點出一個判斷原則：對客戶而言，答錯的成本比不回答還高，所以難以選擇的情況（例如單選題卻有多個候選答案）就該直接放棄作答，設計不良或有特例的屬性改用規則庫處理，不合理的參考資料集則直接修正資料集本身，而不是硬凹Prompt去配合。

投影片也提到整個改善循環跑了大約二十輪：架構師陪著團隊跑了第一到第十輪，先把執行環境與流程建起來；接著跟大PO一起跑了第十一到第十三輪，把問題判定與改善方向的決策流程確立下來；剩下的十幾輪，團隊就能自己跑完，不再需要架構師隨行。

工程面的加速：格式選對、工具選對、報告選對

投影片點名三個從工程角度做的改善，並各自附上具體成效數字：一是改善AI本身的成效，調整輸入輸出的結構，正確率因此多拉了5個百分點；二是改善工程師的執行效率，把修改與跑分的時間從4小時壓到10分鐘；三是改善PO與領域專家的執行效率，把檢視報告與決策改善方式的時間從8小時壓到30分鐘。

輸入輸出結構的調整，投影片給了實際對照：原本的輸入是一長串未分段的商品資料文字，改成用Markdown分段標記欄位（像是用#ProductID、#SalePageName、#ProductDescription這樣的標題把欄位隔開），讓AI更能理解文字的意義；輸出則從一句純文字描述，改成Json加Schema的結構化格式，每個規格欄位除了填入的值之外，還多帶了sure（是否有把握）跟reason（推論理由）兩個欄位，格式更精準也更容易讓程式接手處理，這項調整讓正確率多了5個百分點。

投影片點名了實際用來加速這個循環的工具是Dify，用途是「加速AI應用的開發與驗證流程」，讓團隊每次調整LLM參數與Prompt之後可以立刻驗證成果，把原本4小時的驗證流程壓到10分鐘。另外投影片附了一張評估方法的參考出處截圖，圖片來源標註是Anthropic官方文件（build-with-claude/develop-tests章節）；下一頁則直接放了ihower部落格文章的連結，作為評估方法的另一個參考依據。

報告輸出的部分，投影片列出三種產出：一份總表（csv格式），把每次評估的指標數值用類似Excel公式的方式算出來，讓PO能快速看懂結果；一份逐筆的評分結果報表（Markdown格式），每一格對應「正確答案、AI答案、註記」，並連結回原始商品資訊與規格定義，方便PO追根究柢；一份用mermaid語法畫出的資料流向圖，統計整批資料最終落在哪個分類。投影片附的那張流向圖數字相當具體：總共393筆進入有效評估（effect），另有68筆被排除（exclude）；393筆裡231筆AI有作答（answered）、150筆AI主動放棄（aborted）、12筆出錯（error）；231筆有作答的裡面，192筆是AI有信心的答案（trusted-answer）、39筆是AI沒把握的答案（non-trusted-answer）；有信心的192筆裡，167筆最終確認答對（correct）、25筆答錯（wrong）。這組流向圖等於是把正確率、覆蓋率背後的原始筆數全部攤開來對帳。

總結：對客戶而言，這是輔助功能，不是AI炫技的地方

投影片收尾強調：不是所有AI Agent都得是對話型態的應用，做對方式，這類「幕後」功能一樣能替客戶帶來大幫助。客戶真正在意的期待，要換算成量化指標：效率等於減少客戶需要手動輸入的資料數量，加上減少客戶需要檢查的資料數量。投影片把最後的目標寫成一組具體數字：老闆的期待是正確率九成以上、覆蓋率九成以上、替客戶省下九成的時間。經查INSIDE的專訪，內文把這個專案最終的成果同樣寫成正確率90%以上、覆蓋率90%以上、時間節省約90%，跟投影片上這組目標數字對得上；受訪時吳剛志也說了類似的結論：「這是個輔助功能，不能抱著AI炫技的心態去做」，跟這頁投影片的標題基本上是同一句話的兩種講法。

投影片最後歸納出四條內部心得，各自附上一句補充：Scope（界定處理範圍）——你的Prompt會被執行超過一百萬次，能用程式碼處理明確問題，效果會比丟給AI處理來得好；Evaluate（掌控正確性）——把目標換成能量化的指標，建立評估機制，同時要分別掌握「選擇題」型跟「問答題」型的評估能力；Optimize Improvement Cycle（加速循環）——評估到改善的循環速度，直接影響優化能力的上限，必要時投入開發人力去建立評估循環，比直接開發功能本身還重要；Prompt Engineering（學習正確使用LLM）——工程師應該掌握LLM API的正確用法，Json Mode、Function Calling、Prompt Engineering都是必要技巧。

3. 關鍵數據與案例

• 案例規模：一個商品上架平均要從約200個選項中挑出20個規格值。
• 初始基準：正確率52.3%，覆蓋率87%。
• 選擇題實驗對照：方案A每題都答但正確率約70%；方案B只答50%的題目、正確率90%以上，另外30%附提示。
• 工程面改善成效：輸入輸出結構調整優化後正確率提升5個百分點；工程師跑分驗證時間從4小時壓到10分鐘；PO檢視報告與決策時間從8小時壓到30分鐘。
• 改善循環規模：架構師帶跑第1至10輪、與大PO協作跑第11至13輪，其餘約十幾輪由團隊自行完成。
• 資料流向的具體筆數：393筆進入評估、68筆被排除；231筆AI有作答、150筆放棄、12筆出錯；有作答中192筆屬有信心答案、39筆屬無信心答案；有信心的192筆中167筆答對、25筆答錯。
• 目標門檻：正確率須達90%以上，覆蓋率才被視為有意義；最終期望是正確率90%以上、覆蓋率90%以上、替客戶省下90%時間（講者自述目標，無外部來源佐證）。
• Prompt執行量級對照：內部用法約重複百次、可逐筆review；產品化後約被執行百萬次以上、不可能逐筆review。

4. 金句

以下都是投影片上直接寫出的標語或關鍵句：

• 「只有能精準輸出、能量化正確率、Gen AI強化的功能才能上線」
• 「對客戶而言，這是個輔助功能，不是AI炫技的地方」
• 「效率＝減少客戶需要手動輸入的資料數量＋減少客戶需要檢查的資料數量」
• 「你的Prompt會被執行1,000,000+次」
• 「將目標換成能量化的指標，建立評估的機制」

經查INSIDE對這場的專訪，裡面另外引了兩句吳剛志受訪時說的話，附連結列在這裡，跟上面投影片標語分開標示：

• 「做在消費者產品裡面的prompt可能一年被用100萬次，你會想要花這麼多token嗎？而且可能每次結果都有落差？」
• 「這是個輔助功能，不能抱著AI炫技的心態去做」

（INSIDE專訪：91APP吳剛志：高正確率的AI功能該如何煉成？）

5. 提到的工具與名詞

• Dify：投影片點名用來加速AI應用開發與驗證流程的平台，官方定位為可視化的智能代理／RAG工作流開發平台，提供雲端託管、企業自架與開源三種形式。補查：Dify官網。
• 正確率／覆蓋率：投影片自定義的兩個評估指標。覆蓋率＝AI有回答的規格數除以規格總數；正確率＝AI答對的規格數除以AI有回答的規格數。
• Rulebase（規則庫）：投影片中用來處理「特例」與「設計不良屬性」的機制，原則是特例不要硬塞給Prompt處理。
• Json Mode／Function Calling：投影片列為架構師認為工程師必須掌握的LLM API使用技巧。
• mermaid：投影片用來畫資料流向統計圖的語法工具。
• 補查：投影片引用的評估方法論參考出處之一，是Anthropic官方文件中「定義成功標準與建立評估」（Define success criteria and build evaluations）章節，內容涵蓋任務忠實度、一致性等多種成功標準定義方式，以及精確匹配、餘弦相似度、ROUGE-L、李克特量表、二元分類等評估方法。Anthropic文件連結。
• 補查：投影片引用的另一個參考出處，是ihower（張文鈿，同場次第4位講者的社群暱稱）部落格文章〈評估驅動開發：生成式AI軟體不確定性的解決方法〉，核心概念是「評估驅動開發」（Eval-Driven Development），主張先建立評估機制再開發LLM應用，並搭配LLMOps持續收集線上資料迭代。ihower部落格原文。

6. 延伸觀察

這場的核心價值就在第2、3節那些具體數字：52.3%到90%、87%到50%、4小時到10分鐘、8小時到30分鐘，每一組數字背後都對應著一個明確的改善動作（加規則、換格式、換工具），比起很多場只講願景不給數字的分享，這場幾乎是把整個Eval-Driven Development的操作手冊攤開來給你看。隔天年會的另一場分享（李昆謀那場）用的正是同一套「正確率、覆蓋率」定義，也提到同一個商品規格自動填寫案例，兩場合起來看等於同一個91APP專案的產品端與架構端雙重視角，資訊互相補足。

比較可惜的是投影片沒有交代這個91%正確率的評估資料集規模有多大（幾百筆還是幾千筆商品），也沒說清楚Dify在這個專案裡具體扮演什麼角色——是拿來管理Prompt版本、跑批次評估，還是兩者都有，投影片只給了「4小時到10分鐘」這個結果，中間怎麼接起來的細節留白。另外「藍與紅」這組對照是整場最好的框架，把「內部用AI」跟「做給客戶用的AI產品」這兩件常被混為一談的事情，用能不能review、要重複幾次講得非常清楚，值得記下來套用到其他專案評估。

順帶一提，91APP這兩天等於連上了三位講者：開發者年會這場的吳剛志、同場次的陳俊毅（第7場，內容另有獨立筆記），加上隔天年會的李昆謀。經查李昆謀自己寫的參加心得，他也提到「91APP內部有兩位同事也在開發者年會上分享」，對應的就是吳剛志（Andrew）跟陳俊毅（Levi）兩人（happylee.blog）。至於91APP是不是這次年會的正式贊助商，查無2025年官方公布的具名贊助商名單可以佐證，這點此處不做裁決。

7. 資料來源