Apple 前高管對 AI 購物代理持保留態度？Apple 前零售高管 Ron Johnson 近期對矽谷在自主人工智慧（AI）購物代理領域的大規模投資提出了根本性的質疑。儘管技術提供商與創投業者持續推廣能評估庫存並為消費者完成交易的自主代理，但這位協助建立 Apple 實體店網絡的零售架構師認為，這種願景曲解了消費者的決策心理。對於高決策門檻的商品（如高階筆電、專業電子產品、紡織服飾），購買過程仍需深思熟慮的人工評估、品牌信任與親自驗證。在許多高門檻的消費路徑中，代理式商務更適合作為上游的「探索層」，將高意向的購物者引導至商家可控的數位與實體接觸點，並透過原生行動應用程式提供安全、順暢的結帳體驗。
代理式商務的演進時間軸
推動自主購物浪潮代表了數位分發模式的演進。過去兩年間，企業技術平台已將生成式 AI 從對話式搜尋助手擴展為直接的商務中介。在此框架下，自動化助手被設計用來解讀消費者需求、執行跨目錄產品比較並發起採購指令。
+-------------------------------------------------------------------------+ | 零售探索方式的演進 | +-------------------------------------------------------------------------+ | 2000s-2010s: 實體體驗與直接網頁 | | [實體店網絡] --> 門市試用與觸覺驗證 | | | | 2020-2025: 平台聚合與早期 AI 助手 | | [市集 / 聊天機器人] -> 聚合搜尋與外部導流 | | | | 2026: 代理式探索轉型 | | [對話式 AI 層] -> 輔助探索與商家交接 | | (調查顯示僅 7% 用戶允許自主購買) | | | | 當前基礎設施整合： | | [AI 探索引擎] -----> [驗證過後的深度連結] ---> [原生 App] | +-------------------------------------------------------------------------+
核心觀點
- 調查數據揭示消費者猶豫：根據 ACI Worldwide 對超過 3,300 名購物者的調查，僅 7% 的人願意讓 AI 助手在預設條件下進行自主購買，而 53% 的受訪者對「自主結帳委託」表達了明顯的不安。
- 高決策門檻零售需要細膩評估：Ron Johnson 指出，觸覺體驗與個人信心對於高階電子產品購買至關重要，因此 AI 的角色應定位於「探索助手」而非「自主購買代理」。
- 情境路由連接探索與原生結帳：對於將用戶從外部 AI 探索轉移至行動 App 的商家路徑，透過驗證過的 App Links、Universal Links 及延遲深度連結（Deferred Deep Linking）技術，可以有效保留目的地的情境與參數。
行業的技術方向已透過結構化計畫具體落實，例如 Google 的通用商務協定（UCP），該協定標準化了產品目錄、購物車管理、身份識別與結帳結算的機器可讀通訊層，同時保障了商家的參與度。同時，OpenAI 也擴充了對話式購物工具，讓用戶能在對話過程中直接評估產品並導航至商家的庫存介面。
Ron Johnson 於 2000 年加入 Apple，與 Steve Jobs 共同建立了其全球零售網絡。他質疑消費者是否真的會將購買決策權完全移交給演算法。在與《Shop Different: How Retail Revealed Apple’s Genius》相關的分享中，這位前高級副總裁在接受 TechCrunch 採訪時提到，早期的預測在電子商務興起時曾斷言實體店將會消亡，但 Apple 反而選擇透過實體店提供產品演示、親手試用與客戶支援來強化品牌價值。
Johnson 強調，若將價值 1,000 至 2,000 美元的筆電購買決策交給演算法代理處理，而未經過個人親自驗證，將忽視基本的消費行為。購物者通常需要在投入資金前，親自確認顯示品質、實體重量、鍵盤手感與工業設計。
跨國消費者調查反映了此類行為偏好。一項由 ACI Worldwide 針對美國與英國共 3,328 名消費者的調查顯示，僅 7% 的時尚與服飾購物者對在設定條件下（如預算閾值或指定零售商）授權 AI 進行購買感到自在。此外，53% 的受訪者對自主結帳感到不安，而 14% 的受訪者要求必須針對每一筆交易進行手動確認。
雖然消費者看重自動化功能過濾、價格追蹤與推薦選品，但許多消費者仍傾向保留最終購買的授權。當自動化購物流程進入交接階段時，平台必須確保能順暢地將高意向的購物者引導至安全的商家應用程式中，並讓品牌展示與轉換漏斗可靠運作。
技術深度探討：無頭自動化與未授權交接中的摩擦
嘗試透過自動化瀏覽器抓取（Scraping）或無頭腳本（Headless Scripts）執行交易會面臨顯著的技術挑戰。當外部腳本代表用戶與商家店面互動時，其會話特性與一般的用戶操作行為不同，這會對會話完整性與防詐欺檢測造成障礙。
結帳執行：AI 代理 VS. 原生 App
[外部 AI 探索引擎]
|
+--------+--------+
| |
v v
[無頭抓取流程] [程式化深度連結流程]
| |
無頭會話 作業系統級域名驗證
暫時性情境 (apple-app-site-association / assetlinks.json)
無儲存 Token |
| v
x 機器人防禦 [原生行動應用程式]
x 安全牆 * 安全平台金鑰庫（Keychains）
x 會話丟失 * 生物辨識驗證（Face/Touch ID）
| * 已授權結帳
v |
[轉換流失] v
[完成交易]
抓取式無頭自動化的挑戰
執行於伺服器端的無協調無頭會話，通常在缺乏持久性 Cookie 或本地儲存內容的情況下運作。與擁有完整瀏覽歷史紀錄及一致設備標頭的消費者會話不同，抓取式自動化經常循環切換代理伺服器（Proxy）與非標準的 TLS 設定。
Web 應用程式防火牆與安全邊界會監控這些自動化模式。當自動化代理嘗試以程式化方式修改購物車內容或導航結帳漏斗時，安全系統可能會將這些請求標記為自動抓取或憑證測試，從而觸發驗證機制，中斷自動化流程。
身份驗證與支付治理
授權支付需要安全憑證處理，並符合相關監管框架。處理持卡人資料的支付系統仍需遵守 支付卡產業資料安全標準 (PCI DSS)。在對話式代理中儲存與傳輸支付憑證會增加合規範疇，因此許多支付架構採取 Tokenization（代碼化）、託管欄位與單次使用支付憑證，以降低資料曝險。
+-------------------------------------------------------------------------------+ | 自動化腳本設定檔 VS. 原生運行設定檔 | +-------------------------------------------------------------------------------+ | 屬性 | 無頭腳本會話 | 原生應用程式 | +----------------------+------------------------------+-------------------------+ | 會話狀態 | 瞬時記憶體內容 | 持續性安全快取 | | 設備驗證 | 模擬標頭 / 動態 | App/設備憑證 | | 風險評估 | 異常設定檔程度較高 | 已驗證應用程式 ID | | 生物辨識鏈 | 僅限瀏覽器介導 | 原生 Face ID/Touch ID | | 結帳流程 | 通常需額外交接 | 直接在 App 內結帳 | +----------------------+------------------------------+-------------------------+
原生行動應用程式可存取作業系統級的身份驗證元件，包括硬體支援的金鑰庫與生物辨識系統（如 Apple Face ID 與 Android Biometrics）。儘管現代網頁標準（如 Passkeys 與 WebAuthn）已將生物辨識驗證引進行動瀏覽器，但原生行動應用程式維持著預先驗證的用戶會話，讓客戶能以最少的人工重新輸入步驟完成購買。
跨 Web 到 App 的情境保留
對於將 AI 助手作為上游探索表面，並在商家控制的行動體驗中完成交易的零售旅程而言，下一個工程難題是如何在交接過程中保留情境。
當外部平台產生標準網頁 URL 時，在行動裝置上點擊它可能會開啟應用程式內的瀏覽器視窗，導致用戶處於未授權狀態。如果查詢參數在重導向過程中被移除，行動登陸頁可能會顯示 Cookie 提示、登入畫面或通用索引頁面。用戶在 App 內尋找產品的每一步額外步驟，都會增加結帳流失率。工程團隊透過實作「驗證過的深度連結」，將購物者直接轉移至原生 App 環境來解決此問題。
最佳實踐：驗證域名關聯與情境化行動路由
將探索管道連接至原生行動結帳系統，需要符合標準的路由協定。為了避免因脆弱的網頁重導向而丟失追蹤參數，開發人員需實作作業系統級的域名驗證：iOS 上的 Universal Links 與 Android 上的 Android App Links。
+-----------------------------------------------------------------------------+ | 驗證過後的域名到應用程式路由流程 | +-----------------------------------------------------------------------------+ | | | 1. 傳入驗證過的 HTTPS 連結 | | https://shop.brand.com/products/laptop-9050?source=ai_agent&campaign=20 | | | | 2. 作業系統域名關聯檢查 | | Android: 查詢 /.well-known/assetlinks.json | | iOS: 查詢 /.well-known/apple-app-site-association | | | | 3. 路由路徑決策 | | +-----------------------------------+--------------------------------+ | | | 已安裝應用程式 | 未安裝應用程式 | | | +-----------------------------------+--------------------------------+ | | | 標準作業系統 App Link 解析 | 標準網頁備用方案 | | | | 直接派發 App 內意圖 | 開啟備用網頁目的地 | | | | 開啟指定 SKU 頁面 | (無自動化延遲情境) | | | +-----------------------------------+--------------------------------+ | | | | | v | | [選配 DDL 層] | | | | | 下載商店 | | | | | 安裝 | | | | | 首次啟動 | | | | | 恢復合規情境 | +-----------------------------------------------------------------------------+
實作驗證過的關聯域名
現代行動平台使用加密域名關聯來確保只有經過授權的應用程式能處理特定網頁域名的連結。
在 Apple 平台上，開發人員需使用 applinks: 前綴設定「關聯域名（Associated Domains）」權限。網頁伺服器須透過 HTTPS 在 https://domain.com/.well-known/apple-app-site-association 託管一個 apple-app-site-association 檔案，具體步驟請參考 Apple 關於通用連結（Universal Links）的開發者文件：
{
"applinks": {
"apps": [],
"details": [
{
"appID": "TEAMID6E65.com.brand.storeapp",
"paths": [ "/products/*", "/checkout/*" ]
}
]
}
}
在 Android 上，開發人員需在 AndroidManifest.xml 中加入設定 android:autoVerify="true" 的 intent-filter。安裝過程中，系統會比對 https://domain.com/.well-known/assetlinks.json 的清單來驗證域名關聯，詳細請參考 Android App Links 開發者指南：
[
{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.brand.storeapp",
"sha256_cert_fingerprints": [
"14:6D:E9:DE:0F:73:98:E8:83:8E:12:12:36:FA:2F:12:8F:33:80:55:01:A6:DC:05:4B:D5:49:4A:BC:B6:57:02"
]
}
}
]
當平台條件允許解析已驗證的 App Link 時，作業系統會將匹配的連結直接路由至已安裝的應用程式，讓用戶導航至正確頁面，且無需經過未授權的中間瀏覽器跳轉。
透過延遲深度連結（Deferred Deep Linking）跨越安裝界限保留情境
驗證過的 Universal Links 與 App Links 僅在應用程式已安裝時有效。然而，當外部探索連結激發了尚未安裝 App 的用戶購買意願時，標準 App Links 會回退至網頁 landing page 或 App Store 頁面。
標準的 App Store 安裝流程不會自動將預安裝瀏覽器的任意查詢參數傳遞至新安裝的應用程式二進位檔中。儘管平台特定的工具（如 Google Play Install Referrer API）能保留部分支援的推薦人中繼資料，但要跨越安裝邊界傳遞完整的自訂行銷活動情境，通常需要專用的延遲深度連結架構。
商用延遲深度連結平台解決了此生命週期斷層：
- Web 接點情境捕獲：當未安裝的用戶與網頁行銷連結互動時，網頁層會記錄活動參數（如活動 ID、促銷碼與目標 SKU 參考）以及受權的裝置情境。
- 商店路由：用戶被導引至官方平台商店下載 App。
- 首次啟動情境恢復：在應用程式首次啟動時，客戶端 SDK 會聯繫參數伺服器以匹配安裝事件並取回已快取的路由負載。
- App 內導航：應用程式解析取回的參數，將購物者引導至對應的產品或優惠頁面，並套用後端驗證以完成訂單。
架構評估：自建 vs. 採購
工程組織需評估是自行建置深度連結架構，還是採用專門的路由 SDK。能力視提供商與部署模型而異：
| 評估因素 | 內部自建 | 典型託管式深度連結框架 |
|---|---|---|
| 工程範疇 | 需要建置路由、域名驗證與邊緣快取 | 預先設定的 SDK 與標準化 API |
| 邊緣伺服器維護 | 需要管理自訂狀態資料庫與全域同步 | 受支援部署模型下的託管基礎設施 |
| 域名關聯 | 手動設定 AASA 與 assetlinks.json | 提供商協助驗證/託管（如支援） |
| 安裝邊界處理 | 自訂參數快取與匹配邏輯 | 內建延遲深度連結工作流程 |
| 多管道追蹤 | 自訂分析與連結生成服務 | 集中式儀表板與連結管理 |
管理跨平台連結路由的商用框架包括 Branch、AppsFlyer、Adjust 與 OpoInstall。根據廠商文件，OpoInstall 提供延遲深度連結與參數恢復功能，設計旨在將活動參數傳遞跨越 Web 到 App 的安裝旅程，無需手動輸入代碼。
結合驗證過的作業系統連結與延遲參數恢復，工程團隊能維持從外部探索管道到 App 內轉換漏斗的情境連續性。
+-----------------------------------------------------------------------------+ | 技術實作檢查清單 | +-----------------------------------------------------------------------------+ | [ ] 驗證 AASA JSON 結構並託管於 /.well-known/apple-app-site-assoc | | [ ] 使用確切的發布 SHA-256 憑證雜湊配置 assetlinks.json | | [ ] 在合適的 Android 生命週期中處理傳入的 App Link 意圖 | | [ ] 在合適的 iOS 生命週期中處理傳入的 Universal Links | | [ ] 為未安裝用戶流程實作延遲深度連結備用方案 | | [ ] 驗證模擬 App Store 安裝過程中的參數恢復 | +-----------------------------------------------------------------------------+
常見問題 (FAQ)
為什麼消費者對委託 AI 代理進行高單價購買猶豫不決？
Universal Links 與 App Links 如何將購物者引導至原生 App？
如果購物者在未安裝 App 的情況下點擊產品連結會發生什麼？
實際影響與未來展望
Ron Johnson 的觀點突顯了零售業的一項永恆真理：消費者對新技術的採納，取決於人類的決策與信任。雖然人工智慧正在徹底改變探索、產品比較與個人化推薦，但高價值交易仍依賴人類的決策力、實體店體驗與值得信賴的品牌接觸點。
對於工程與成長團隊而言，主要的架構機會在於優化上游 AI 探索與商家應用程式之間的交接流程。將原生行動應用程式視為核心的轉換表面，能讓品牌提供已驗證的會話、安全的生物辨識結帳與具凝聚力的用戶體驗。
隨著對話式助手成為普遍的探索管道，可擴充的商務架構將依賴於可靠的路由基礎設施。實作已驗證的關聯域名、彈性的備用機制與延遲狀態恢復，能確保無論客戶旅程從何處開始，通往最終購買的路徑始終直接且情境完整。
參考資料
-
TechCrunch — 打造 Apple 門市的男人，不看好矽谷對 AI 購物的豪賭
-
ACI Worldwide — 消費者對商業中 AI 觀點的調查
-
Google Blog — 零售商通用商務協定 (UCP) 更新
-
PCI Security Standards Council — 確保 AI 在支付環境中的安全使用
-
Apple Developer Documentation — 支援關聯域名與通用連結
-
Android Developers — 處理 Android App Links 與數位資產連結
-
Android Developers — Google Play Install Referrer API
-
OpoInstall — 開發者文件與 SDK 整合指南
-
OpoInstall — 行動歸因與深度連結概覽
Share this article
