17 分鐘看完 Google AI 課程 Day 4+5 完結篇，安全與驗收

影片開場的故事深刻說明了 AI Agent 的核心風險：一位工程師要求 AI 加個按鈕，AI 不只加了，還自己按下去，在沒人指定郵件系統的情況下，它從 Context 中撈到一個廢棄服務的地址，自作聰明接上去，導致 50 位同事收到烏龍信。這種 Context Hallucination 現象顯示，AI 不會在缺乏資訊時坦白說不知道，而是用手上的現成素材拼湊出答案完成目標。如果把寄信換成刪資料庫或轉帳，笑話就變成了災難。

解決之道的第一步是 Spec-driven Development。在 AI Agent 時代，工程師角色從寫程式的人變成了畫藍圖的建築師，大部分時間不再花在敲代碼，而是寫 Spec——告訴 AI 要做什麼的詳細技術規格。一份好的 Spec 必須清楚交代五件事。做什麼就是你的需求本身；為什麼做是背景脈絡，讓 AI 知道最終目的後能主動補齊你沒想到的步驟；用什麼做要特別註明工具和版本號，因為 AI 容易靠過時記憶選舊版本；什麼不能碰是你的底線，例如資料庫絕不能動、正式環境不能碰；什麼叫完成則要用「當使用者輸入正確帳密按登入後，應該進到首頁；若密碼錯誤應跳出提示；連錯十次帳號應被鎖」這樣的格式，把好情況和壞情況都寫清楚。Spec 的格式選擇也會影響 Model 的理解效率——根據 2026 年的研究，格式未優化時 Agent 表現最多相差 40%，因為模型逐字讀入，層層嵌套的 JSON 全是分心。建議用 Markdown 寫說明文字以便快速掃讀，用 YAML 寫結構化資料以降低解析負擔。

但 Spec 再完美，AI 還是會出錯，因為它本質上是概率模型，永遠有一定機率走歪。第二個防線是零信任架構的三層防護。第一層 Sandbox 把 AI 的執行環境完全隔離，它可以在裡面隨意删檔、亂裝套件、執行任何代碼，但這一切只發生在用完即丟的隔離房間裡，你的電腦和正式環境毫髮無傷。第二層是對部署到產品、改資料庫結構、任何涉及金錢的操作設置簽核關卡——Agent 走到這裡必須停下來等人點頭。但這裡有個陷阱：人類如果看到幾百行看不懂的代碼只能反射性地按同意，簽核就變成了空洞儀式。解決方案是 Vibe Diff，在簽核前把代碼翻譯成白話文，告訴你原始要求是什麼、實際上打算做什麼，兩邊對得上才批准。第三層是嚴格控制依賴套件，防止 Slopsquatting 攻擊——駭客發現 AI 寫代碼時常幻覺出不存在的套件名稱，就搶先用這些名字上架真正的惡意套件，等著某個 Agent 自動幫你裝進專案。防法很直接：套件只從公司核可來源安裝、版本號鎖死、上線前用 CI 再掃一次。

驗收系統是第三道防線。傳統軟體的二元測試——給這個函數這個輸入就應該吐這個輸出——對 Agent 不適用，因為 Agent 可以單位測試全過，實際任務裡卻選錯工具或把關鍵回答改寫到跑題。所以需要 Observability 加上 Evaluation。首先建立可觀測性，記錄 Agent 的整趟工作過程（哪些步驟跑了）、每一步的思考（它在想什麼）、實際動的工具（參數是什麼）和花費成本。有了這三層記錄，Agent 做出任何怪事你都能回放找出轉折點。驗收則分兩組維度，一組是用戶感受得到的（功能有沒有做出來、代碼能不能跑、畫面對不對），一組是引擎蓋下的（解題路徑合理不合理、出錯後自我修復還是越修越爛、一共燒了多少 Token）。人通常只在意第一組，但第二組才是預測它下次會不會出事的地方。四個馬上可用的驗收招式：保存最初需求當考題，讓 AI 每個步驟都對著這句話重新打分數看有沒有偏題；看成品不看代碼，網頁跑版、按鈕沒反應、字太灰看不清，打開三秒鐘就抓出來，比盯代碼一輩子有效；看收斂程度，不是第四輪有沒有答對而是折騰到最後有沒有拿到東西，改兩次就精準到位的是好員工，改八次還是錯的得自己動手做就該回頭研究為什麼；把每次你說「不對、不是這樣、你搞錯了」都存起來，這些話精準標記出 AI 認為對但你認為錯的認知落差，稍微分個類就會發現 AI 的錯通常集中在少數幾種類型，然後回過頭去修改 Spec 和死規則，比自己凭空想考題快得多。