【2026 最新】Claude 遊戲視覺回歸怎麼做？固定鏡頭＋Golden Scene＋盲評 7 步實戰

你叫 Claude 把港口場景「改得更有電影感」，幾分鐘後燈光、材質與建築都換好了。可是第二次打開遊戲，你真正要回答的不是「它有沒有改」，而是：畫面變好、變壞，還是攝影機剛好偏了一點？這正是 Claude 遊戲視覺回歸要解的問題。

近期兩位開發者分別在 Unity 遊戲開發分享與 AI 釣魚遊戲工作流裡談到同一個痛點：改程式很快，視覺驗收仍反覆而且高度仰賴人。這些是作者自述，不是獨立稽核結果；但它們把問題問得很準。

這篇專為第一次做遊戲測試的人寫。我們會從零建立一條 Unity 或 Godot 都能套用的流程：固定輸入與鏡頭、保存 Golden Scene、用 diff 分流，再讓 Claude 做去識別的 A/B 第二意見。你不需要先懂測試框架；先讓一個場景能重跑，就已經跨過最重要的一步。

先說結論：AI 改畫面，人類定標準

一套可靠的遊戲視覺驗收，不是叫 Claude 對截圖打分數，而是先把問題拆開：

可驗收遊戲畫面 ＝ 固定輸入 ＋ 固定鏡頭 ＋ 分層 Diff ＋ 盲評 ＋ 人類否決權

• 機械 diff：回答「哪裡變了」。
• 感知指標：回答「這個變化是否超過場景平常的渲染噪音」。
• 盲式 A/B：回答「依預先寫好的 rubric，哪一版更符合目標，理由是什麼」。
• 人類 reviewer：決定要不要接受新基準，並保留 art-direction veto（美術方向否決權）。

Claude 遊戲視覺回歸的 5 個關鍵詞

視覺回歸測試是把目前畫面與一張已批准的參考畫面比較，找出非預期變化。它像替場景拍證件照：拍攝條件要固定，兩次照片才有比較意義。

• Golden Scene：本文用來稱呼「團隊自己定義、可重跑的測試場景」。它把場景檔、種子、鏡頭、解析度、品質設定與截圖時機綁成一份測試 fixture。
• Golden image：由人類批准、與 Golden Scene 綁定的參考 PNG。
• Perceptual diff：不只逐像素數差異，也用結構或感知指標協助分辨「畫面真的變了」與「邊緣或光照有微小波動」。
• Rubric：評分前先寫好的驗收準則，例如主角可讀性、視線焦點、空間層次與風格一致。
• 盲式 A/B：把兩張圖標成 A、B，隱藏新舊、作者與投入成本，避免「新的一定比較好」先污染判斷。

如果你已經做過 Godot Sprite Atlas 與動畫循環，可以把 Golden Scene 想成更外層的驗收殼：Sprite 測單一資產，Golden Scene 測資產放進真實鏡頭後的整體結果。

固定鏡頭為什麼還不夠？你其實要固定一份「拍攝合約」

攝影機只是一個變因。只鎖 Camera，卻讓粒子、日夜時間、動畫幀或品質設定漂動，diff 仍會每天報警。成熟的 Golden Scene 應把以下資訊一併保存：

• 場景與角色初始狀態，以及所有會影響畫面的 RNG seed。
• Camera 的位置、旋轉、FOV／投影模式與後製設定。
• 輸出解析度、長寬比、色彩空間與品質等級。
• 動畫幀、物理 tick、截圖前要等待的 frame 數。
• 引擎版本、作業系統、渲染後端、GPU／驅動與 commit SHA。

這些 metadata 不是裝飾。即使網頁測試領域的官方工具也提醒，截圖會受作業系統、版本、硬體與設定影響；遊戲渲染更應把執行環境視為測試輸入。可參考 Playwright 的視覺比較文件所列的環境差異原則。

Claude 遊戲視覺回歸：7 步建立第一條可重跑流程

第 1 步：先寫 rubric，再讓 AI 改圖

痛點：如果「更好看」是唯一標準，任何結果都能事後合理化。解法：先替每個 Golden Scene 寫 4～6 個可觀察準則，每項都要求 reviewer 指出畫面證據，不先要求一個總分。

scene: harbor_day
goal: 玩家進場後 2 秒內看見主角與可互動碼頭
rubric:
  - 主角輪廓能否從背景分離
  - 視線是否先落在主角，再移到碼頭
  - 前景、中景、遠景是否有清楚層次
  - 建築、材質與光色是否一致
