DOTS demo 重來一次｜OpenAI DevDay 2026 ☕ Buy me a coffee

🧑‍🏫 這支影片是講者把前一天搞砸的現場示範重做一次：她直接打電話給自己的 DOT（OpenAI 的 AI 助理產品），一口氣交辦訂機票飯店、整理使用者回饋、草擬 Slack 回覆三件事。值得看的地方是它沒修飾，你能看到 AI 助理實際工作時會主動查證、會講自己還不確定什麼。

• 00:00 前一天的發表 demo 沒有照計畫進行，所以今天重新示範一次；demo 的重點是展示 DOTS 能用在真實工作、真實發表上。
  ↳ 前一天上台示範出包了，所以今天再來一次。目的不是炫技，而是證明 DOTS 這個 AI 助理真的能拿來做正經工作。
• 00:00 講者說 DOTS 確實已經推出，她自己也真的有很多事要做，所以直接不修飾地展示她平常怎麼用自己的 DOT。
  ↳ 她不走排練好的劇本，直接拿自己手上真的要處理的事來示範，等於讓大家看她平常怎麼用。
• 00:32 示範從打電話給 DOT 開始：講者明天臨時要去 LA，想讓 DOT 幫她先處理掉一堆事情。
  ↳ 用法是「打電話」交辦，像打給助理一樣用講的。情境是明天臨時要出差去洛杉磯，一堆事要先處理。
• 00:32 需求一：明天在 LA 有重要會議，下午 3 點左右要到 Hollywood，最晚上午 10 點才能離開辦公室。
  ↳ 她先講清楚時間限制：最早 10 點能離開辦公室、下午 3 點要到 Hollywood。給 AI 的條件越明確，它越不會亂訂。
• 01:02 需求二：訂一班符合公司政策（on policy）且可退款的航班，並找 East LA 的飯店選項。
  ↳ on policy 是「符合公司差旅規定」，例如票價上限；refundable 是「可退票」。她另外要找洛杉磯東邊的飯店。
• 01:02 需求三：要看飯店的截圖來挑選，也要飯店在 Google Maps 上位置的截圖，方便看能不能順便找人碰面。
  ↳ 她不要只聽文字描述，要看飯店照片和地圖位置的截圖，自己判斷住哪裡順路、能不能順便約人。
• 01:33 DOT 回覆會確認航班同時符合政策且可退款；被問到目前首選時，說先前看到的是 Southwest 11:30 起飛、12:55 抵達的可退款航班。
  ↳ DOT 先複述條件確認沒聽錯，再報目前看中的班機：西南航空 11:30 飛、12:55 到，可退票。
• 02:03 DOT 主動說明還需要驗證結帳總額與是否符合政策。
  ↳ 它沒有直接說「搞定了」，而是主動講還有兩件事沒查完：結帳的實際總價、是否真的符合公司規定。
• 02:03 飯店方面，DOT 提出 Silver Lake Pool and Inn 是最合適的選項，Kara 是另一個領先選項、離 Hollywood 較近。
  ↳ 飯店它給了一個首選和一個備案，並說明備案的優點是離開會地點比較近，讓她自己取捨。
• 02:03 講者問若 1 點降落能否 3 點前到 East Hollywood；DOT 說航班準時且直接過去的話大概可以。
  ↳ 她反問：1 點才落地，3 點前趕得到嗎？DOT 的回答有附條件：班機準時、下機直接過去，才大概可以。
• 02:37 DOT 估算：離開 LAX 約 30 到 45 分鐘，車程約 45 到 75 分鐘，並建議降落時間接近中午會比較保險。
  ↳ 它把時間拆開算：出機場半小時到 45 分鐘，車程 45 到 75 分鐘。算下來很緊，所以建議改搭中午前後落地的班機。
• 02:37 講者同意改成接近中午抵達，DOT 表示會依這個條件重新查詢，同時在抓飯店截圖。
  ↳ 她接受建議，DOT 就用新條件重查班機，同時繼續抓飯店截圖。也就是它能一邊改需求、一邊做別的事。
• 03:08 講者說她靜音時最喜歡做的事之一，是看她的 DOT 的 browser。
  ↳ browser 是瀏覽器。她的意思是可以直接看到 DOT 在網頁上點來點去查資料的過程，知道它現在在做什麼。
• 03:08 DOT 補充先前看到的另一班 Southwest 是 11:20 抵達，緩衝時間較充裕；正在確認是否仍有符合政策的可退款票價，並會把飯店照片和地圖傳到 chat。
  ↳ DOT 想起另一班 11:20 就到的班機，時間更寬裕，但還要確認有沒有合規又可退的票。照片和地圖會傳到聊天視窗。
• 03:49 講者看了照片後決定選 Silver Lake Pool and Inn。
  ↳ 照片傳來後，她看了一眼就決定住首選那間。挑選這件事還是人自己做，AI 負責把資料備齊。
• 03:49 DOT 還在處理訂位時，講者接著交辦第二件事：user feedback 頻道內容太多，希望有更具體的 workflow 來收集。
  ↳ 機票還沒訂完，她就接著交辦第二件事：使用者回饋的頻道訊息太多，想要一套固定的做事流程（workflow）來整理。
