早說嘛。

很多事情，好像只要對方早說就解決了。做過產品的，大概都在心裡罵過這三個字吧？使用者丟來一句「AI 回覆到一半就卡住了」，你回問：那時候 AI 正在回覆嗎？有切分頁嗎？網路正常嗎？一輪問完，還是不知道到底發生什麼事。

10/14 的 GAI 小聚，康富淼直接把這句話放進講題：〈案發現場通靈之戰 - 早說嘛為什麼不早說〉。整晚聽下來，問這一題的，不只康富淼。

這場還是在 SPARKFUL，主題是「UX 研究 + Eval」，七位講者，每人十分鐘。活動頁上是這樣寫的：

現在任何人都可以用 AI Agent 做出 80 分的系統，接下來的關鍵是怎麼樣做得好。

UX 研究幫你設計出更好的系統，Eval 幫你評估這個系統到底多好，而「這兩題剛好都是需要『人』來做的題目」。

上半場四位偏 UX，下半場三位講 Eval。我一樣把類似的放在一起，順序就照議程走，只把站在兩半中間的康富淼單獨拉出來。

小知識：對 UX 跟 Eval 不熟的話，想像一家手搖飲店就好。

UX（ User Experience，使用者體驗 ）管的是客人用起來順不順。客人站在菜單前面猶豫半天，分不清微糖跟半糖，UX 研究就是在旁邊看、開口問，找出卡在哪裡；UX 設計再把菜單重新排過，讓下一位客人容易一眼就點到想喝的。

Eval（ Evaluation，評估 ）管的是做出來的東西夠不夠好。店長拿一疊固定的訂單，讓新來的店員照著做，甜度、冰塊、加料一項一項驗；配方改了，就拿這疊訂單再驗一次；開了分店，也用同樣的標準。換成 AI，訂單就是一批題目，甜度、冰塊就是評分標準，每調整一次就整批重跑，看有沒有比上一版好。

那，到底為什麼不早說？

Rei、Lihsuan、卓致遠：題目得自己先出

前三位講的其實是一樣的概念。Rei 這一年在悠識數位跟致遠體驗設計當 AI 顧問，而接下來的兩位講者，剛好就來自這兩家。Rei 說：「我們沒有事先說好今天要一起分享，剛好都被邀請。」（ 這世界也太小 XD ）

Rei Huang（ 完美像素負責人 ）自稱為 Builder，對 Builder 的定義，是一個人透過 AI，從概念做到產品上線，再拿去市場變現。做出產品現在很快，「最難的就是把產品推上市場」。

Rei 把做產品要跟 AI 講清楚的東西，分成四層意圖：問題、功能、操作、執行。大部分人跟 AI 討論的都是後面三層，最前面的「問題意圖」常被跳過。很多人說要做 CRM（ 客戶關係管理系統 ），可是「為什麼要做這件事？」Rei 簡報上舉的例子是，真正的問題可能是客戶資料散落各處、業務不知道該 follow 哪些客戶，CRM 只是其中一種解法。而且「問題的意圖，AI 沒辦法幫你定義」。

但 Rei 的節奏很快。以前要先規劃功能、排時程，現在是「想一個、做一個」，驗證則是「直接推上市場，然後馬上做產品的驗證」。給想轉 Builder 的設計師，Rei 指了兩個方向：把專業累積成知識庫，以及建一套可以持續交付的系統。

Rei 講到持續產出的部分，其實蠻有感的。尤其在這個時代，使用 AI 快速產生出可以交付，或者說不算交付，而是持續的產出，似乎不是難事。（ 但也好像出現了很多重新打造的輪子，或是所謂的 AI Slop XD ）關鍵是，這些東西可不可以被稱為產品，而且它是不是源源不絕地、順著一定的脈絡產出。我覺得這是一件很重要的事情。

最大的重點在於有意識地使用 AI 來做持續的產出。