hard_fail:
  - 主角、出口或互動物件缺失
  - 解析度、長寬比或 Camera 不符

分數可以留到最後做排序，但不要把「8 分就能 ship」當成普遍真理。它若沒有用你自己的場景與人類判斷校準，就只是一個看起來精確的偏好值。

第 2 步：鎖定 seed、鏡頭、解析度與時間

版本先釘死：本文研究截止日為 2026 年 8 月 21 日，Godot 官方 archive 列出的穩定版是 4.7.2-stable；Unity 範例則對照 Unity 6.5 與當時仍標成預發布的 Graphics Test Framework 9.0.0-pre.25。你的專案應記錄完整 Editor／引擎與套件版本，不要只寫「Unity 6」或「Godot 4」。

Godot：建立一個包含固定 SubViewport 與 GoldenCamera 的測試場景，所有隨機內容都從同一個 RandomNumberGenerator 取得。Godot 官方文件說明，相同 seed 會產生可重現的偽隨機序列；但底層演算法屬實作細節，因此升級引擎後仍要重新驗證基準。

extends Node

const SIZE := Vector2i(1280, 720)
const WARMUP_FRAMES := 8  # 專案固定值，不是失敗後重試
var rng := RandomNumberGenerator.new()

@onready var viewport: SubViewport = $GoldenViewport
@onready var camera: Camera3D = $GoldenViewport/GoldenCamera

func _ready() -> void:
    rng.seed = 20260821
    # 場景內所有隨機生成都要改用這個 rng
    viewport.size = SIZE
    viewport.render_target_update_mode = SubViewport.UPDATE_ALWAYS
    camera.make_current()

    for _frame in range(WARMUP_FRAMES):
        await RenderingServer.frame_post_draw

    var image := viewport.get_texture().get_image()
    var err := image.save_png("user://harbor_day.png")
    assert(err == OK)
    get_tree().quit()

執行時再固定解析度與時間步進：

godot --path . --scene res://tests/visual/harbor_day.tscn --windowed --resolution 1280x720 --fixed-fps 60

上面的 API 與參數可對照 Godot 4.7 的 RandomNumberGenerator、SubViewport與命令列文件。--fixed-fps固定時間步進，但不會自動消除所有 GPU、shader 或粒子差異。截圖階段也不要加 --headless：Godot 的 DisplayServer 文件明確說明 headless 模式會停用渲染與視窗管理功能。

Unity：Unity 的官方 Graphics Test Framework 已經提供 scene test、reference image 與 ImageAssert。不過截至研究日，現行 9.0.0-pre.25 文件仍屬預發布；請把版本寫進 Packages/manifest.json與 lock file，並先在你釘定的 Unity Editor runner 驗證。

using System.Collections;
using NUnit.Framework;
using UnityEngine;
using UnityEngine.SceneManagement;
using UnityEngine.TestTools;
using UnityEngine.TestTools.Graphics;

public sealed class GoldenVisualTests
{
    [UnityTest, Category("GoldenVisual"),
     SceneGraphicsTest("Assets/Tests/GoldenScenes")]
    public IEnumerator Golden(SceneGraphicsTestCase testCase)
    {
        Random.InitState(20260821);
        SceneManager.LoadScene(testCase.ScenePath, LoadSceneMode.Single);

        for (var frame = 0; frame < 8; frame++)
            yield return null;

        var cameraObject = GameObject.Find("GoldenCamera");
        Assert.That(cameraObject, Is.Not.Null);

        var settings = new ImageComparisonSettings {
            TargetWidth = 1280,
            TargetHeight = 720,
            TargetMSAASamples = 1,
            UseHDR = false,
            UseBackBuffer = false
        };

        ImageAssert.AreEqual(
            testCase.ReferenceImage.Image,
            cameraObject.GetComponent<Camera>(),
            settings);
    }
}

第一次執行時，reviewer 可依官方的 Accept Result 流程把 actual 複製成 reference；本文把這個動作保留給人工確認，不讓 CI 自動接受 candidate。解析度、MSAA、HDR 與 back buffer 設定則來自 ImageComparisonSettings。若場景含隨機生成，Random.InitState負責 Unity RNG；shader 時間、VFX、其他 PRNG 與 GPU 歷史要在各自的設定與 capture manifest 另外控制。

第 3 步：建立 Golden Scene，而不是一張來路不明的截圖

