設計還原度要怎麼自動檢查

這三類工具經常被混在一起討論，但它們的提問其實完全不同。搞錯這件事，選型就會從第一步開始歪。

差別最明顯的是這個情境：如果你的第一版就做錯了。

假設設計稿的內距是 12px，工程師寫成 8px，而且從第一天就是 8px。像素回歸會說 PASS——因為這一版跟上一版都是 8px，沒有回歸。它從頭到尾不知道 12px 這件事，因為它的基準是「上一版的自己」，不是設計稿。

疊圖看得出來，但需要有人打開工具、對齊、瞇著眼睛判斷那條邊差了幾像素，然後把結論寫進 ticket。

屬性級比對會直接說：padding-left: 設計 12px / 實際 8px / 差 -4px。

像素回歸防的是「改壞」，屬性級比對防的是「從一開始就沒做對」。

兩者不互斥，通常該一起用。

機制不複雜：一邊從 Figma REST API 拿設計節點的屬性，另一邊用 Playwright / Puppeteer 之類的工具在真瀏覽器裡跑 getComputedStyle() 和 getBoundingClientRect()，然後逐項比。

會比的通常是這幾類：尺寸（寬高）、內距與間距（padding / margin / gap）、字體（字級、字重、行高、字距）、顏色、圓角、相對位置。

這是最容易做錯的一項。#3B82F6 跟 #3B82F7 字串不相等，但人眼絕對看不出差別；反過來，兩個色差很大的顏色也可能只差幾個 hex 值。

正確做法是換到感知均勻的色彩空間算色差——sRGB → CIELAB → CIEDE2000，得到一個 ΔE 值，再設容差。另外還要處理半透明（要先跟背景合成才知道實際呈現的顏色）與現代色域（oklch()、display-p3 需要矩陣轉換）。

「這個按鈕在設計稿的 x=240，實際渲染在 x=248」——這種比對在彈性版面下必定誤報。容器寬度差一點、字串長度不同、RWD 斷點不一樣，整排元素的絕對座標就全都對不上，但版面其實完全正確。

可行的做法是比相對關係：這個元素跟它旁邊那個的間距是多少。而且參照物要挑——文字框（TEXT / HUG）的邊界天生就跟瀏覽器量法不同，拿它當參照等於自找誤報。

看完上一節你可能會覺得：這不就是兩邊拿數字然後 diff 嗎，一個下午就寫完了。

取數值確實不難。難的是下面兩件事，而它們決定了一個工具能不能真的被團隊每天用。

誤報會毀掉工具的信任——一份 80% 是雜訊的報告，第三次之後就沒有人看了。

所以容差設定與忽略規則，通常才是這類工具好不好用的關鍵，而不是它能比幾種屬性。試用時值得特別測這一塊：拿一個你確定做對的頁面去跑，看它報出多少不存在的問題。

如果設定寫錯導致一個元素都沒配對上，工具會得到「零個落差」。這時候絕對不能回報 PASS——那是「什麼都沒檢查」，不是「什麼問題都沒有」。一個負責任的工具應該先驗證配對可信度，配不到就直接失敗。這個細節很少人講，但它決定了你能不能把這個工具放進 CI 而不是只拿來參考。

這個品類這兩年才成形，工具還在快速變動。以下依做法分類，功能描述以各家官方說明為準，已於 2026-08-18 逐一查核；但我沒有全部實際試用過，選型前建議拿同一個頁面自己跑一次再判斷。

• Uiprobe（uiprobe.io）——目前這個品類最完整的商業方案，瀏覽器擴充形式，讀 Figma 屬性對照頁面 computed style，逐項列出設計值與實際值，支援 localhost 與登入後頁面。有免費額度與付費方案。
• Loupe（loupetool.dev）——同時提供 Figma 框對照、CSS 屬性比較與 DOM inspector，偏向開發者拿來 debug「為什麼沒還原」。
• OverlayQA（overlayqa.com）——混合型。主體是疊圖，但可以點任一元素抓它的 computed CSS，並把差異連同 selector、數值、截圖一起送進 Jira / Linear / Notion。強在把發現變成工單。
• Over.fig（overfig.com）——免費 Chrome 擴充與 Figma plugin，半透明疊圖加上點擊元素抓 CSS / Tailwind，資料全在本機處理。
• The Punisher（thedevpunisher.com）——免費桌面程式（macOS / Windows），支援 live、preproduction 與本機環境。注意：官網描述以 pixel-perfect comparison 為主，實際上偏像素比對而非屬性級，歸類請自行確認。
• uiMatch（開源，kosaki08/uimatch）——用 Playwright 渲染實作對照 Figma 節點，產出一個還原度分數與可設定的 pass / fail。仍在 0.x。