Lihsuan Pan（ 悠識數位體驗研究員 ）做的是體驗研究，看使用者對產品有什麼感覺、期待它解決什麼問題。Lihsuan 分享的是今年 Q2 的一個案子：需求團隊接手了一個音樂資料庫，卻不知道誰在用、來的人在找什麼。研究用的是焦點團體，一個主持人同時跟五、六位受訪者一起討論，一場兩個小時。

訪綱是跟 AI 一起設計的。專案目標、兩小時分幾個環節、要包含哪些內容，條件全部丟給 AI。結果是：

我們設計完一個看起來蠻有模有樣的訪綱，簡報也做好了，客戶都看過了，一切好像都沒有問題。

可是 Lihsuan 心裡「一直有一種不是很踏實的感覺」，不知道這樣問下去會得到什麼，也不知道得到的東西能不能幫客戶解決問題。團隊就這樣「一直拖著，沒有進到正式的訪談」。

停下來才發現，團隊有三個很清楚的專案目標，卻跳過了中間那一步：研究問題。專案目標是這個案子要達成什麼，研究問題是這次訪談要回答哪些問題，訪綱才是實際拿去問受訪者的題目。少了中間那一層，「不管是人寫還是 AI 寫，其實都不知道它到底要回答什麼樣的問題」。

團隊先把訪綱擱著，重新寫下四個研究問題：誰會找音樂資料、在什麼情況下找、卡在哪裡、這個資料庫該扮演什麼角色。這四題變成指南針，之後不管是 AI 設計的訪綱還是 AI 做的分析，都拿它們回頭檢查，「它是不是真的有回答到」。Lihsuan 的建議很直接：

研究問題這件事情不要交給 AI。

另外有個細節：受訪者常常「不知道自己講到多細，一句話就帶過了」，例如只說一句「資訊不足」或「我會去 YouTube 或 Google 找」。所以 Lihsuan 事先準備了一份追問清單，聽到哪句話，就知道該往下問什麼。

把 Rei 跟 Lihsuan 放在一起看蠻有意思的。一個是想到就做、直接上市場，一個是必要的時候要「幫自己踩煞車」。我的解讀是差在問錯的代價：一個人做產品，上錯了改就好；一場焦點團體找齊五、六個人談兩小時，問錯了就回不去，方向也就偏了。問錯越貴，越該先想清楚。

卓致遠（ 致遠體驗設計體驗總監 ）接的任務，是幫政府的承辦人開協作會議。Join 公共政策網路參與平臺上的提案，附議過了門檻就成案。有些成案的提案，負責的機關會開協作會議，把提案人、受影響的人、相關機關跟專家找來一起談。AI 幫卓致遠整理了過去 80 場協作會議的資料，要讓新手承辦人知道下一場該怎麼開。

AI 一開始直接丟答案，卓致遠要它先講清楚：這要怎麼判斷？於是 AI 把議題難度拆成五個維度拿給與談人填寫：價值衝突、政治鎖定、異質性、認知門檻、協調結構，「沒有價值衝突是一分，很有價值衝突是五分」，最後畫成一張雷達圖。

接著 AI 列出「酒駕要加高刑責」該找哪些人來開會，卓致遠的反應是：

幹，這樣不行吧。你如果列出這些人，我怎麼知道你真的有列齊了？

卓致遠要 AI 先給一套分類：誰制定、誰執行、誰被影響，確定第一排的關鍵人都找齊了。

這一場聽到最多次的，就是這句「幹，這樣不行吧」。卓致遠說話有一種燃盡生命的聲音，每一句說完都有氣快用完的那種感覺，搭配這句，的確很符合這一場要表達的意象跟內容 XD。

最有重量的一段，是請 AI 模擬這些人在會議上會說什麼。警政單位會說：「你提高罰則，我抓不到也沒有用。」成癮專家會說：「這些不是壞人，是病人。」受害者家屬會說：

我只知道我女兒今年應該 23 歲。

這句是 AI 模擬出來的。每個人講的是完全不同的語言，卓致遠說，原本的會議「可能就停在這裡」。

但 AI 整理那 80 場的時候發現，辦得特別好的那幾場，有時候是在重新定義問題。「酒駕是否要提高加重刑責」被改寫成：「其實我不是要加重刑責，我是要讓這件事情不再發生。」卓致遠的說法是：

