前面二十八天講的「攔截」，很多時候是在確認：AI 寫的東西，我到底有沒有理解？

Day 29 遇到的是與 AI 協作時另一種非常致命且比較難發現的陷阱：
「AI 不只是寫錯，還可能替自己寫錯的東西，用真的證據，去支撐一個錯誤的前提」。
AI 因為邏輯能力極強，往往能幫我們把謊圓得完美無瑕，甚至引經據典，反而把人類帶往更深的迷宮。

這次從 GitHub Issue 查到 Godot 原始碼，讀到的引擎原始碼是真的，Info.plist 的內容也是真的。
但最後發現只是型別寫錯了

問題出在最一開始的一個設定值。
而我最後發現它的方法，也沒有什麼高深技術，
只是打開 Godot 的 Project Settings，自己看了一眼下拉選單的設定值。
直接重設一次。

一、超寬螢幕的留白

這天一開始要處理的是另一個問題。

我用桌機瀏覽器模擬 iPhone 11 尺寸，發現畫面左右還有很大一塊空白。

專案的 window/stretch/mode 設成 canvas_items，但沒有另外設定 window/stretch/aspect，所以使用 Godot 4 的預設值 keep，也就是維持原本的長寬比。

我的設計基準是 1280×720，也就是 16:9。
但 iPhone 11 橫向的比例比較寬，超出 16:9 的部分就會留下空白。
這塊空白不屬於畫面裡任何一個節點，工具列、卡片和其他 UI 的排版也不知道旁邊多出了這些空間。
把 aspect 改成 expand 之後，畫面的邏輯尺寸會跟著視窗比例撐開，留白就消失了。

因為這是全域設定，所以 Claude 動手前先盤點了全部場景的排版方式。
大多數 UI 使用的是會跟著縮放的錨點設定，少數固定寬度的節點也都是刻意這樣設計。
修完之後，留白消失，排版也沒有跑掉。
這個問題處理得很順利。

二、想讓 iOS 支援兩個橫向方向

我接著問 Claude：

能不能讓 iOS 支援橫向的兩個方向？

這個專案原本只支援一個橫向方向，也就是前鏡頭在右邊。
如果把手機轉到另一邊，畫面不會跟著轉。

Claude 開始查這個問題。
第一步先看 project.godot。
裡面沒有設定對應的朝向欄位，套用預設值只支援單一方向。

於是修改設定，再重新匯出。
接著用 plutil 讀實機安裝版本的 Info.plist。
結果還是只有一個方向。

再往下查，Claude 找到一個 2019 年的 Godot GitHub issue，內容描述的是 iOS 匯出時，方向設定可能被引擎的 Info.plist 產生器處理錯誤。
症狀跟現在的情況很像。

於是又換一個方式測試。
直接在 iOS 匯出設定裡塞入完整的方向陣列，蓋過引擎產生的版本。
重新匯出，再用 plutil 確認。

這一次，Info.plist 裡確實有兩個方向。
但裝到 iPhone 11 實機後，畫面還是只認原本那一個方向。

接著排除最容易想到的問題：螢幕方向鎖定。
確認是關的。

Claude 又去讀 Godot 目前開發版分支裡處理這個設定的原始碼。
原始碼裡的邏輯看起來沒有問題。

但我的專案用的是穩定版 Godot，開發版的原始碼正確，也不能直接代表目前使用的版本完全一樣。
查到這裡，Claude 的判斷是：

Info.plist 已經正確宣告兩個方向，方向鎖定也排除了，實機卻還是沒有反應，所以問題可能是在引擎執行期的判斷。專案設定本身已經很難再處理，可能需要升級 Godot。

我聽完，覺得這個功能不能轉方向雖然有點不方便，但不是遊戲不能玩的問題。
所以我決定先不追 Godot 升級，接受這個限制。
當時看起來，這個結論沒有什麼奇怪的地方。

三、我後來重新看了一次 Project Settings

後來我自己又回到 Godot 編輯器。

打開 Project Settings，找到「掌上型／朝向」的設定。
這次我沒有看 project.godot，也沒有看 Info.plist。

就是直接看下拉選單現在選的是什麼。
結果看到的是：
Landscape

不是我以為已經設定好的：
Sensor Landscape
我重新在介面上選擇 Sensor Landscape。
重新匯出、裝到 iPhone 11。

兩個橫向方向這次真的都能轉了。

所以前面查了半天的引擎 bug，其實不是這次的問題。

四、真正的問題是設定值的型別

回頭重新查這個設定，才發現問題出在：
display/window/handheld/orientation

這個欄位在 Godot 裡是整數列舉。
Project Settings 裡的七個選項，對應的是 0 到 6 的整數。

其中：

