開發到第五天後半，CC 叫我去刷卡，說是要開通 Apple 開發者帳號，才能讓其他朋友用 TestFlight 測試。

開發者帳號要年費我知道，iOS 的 App 測試要走 TestFlight 我也知道，但一時間我還無法把兩者連在一起。更何況，這樣就能上線了嗎？有沒有什麼我沒注意到的雷點？

2025 年 9 月，一個推廣 Vibe Coding 的 AI 導師被 Google AI Studio 收了一萬多塊，那件事我印象很深刻。

她說自己讓使用者在前端自己填 API key，以為費用就算在使用者頭上，發出去之前還問了 Gemini 這樣對嗎？
實際部署後 Google 用的是她自己的金鑰，所有人的用量全記在她帳上。
大震驚之餘這個案子成為 Vibe Coder 的一個重要案例：記得注意安全機制與保管金鑰。

除了金鑰不要亂放，沒有後端與帳號以確保用戶跟我自己的安全，我還該注意什麼事情？
壓抑著慌張情緒，我想著問問第三方吧，我最會用多個 AI 交叉驗證。

於是連珠炮的問了 ChatGPT 的 Codex 一堆問題：

我請 Claude Code 幫我寫了個旅遊相片整理 app, 正打算整理後申請上架 apple app store. 以便朋友可以用 testflight 下載。（順序這樣對嗎？）請問有什麼該注意的事情，你能幫我 review code ，並且做安全性檢查嗎

得到 Codex 對程序的認可後，我才真的把程序走完。後來翻信箱才確認那天晚上的紀錄長這樣：

從簽協議到真的付完，41 分鐘。

那 41 分鐘就是「一陣慌張」的實際長度。帳號名稱按下去就不能改，必須是護照拼法才能跟事後的證件還有銀行帳戶相同。
我一度自己手殘按錯，把 Yoju 改成 Erica 又改回來。

事後回想，我問了 Codex「作業程序、Code Review、安全性檢查」，恰恰對應了工作上正式部署前的動作，只不過在工作中，開發團隊有 TPM 做作業程序的安排，同儕互相做 Code Review，還有弱掃與資安檢測的作業規則。

這些團隊合作在一人開發中通通沒有，於是我都請另一個 AI 幫忙了。

兩個 AI，一個開發者，一個審核者，恰恰幫我處理了分工。

事後討論，CC 一直問我「為什麼你會想請第三方檢核？起心動念是？」

我用力回憶好久，還回去把我跟兩組 AI 的對話，還有申請與刷卡紀錄翻了又翻，知道我進入了一個「不知道自己不知道什麼」的陌生領域，甚至連該怎麼問 AI 現在還缺什麼都沒把握：你怎麼會去問一個球員怎麼做裁判呢？

只好竭盡所能搜尋過去經驗中的關鍵步驟，程序要對吧、Code Review 要互相檢查吧、安全性審核要做吧。

換句話說，我把經驗作為起點，搭配第三方 AI，建立自己能使用的把關框架。

實際怎麼操作的？

首先是我請 Codex 出一份工作計劃，再回頭請 CC 提供哪幾段資料不用給 Codex，哪些原始碼該給它看。

CC 很同意要有第三方審核，而對於要提供的素材也有符合專案精神的建議：

我寫的程式碼由另一個 AI 用陌生眼睛看一遍，比我自己再看一遍更有價值，我會有自己的盲點慣性。給 Codex 的資料夾改成只給原始碼子資料夾，連 .git 都不要給。原因：repo 的 commit 歷史裡有朋友的名字和你們的旅程細節，程式碼審查用不到那些。

個人性的照片資料當然更不用給。內外的分界作用在每一層，不只是照片不上傳，連 commit 訊息裡的人名都不交出去。

它還幫我寫了一段給 Codex 的需求文件：

角色：你是這個 iOS 專案的獨立審查者與測試工程師。專案即將送 App Store 審核。
資料夾在⋯⋯

任務一：Pre-submission code review
只回報四類問題，每條附「檔案:行號＋嚴重度（高/中/低）＋一句話修法」：

1. 崩潰風險：force unwrap、越界、未處理 Optional，特別是 SwiftData 與 Photos 邊界
2. 審核紅線：權限文案與實際用途一致性、PrivacyInfo.xcprivacy 是否涵蓋實用 API
3. 可用性：iOS 17 裝置上未包 #available 的 18/26 API
4. 記憶體：2000+ 張照片掃描路徑的累積與未釋放快取

不要建議架構重構、不要改風格、不要動產品行為。

任務二：建立測試工作流 ⋯⋯

專案硬約束（違反會白做工）⋯⋯

產出格式：兩個清單（review findings / tests added），不要直接大改程式碼。發現的問題先列出來，由另一位審查者裁決後才修。

怎麼審核我還是不懂，但審核與任務編排的精神我是可以理解的。這段寫法跟我理解的一樣，於是我做起了兩個 AI 之間的搬運工，CC 也根據 Codex 的建議修正了一些嚴重錯誤，編排了文件等等。

AI 們對話並不是在互相吹捧

它的測試我全收，它的優化建議我砍了一半。

駁回也是有理由的。 都是記憶體建議：其中一條 CC 說 Codex 看錯了層級（以為是 N×N 的照片矩陣，實際是子場景，只有幾十 KB），另外兩條對記憶體的影響量級都在個位數 MB 以下，而蒙古 2577 張實機早就驗過。

另一個有趣的是後來在開發《這場》遇到的模擬器與實機差異，Codex 抓出 PDF 串流的問題：PDF 改成串流寫檔，一次只放一頁在記憶體。

原本是整份 PDF 組完才寫出去。研討會拍幾十張投影片、每張都是原解析度拉正後的圖，一次全塞進記憶體，手機上會直接當機。這種錯在模擬器上很難遇到，因為 Mac 的記憶體太大，所以怎麼塞都 OK。

這跟前幾天提到的 Vision framework 的美學分數在模擬器無法測是同一組問題的相反形式，一個是模擬器測不到要實機才行，另一個是模擬器不會有問題實機才會有。兩種都值得處理，也是在開發中才注意到的狀況。

心得

• 我不寫 code，但我是那個該負責的人，發布前找出所有可能影響負責的點是我的責任。
• 找第三方不是因為不信任，恰恰是在畫一個信任地圖，問過一輪之後，我建立了一個自己能理解與應用的把關框架。
• AI 審 AI 的價值在於陌生的眼睛。採納率大概七成，採納與不採納都需要理由。

這個系列同步寫在我的部落格：yojuhsu.com/blog

前一篇：【Day18】那些背叛我的權重
下一篇：【Day20】上架大魔王？按部就班來其實不難