《異世界救援》最後要匯出到 Web、Android、iOS 三個平台。

匯出時程式碼幾乎沒有為了三個平台特別修改。
這段時間主要是在處理設定、匯出，以及過程中冒出來的問題。

在開發時像匯出及測試指令這些事情，我大多是把需求講清楚，讓 AI 去處理。
但到了上線階段，開始碰到一些前面比較少遇到的東西：
憑證、簽章、帳號，還有「把東西送出去」的動作。

程式碼寫錯了，大多還有機會改。
但如果一個指令把不該公開的東西推上去了，很可能不能取消，處理方式就完全不一樣。
這次剛好遇到幾個很具體的例子。

一、指令可以請 AI 代勞，送出去的東西要自己看

三個平台的匯出過程，其實有很多事情可以直接交給 AI：

• 匯出設定要填哪些欄位
• project.godot 要加什麼
• 命令列指令怎麼下
• 匯出後怎麼驗證
• 報錯之後怎麼查

這些事情 AI 做得很快。
但碰到下面這些東西，我就會自己再看一次：

AI 可以幫你執行，但它不知道哪些東西是你願意公開的，也不應該替你決定帳號要怎麼授權。
如果工具需要登入，我會先自己在終端機或瀏覽器完成登入，讓授權狀態留在本機。
接著只要告訴 AI：

我登入好了，可以繼續。

這樣 AI 還是可以接手後面的操作，但密碼本身不需要經過 AI。
如果真的不小心把密碼貼進對話框，也不要繼續使用。
直接把它當成已經外洩，修改密碼。

二、匯出到 itch 前，先確認 butler push 會處理哪些檔案

這次一個很具體的例子，是 itch.io 的 butler。

butler 是 itch.io 提供的命令列工具，可以把遊戲檔案推上去。
指令本身看起來很簡單有一行：。

butler push build jasonhung/obsidiantrial:html

但真的執行之前，我先問了一句：

butler push 的第一個參數，是資料夾，還是我指定的檔案？

答案是：
資料夾，而且會遞迴處理裡面的內容。

也就是說，build/ 底下的東西會全部上傳。
於是我回頭看了一眼 build/。當時網頁版直接匯出在這一層，跟其他平台的產物混在一起：

build/
├── index.html、index.wasm、 ...   網頁版，48MB
├── android/                      Android 安裝檔
└── ios/                          Xcode 專案、xcarchive、ipa，578MB

整個目錄加起來約 626MB。

也就是說，如果照原本的直覺直接執行，這些東西可能會一起被推到公開頁面。後來 build/ 又多了 iOS 的另外兩份匯出、兩個網站的 repo，現在整個資料夾 2.6GB。如果當初沒把網頁版分出去，今天這行指令要推的東西是當時的四倍。

如果當時只有web網頁的檔案，還沒有其他平台的檔案，你可能完全沒有注意到直接照 ai 的指令匯出 build 目錄風險！。

最後的處理方式很簡單：
讓每個平台的匯出產物各自放在自己的子目錄，再讓 butler push 只指向 Web 版的目錄。

這件事情讓我想到 Day 06 攔下 git init 的那次。
當時也是 AI 準備執行一個看起來很普通的指令，我停下來看了一下它到底會對哪個範圍動手。
這次只是換成 butler push。
差別在於，這次的東西是要送到公開網路。
所以看到：

「這個參數是一個目錄。」

之後，我會再多問一句：

那這個目錄裡到底有什麼？

簡單的確認，避免了把一堆完全不相關的檔案一起公開。

三、Team ID 該不該進公開 repo？

iOS 匯出的時候需要填 Team ID。
這個值會寫進專案的匯出設定檔，而設定檔本身是純文字。
這裡容易出現一個誤會：

Team ID 本身不是密碼，也不是私鑰。

所以看到它出現在設定檔裡，不代表「公開 Team ID 就等於憑證外洩」。
但問題還是存在：

這份設定檔到底要不要放進公開 repo？

這就不是 AI 幫你填完欄位之後，可以順便替你決定的事情。
AI 可以告訴你：

• Team ID 在哪裡查
• 這個欄位是做什麼的
• 匯出設定怎麼填
• 哪些檔案是 Godot 需要的

但這份專案到底要公開到什麼程度，還是要自己看過。
真正需要特別保護的，則是私鑰、憑證、Provisioning Profile 等敏感的簽章材料。
所以我現在看到這類設定時，會先分清楚兩件事：
這個值本身是不是秘密？

以及：

這份檔案裡，有沒有其他不該公開的內容？

四、帳號授權，密碼不要交出去

還有一個很實際的情況。
上傳工具需要登入。
如果這件事情完全交給 AI，很容易變成：

AI：「請把帳號密碼給我。」

這種事情就不要做。
比較正常的流程是：

1. 自己在終端機或瀏覽器登入。
2. 授權狀態留在自己的電腦。
3. 告訴 AI：「我登入好了。」
4. AI 繼續執行後面的命令。

這樣 AI 不需要知道密碼，也不需要把密碼寫進指令或對話紀錄。
如果手滑真的把密碼貼進對話框，也不要抱著「應該沒關係」的心態繼續用。

直接改密碼。
能避免秘密經過不必要的地方，就不要讓它經過。

五、還是有些事情得自己按

除了前面幾個資安相關的地方，這次上線還有一些事情本來就沒辦法完全交給 AI。

例如：

• 在 Godot 編輯器裡下載匯出樣板，約 1GB 的引擎執行檔
• 申請開發者帳號
• 收信完成驗證
• 上架平台的帳號設定
• 把某些內容從草稿改成公開
• 實機測試時解鎖手機、信任裝置

這些事情不一定是「AI 做不到」。
比較準確地說，是最後那個動作需要帳號本人或實體裝置來完成。
例如驗證信只會寄到自己的信箱。

iPhone 第一次連接開發環境時，也得在手機上按下信任。
這些事情沒有什麼技巧，就是自己做。
跑完三個平台之後，我也慢慢整理出一個很簡單的習慣。
匯出設定、命令列參數、報錯排查，這些都可以讓 AI 幫忙。
但看到：

憑證、簽章、帳號、密碼，或者任何「送出去」的動作。

就會多看一眼。

六、今天留下來的幾個經驗

這次上線沒有遇到什麼很大的技術難題。
反而是幾個很小的停頓，讓我記得比較清楚。

butler push 執行前，先確認：

這個參數到底是檔案還是整個目錄？

看到 Team ID 出現在設定檔裡，先確認：

這個值到底是不是秘密？這份設定檔裡還有沒有其他不該公開的東西？

需要登入工具時，先處理好：

讓工具取得授權，但不用把密碼交出去。

這些問題 AI 都可以幫忙查答案。
但最後做決定的人還是我。
現在使用 Vibe Coding，我比較習慣把事情分成兩類：

怎麼做，交給 AI。
做完之後會影響誰、會公開什麼、會授權什麼，自己看。

這個習慣也是一路踩著這些小問題慢慢養出來的。

明天 Day 27，來看另一個做法：把 AI 的建議丟給另一個 AI 審查。這次不是讓 AI 幫我寫，而是讓它幫我找規格裡的問題。

💬 你在部署或上線時，有沒有遇過一個指令看起來很普通，仔細看參數才發現它實際操作的範圍比想像中大的情況？歡迎留言聊聊。