Sensor Landscape = 4
所以 project.godot 裡正確的寫法，是：4
不是："sensor_landscape"

[display]

window/size/viewport_width=1280
window/size/viewport_height=720
window/size/window_width_override=1920
window/size/window_height_override=1080
window/stretch/mode="canvas_items"
window/stretch/aspect="expand"
window/handheld/orientation=4

前一輪 Claude Code 修改 project.godot 時，是直接用文字方式編輯設定檔，寫進去的是加了引號的字串。
也就是說，預期的型別是整數，實際寫進去的卻是字串。

這也解釋了前面看到的結果。
設定沒有正確套用 → 匯出後的 Info.plist 只有一個方向 → 裝到實機後也只認一個方向。
所以問題根本不是「Godot 引擎知道我要兩個方向，但後來沒有照做」。
而是：

** 從頭到尾都沒有成功設定正確的設定值。**

前面找到的 2019 年 GitHub issue，症狀確實跟這次很像。
但它跟這次沒有關係。

五、為什麼這次很難發現？

現在回頭看，前面的每一次查證其實都是真的。

• Info.plist 真的只有一個方向。
• GitHub issue 真的存在。
• 引擎原始碼也真的讀到了相關的處理邏輯。
• 方向鎖定也真的關掉了。

問題是，這些看似嚴謹的查證，全建立在同一個共同前提上：

project.godot 裡剛才寫進去的設定是有效的。

但這件事，從頭到尾都沒有被驗證過。
因為第一步被漏掉了，後面的邏輯連環套就一路順理成章地接了起來：

設定改了，但 Info.plist 還是單向 → 找到相似的 Godot bug → 再繞過匯出設定 → Info.plist 變成雙向了 → 實機還是不行 → 再深入讀引擎原始碼 → 推測可能是Godot 執行期限制。

每一個環節都有證據可查、每一步看似都很專業，最後卻是第一步就錯了。

這次讓我比較有感的是：
查證得越深入，不代表一定越接近答案。

如果最前面的前提未經確認，後面搜集到的資料越多，反而只會幫錯誤的解釋築起一道更完美、更無法反駁的牆。

而這次真正解開謎底的檢查，其實非常簡單：
直接打開 Project Settings，看目前選的是什麼。

六、修好旋轉後，連帶浮出水面的排版邊界

雙方向旋轉順利運作後，隨之而來的是全新的 UI考驗——當鏡頭轉到左邊時，左側工具列直接被安全區擋住。

以前鏡頭固定在右邊，這個「邊界」從來沒被碰過；現在支援了雙向，原本以為很安全的佈局就暴露了問題。最後我拿 iPhone 實機手動調了幾輪安全區數值，把左右兩側都統一拉寬。

這也讓我體會到：功能支援的範圍一變，以前沒被測過的邊界就會一口氣冒出來。

七、這一天我重新理解了一次「查證」

回頭看這一天前後遇到的三個問題：

• 第一個是超寬螢幕的留白，改 expand 就解決。
• 第二個是 iOS 雙方向旋轉，一路查到 GitHub issue 與引擎原始碼，結果只是一個型別寫錯。
• 第三個是新功能引發的安全區邊界問題。

其中，第二個過程最值得記下來。
AI 給出的解釋可以有真實資料、有真實程式碼、有真實 issue，但它依然可能是錯的。

因為我們在除錯時，常常只顧著檢驗「後面的證據是不是真的」，卻忽略了最核心的一件事：
最前面的那個前提，到底有沒有成立？

如果一開始直接打開 Project Settings，或許幾分鐘就能收工。但我並不覺得多看了一輪原始碼是浪費，它讓我更清楚一件事——當盲點出現時，不能只一味往更深、更複雜的地方鑽，而是要學會隨時回頭，去確認最基底的常識。

而第三個問題則讓我看到另一層教訓：
功能支援的範圍一變，原本沒被測過的邊界就可能出現。

以前鏡頭只在右邊，左側工具列安然無事；現在多了一個方向，舊的安全值立刻受到考驗。
30 天的開發路上下來，這些「以為理所當然」的盲點，往往才是最真實的收穫。

Day 30 是完賽總結。

30 天做完，我想留下來的不只是這個遊戲，還有一份之後真的有人能接手的紀錄。
如果是下一個人，甚至是下一個 AI，要接著修改《異世界救援》，它需要知道的不只是程式碼放在哪裡。

還需要知道：
哪些決定是怎麼做的、哪些坑踩過、哪些做法最後被放棄，以及為什麼。
明天，就把這 30 天整理成最後一篇。

💬 你有沒有遇過 AI（或任何人，包括自己）給出一個查證看起來很完整，最後卻建立在錯誤前提上的結論？你是怎麼發現的？歡迎留言聊聊。