我平常的本業是寫程式，副業是教人用 AI 寫程式。講了很多「AI 可以幫你寫」，但學生常問的其實是另一件事：從頭做到上架，到底長什麼樣子？
所以這篇不講通論，只講我最近實際做完的一件事：用一支 AI 團隊，做了一款 Android 回合制推箱解謎遊戲《地城100》（又名「百關地牢」），並送上 Google Play 封閉測試。我會把時間、版本數、踩坑都寫出來，包括做壞的部分。
先把話說在前面：「5 天」是從 git 第一個 commit 到封閉測試版本上線的日曆天數，不是「一個人專心做 5 天」，也不代表遊戲已經完美。後面會看到，有一個世界的關卡到寫這篇時還沒調好。
成果先看：這款遊戲現在長這樣
遊戲玩法是回合制推箱：角色每走一步，場上的東西也跟著動一步，目標是走到樓梯過關。目前共有 80 關（8 個世界、每世界 10 關），加上後來新增的第 9 世界「鏡偶」10 關，合計 90 關。
上面這張是 Android 實機尺寸比例（9:16）的自動截圖，不是美術設計稿。每一版我們都要求附上這種截圖，原因後面「驗收」那段會解釋。
時間線：10-23 到 10-27
數字來自 git 紀錄與我們的工作日誌：
| 日期 | 發生了什麼 |
|---|---|
| 10-23 | 第一個 commit：世界 1 十關可玩、十字鍵操作、世界 2 加入炸彈機制 |
| 10-24 | 世界 3～5 等大量擴充（當天 repo 有 34 筆提交；細節我沒有逐項查證，這裡不編造） |
| 10-25 | 我決定「今天衝 Android 上架」；UI 換皮第一輪 6 張參考圖全被我退件，第二輪才收斂；發出第一個側載測試版 |
| 10-26 | 第 9 世界第一版做完被我否決並整個作廢；封閉測試 1.7.2 送審，下午通過；重做鏡偶世界，整合英日雙語（1.7.3） |
| 10-27 | 世界地板換色（1.7.4）、鏡偶盲測後修三輪；晚上 1.7.5 版（versionCode 32）上傳並顯示為最新版本 |
整段期間，repo 約 76 筆提交（10-23 是 4 筆、10-24 是 34 筆、10-25 是 7 筆、10-26 是 24 筆、10-27 是 7 筆）。對外有名字的版本是 1.7.0 到 1.7.5 共 6 版。真正送 Google 審的只有兩個版本：1.7.2 與 1.7.5。
所以「5 天」的意思是：10-23 到 10-27，日曆上跨 5 天。這 5 天裡 AI 是輪班跑的，我主要在做決定、玩遊戲、挑毛病。
團隊怎麼分工
我沒有讓一個 AI 從頭做到尾，而是把它當成小公司，一個崗位一個模型。下面是這次實際跑出來的觀察，不是理論：
| 角色 | 用的工具 | 這次做什麼 | 我的觀察 |
|---|---|---|---|
| 開發主管 | Claude | 架構、疑難、最終審查、在 Play Console 代填表單 | 不叫它大量實作，省額度也省共用電腦的資源 |
| 開發二 | Codex | 遊戲規則、存檔、建置 AAB、版本整合 | 額度會中途用完（10-26 就斷了一次） |
| 總經理 | Codex | 上架文件、審查單、交叉審查 | 自己沒親自跑的測試，要它明講「未親跑」 |
| 企劃 | Gemini | 玩法構想、英日翻譯、點子 | 規格要多輪審查才收斂；數字和網址要抽查 |
| 美術 | Grok | 角色、封面、配色圖 | 週額度會用完；風格要先定 |
| 臨時幫手 | Claude 代理 | 新手盲測、獨立審查、額度斷線時接手 | 用完即關，預設用便宜的模型 |
有三個做法很值得學。
第一，「檔案寫好」不算交棒完成。 上一棒把檔案放到資料夾，下一棒要回「已接件」才算數。我們前一晚就發生過一次，A 做完後沒人轉給 B，流水線空轉了好幾個小時。
第二，審查意見合併成單一修改單。 多個審查者各丟一份意見，實作者會被搞瘋。我們要求合併成一張編號清單（E1、E2……），並規定「同一件事退修兩輪還沒過，由開發主管直接裁定改法，不開第三輪」。
第三，每個人額度都會用完，所以任務卡要寫代班人。 這次就遇到 Codex 額度斷線，後續版本的退修改由 Claude 代理接手；美術額度用完，封面修補由總經理用生圖工具代班。
驗收：不讓做的人自己說「做好了」
這是整個流程裡我認為最值錢的一段。AI 很會說「已完成、測試通過」，所以我們把驗收拆成三層，而且沒有一層是實作者自己做的：
1. 獨立審查：每個版本交給一個沒參與實作的 Claude 代理，從頭讀交付說明、跑指令、看截圖，只回報「可上傳」或「必修清單」。 2. 新手盲測：新的鏡偶關卡，我們只給代理一份「沒有答案」的關卡資料與玩法說明，叫它當新手去解。結果抓到某一關新手 20 次都解不開，另一關操作很繁瑣。如果給它答案，這種問題永遠看不到。 3. 真機：自動測試跑在瀏覽器裡，測不到真機行為。像「開信件」「購買流程」這類原生功能，我們就在交付檔裡標「真機未驗」，直到我親手在手機上試過才改狀態。
每一版的交付資料夾都附：邏輯測試 log、多語系 log、瀏覽器截圖、原生建置 log，以及檔案的雜湊值。連「第一次失敗的 log」都留著，這樣事後可以看見當時是怎麼修的，而不是只剩一個漂亮的結果。
交付說明裡有一類檢查我特別推薦：上傳前實際掃描安裝檔，而不是相信設定旗標。這次 1.7.5 的 Play 聲明是「無廣告、無內購」，所以我們用工具掃描 manifest（沒有廣告 ID 與計費權限），並掃了編譯後的 DEX：6,559 個型別裡，廣告與計費相關類別是 0 個。這比「我把開關關了」可靠得多。
上架 Play 的實際門檻
我的帳號是新建立的個人開發者帳號（帳號類型在素材裡沒有明確記載，這點我標為未查證；以下是針對個人帳號的規定）。
根據 Google Play Console 說明頁，在 2023 年 11 月 13 日之後建立的個人開發者帳號，必須先跑封閉測試：至少 12 位測試者，連續選用（opt-in）至少 14 天，然後才能在 Play Console 申請正式版（production）的發布權限，在那之前 Production 與預先註冊功能是關閉的。官方說明：Test your app requirements for new personal developer accounts。
我們的實際狀況：
- 10-26 送審封閉測試時，名單只有 2 人；當天過審後增加到 6 人，10-27 晚是 7 人。
- 離「12 人」還差 5 人，所以 14 天的倒數還沒開始（我們的紀錄是「從第 12 人加入起算」；Google 說明頁寫的是「連續 14 天」，是否從第 12 人加入才開始算，我沒有在官方頁面找到明確文字，未查證，請以官方說明為準）。
- 網路上有文章說「測試者數量中途掉到 12 以下，14 天會重算」，這是第三方說法，我沒在官方頁面看到，也未查證。
另外有三個容易漏掉的限制：
- 版本號（versionCode）只能遞增。 我們側載試玩版和 Play 版共用同一串版本號，試玩版號跳得快，結果 Play 版 1.7.2 是 16，到 1.7.5 已經是 32，下一版至少要 33。
- 商店聲明要和安裝檔一致。 聲明寫「無廣告」，就不能把含廣告 SDK 的版本放上去。這是為什麼我們把 1.7.5 刻意維持在無廣告、無內購的狀態。
- 找測試者要早點開始。 我們一直到送審當天才開始湊人，是最典型的「程式做完才找人」。
3 個真的踩到的坑
坑 1：把「難」翻成數字，結果關卡變得沒人想玩
第 9 世界第一版，我們用步數與狀態數當「難度」指標，工程驗收全過，但我一玩就說「刻意，感覺沒招了」，整個作廢重做。重做成「雙生鏡偶」之後，又經過三輪修正，寫這篇時最後一關還是新手解不開（我決定先自己用真機玩過再決定怎麼改）。
下面兩張是鏡偶世界的畫面。9-9 是我們反覆修改的關卡之一，兩隻石偶的移動方向不同，會互相擋路：
根因：我們優化了錯的指標。難度應該來自「啊哈，原來可以這樣」，而不是站位湊不出來。這件事的教訓：新機制先做 3 關紙上原型給人玩，再擴量；難度靠洞察，不靠步數。
坑 2：兩條分支同時活著，資料來源卻不唯一
為了讓 Play 版保持乾淨，我們同時維護「Play 線」與另一條準備之後版本的分支，還有好幾個 git worktree（每個版本一個資料夾）。結果 1.7.5 需要把另一條分支裡修好的第 9 世界資料，手動搬到 Play 線的基底上，連回饋功能的外掛都要獨立帶入。更危險的是：這些分支在寫這篇時都還沒 push 到遠端，硬碟壞了就全沒了。
教訓：關卡資料、字串要獨立成可以單獨 cherry-pick 的目錄；交接檔要寫清楚「哪條對應 Play、哪條還沒 push」；盡早 push 備份。
坑 3：美術來回五輪，最後維持原版
我嫌封面太可愛、有 AI 味，美術重畫了好幾版（拼接素材版、剪影版、海報風三案……）。後來才發現：Q 版圖示、寫實海報、像素遊戲截圖三種畫風擺一起本來就打架；而且晚上請朋友看，朋友說原本的好看。最後維持原版。
教訓：換封面前，先拿 2～3 位目標玩家看現版，並把候選方案縮成商店縮圖大小並排比較，而不是只看大圖。我們同時也犯了「只給單張圖、沒給對標」的錯，第一輪 UI 參考圖 6 張全被退，浪費了一輪。
你可以照做的檢查清單
如果你也打算用 AI 做 Android 遊戲或 App 並上架，下面是我整理的清單：
- [ ] 先查商店規則：封閉測試人數、天數；把「首版要不要含廣告／內購」寫成明確決定
- [ ] 範圍逐項確認再開工：美術精度、音效、掉寶……不要邊做邊猜
- [ ] 每個新機制先做 3 關紙上或最小原型，自己玩過再擴量
- [ ] 難度定義為「啊哈＋挫折」，不要只用步數、狀態數當依據
- [ ] 版本表：versionName、versionCode 序列，側載版與商店版分開，試玩檔另取檔名
- [ ] 分支圖寫進交接檔，並盡早 push 到遠端備份
- [ ] 開畫前附上 1～2 張對標圖，並讓目標玩家看過現版
- [ ] 每版交付附：測試 log、至少兩種手機尺寸的截圖、檔案雜湊值；原生功能標「真機未驗」
- [ ] 審查由沒參與實作的人（或新的 AI 對話）做；盲測只給無答案資料
- [ ] 派工前先確認每個 AI 的額度，任務卡寫代班人
- [ ] 邀請測試者和開發同步進行，不要等到上傳前才找
- [ ] 上傳前實際掃描安裝檔（manifest 與 DEX），確認與商店聲明一致
最後說幾句
回頭看，AI 讓「做出一個能玩的東西」這件事變快了很多，但真正花時間、也最值錢的，是驗收、決策與商店規則。AI 不會替你發現「這關其實不好玩」，也不會替你記得 Google 要 12 個測試者。
這支團隊的成績單也不漂亮：一個世界整個作廢、一關到現在還沒調好、正式版門檻還差 5 位測試者。但正因為這些都是真實發生的事，我才覺得值得寫下來。下一篇我想拆解「怎麼設計新手盲測」，如果你有興趣，歡迎在課程裡告訴我。
想看看這款遊戲長什麼樣子，可以到《地城100》介紹頁逛逛。
*本文所列數字（提交數、版本號、測試人數）均取自我們的 git 紀錄與工作日誌，截至 2026-10-28；標示「未查證」之處為我沒有在官方文件確認的內容。*