一個最小資料夾可以長這樣：

tests/visual/
├── scenes/harbor_day
├── golden/harbor_day.png
├── current/
├── diff/
├── rubrics/harbor_day.yml
├── impact-map.yml
└── decisions/

第一次建立 golden 時，請由人類確認場景狀態、鏡頭與 rubric 都正確，再把 PNG 和設定檔一起 commit。Golden 不是「永遠正確」，而是「目前已批准的比較基準」。

第 4 步：先做 exact diff，再做 perceptual diff

先用逐像素差異抓尺寸不符、缺件、透明度與大範圍位移，再用結構型指標協助分流微小渲染差異。ImageMagick 的 compare 官方文件提供 AE、SSIM 等 metric 與 diff 輸出：

# 完全對齊後，先計算不同像素與差異圖
magick compare -metric AE +  golden/harbor_day.png current/harbor_day.png diff/harbor-ae.png

# 再看結構型差異；同一專案要固定 ImageMagick 版本與參數
magick compare -metric SSIM +  golden/harbor_day.png current/harbor_day.png diff/harbor-ssim.png

SSIM 原始論文評估的是對齊影像的亮度、對比與結構資訊；其驗證範圍並非遊戲 art direction 或場景邏輯。本文只把它用來分流變化，不把輸出解讀成「美感分數」。

第 5 步：為每個場景校準閾值，不要找一個全站神奇數字

在沒有任何程式或資產變更時，讓同一個 Golden Scene 重跑多次，記錄 AE、SSIM 輸出與熱圖位置。第一輪可以先收集 10 次，目的是看見自己的噪音帶，不是宣稱 10 次就有統計保證。

• PASS：差異落在這個場景已知的噪音帶，而且沒有 hard-fail 規則命中。
• REVIEW：超出噪音帶，或差異集中在主角、UI、出口等高風險區域。
• FAIL：解析度／鏡頭合約不符，或必要物件缺失；不要靠放寬 fuzz 把它洗掉。

粒子特效很多的戰鬥場景，和靜態角色選單不應共用閾值。若某個區域本來就有時間噪音，優先固定動畫幀、關閉非必要粒子或建立 mask；最後才考慮提高容許值。

第 6 步：用 rubric 做盲式 A/B critic

Anthropic 的 影像輸入文件說明 Claude 可在同一個請求中接收多張圖片，因此可以把 baseline 與 candidate 交給它比較。但請先把檔名、commit、作者與「哪張較新」拿掉，再使用固定 prompt：

你會收到兩張同一鏡頭的遊戲截圖，標記為 A 與 B。
不要猜哪張較新，也不要因畫面更亮或細節更多就偏好它。

依序檢查：
1. 主角可讀性
2. 視線焦點
3. 空間層次
4. 風格一致

每項輸出：winner = A / B / tie、觀察到的具體區域、信心 low / medium / high。
最後只能給 recommendation = A / B / inconclusive。
不要替人類批准 Golden。

接著把順序交換成 B/A 再跑一次。若結論跟著位置翻轉，就標記 inconclusive，不要平均成一個看似穩定的分數。LLM-as-a-judge 研究已觀察到位置偏誤等問題；多模態 judge 研究也記錄了不一致、幻覺等挑戰，所以盲評只能整理第二意見。

如果你想把這一步做成可維護的評測系統，可以接著讀 AI Evals 新手指南與 AI Agent Harness 實作；差別只在這次的輸入是遊戲截圖，最終批准權仍在 reviewer。

第 7 步：把 USER／AI 決策、來源檔與 git diff 綁在一起

每次驗收都保存一張 decision receipt（決策收據），避免三週後只剩一句「Claude 說新版比較好」：

{
  "scene": "harbor_day",
  "base_commit": "<golden-sha>",
  "candidate_commit": "<head-sha>",
  "changed_sources": ["Assets/Harbor/roof.png"],
  "metrics": {"ae": "<ci-output>", "ssim": "<ci-output>"},
  "critic_orders": ["A/B", "B/A"],
  "ai_recommendation": "inconclusive",
  "human_decision": "accept",
  "owner": "USER",
  "reason": "保留夕陽色，但退回會遮住主角的前景霧"
}

CI 先用 git diff --name-only列出變動檔，再查 impact-map.yml決定重跑哪些 Golden Scene。例如角色材質只跑近景與港口；共用 shader、render pipeline 或無法解析的變更則回退成全跑。增量測試的原則不是「永遠少跑」，而是只有依賴關係明確時才少跑。

