Google AI profile image Stephanie Wong

我們正處於週末 AI 副業的黃金時代。多虧了氛圍編碼和 LLM，你可以在一杯咖啡的時間內，將一個瘋狂的想法從空白畫面變成一個可運作的應用程式。

但當你試圖將這個隨意的原型帶進大型企業環境時，你會撞上一堵牆。僵硬的基礎設施、嚴格的合規規則，以及害怕破壞一切的領導團隊，將扼殺你的動能。

數據相當殘酷：只有 5% 的 AI 原型能夠成功上線。其餘 95% 都消失在企業的煉獄中。

看著社群媒體上的人們快速推出 AI 功能，而你卻困在無止盡的企業審核迴圈中，確實令人抓狂。為了找出如何彌補這道鴻溝，我深入調查了 YouTube 的工程戰壕，看看他們是如何處理這種速度與風險的矛盾。

速度與風險的矛盾

當你獨自開發時，失敗的代價很低。如果你的 AI 代理出問題，你只需要調整提示詞並重新啟動即可。

但在公司內部，讓不受限制的 AI 代理自由運作會造成巨大的影響範圍。在 Emergent 的首集節目中，AI 工程領導者 Addy Osmani 談到在個人專案中同時運行十個代理。由於變更沒有被適當隔離，技術債務立即累積，並且災難性地破壞了兩個應用程式。

現在想像一下這種風險在 YouTube 規模下的情況，你需要在 20 年前的程式碼庫上處理數十億用戶。你不能讓實驗性程式碼隨意運作。但傳統的合規管道需要數月時間，而當你的演示真正獲得批准時，AI 模型已經演進，讓你的功能變得過時。

進入 YouTube 的 AI 原型堆疊

Benji Bear，Google Deepmind 和前 YouTube 工程師，通過徹底改變基礎設施理念解決了這個問題。他的團隊沒有試圖加速手動審核，而是將實驗與主流生產伺服器解耦。

他們建立了一個原型堆疊，解決了開發人員的兩個最大瓶頸：

  • 安全的即時資料層：開發人員不再使用假資料在真空中測試，而是使用 Google AI Studio 範本來啟動想法。這些範本連接到安全的 Google Cloud 代理伺服器，提供對即時元件（如播放清單、影片和頻道）的預先驗證唯讀 API 存取。你可以獲得技術準確性，而沒有污染或損壞核心資料庫的風險。

  • 即時 UI 注入：為了了解功能對真實用戶的實際感受，開發人員使用客戶端擴充套件包裝器將實驗性 UI 直接注入到他們的本地瀏覽器中。它與生產程式碼完全隔離，這意味著更新可以在幾分鐘內安全地進行分階段和測試。

通過轉換到這種設定，YouTube 從需要四分之一的時間來驗證單一功能，變成在數週內將幾個成功的原型（如 YouTube Recap）直接推送到使用者研究研究。

擁抱可拋棄程式碼

要讓這件事運作，需要相當大的心理轉變：你必須擁抱可拋棄的程式碼。

作為工程師，我們被訓練要編寫完美、永久的基礎設施。但原型程式碼應該是混亂的。它唯一的目標是驗證用戶是否真正關心這個功能。試圖清理並強迫混亂的 AI 生成腳本直接進入企業程式碼庫是一個架構陷阱。

相反，你可以使用 Google AI Studio 在第一天就建立一個高度準確的基線。運行你的使用者測試，查看資料，如果想法成功，就丟棄混亂的腳本。因為你已經證明基線參數有效，所以為生產環境重寫乾淨版本會變得更快、更便宜、更安全。

快速移動而不破壞東西

95% 的失敗率不應該被視為錯誤——它應該是策略。AI 讓生成程式碼變得非常便宜，將我們的角色從語法守門員轉變為系統架構師。

我們現在的工作是設計唯讀沙箱和隔離管道，讓我們的團隊能夠以超高速安全地失敗。最大的風險不是用混亂的 AI 程式碼破壞伺服器；而是因為驗證迴圈太慢而錯過技術浪潮。

要查看完整技術分解、開發人員訪談以及 AI 原型堆疊的深入探討，請在 YouTube 上查看 Emergent 的首集節目。