• 04:24 她想知道三件事：回饋的最大主題是什麼、最迫切的問題是否已有解法、有哪些還沒人足夠關注的未解事項，請 DOT 整理分析。
  ↳ 她要的不是摘要，而是三個答案：大家最常抱怨什麼、最急的問題有沒有人在修、哪些問題被忽略了。
• 04:24 DOT 說上一版 dashboard 只有 baseline，會整理主要主題、修復與缺口，並把收集 workflow 具體化。
  ↳ dashboard 是把資料彙整在一頁的儀表板；baseline 是初步的基本版。DOT 說舊版太陽春，這次會整理得更完整。
• 04:55 目前的收集流程是手動的新頻道批次：讀頻道回報與回覆、把每項放進 master list、分類分組，再把實際問題連到已驗證的 Linear ticket。
  ↳ 現在的做法是人工分批做：讀頻道訊息、全部登記到一份總表、分類，再連到 Linear（工程團隊管待辦問題的工具）上的工單。
• 05:27 流程也會把 ticket 對應到 PR，追蹤修復是進行中、已上線或已重測；dashboard 只是彙整這些工作，不會自動擷取新訊息，且 ticket 對帳仍未完成。
  ↳ PR 是工程師送出的程式修改。流程會追每張工單修到哪。但 DOT 坦白說：儀表板不會自動抓新訊息，工單核對也還沒做完。
• 05:27 講者認為手動跑回饋流程沒關係，更重要的是掌握目前沒有解法的大問題。
  ↳ 她不在意流程是不是全自動，手動跑也行。她真正在乎的是：有哪些大問題到現在還沒人解。
• 05:57 她要求：當 PR 合併且預期解決了某個大的回饋主題時，由 DOT 到 Slack 回覆、附上 PR 連結，請使用者再試一次。
  ↳ 她加了一個要求：某個大問題的修正一併入正式程式，DOT 就去 Slack 回覆當初反應的人，附上連結請他們再試一次。
• 05:57 DOT 確認作法：先依「沒有可信修復的最大問題」排序，再用附 PR 連結的回覆請大家重試來收尾。
  ↳ DOT 複述做法：先把「還沒有可靠修法的大問題」排最前面，修好後再回頭通知大家重試。
• 06:27 DOT 指出重測（retest）才是確認真正閉環的關鍵，而這部分一直做得不一致；會把沒有修復的主題列為優先，並在修復推送給使用者後於討論串跟進。
  ↳ retest 是修完後請人再測一次。DOT 指出沒重測就不算真的解決，而這步過去常被漏掉，所以它會在修正上線後回去追。
• 06:57 過去 24 小時最明顯的問題是 reliability：DOT 看起來在運作，但沒有回覆或無法存取工具。DOT 說在斷定這是數量最大的主題前，還在檢查完整排名。
  ↳ reliability 是穩定度。最近一天最明顯的抱怨是 DOT 看似在跑，卻沒回應或用不了工具。但它說還沒核對完，先不下定論。
• 06:57 DOT 目前最強的判讀是：使用者分不清自己的 DOT 是否真的在工作，包含漏回覆、工具存取失敗、進度不明；有些是真問題，有些是可見度問題。
  ↳ 它目前的判斷是：使用者搞不清楚 DOT 到底有沒有在做事。有些是真的壞了，有些其實有在做，只是使用者看不到進度。
• 07:30 講者請 Drew 把畫面拉近，讓大家看 DOT 在搜尋 repositories 時的可愛動畫。
  ↳ repositories 是存放程式碼的地方。這段是輕鬆的插曲：她請同事把畫面放大，讓大家看 DOT 搜尋時的小動畫。
• 07:30 第三件事：go to market 動作很多，大家想知道 dots 與其他已推出項目（如 ChatGPT、Slack 與 Teams）之間的關係，請 DOT 整理她最重要的未回覆 Slack 訊息並草擬回覆。
  ↳ go to market 是產品上市推廣。很多人在問 DOTS 和 ChatGPT 等產品的關係，她請 DOT 挑出最重要的未回訊息並先擬好回覆。
• 08:07 講者小結：DOT 還在訂航班、已找到飯店，她從照片中挑了一間；DOT 也了解正在實作的回饋流程，會優先處理她最新交辦的事。
  ↳ 她整理一下進度：機票還在訂、飯店已選好、回饋流程 DOT 已經弄懂。三件事同時進行，最新交辦的會先做。
• 08:41 DOT 傳訊息回報回饋的最大類別：reliability（團隊正在處理），以及 mobile 與通知相關的 UX polish。
  ↳ DOT 回報回饋的兩大類：一是穩定度問題，團隊已在處理；二是 UX polish，也就是手機版和通知這類使用體驗的細節修整。
• 08:41 最後講者決定叫 DOT 再跑一次 feedback flow 看看結果。
  ↳ 最後她請 DOT 把回饋整理流程再跑一次，看看結果如何，示範到這裡結束。

根據 DOT 的說明，過去 24 小時內最明顯的使用者回饋問題是什麼？