這麼瘋狂其實有幾個原因：

首先，過了 7 天腦力雲霄飛車的超 high 日子，我有點捨不得降速。

其次，開發的過程中我捨棄了好多可能性，想趁機來把它們都做出來。

最後，因為一切都在 CC 保姆級教學下完成，我想說要多練習才知道自己斤兩。

前兩個是擴張性理由，但最後一個是收斂學習型的。

我問了 CC：

1. 有以下幾個想法，請建議優先順序：1 手機截圖整理 2 親人照片整理 3 研討會或學習課程簡報整理
2. 也可以幫我做個市場調查，一般人對於照片整理還有其他需求嗎？

13 分鐘後，排序建議來了，跟我的偏好正好相反。

我從善如流，先從簡報歸檔做起。

事後也證明，雖然它是情感牽動最小的 App，也是我推廣上最難使力的，但可能因為有獨立完整的市場定位，競品又少，它反而是這三個 App 中下載數跑得較快的那個：《這場》已經有 134 個，《這餐》跟《這隻》都才剛剛突破 100 個。

更棒的是，從概念確定到開工再到收工，不到一小時。幾乎就是教科書等級的夢幻創業產品：找到只有你熟悉的市場，深挖它，開發它，佔領它。（只可惜佔領它這段我還遠遠沒有做到，歡迎看到這裡的人下載《這場》，整理拍過的簡報成為可以交流與沉澱思緒的 PDF）

這份報告最合我意的話是它看透了我的心思：

這三個題目其實是同一條管線的三張皮。核心資產是「從雜訊相簿依主題撈照片、擇優、產出可分享成品」，ThisTrip 按旅程切、親人題按人切、簡報題按場次切。

後來我跳過親人照片，現在回想，應該是怕踩隱私權的雷，改走寵物與用餐（我一直覺得被低估的市場，誰不想找出好吃的餐點與餐廳呢？現在的交流方式太沒有效率了），算是把我在照片整理這條路線上想做的都先做完。

四個 App 一起踩的同一個雷：我從未看過沒資料的空 App

Day 20 列過的那四次退件，四個不同的代號，我一開始以為是 CC 犯了四種錯，排開之後才發現不是。

我沒有想過：審核員的手機是空的，沒有預載資料。

我的 App 吃的是使用者自己的照片。沒有帳號、沒有後端、沒有我準備好的內容，所以「App 裡有什麼」這件事，完全取決於「開啟它的那支手機裡有什麼」。

審核員拿到的是一台測試機。相簿裡沒有我媽、沒有蒙古的馬、沒有任何一餐飯或一隻貓。

他按下開始掃描，掃完是零。故事書是空的，地圖是空的，早安圖生不出來。於是他寫信告訴我，他找不到我在商店頁描述的功能。他說的是對的。那一刻那個 App 真的沒有那些功能。

為什麼我到送審才知道

因為從開始到送審，沒有任何一刻有人打開過一個空的 App。

我手機裡有兩千五百多張蒙古照片、十幾年的旅遊照、家裡的貓。CC 拿這些跑測試，朋友拿他們自己的相簿測，每一次打開都是滿的。我們調的是「照片太多怎麼挑」，從來沒有人問過「照片是零的時候長什麼樣」。

上班的時候這段是有人檢查的，QA 夥伴有測試帳號，有乾淨的 staging 資料，新功能上線前會有人用全新帳號走一遍。

一人開發加上 AI，這一層完全不存在。AI 不會自己想到要清空你的資料試一次，它跟你用的是同一台機器、同一批照片。

所以不是它的錯，也不只是我的錯，是這條產線少了一關。

如果你也在做 Vibe Coding 的 App，而且它吃的是使用者自己的資料，送審前最有效的一件事不是再檢查一次隱私問卷，是拿一台空的裝置打開你的 App。或者至少讓你的 AI 模擬一次。 你會看到審核員會看到的東西。

CC 後來把這件事寫進了出貨清單，變成一行字：資料依賴型頁面，空狀態要能走完。 同一張清單的上面一行是：權限引導頁的按鈕禁用「允許」字樣。

那兩行就是那兩次退件。退件不是結束，是變成清單裡的一行。

心得

Day 3 說過，資源限制就是祝福。

我努力記起每個上班時候跟開發同事合作的方式，獨獨忘記身為 PM 自己本來就會做的空資料測試。每個人都可能忘在不同的地方。

忘掉沒有關係，把忘掉的東西變成檢查清單，也就是以後不會忘的基礎了。當然啦，你要記得用自己的檢查清單。

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

前一篇：【Day21】審核到底是 9 小時，還是 109 小時？
下一篇：【Day23】能幹的是 AI，還是我？