給系統設計者2026.06.16

AI 可以幫我驗收，但它有些事情是 AI 看不到的

AI 幫你驗收程式，最危險的不是它出錯，是它說「通過」的時候。驗收其實分兩層：機器能驗的 functional（檔案在不在、HTTP 200、文字對不對），跟機器驗不到的 aesthetic／behavioral（影片有沒有真的播、視覺對不對、環境差異）。我這次改版踩到三個盲區，整理出一條紀律：先量再下結論，而且要知道機器驗不到哪一層、那一層一定要人來驗。

AI 驗收分兩層，機器只驗得到一層

用 AI 輔助開發的人，幾乎都會讓它順手做驗收：跑個 script 確認檔案有沒有送上去、頁面回不回 200、關鍵文字對不對。這些事 AI 做得又快又準，問題不在這裡。

問題在於，驗收其實有兩層。第一層是 functional，機器可驗：檔案在不在、HTTP 狀態碼對不對、文字內容對不對。第二層是 aesthetic／behavioral，機器驗不到：影片有沒有真的在播、視覺比例對不對、不同環境下會不會長得不一樣。機器只能驗第一層，而最危險的是，第一層「通過」的時候，它還會給你一種假信心，讓你以為整件事都 OK 了。

這篇不是「AI 不可靠」的抱怨文。會用 AI 的人，要做的不是不信任它，而是清楚知道它在哪裡會給你假信心，並且為那一層設計對應的驗證紀律。下面三個案例，全來自我這次 gwarket L5 改版上線時真實踩到的盲區。

案例一：截圖騙了我，因為 headless 解不開影片

桌機版的場景背景是一支 H.264 影片。我用 headless 瀏覽器（無介面、純背景跑的瀏覽器）截圖來驗收，截出來的畫面看起來「正常」，於是我一度以為這項過了。

但這裡有個陷阱：headless 瀏覽器根本解不開 H.264 這種影片編碼，它截到的其實是影片的靜態 fallback 幀，不是影片真的在播放的畫面。換句話說，「截圖看起來正常」完全不等於「影片真的會動」。截圖通過的，只是「這個位置有東西、格式對得上」，至於它會不會順順地播下去，截圖根本回答不了。

這件事的結論很明確：影片、動效這類產出，機器只驗得到「檔案送得到、格式對」，「真的順播」這一層必須由真人在真實的瀏覽器裡親眼看。所以我在交付的時候直接寫明「這一項我驗不到，要你親眼確認」，沒有把它包裝成已經驗過了。把「我驗不到」誠實標出來，比假裝全部驗完更可靠。

案例二：「字變小」的直覺，差點讓我冤枉了 CDN

上線之後我的第一反應是：正式站的文字怎麼明顯變小了？直覺馬上把矛頭指向 Cloudflare 或部署流程，懷疑是不是 CDN（內容傳遞網路）在中間動了什麼手腳、壓縮或改寫了樣式。

但我沒有先怪 CDN，而是先量三件事：

線上版跟本機版的 /l5/style.css 檔案 byte 數比對，結果完全一致（44106 = 44106），代表 CDN 沒有改動 CSS。
用瀏覽器實測大標的 computed font-size：1920px 寬時是 142px（正好是設計的最大值）、1280px 寬時是 95px，都在設計範圍內。
比對 viewport meta 標籤，線上跟本機一致。

三項都對得上，代表這不是部署 bug。真正的原因有兩個：一是大標用了 clamp(48px, 8.3vw, 142px) 這種響應式字級（字的大小綁著視窗寬度走），視窗一窄字就變小；二是瀏覽器分頁本身被縮放過。一句話總結這個盲區：當你覺得「全部的字等比例一起變小」，幾乎都是瀏覽器縮放（按 Ctrl+0 重設就好），不是程式出錯。

這裡真正的教訓不是 CSS 怎麼寫，而是歸因的順序。最不透明的那一層（CDN、build pipeline）最容易被當成代罪羔羊，因為你看不進去、所以方便懷疑。但正確的做法是先量證據再下結論，而不是先把鍋甩給那個你最不熟的環節。

案例三：兩支影片大小一樣，但它們不是同一支

在把場景影片放上去之前，我發現一支自製影片，跟參考素材庫裡的一支 clip，檔案大小一模一樣，都是 3.64MB。第一直覺是：這該不會是同一支檔案吧？如果是，那就是著作權風險，得擋下來。

但我沒有只看檔案大小就下判斷，而是用多個彼此獨立的訊號交叉查證：

用 ffprobe（影片資訊檢測工具）比尺寸跟長度：自製的是 16:9、8 秒；參考的是 1:1、4 秒。完全不同。
抽出影格比畫面內容：一支是飛船艙望向雲海，一支是工業風的 3D 渲染。完全是兩回事。

結論是這兩支影片完全不同，3.64MB 一致純粹是壓縮後的巧合。這個案例的判斷點是：檔案大小一致，不等於同一個檔案。provenance（來源判定）這種事，絕對不能只靠單一一個弱訊號就定罪，要用多個正交（彼此獨立、不會一起錯）的訊號交叉驗證。

兩種誤判，同一帖解藥

把這三個案例放在一起看，會發現它們其實是兩種不同的誤判模式。

第一種是「驗證手段本身有盲區」：案例一被截圖騙了，因為我用的驗證工具（headless 截圖）天生就驗不到我要驗的那一層（影片是否播放）。第二種是「缺證據就先歸因」：案例二想怪 CDN、案例三想當成同檔，兩個都是還沒拿到證據，就先憑直覺把問題塞給一個看起來可疑的對象。

這兩種誤判的共同解藥，是同一句話：先量，再下結論。先量，逼你拿出可驗證的證據，治的是第二種誤判；而「知道自己的驗證手段驗不到哪一層」，治的是第一種——當你知道截圖驗不到播放，你就會主動補上人工驗收，而不是被一張看似正常的截圖餵了假信心。

我的觀點

我認為，AI 協作裡最值得投資的能力，不是「讓 AI 幫你做更多驗收」，而是「分得清楚哪一層它驗得到、哪一層它驗不到」。前者只是把人力外包出去，後者才是真正的紀律。一個會用 AI 的人，跟一個被 AI 餵假信心的人，差別就在這條線畫得清不清楚。

我也認為，「先量再下結論」這條紀律，價值不在於它多高深，而在於它反人性。人的直覺天生喜歡找一個可疑的對象來怪——最好是那個你最不熟、最不透明的環節，因為怪它最不費力。但越是這種時候，越要忍住，先去量那幾個能拿到的硬數字（byte 數、computed 值、影片尺寸），讓證據說話。我這次三個案例，每一個如果順著直覺走，都會得出錯的結論。

最後我想說的是，把「我驗不到這一層」誠實標出來，不是示弱，反而是專業的表現。最怕的不是 AI 漏驗，而是你把「functional 全過」當成「品質 OK」交出去，結果影片根本沒播、上線才被使用者發現。寧可在交付時誠實寫「這項要你親眼確認」，也不要用一張漂亮的截圖，給自己跟別人都灌一口假信心。