Design QA

設計品質檢查是什麼，跟「視覺回歸測試」具體差在哪裡？

設計品質檢查比對的是「實際上線的畫面」跟「原始設計規格」是不是一致——例如檢查一個按鈕的間距是不是真的照著 Figma 裡標註的數值做出來、顏色色碼有沒有對上設計系統裡定義的 Token、文案有沒有被改動過。這個檢查回答的問題是「這個東西做得對不對」，比對的基準是設計師的原始意圖。

視覺回歸測試則是完全不同的問題：它比對的是「這次的畫面」跟「上一次通過測試的畫面」有沒有出現非預期的變化，目的是抓出「不小心改壞了什麼」，比對的基準是過去某個時間點拍下的基準截圖，而不是設計規格本身。這代表視覺回歸測試可能會抓到一個「這次改動確實跟上次不一樣」的差異，但完全不知道這個差異是不是符合設計師原本的意圖；反過來，一個畫面即使通過了視覺回歸測試（跟基準截圖一致），也不代表它真的符合設計規格——如果基準截圖本身當初就做錯了，回歸測試只會確保這個錯誤被穩定地複製下去。

為什麼需要兩種不同的檢查機制，不能只做其中一種就好嗎？

因為兩者能發現的問題完全不重疊，各自有無法互相取代的盲點。視覺回歸測試擅長的是大範圍、高頻率地掃過整個介面，快速抓出「哪裡出現了非預期變化」，適合用來保護一套已經確認正確的畫面集合，防止後續開發過程中不小心破壞既有的正確狀態；但它沒有能力判斷「這個變化是不是符合設計意圖」，因為它比對的基準是舊截圖，不是設計規格。

設計品質檢查擅長的是判斷「這次新做的東西，是不是真的符合設計師想要的樣子」，適合用在評估新的實作選擇是否吻合產品既有的視覺與互動慣例，但這種檢查通常需要投入人力逐一核對，沒辦法像視覺回歸測試一樣大規模、高頻率地自動掃描。實務上比較穩妥的做法是兩者搭配：用視覺回歸測試保護已經確認正確的部分不被意外改壞，用設計品質檢查專門處理新增或修改過的部分，確認它們是不是真的做對了——只做視覺回歸測試，等於是在確保一個可能本來就有問題的基準被穩定複製；只做設計品質檢查，則會漏掉那些不是刻意修改、卻意外跑掉的非目標區域。

設計品質檢查實際上是怎麼被執行的，AI 工具在這個流程裡扮演什麼角色？

傳統上設計品質檢查是純人工作業：QA 人員或設計師本人，拿著設計稿跟實際成品逐一比對每個元件的間距、色彩、文案、互動細節，這個過程費時費力，也容易因為人工比對而有所遺漏。近年出現的 AI 輔助設計品質檢查工具，做法是讓 AI 直接比對一份正在運行的實際成品跟 Figma 設計規格，自動標記出兩者之間不一致的地方，並附上初步的問題描述，把「發現差異」跟「初步描述問題」這兩個重複性高的步驟自動化。

需要留意的是，AI 輔助設計品質檢查工具取代的只是流程裡重複、機械性的部分（螢幕截圖比對、初步標記問題），並不能取代人類對「設計意圖」跟「使用者體驗品質」的判斷——AI 可以標記出「這個按鈕的間距跟規格差了 4 像素」，但沒辦法判斷「這個差異在視覺上真的有影響嗎、值不值得優先修正」，這類需要脈絡判斷的問題，仍然需要人來做最後決定。

如果我用 AI 設計工具（例如 Claude Design）生成原型，之後要交給工程團隊實作，設計品質檢查這一步驟對我有什麼實際意義？

這一步驟特別重要的原因，是 AI app 生成工具（無論是設計原型工具還是程式碼生成工具）產出的介面，經常帶有明顯的「視覺債」——例如間距不一致、色彩沒有對照設計系統、同一個互動模式在不同畫面有不同實作方式，這些問題在生成當下往往不會被立刻發現，因為每個畫面單獨看都還算過得去，只有放在一起比對時才會顯現出不一致。這正是前面文章討論過的「原型債」在實作階段的具體呈現，設計品質檢查是在這個階段主動把這些落差揪出來的機制。

實務上，如果你的原型之後要真的進入工程實作，值得在生成階段就先做一輪設計品質檢查，把生成出來的畫面跟你原本的設計意圖（或匯入的設計系統規格）逐一核對，抓出真正需要修正的落差，而不是等到工程團隊實作完成、上線後才發現「這裡跟設計稿對不上」——那個階段的修正成本，會遠高於在原型階段就先處理好。