Airbnb 表示，接近 60% 的工程程式碼已有 AI 參與。
這個數字很適合成為標題，卻不適合直接拿來管理產品團隊。更值得追蹤的是上一層結果：部分關鍵專案從概念到交付最多縮短 60%；2026 年上半年推出的功能與改善項目，較去年同期接近增加 80%；從 AI Assistant 開始的客服問題中，近 45% 不需人工即可解決；每筆預訂的客服相關成本則年減約 16%。
這些數字不能證明 AI 自動做對了所有產品判斷。它們顯示的是：當 Agent 被放進一套可管理的交付系統，執行可以變得更快、更便宜。
從 Buda 的官方產品視角來看，AI-native 團隊不是把所有決定交給模型。人負責目標、邊界與驗收，Agent 負責持續執行；上下文、過程檔案與結果都必須可見、可追查。
三種 AI 場景，三種證據成熟度
Airbnb 同時披露產品研發、客戶支援與 AI 搜尋的進展。三者都用了 AI，卻不能寫成同一種「成功」。
產品研發已有交付證據。 Airbnb 表示，部分關鍵專案從概念到交付最多加快 60%，上半年推出的功能與改善接近增加 80%。公司將變化歸因於 AI、團隊能力與更好的執行共同作用，並未全部算在模型上。
客戶支援已有營運證據。 近 45% 只適用於「從 AI Assistant 開始」的問題。Airbnb 沒有披露全部客服問題中，有多少先進入這個入口。每筆預訂的客服相關成本下降約 16%，官方也只說其中一部分由 AI Assistant 的改善所帶動。
AI 搜尋只有測試證據。 Airbnb 準備保留傳統搜尋作為預設入口，只讓少量使用者透過開關進入自然語言搜尋。目前尚未公布轉換率、預訂增量或留存結果。
這三個階段分別代表交付效率、營運結果與早期實驗。把證據分開，比籠統地說「Airbnb 全面用上 AI」更有用。
程式碼更多，不等於產品更快
如果 AI 寫出更多程式碼，但需求仍然模糊、測試仍然薄弱、上線仍卡在原本的審批隊列，團隊只是增加產出，沒有改善系統。
產品速度應從一個決定開始，直到拿到可靠證據為止。它包含研究、需求、實作、測試、發布、指標觀察與修正。AI 可以降低每一步的執行成本，卻不能替產品負責人決定哪個使用者問題值得做，或什麼失敗程度必須停止。
因此 Airbnb 更有意義的數字，不是「60% 的程式碼」，而是部分專案從概念到交付更快，更多改善真正到達使用者手上。
交付變快，應該換來更多有效試錯
縮短交付週期的價值，不只是多發幾個版本，而是增加把判斷放到真實世界驗證的次數。
一套可管理的 Agent 產品流程可以這樣運作：
- 人定義使用者問題、成功指標、限制條件與發布邊界。
- Agent 蒐集證據、整理需求、執行實作、進行檢查並準備交付檔案。
- 人審核證據，決定繼續、修改或停止。
- 團隊觀察線上結果，再把失敗與新資訊帶回下一輪。
執行越快，人的判斷越重要。一個錯誤需求，現在可能很快產生一整套看似專業的研究、程式碼、文案和客服回覆。速度需要更明確的審核點，而不是更少的責任。
AI 搜尋的開關，是良好的發布邊界
Airbnb 沒有立刻讓 AI 搜尋取代所有人熟悉的地點、日期與篩選條件，而是先做小流量、可切換測試。
這讓舊流程繼續可用，也讓新體驗能被比較。願意嘗試的使用者主動進入，產品團隊先觀察自然語言搜尋是否改善探索效率，再決定是否擴大。
Agent 一旦要改變客戶可見的流程，就應先限定任務、保留可逆入口，並預先定義結果指標。內部展示成功，不等於可以直接成為預設產品行為。
客服案例說明：轉交給人也是產品的一部分
Airbnb 的數據不是「AI 取代了 45% 的客服」。它的分母較窄：從 AI Assistant 開始的問題。
真正的產品不只是回答問題的模型，還包括周圍的分流系統。標準問題應快速解決，爭議、異常與高風險情況則要帶著完整上下文交給人。
客服 Agent 至少要同時觀察：
- 自主解決率
- 錯誤升級與錯誤攔截
- 解決時間
- 每次諮詢或每筆業務的成本
- 重開案件、客訴與滿意度
成本下降只有在服務品質沒有同步下降時才有意義。
Buda 如何把 Agent 產出變成交付系統
Buda 圍繞持續存在的 Agent Workspace 組織工作，而不是一次性聊天。團隊可以把來源資料、需求、歷史決定、生成檔案與失敗記錄放在同一個專案中。Agent 使用可重複的 Skills 按固定方法執行，在沙箱中操作檔案與工具，並留下完整過程供人審核。
這套分工很清楚：
- 人設定意圖： 選擇問題、指標、限制與審批邊界。
- Agent 執行： 研究、整理檔案、起草、測試、比較與準備交付物。
- Workspace 保存上下文： 輸入、中間檔案與結果不再散落於不同工具。
- 審核決定流轉： 高影響結果只有在人檢查證據後才能進入下一步。
- Skills 與 Automations 固化方法： 跑通的流程可以重複執行，不必每次重寫提示詞。
Buda 不會替產品負責人決定功能是否該上線。它減少的是從決定到證據之間的執行損耗。
查看 Buda Agent Workspace，或在 Buda 中開始建立可管理的 Agent 工作流程。
最值得保留的管理指標
Airbnb 這次披露最有價值的，不是某個程式碼比例，而是管理單位發生了變化。
不要只問 AI 產出了多少。要問團隊多久拿到可審核結果、人在哪一步發現錯誤、客戶行為發生什麼變化，以及成本下降時品質是否仍被守住。
Agent 會讓執行愈來愈充足。稀缺的仍然是人的產品判斷。