我訪談不是為了讓這群人來許願用的，我訪談是為了重新定義問題用的。

AI 直接幫忙重新定義了題目，卓致遠一開始也覺得「哇塞，這個超棒的」。然後又是那句：「可是，幹，不行吧」。AI 做得到，「可是它是怎麼做到這件事的？」「我不能每一次都丟給 AI 去分析」。追問到最後，AI 交出了三個方法：升一層、切一刀、換並存。

講到最後，卓致遠說：「我覺得我們一路上都是在這樣」。位置不一樣，講到的卡點卻很像：題目明明是自己的，可是在 AI 交出東西之前，人常常還沒想好自己要什麼。

康富淼：使用者一句話就帶過了

康富淼一上台先自嘲。看了與會名單，「全部都是 C-level」，只有自己什麼都不是，「所以我就想說，我來搞笑一下」。去年在小聚分享完，只有一個人跑來說笑話很好笑。

開場那個例子，從康富淼的簡報借來的。他表示常收到使用者回報是：「欸富淼，為什麼 AI 回覆到一半就會卡住？我也不能切換對話？」後面接著工程師的一串追問，以及工程師心裡的 OS：

早說嘛，到底為什麼不早說？你講清楚，我們就很好辦事了嘛。

問不出來怎麼辦？我筆記上這一段記了一句：「有緣自然就會好？」以及富淼投影片上的經典梗圖（ 笑 ）看來最後，富淼沒有打算等緣分。

使用者一句話就帶過，這跟 Lihsuan 的受訪者很像。Lihsuan 的解法是事先準備追問，康富淼的解法是乾脆把現場整段錄下來。

Sentry（ 一個幫網站收錯誤回報的服務 ）有 session replay 功能可以做這件事，可是免費版一個月只有 50 次。康富淼不想付錢，乾脆自己做。

背後的技術是 rrweb（ Record and Replay the Web，錄下網頁再重播 ）。康富淼用舞台表演來解釋：先把台上有哪些角色、拿什麼道具、布景長怎樣記下來，之後只記有變化的動作，整段就變成一份劇本。照著劇本在電腦上再演一次，案發現場就還原了。使用者一按下問題回報，前面那一段操作就自動打包，送進團隊的 Discord。

如果你是 UX 設計師，你應該會覺得很興奮。

因為從錄影裡，看得到使用者想做什麼、卡在哪裡、最後怎麼解決，康富淼說，這或許也能拿來做易用性測試。一個工程師做來 debug 的工具，就這樣轉頭推給了 UX 設計師，上下兩半在這裡第一次碰到。

這邊補充，錄影的畫面連滑鼠的軌跡都會一起錄下來，所以其實蠻適合拿來觀察使用者的操作行為，的確會讓 UX 設計師很有感覺。

有了錄影，「用戶在這邊回報的問題文字，就一點關係都沒有了」。但光有畫面還不夠，康富淼再把前端呼叫的 API、瀏覽器裡的紀錄、AI 串流時的摘要，加上後端的紀錄，全部打包交給 Claude Code 分析。

嚐到甜頭之後，連分類都交出去了：小問題 Claude Code 自己修完直接上線；只有前端的中等問題，發 PR（ 修改提案 ）等人看；牽涉到後端的，就找康富淼討論，或直接 tag 後端的同事。最後康富淼補了一句警語：rrweb 會錄到使用者的整個畫面，有機敏資訊的話，記得要遮起來。

YC、Ian Su、劉詩雁：替還沒想好的人出題

中場休息之後，換 Eval 上場。

YC（ 陳宜昌，Noopher AI 創辦人 ）8/19 那場講的是企業導入 AI 怎麼算錢，這次講的是怎麼衡量自己的系統。YC 的團隊在做簡報產品 Slidra，裡面的 Slidra Agent 會代替你修投影片：改完自己檢查排版、邏輯、美感，沒過就再修一輪。修的輪次當然越少越好。

