Day 26 講的是上線時，哪些事情可以交給 AI，哪些事情要自己看。
今天碰到的問題換了一種形式。

如果一份規格本身就是 AI 產生的，做之前要不要再找人看一次？
這次我的做法是：

Gemini 負責提案，Claude Code 負責審計。

不是把 Gemini 的規格直接丟給 Claude Code 開始寫，而是先讓 Claude Code 讀過目前的程式碼，再回頭檢查這份規格跟現況有沒有衝突。

結果真的抓到了一個會直接影響遊戲核心流程的問題。
而且後面還有一個我沒想到的結果。
原本為了避開物理引擎的風險，換成了 Tween。
結果新的做法，又踩到這個專案以前自己記錄過的舊坑。

一、想讓主畫面更有動感，Gemini 提了一份規格

我覺得主畫面有點太靜態，想加一些會動的元素，讓畫面活潑一點，就請 Gemini 幫我想想可以怎麼做。
Gemini 對主畫面提出一份加入物理引擎的方案規格。

內容包括：

• 背景散落可以拖曳的物理零組件
• 用一列燈泡顯示各城鎮是否通電，並用 PinJoint2D 懸掛，讓燈泡可以搖晃
• 主畫面的 CTA（Call to Action，主要按鈕）點下去時，加入有重量感的回饋

規格看起來很完整，Godot 的術語也都用得很正確。
這次沒有直接照著 Gemini 的建議做。
我把規格丟給已經讀過現有程式碼的 Claude Code，只說了一句：

Gemini 建議，你審計一下。

這次的任務不是寫 code，而是先確認這份規格跟目前的專案到底合不合。

二、CTA 指到錯誤場景，會跳過整個構築流程

Claude Code 很快抓到一個問題。
Gemini 的規格寫的是：

CTA 按鈕點擊後切換至 BattleScene.tscn

但目前專案的實際流程是：

RewardScene.tscn → 第 1～9 關開寶箱、三選一構築牌組
BattleScene.tscn → 第 10 關魔王戰

也就是說，如果完全照這份規格做：
玩家點一下按鈕，就會直接跳進第 10 關魔王戰。
中間第 1～9 關的開寶箱、選卡、構築牌組，全部被跳過。

這不是視覺效果喜不喜歡的問題。
它會直接把遊戲原本的核心迴圈砍掉。

這個問題特別容易漏掉，因為規格本身讀起來完全通順：

點擊按鈕 → 切換場景 → BattleScene.tscn

每一句看起來都沒問題。
真正要問的是：

BattleScene.tscn 在目前這個專案裡，到底代表哪一段流程？

這個答案不是看規格書可以知道的。
要讀目前的程式碼和場景結構，才知道 BattleScene.tscn 現在是第 10 關魔王戰。
所以這次審計抓到的不是「程式碼寫錯」，而是規格裡寫了一個跟目前專案狀態不符的場景名稱。
如果沒有先審查，這個錯誤很可能就會直接進 codebase。

三、另外兩個問題：可以做，但值得嗎？

除了按鈕場景的問題，Claude Code 還指出兩個比較偏設計面的問題。
這兩個跟前面的硬傷不太一樣。
不是「做了就會壞」，而是「真的要這樣做嗎？」

1. 跟剛定好的方向衝突

城鎮供電狀態這份資料，EndScene 最近才改過顯示方式。
原本用固定座標排版，後來因為要支援 20 座以上的城鎮，改成動態清單。
但 Gemini 的規格又希望在 MainMenu 裡，用物理燈泡來表示同一份城鎮狀態。

問題就出現了。
如果城鎮數量增加，固定位置的物理燈泡要怎麼安排？
這會跟剛改好的「支援大量城鎮、不要靠固定座標排版」方向互相衝突。

2. 花的成本，跟得到的效果不太成比例

《異世界救援》本來就是主打 3～5 分鐘生活空檔的遊戲。
玩家每次開 App 都會看到主畫面。
如果在這裡放一套持續運算的物理模擬，得到的主要效果只是背景裝飾。

而這個專案在觸控輸入上本來就有過一次經驗：
iOS 轉向之後曾經發生觸控座標偏移，到現在還沒有完全修好，只能靠提示規避。
現在如果再加入「拖拽物理零組件」，就等於主動增加滑鼠、觸控、Web 匯出三種輸入路徑的風險。
所以這兩個問題最後都沒有變成「不能做」。
比較接近：

可以做，但目前沒有足夠的理由值得做。

四、決定：效果留下來，做法換掉

最後的決定是：

• 背景拖曳零組件不做。
• 吊燈搖晃也不做。
• 但主要按鈕「按下去有回饋」保留。

只是不用真的掛物理節點，改用 Tween 做出縮放時的彈性感。

明天 Day 28，驗收的工具從第二個 AI 換成人的耳朵。AI 用波形數字挑了三次護甲音效，每次理由都講得完整，三次都被一句聽感打回票。

💬 你有沒有讓一個 AI 審查過另一個 AI 的建議？有沒有抓到過原本沒發現的問題？歡迎留言聊聊。