PerfectPixel、Pixelay 這類老牌擴充。純粹把圖疊上去讓人看，不產生數值。快速抽查很好用，但沒有辦法自動化，也沒辦法告訴你差幾像素。

Percy、Chromatic、Playwright 內建的截圖比對。成熟穩定，但如 § 01 所說，它們防的是改壞，不是還原度。

Figma REST API（或 Figma MCP）＋ Playwright 的 page.evaluate() 抓 computed style，兩邊 diff。這仍然是目前相當常見的做法——尤其是需要塞進 CI、規則要完全自訂的團隊。核心邏輯不難，難的是 § 03 那兩件事：元素對應與誤報處理，那才是會吃掉你大部分時間的部分。

一個實務建議：先確認它能不能碰到你的 localhost。設計 QA 是上線前的活，如果工具只能吃公開網址，那它永遠只能在事情發生之後才告訴你。

屬性級比對讀的是數值，所以凡是「最終視覺效果」但不表現在 computed style 上的東西，它都看不到：

• 圖示的 SVG 路徑畫錯——尺寸與顏色都對，形狀不對
• 字型實際渲染出來的樣子（連字、字距微調、hinting）
• 陰影、漸層、濾鏡疊起來的實際觀感
• 圖片裁切位置、焦點跑掉
• 動畫與轉場的感覺

這些仍然需要截圖比對或人眼。所以合理的配置是兩種一起用：屬性級比對守規格（間距、字級、顏色、圓角），像素回歸守最終畫面。它們不是競爭關係。

以下是我自己的工具，請自行打折。放在這裡是因為它填的是 § 05 表格裡「要進 CI、不能有人工步驟」那一格——上面列的工具大多是讓人打開來看的，發現落差之後還是得自己開工單。

Cornhsu.Parity 是一個 dotnet tool（也可以 npx 執行，不需要裝 .NET），輸出是 exit code 與 PR 留言，不是一份要人讀的報告。

$ parity check --config parity.config.json --target /pdf-unlock

target /pdf-unlock
  matched 169/169 design nodes; 6 with diffs
  ✘ dz-note  [critical]
      height         expected 22.97px   actual 46.08px
  ✘ ic       [critical]
      fontSize       expected 13.12px   actual 11.52px
      lineHeight     expected 22.96px   actual 20.16px
      fontFamily     expected Noto Sans TC  actual "Space Mono", monospace [soft]
      color          expected #B03A22   actual #F6F1E799 (ΔE 50.28)

fidelity score: 96/100

✘ GATE FAIL (fail on: critical, serious)
  · /pdf-unlock: has critical/serious severity diffs

上面這段不是示意圖，是這個網站自己跑出來的——那一頁的下載區有段註記換了字型與顏色，快照基準沒跟著更新，於是被擋下來。注意最後一行的 ΔE 50.28：這就是 § 02 講的 CIEDE2000，用 hex 全等只會得到「不相等」三個字，得不到「差多少」。

§ 03 講的兩個難題，它的處理方式是：配對走四關遞進（文字錨定 → 圖層名對 id/class/aria → 已配對子孫的最近共同祖先推論 → 手動補漏），配不到的列成清單而不是硬湊；誤報則是採「寧可漏、不可誤報」——刻意不比絕對座標、相對位置取最近的可靠兄弟當參照、量不準的軸誠實跳過。零配對時 gate 直接失敗，不會回報假的 PASS。

顏色走 § 02 說的 CIEDE2000（以 Sharma 標準資料集驗證），支援半透明合成與 oklch() / display-p3。設計來源有四種：Figma API、畫面快照、圖片＋標註、JSON——快照模式表示沒有 Figma 也能用，等於數值版的視覺回歸。實作端除了網頁（含 Shadow DOM、同源 iframe、RWD 多斷點）也支援 Electron（CDP attach）。baseline 存 SQLite，CI 只擋新增與惡化，所以有一堆舊債的專案也能今天開始用。

你該知道的限制：目前 v0.14.0，還沒到 1.0，介面可能會變；單人維護；沒有雲端版，也沒有給非工程師用的圖形介面——設計師要手動抽查的話，§ 04 那些擴充比它適合。它也不解 § 06 列的那些問題。

一句話總結

疊圖讓人看見落差，像素回歸防止改壞，屬性級比對驗證有沒有照設計稿做——三件不同的事。要自動化還原度檢查，你要的是第三種；但它的成敗不在能比幾種屬性，而在元素對應準不準、誤報多不多。試用時拿一個你確定做對的頁面去跑，看它報出多少不存在的問題，那個數字比功能表有用得多。

寫於 2026-08-18。工具生態變動很快，文中各家的功能描述多來自其官方說明，請以你實際試用的結果為準。