怎麼讓它越改越好？YC 的方法取自 Anthropic 的一篇文章，兩步：先把量尺做好，再讓 AI 在這把量尺上反覆改。白話講，就是先出一份好考卷，再讓 AI 一次只改一個地方，分數變好就留下、變差就退回，YC 叫它「爬坡法」。

這裡有兩個坑。

第一個是背答案。系統把考過的題目答案記起來，下次一定過，分數看起來進步了，只是背起來而已。所以題目要分成練習題跟期末考，練習的時候，期末考要遮起來，不給它看。

這裡的「早說嘛」恰恰被反過來。對人，我們希望對方早點說；對 AI，有些題目反而要藏好，早說了它本能地會背答案。

第二個坑是改東壞西：改好一處，另一處又壞掉，永遠改不完。YC 的做法是把已經改對的項目設成「護欄」，例如第一輪修好了文字重疊，之後每一輪都不准再讓文字重疊回來。

想試的人，YC 的簡報上列了兩個指令：/claude-api build-eval 建考卷、/claude-api hillclimb 爬坡。出處是 Anthropic 9 月底的文章〈Automating eval design and hillclimbing with Claude〉（ 白話：讓 Claude 幫你出考卷，再幫你一路往上爬 ）。文章裡的用法是先 claude update，簡報上也提醒要先設定好 Claude API 的憑證。

有趣的是，建考卷的第一步，是 Claude 先來「問你真實的狀況」。連出考卷，第一步都是訪談。

（ 這一段分享我跟大師姐 ViVi 有一樣的感覺，難得聽到 YC 講得如此平易近人 XD ）

Ian Su（ Codeer AI CEO ）上台前，主持人介紹說，LLM（ 大型語言模型 ）剛出來的時候，Ian 非常興奮，覺得終於有辦法把高手的本事複製下來，現在反而沒有那麼興奮了。

Codeer 做的是讓專業團隊把自己的工作教給 AI，客戶有獸醫、補習班，也有顧問。這些客戶很怕出錯，Ian 自己是工程師出身，心想這很好解決：用 Eval 就好，列出客戶可能會問的問題跟標準，讓另一個 AI 判斷答得有沒有符合，列個一百題。幾週之後，客戶的回覆是：

我看了五題，我就覺得受不了了。

因為全部都是表格，表格裡面一堆字。

更麻煩的是沒過的題目要 debug。問題不一定出在 prompt，可能是客戶給的知識庫本身就有矛盾，拿來當標準答案的客服紀錄也不一定對。Ian 的結論是：「全部都不一定是對的。」

後來的解法，是把技術全部包起來，客戶只要給一份簡單的工作準則：你喜歡怎樣、你想幹嘛。知識庫裡有兩個地方寫的規則互相打架，就「請 AI 整理一個問卷，然後把那個問卷給客戶」，客戶回答完，AI 再去更新工作準則。

做 Eval 的人，最後發了一份問卷給客戶。

Ian 還舉了一個獸醫的例子。飼主只會說狗狗咳嗽，可是有沒有吐東西、多久咳一次、會不會夜咳，這些醫生想知道的，「飼主自己是不會問的」。

做到九成多之後，Ian 跟客戶說：已經 98% 了。客戶的回答是：

我還是擔心這個客戶會問一些很凶狠或是很奇怪的問題，我也不確定你這個測試集是不是真的所有狀況都測過了。

Ian 的反應是：「那也是合理啊。」於是又做了一個功能：AI 先打一份草稿，客服看了可以按套用，也可以按再次生成、順便講這個答案哪裡不好。這些全部存起來，以後就變成新的測試題。

Ian 最後的三個重點裡，有一句是這樣：

系統性的 performance，還是不代表用戶會覺得安心。

要安心，得讓人真的「坐在那邊，然後去看 AI 回」。

這段跟 Lihsuan 剛好相反。Lihsuan 的客戶說沒問題，Lihsuan 自己不踏實；Ian 說 98%，換客戶不安心。同一種感覺，只是坐的位置對調了。

