AI 系統上線前，你測過這些嗎？Taco Bell 和 McDonald's 的慘痛教訓

AI 系統上線前，你測過這些嗎？Taco Bell 和 McDonald's 的慘痛教訓 目錄 1. 18,000 杯水讓 Taco Bell AI 系統崩潰 2. McDonald's AI 招聘系統密碼是 123456 3. 兩個事故的共同根源 4. AI 系統的測試盲點在哪裡 5. 測 AI 系統，QA 要問的問題 18,000 杯水讓 Taco Bell AI 系統崩潰 2025 年，Taco Bell 在多間分店導入 AI 語音點餐系統，讓顧客在得來速直接跟 AI 說話點餐。 系統上線後跑得很順。AI 能辨識各種口音，能處理客製化需求，能推薦加購項目。測試通過，產品滿意，大規模推廣。 然後有人點了 18,000 杯水。 這不是真的要喝 18,000 杯水——是網路上流行的惡作劇，專門針對 AI 點餐系統。那個數量讓系統的訂單處理邏輯陷入無限迴圈，最終整個系統掛掉，分店被迫回到人工點餐。 影片在社群媒體上瘋傳。 McDonald's AI 招聘系統密碼是 123456 同年，McDonald's 使用第三方 AI 招聘平台 McHire 來處理求職者的初步篩選和面試安排。這個系統儲存了大量的應徵者資料，包括姓名、電子郵件、電話號碼和面試對話記錄。 後來有安全研究員發現：這個平台的後台管理介面是對外開放的，而且 admin 帳號的密碼是 123456。 不需要任何技術手段，直接登入，就可以看到 6,400 萬筆應徵者的個人資料 。 這不是複雜的攻擊，不是零時漏洞，不是精心設計的滲透。是一個任何人都可以想到去試的密碼。 兩個事故的共同根源 這兩個事故表面上看起來不一樣——一個是功能崩潰，一個是安全漏洞——但根源是同一件事： 測試只覆蓋了「正常使用者」，沒有測試「不正常使用者」。 Taco Bell 的 AI 系統肯定測試過：一個漢堡、兩個漢堡、不要洋蔥、加大杯可樂。這些都過了。但沒有人問過：「如果有人點了一個荒謬的數量呢？如果輸入完全超出預期的範圍呢？」 McDonald's 的招聘系統肯定測試過：求職者登入、查看職缺、完成問卷。但沒有人問過：「後台管理介面有沒有做存取控制？密碼是什麼？有沒有辦法從外部直接訪問？」 這就是 AI 系統測試最大的盲點： 邏輯測試和安全測試，常常被當成兩件分開的事，甚至被當成不重要的事。 Capgemini《World Quality Report 2024 25》的數據顯示，73% 的受訪組織表示尚未建立針對 AI 功能的完整測試策略——在 AI 系統快速商業化的同時，測試方法卻還停留在傳統軟體的思維框架裡。 AI 系統的測試盲點在哪裡 盲點一：只測 Happy Path AI 系統的開發過程通常是：訓練模型 → 調整效果 → 達到可接受的準確率 → 上線。 測試的重點放在「模型表現是不是夠好」，而不是「使用者能不能用奇怪的方式讓它壞掉」。 傳統軟體的 QA 思維是：找邊界值、找異常輸入、找非預期的操作路徑。這些思維在 AI 系統上更重要，因為 AI 接受的輸入更開放、更難預測。 盲點二：第三方 AI 工具的安全測試被跳過 McHire 是第三方供應商提供的工具。McDonald's 的決策者大概認為：「這是他們的系統，安全是他們的責任。」 但資料是你的。洩漏出去之後，受影響的是你的使用者，監管機關找的是你，賠償的是你。 導入任何外部 AI 系統之前，供應商的安全性是你的責任，不是他們的承諾。 盲點三：Prompt injection 和對抗性輸入沒有測試 Taco Bell 的案例是一個純粹的「誇張輸入」——系統沒有限制輸入的合理範圍。 更危險的是 prompt injection：使用者輸入的內容可以改變 AI 的行為，繞過設計好的邏輯限制。這在各種 AI 客服、AI 助手、AI 表單填寫系統上都是已知風險，但很少被納入測試範圍。OWASP 已將 Prompt Injection 列為《OWASP Top 10 for Large Language Model Applications》的第一大安全風險——在 QA checklist 裡，這一項幾乎是空白的。 測 AI 系統，QA 要問的問題 下次你在測一個 AI 功能或導入一個 AI 工具，可以把這些問題帶進去： 邊界和壓力： 輸入一個完全不合理的值（超大數字、超長字串、空值、特殊字元），系統怎麼反應？ 系統有沒有設定輸入的合理範圍？超出範圍有沒有 graceful error 處理？ 有沒有 rate limit？短時間大量請求系統怎麼反應？ 對抗性輸入： 有沒有試過讓使用者的輸入改變 AI 的行為（prompt injection）？ 有沒有試過讓 AI 說出它不應該說的話（jailbreak）？ 有沒有試過輸入可能被當成指令的內容？ 安全和存取控制： 第三方 AI 供應商的後台有沒有做存取控制審查？ 系統儲存了什麼資料？在哪裡儲存？誰可以存取？ 如果 API key 外洩，攻擊者可以做什麼？ 降級和例外處理： AI 不確定的時候，系統怎麼處理？會不會亂猜？ AI 崩潰或 API 超時的時候，有沒有 fallback 機制？ 有沒有人工介入的路徑？ 這些問題不需要你懂 AI，需要的是你帶著「怎麼把它搞壞」的 QA 思維去看一個新系統。 AI 系統不是測不了，是我們還在用測傳統軟體的方式去測它。 參考資料 1. OWASP Top 10 for Large Language Model Applications — LLM 應用的十大安全風險，含 Prompt Injection 的詳細說明 2. Capgemini World Quality Report 2024 25 — AI 功能測試策略成熟度的全球組織調查 3. Google Testing Blog — AI 系統測試思維與傳統軟體測試的比較實踐 4. DORA 2024 State of DevOps Report — 安全測試整合與軟體交付效能的關聯研究 5. 9 Biggest Software Bugs of 2025 TestDevLab — 2025 年重大軟體事故案例彙整，含 AI 系統相關事故