Tony Alicea 在 NN/g 2026-11-13 發表〈Research-In-The-Loop: How UXR Adapts to Development at AI Speed〉,主張 AI 編碼代理讓「先上線再學」成為常態之後,使用者研究不該消失,而要改成跟著每次發佈運轉:由研究先定義這次發佈要收集什麼,功能與埋點一起做,上線後再研究結果、回頭寫下一輪需求。讀到的程度:我透過網頁擷取讀到文章全文的摘要,沒有逐字核對原文;文章本身不含統計數字,下面標明「我的判讀」的部分是推論。

📖 學

一、問題:發佈只告訴你發生什麼

文章的出發點是建置成本下降。程式碼改動變便宜,團隊傾向先發佈、再看結果,這削弱了漫長前期研究的理由。但文章指出:「發佈告訴你發生了什麼,卻很少告訴你為什麼。」所以研究要改變節奏,而不是退場。

二、三種研究活動

  • 評估(evaluation): 這次改動有沒有產生預期結果、有沒有帶來預期中的問題,靠預先定義好的指標埋點追蹤。
  • 探究(investigation): 使用者為什麼這樣做,通常是從資料異常出發,再用質性研究追根。
  • 探索(discovery): 團隊沒料到的需求或問題,要靠開放式研究,不綁發佈節奏,埋點取代不了。

三、具體做法

第一,在產品規格裡加一節「研究」:預期結果、成功的徵象、傷害的徵象、要追蹤什麼、何時該去跟人談。文章的例子是客服系統讓部門之間直接轉單,規格以部門(而非個人)為單位追蹤轉手次數,若某部門退回的比例異常高,或單子卡在那裡,就觸發情境訪談。

第二,研究工具跟功能一起做。事件紀錄、儀表板、攔截式問卷、針對該次發佈的回饋按鈕,都可以請編碼代理低成本生成。

第三,質性研究用三種觸發來平衡:固定節奏(例如每週,不綁發佈)、訊號(發佈資料或回饋的異常)、決策(定價或敏感資料處理這類難以回頭的選擇,要先有證據;原型可以由代理快速做出來)。

第四,技能要更新:用 markdown 寫規格、指揮編碼代理並檢查產出、理解分析埋點、管理資料存取。文章強調提問、避免偏誤與研究倫理這些核心功夫更重要而非更不重要。

建議從小處開始:盤點使用者訊號分布在哪裡,寫一個研究章節給產品團隊看,完整跑一次發佈。

四、文章自己列出的限制與未解問題

規格只說明要量什麼,並不能證明因果;有效的評估可能需要對照組、樣本量與觀察期。指標本身也要檢查是否真的反映預期結果,文章舉例:解決時間變短,可能只是排隊等候變短,而不是每張單的處理時間變短。人力調度、季節性單量等干擾因素也要考慮。未解問題包括生成式與長期研究的位置、整體系統層級的影響怎麼評估、AI 整理資料時如何避免偏誤與憑空編出的模式、研究需求由誰負責,以及埋點多到什麼程度會變得有侵入感、像監控。

五、我的判讀

我的判讀:這篇最實用的是「研究章節」這個交接物,它把研究從會議變成規格裡的欄位,和上一週 NN/g 談的 agent harness、UX 在軟體工廠裡的角色是同一條脈絡。但有兩點要保留。第一,文章全是方法主張,沒有任何實證數據顯示這樣做比傳統流程好,屬於專家意見。第二,「埋點加回饋按鈕」偏向行為與滿意度訊號,對於使用者根本沒開口的需求,文章自己也承認要靠探索研究,這部分沒有被自動化。

🧠 記

  • 來源: NN/g,Tony Alicea,2026-11-13。
  • 概念: research-in-the-loop,研究定義埋點、代理建置、研究解讀、回寫需求。
  • 三種活動: 評估、探究、探索(探索不能被埋點取代)。
  • 三種觸發: 節奏、訊號、決策。
  • 規格研究章節五項: 預期結果、成功徵象、傷害徵象、追蹤項目、何時找人談。
  • 數字: 文章無統計數字;以上全是方法描述。

✍️ 實踐

挑一個最近一次或即將上線的功能,為它補一段研究章節,控制在半頁內。寫下預期結果,以及一個「成功的徵象」與一個「傷害的徵象」;列出要追蹤的事件,單位選對(例如以部門而非個人);最後寫一條明確的觸發規則,例如某個數值超過什麼範圍就安排一次訪談。上線兩週後回頭看,是否能解釋「為什麼」,還是只知道「發生了什麼」,並記錄哪些問題只能靠找人談才有答案。

🔗 延伸學習

💬 問 AI

我的團隊用 AI 編碼代理快速發佈 [某功能],目前只看使用量儀表板。請依 research-in-the-loop 的概念幫我:1) 為這個功能寫一段產品規格的「研究」章節(預期結果、成功徵象、傷害徵象、追蹤事件與分析單位、何時該找使用者談);2) 設計三種質性研究觸發(固定節奏、訊號、決策)各一個具體例子;3) 指出我的指標可能被哪些干擾因素誤導(例如人力、季節),以及需不需要對照組;4) 列出埋點可能讓使用者覺得被監控的地方與緩解方式;5) 標明哪些是研究方法的常規做法、哪些只是專家主張。