劉詩雁（ 納曦智能創辦人暨執行長 ）8/19 講的是把 AI 搬進自己的機房，這次講 AI 客服怎麼驗收。客戶給的需求常常很模糊，測完只會說「感覺不太對、回答風格不太好」，或是希望 AI 講話能像阿姨一樣親切。劉詩雁每天在做的，就是「把這些模糊的需求，具體化成一些更貼近規則的東西」。

最難的一點，劉詩雁說，是「你很難去建立什麼東西叫做好、什麼樣的狀況叫做完成、什麼樣的狀況可以叫上線」。早期有客戶 Eval 了大概半年都沒上線，偏偏合約是客戶上線之後才開始收錢：「那就是我們虧啊。」

上線之後更熱鬧。真實的消費者開始問各種沒人想到的問題，早期每天會收到四、五十則：「帥哥，這個能不能調一下。」其中一則是這樣的：有人拿客戶的 AI 去問「我怎麼寫負評來攻擊這個品牌」（ XD，這方法好有創意…… ）

結果 AI 還回答得非常好。

整晚最尖的一個例子，就是這一題。AI 太會答了，連不該答的都答得很好。上線前沒有人想到要出「哪些不能答」這一題，直到消費者自己出了。

講到客戶，劉詩雁直接說，狀況「完全跟上一位講者一模一樣」：漂亮的 Eval 給過去，「1000% 沒有客戶會看」；請客戶調整，大概兩、三週才回來一次。窗口很聰明、也很有意願，就是真的沒有時間。劉詩雁的結論是：

最好的 eval 就是不要讓他看到 eval。

題庫由 AI 自動產生，客戶「唯一的任務」，是看這些資料集對不對、有沒有對齊公司的狀況。這也是劉詩雁這場的題目：別等客戶把你 Eval 掉，我想這也是一種大隱隱於市的概念吧。

所以，為什麼不早說？

七場聽完，有件事很好玩。做 UX 的人，一路在寫評分表：卓致遠要使用者在每個維度打 1 到 5 分，Lihsuan 拿研究問題回頭驗收 AI 的產出。做 Eval 的人，一路在發問卷：Ian 真的發了一份問卷給客戶，劉詩雁每天在把客戶模糊的需求翻成規則（ 這本來是做需求訪談的人的事 ）。

今天這一場的體驗是，不管是 UX 或是 Eval 兩邊都需要使用者，兩邊不只需要人，做到後來，還借了對方的工具。這是我自己的解讀，講者們不一定同意。

為什麼會這樣？因為兩邊卡在同一個人身上：最後說「可以」的那個人。這個人可能是自己，也可能是客戶或使用者。而這個人在看到答案之前，自己也還不知道要什麼。

所以，為什麼不早說？因為連自己都還不知道。這是一個從雙方都看不清，到慢慢聚焦的過程。

以前沒想清楚，事情會卡在半路：草稿爛、做不出東西，人就一直停留在思考的階段。現在 AI 會先交出一份可能很漂亮的東西，漂亮到客戶看過都說沒問題，漂亮到分數有 98%。連教人寫負評，它都答得很好。還沒想好的題目，現在也拿得到一份像樣的答案。

這七個人做的，都是在接這個：AI 交出答案之後，人心裡的那一下反應。Lihsuan 心中的不踏實、卓致遠的「幹，這樣不行吧」、Ian 的客戶那句「還是擔心」，真正的答案，就藏在這些反應裡。

今天這場小聚演講，我最大的反思還是回到「過程」這件事情：AI 很好用，無論你問什麼，它都會試圖接住你，給你一個答案。可是走到答案的過程，仰賴的是你的社會經驗、價值判斷以及各種因素，這也是你之所以是你的原因。

最後補一個反過來的想法。我們常對使用者、對客戶喊「早說嘛」，AI 如果會抱怨，大概也很想對我們喊同一句（ 還是？幹！這樣不行吧 XD ）。

你最近一次對 AI 說「早說嘛」，是什麼時候？那一次，是它沒講清楚，還是你自己也還沒想好？