一個失敗案例：畫面變亮，不代表驗收進步

想像 harbor_day 的 candidate 把夕陽加強，第一眼確實更漂亮。這時三層檢查可能得到完全不同的訊號：

1. Exact diff 顯示全畫面大範圍變動；熱圖同時發現 Camera 向右偏移。先修拍攝合約，不進入審美評分。
2. 修正 Camera 後，剩餘差異主要在天空與水面。它超過該場景的噪音帶，因此進入 review。
3. 盲式 A/B 認為新版色彩更一致，但指出主角輪廓與碼頭互動點變得不清楚。人類保留夕陽色，退回遮住前景的霧，再產生下一個 candidate。

這個例子中的數字與場景都是示意；重點是不要讓單一 metric 或單次 AI 偏好跨過所有關卡。視覺一致也不等於遊戲可玩：路徑是否走得通、碰撞是否正確、效能是否穩定，仍要用狀態斷言、效能資料與玩家測試另外驗收。

最常踩的 6 個坑

1. 把 JPEG 當 golden：壓縮雜訊會放大誤報。基準優先用無損 PNG。
2. 新功能與 golden 同次自動合併：這會讓測試永遠追著目前結果跑。更新基準必須有獨立的人類批准。
3. 全專案只設一個閾值：靜態 UI、粒子戰鬥與體積霧場景的噪音特性不同。
4. 讓 critic 看見「新版」：檔名、commit 與作者資訊都可能變成捷徑。去識別後還要交換 A/B 順序。
5. 只保存 pass／fail：至少留下 baseline、current、diff、metadata、rubric 與理由，否則無法除錯。
6. 只重跑直接變更的場景：共用 shader、後製與渲染設定可能影響全站；impact map 不確定時就全跑。

這種「輸入、工具、權限與驗收結果都留下紀錄」的思路，也能和 AI Agent Harness 的治理觀念接起來。差別在於遊戲視覺多了一層難以自動量化的 art direction。

FAQ：Claude 遊戲視覺回歸常見問題

1. 截圖一樣，就代表遊戲功能正常嗎？

不代表。截圖只能證明某個鏡頭在某個時間點看起來相近，不能證明碰撞、路徑、輸入、效能或玩法正確。

2. 所有場景都該要求 pixel diff 等於零嗎？

不一定。靜態 UI 可以非常嚴格；含陰影、粒子或體積效果的場景，先找出同設定重跑的噪音帶，再定場景閾值。

3. 誰可以更新 Golden image？

指定的人類 reviewer。AI 可以提出理由，CI 可以附上證據，但基準更新應留下批准者與變更原因。

4. Claude 可以當最終美術驗收者嗎？

不建議。它適合比較多張圖、整理 rubric 證據與標記可疑區域；審美偏誤、位置偏誤與幻覺仍可能存在，玩家測試也不能省略。

5. Unity 與 Godot 可以共用同一組閾值嗎？

不要直接共用。引擎、渲染後端、品質設定與場景內容都會改變噪音特性；流程可以共用，基準與閾值要各自校準。

6. 光照或粒子一直誤報怎麼辦？

先控制來源，再調閾值。固定截圖幀、seed 與品質設定，關掉非驗收重點的隨機粒子；必要時為已知噪音區建立 mask。

7. 只跑受影響場景會不會漏測？

會，所以要有保守回退。共用資產與渲染設定要映射到所有相關場景；依賴關係未知時，CI 應全跑。

8. 有了視覺回歸，還需要玩家測試嗎？

需要。Golden Scene 擅長攔截非預期畫面變化；玩家測試才會揭露看不懂目標、路走不通、節奏不對與真正的遊玩感受。

給新手的 30 分鐘起手式

1. 挑一個最常被改壞、但不含大量粒子的場景。
2. 固定 1280×720、Camera、seed 與截圖幀。
3. 寫四條 rubric 與兩條 hard-fail 規則。
4. 保存一張人類批准的 PNG，跑 exact diff 並看熱圖。
5. 第二次 commit 後再加盲式 A/B；先不要急著把所有場景接進 CI。

等第一個場景穩定，再把流程擴到資產生成與互動網頁。像 Claude Code 動畫網站工作流與 AI 網頁設計驗收，本質上也都需要「固定輸入 → 可重跑輸出 → 人類批准」這條主線。