自顧自地跟 CC 合作開發出 3 個 App 之後，我開始有點自信了：也許我真的有搞出點東西？能幹的不只是 AI，我也有點功勞？

驗證的方法，自然就是拿我能摸到的另一個 AI，Codex 來試試同一套做法了。

我想知道在 Xcode 沒換、專案文件沒換、需求說明方式沒換，只換掉對話與寫程式的 AI，能不能一樣做出能上架的 App 來？

一樣先說結果：可以，雖然開發風格不同，也遇到一些小阻礙，但跑得通。而且到後來我懶得當 AI 搬運工，它們甚至還會自己分配好作業交代我處理。

需求我用的是同一套手法

先說明需求、再說明限制，並且把 CC 做的專案文件當作給 Codex 的開發規範。

有以下概念 This foodie（吃了啥好料）／This plants（照了什麼樹根花）／This museum（去了哪些美術館博物館）

請根據產品複雜度，市場規模，是否容易引起共鳴，等等選一個來開工。希望兩小時內可以安裝到手機上，而且不會燒光額度

之後我又提到：

如果做不到直接說建議沒關係，我可能半小時內會睡著。

排序以及時間限制，都是我在前三個 App 開發時候用的手法，Codex 果然接住了。

我給它的專案文件中有要求，Codex 必須依照 CC 做的 UI 風格，並且把成果裝在模擬器上讓我看成果，這點它做得很好。

我也不差。

當卡關時，我會問「是不是卡在環境限制？」而不再是直白地問 Codex「為什麼壞了」。

先判斷問題來源是環境不是程式，再叫它換環境，足以見得經過 7 天的開發與交叉驗證，我已經有點判斷力。不是只按了7天的Enter。

兩個 AI 的開發風格有點不同

CC 是一條線走到底式的，Codex 則會開多條路線：例如請它做檢查，它就兵分四路的開工。

code review、UX review、安裝審查、SwiftData 遷移檢查。

這次為了寫作，去回顧對話紀錄時，CC 注意到，表面上我們只經過 18 個回合的對話，但 Codex 底下跑了 19 串子代理、106 個工作回合，有很多我在畫面上看不到的訊息量。

我印象很深的是，在環境處理上，Codex 的權限管理比CC嚴格。

像是它很堅持某些工具與審核的權限必須要我才能按，它無法代為安裝或者處理。

甚至還會自己分派作業給我處理，例如：

模擬器權限卡住時，它寫「請做兩步：1. 在 Simulator 點『允許完整取用』 2. 在 Terminal 執行這行指令。約一分鐘後告訴我『完成』。」

此外，Codex 也沒有像 CC 一樣一開始就堅持要做版控，直到當月底整理東西與上架了，我才請 CC 開始處理版控。

《這餐》是幾個 App 中 Git 次數最少的一個。

跑得動，並且尊重基本工作規範，我就覺得都好。

結果是兩邊都跑得通，而且提供相同的專案文件後，兩邊可以做出長得相似的家族 App。

心得

其實光光做四次，我離懂行還差非常遠，充其量只能說踩過的雷多一點，對自己要的東西清楚一點。

直到寫作這系列，信心指數才扎實往上：有把握靠著不斷問問題與反思，我真的可以在 AI 時代，自學很多不敢想的東西。

當然啦，最後的結論就是，除了 AI 厲害，我也有功勞，不只是按了 7 天的 Enter。

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

前一篇：【Day22】等 TestFlight 上傳與審核的時候做什麼？我開發了另外 3 個 App
下一篇：【Day24】開發的黑盒子沒有消失，只是變成透明的了