高分模型為何仍被使用者否定？一次 AI 產品讓我學會的關鍵決策

註： 以下內容為個人在大型企業推動 AI 產品過程中的觀察與反思。許多細節已經過適度調整，但其中關於產品決策與問題定義的思考，值得持續探討。

「模型評測分數不低，使用者卻只願意給它 3.3 分。」這是我在一個 AI 專案裡，遇過最矛盾的事情。

前陣子，我參與了一個專業文意生成 AI 產品的開發。這項產品在組織內被賦予高度期待，預估商業價值超過數千萬元。然而，專案推進到中後期時，團隊卻遇到了一個棘手的問題。系統評測分數並不差，模型指標看起來正常，甚至部分自動化測試結果也符合預期。但真實使用者的回饋卻相當直接：「生成內容無法使用，實際上不符合需求。」

這是一個許多 AI 團隊都可能遇到的情況 — — 數據告訴你產品沒問題，但使用者卻告訴你它沒有價值。當時主管甚至看著糟糕的用戶回饋，一度考慮是否要對專案進行停損。

一、 當數據與使用者意見開始衝突

為了找出問題來源，團隊嘗試過許多技術路徑，包含模型比較、提示詞調整、以及訓練素材回溯分析等方式。然而，不論技術端如何優化指標，只要進入真實使用情境，使用者對成果品質仍然不滿意。工程團隊陷入了「指標高分」的陷阱，甚至開始懷疑是用戶太挑剔。

模型分數越來越高，使用者滿意度卻停滯不前。

回頭檢視後，我逐漸發現一件事情：問題可能並不在模型能力本身，而在於團隊定義問題的方式不夠精準。當時團隊投入大量精力在優化輸出端，試圖透過技術硬碰硬去逼 AI 完美通靈，卻相對忽略了輸入端資訊品質這個變數。這個觀察，成為後續轉折的起點。

二、 從模型問題，重新定義成資訊問題

其實專案前期已經投入大量資源進行資料治理。我們從約 90 萬份歷史資料中篩選出約 3 萬份高品質內容作為核心知識基礎，並移除大量重複與品質不穩定的噪音資料。如果知識底座已具備頂級品質，那麼問題顯然不在資料，也未必完全在模型。

於是我開始觀察使用者實際操作流程，發現了一個被技術團隊忽略的關鍵：大多數使用者第一次輸入提示詞時，提供的資訊其實非常有限。 典型情況是幾十個字的模糊描述，沒有背景、沒有限制條件、沒有期望格式。

在資訊極度空洞的情況下，即使後台模型再強、擁有再好的專業資料，也難以產生符合專業情境需求的內容，吐出來的往往只是語意正確的精美廢話。換句話說，我們原本期待 AI 透過極少量資訊就能精準還原複雜工作情境，這本來就是一個不合理的期待。當我們一味在技術端死磕、試圖讓模型去「通靈」時，往往就陷入了思維的盲點；在充滿未知的新技術浪潮裡，看清局勢並靈活轉換路徑，才是產品真正的硬實力。

三、 不再要求 AI 通靈，用「靈活思維」重構產品

既然硬碰硬的技術路徑不通，我決定直接轉換策略，從「互動流程」下手。

我捨棄了繁瑣的後台指標，改用 Vibe Code 的路徑，親自用 TypeScript 寫了一套 Agentic（多代理人）自動化協同架構。我不去逼 AI 通靈，而是另外進行流程設計，強行從底層流程介入：

• 引導式追問機制：既然用戶第一次給的資訊不夠，系統就透過分段追問，靈活地引導用戶在過程中投入更多提示詞，用流暢的互動，把這 3 萬份精選資料該有的專業靈魂徹底逼出來。
• 多階段檢核流程：建立多層代理人的內部博弈機制，由額外的稽核角色檢查格式、內容完整性，用冷酷的退回機制攔截幻覺，降低錯誤直接進入最終輸出的機率。

我們將這套架構整合進原系統，演進為「外掛側邊欄」的形式，讓使用者在不離開原本工作頁面的情況下操作，極大降低了情境切換的心理負荷。這些調整沒有更換模型，也沒有增加大量算力，但卻徹底改變了產品與使用者互動的方式。

四、 真正被驗證的，不是技術，而是問題定義

關鍵在於，我是自己把這套架構與追問流程全部做完、迭代出新版本後，才把成品拿去進行真實的使用者測試。

這套新機制真正推上第一線戰場後，回饋上來的數據，給了當時陷入技術僵局的團隊一劑最強力的強心針。雖然 AI 的生成品質本來就難以完全做到 100% 絕對控制，但依據我們收集到的 300份量化分數回饋顯示，新機制上線後迎來了里程碑式的顯著成長：

滿意度平均數從 3.3 分，一路飆升到 7.19 分，整體提升高達 117.9%！這表明近期的優化與互動流程的調整，切切實實地迎來了良好成效。

在同時進行的深度訪談中，系統易用性量表（SUS）平均拿到了 73.7 分，全部的使用者最終堅定選擇了這個新的互動版本。但比起分數，更重要的是我們從中獲得的深層洞察。這群專業使用者真正重視的，其實不是創意，而是「安全感」。他們的工作容錯率極低，格式錯誤、內容遺漏都可能造成實際行政瑕疵。相較於從零開始生成內容，他們更在意：

• 已驗證的內容，比全新生成更重要：使用者依賴舊稿並非因為懶惰，而是因為舊稿已經過層層考驗，最具備行政安全性。他們強烈渴望系統能直接調出、或允許上傳高度相似的歷史案例作為基準，直接進行局部微調。
• 條列式排版的語意密度陷阱：技術團隊喜歡清晰的條列式輸出，但在嚴謹的專業情境中，條列式在資訊不足時易造成論述過度簡化，未能完整呈現脈絡，反而不符專業書寫慣例。
• 願意犧牲速度，換取可靠性：進階使用者在實務考量下，往往採取「可接受體驗缺陷（如生成速度較慢），來換取最大資訊完整性」的務實決策邏輯。
• AI 的角色是加速，而非取代：即便初稿達 80% 完美度，組織內的主管仍有微調文字展現指導權的慣性。這確立了產品的定位 — — 快速達成 60–80% 的高品質半成品，而非取代人工最終把關的空間。

結語：產品工作的核心，是重新定義問題

這次專案讓我最大的收穫，不是找到新的模型，也不是建立更複雜的技術架構。當我帶著新版測試結果、使用者訪談洞察，以及後續優化方向回到會議室時，原本一度面臨停損評估的專案，終於重新看見了繼續推進的可能。

很多時候，產品失敗並不是因為技術不夠強。而是因為我們解決的根本不是使用者真正面對的問題。當團隊持續討論模型參數、評測指標與技術細節時，我們很容易誤以為自己正在解決問題。但如果使用者始終感受不到價值，再漂亮的數據也只是自我安慰。

真正重要的，不是把模型分數從 90 分提升到 95 分，而是理解：為什麼使用者明明拿到 90 分的答案，卻仍然不願意使用。

這次專案最終證明了一件事：很多時候，改變產品成果的關鍵，並不是更大的模型，也不是更多的算力。而是願不願意放下既有假設，重新定義問題。因為產品工作的本質，從來不是追求技術最優解。而是在複雜與不確定之中，找到使用者真正需要的答案。