Y COMBINATOR · STARTUP SCHOOL
Waymo 共同執行長 Dmitri Dolgov 的重點不是「自駕 AI 看起來多聰明」，而是：當模型要在真實道路做決定，產品化必須把錯誤成本、延遲、資料與驗證一起設計。
原始發表日期：2026 年 8 月 3 日 · 49 分鐘
PART 1 · DEMO 與產品之間
Dolgov 以 Waymo 的長期研發經驗指出，一個可以運作的 demo 往往只處理了最容易被看見的情境。真正的產品則要面對罕見、互相交疊、而且不能預先寫好腳本的例外：其他駕駛突然切入、道路施工、感測不確定性，以及每個路口都有不同的社會互動。
這不是貶低 demo 的價值。demo 能證明方向值得探索；但它不是可靠性的證明。把兩者混在一起，會使團隊只為發表時刻優化，而忽略使用者每天都會遇到的長尾。
PART 2 · 實體 AI 的四道缺口
演講把實體 AI 與純數位 AI 的差異拆成四項：錯誤成本、反應延遲、資料，以及驗證。語言模型或聊天工具的失誤，常常可以由使用者修正；車輛的判斷失誤則可能沒有撤回按鈕。車速下的每一毫秒，都改變了可用的反應距離。
他也提醒，實體世界沒有一個現成、完整而已標註的「道路版網際網路」可直接拿來訓練。資料必須在安全限制中收集、擴充與檢查，不能把真實使用者當成未驗證版本的測試者。
PART 3 · 安全不是減速，而是另一種產品速度
這是 Dolgov 的產品判斷：面對原子而非位元，團隊不能以破壞作為學習機制；更合理的要求是「快速移動、安全交付」。這不表示不迭代，而是把安全作為模型、資料、硬體、營運與回饋流程共同滿足的前提。
因此，安全不能只是一個發布後監看的 KPI。它需要事先定義失敗類型、可接受邊界、人工與自動化的交接，以及發現新情境後如何回饋到訓練與測試。
PART 4 · 模擬是閉環，不是表演
Waymo 的脈絡中，模擬讓團隊能建造大量、逼真的交通互動，既用來訓練，也用來檢查行為。它的價值不是產生一支好看的影片，而是讓不同版本能在同一組高風險案例中比較、重現與退回。
這個原則也適用於較一般的 AI 產品：若系統會影響權益、金錢、健康或公共安全，團隊需要可重放的案例、明確的驗收條件與停止機制，而不是等真實使用者暴露每一個邊界。
「demo 解決的是：它能不能動？
產品必須回答的是：它能不能在真實世界持續、安全地動？」
選一項，把「看起來能用」轉成下一步可驗證的工作。