回到 7 月初，Claude 再次放出 Fable5，所有人都興高采烈的，做東又做西，我的社群每天看到各種炫耀。我沒有東西可以炫耀，只有焦慮。焦慮不知道做什麼好。

畢竟 6 月中 Fable5 放出來那輪，我已經嚐過了需求亂開一通，結果搞一整晚，token 燒光光還做不出來的悲劇。

這次務必要謹慎。

想了一整週

終於想到旅遊與拍攝，把我做過的所有東西整合起來不就好了嗎？

行前：過去我讓每個 AI 都做過，給它個大概地區、日期、旅程長短、團隊成員以及主目的。AI 就會俐落地排行程、甚至能畫出這行程的樂趣與風險所在，還能給長輩避雷建議。最後畫出行程圖，還附有示意小地圖。

中間：我認識一些愛拍照的前輩，會根據行程的風景準備衣服，以及準備這次要擺拍的姿勢與主題，到場的時候再一次次地按照計劃擺拍。剛開始覺得繁瑣，可是你別說，拍出來的照片還挺好看。

旅後：每次帶爸媽去旅遊，他們表達滿意的方法就是回來對親友說的嘴角起泡。但聽的人畢竟無法身歷其境。我用旅遊相簿服務印出過幾次旅遊故事書，不但爸媽講的時候有素材，我也可以跟他們一起回味。很喜歡。但挑照片跟編輯就搞死我，如果能讓 AI 幫我做不就太好了？

行前規劃、旅遊中拍照指導、旅遊後挑好照片變故事書。這些都是 AI 可以讓我生活變更好的地方，如果能把它們都整合在一個 App，那不就太棒了嗎？我想用，也想推薦給姐妹用。

把限制先講出來

由於有第一次怎麼做都做不完的慘痛教訓，這次一開始就用結構化的方法跟 Claude Code（以下簡稱 CC）溝通，並且自己先設下限制：

由於計劃宏大，很可能無法在1.5天內做完。請先設計成即使使用一般模型也能完成並上架app store獲得反饋的規劃

限制讓人實際。CC 直接告訴我：

1.5 天內上架 App Store 不可行，這是 Apple 流程決定的，跟模型強弱無關。

它算給我看：我的 Mac 還沒裝 Xcode、開發者帳號審核要一到兩天、送審要 24 到 48 小時，所以「可行的時程是純開發約 2 天，加上等待，7 到 10 個日曆天上架」。

接著它給了一個我沒想過的切法：

規劃的核心切法：v0 完全不做 AI。我把你的十條永久規則逐條對過，其中八條不需要 AI 就能滿足。

十條有八條不用 AI，代表便宜、代表快、也代表不靠運氣。我馬上接受，十分鐘後回它：

v0 我想先做事後管理，因為這一定是最多人的痛點：手機裡面很多缺少分類的相片，如何清理，擇優，炫耀。

宏大的全旅程 App，在這裡縮成三個動詞：清理、擇優、炫耀。

清理和不刪除打架

這時候 CC 指出一個我沒注意到的衝突：

「清理」跟你的規則 6「不得刪除 raw files」有衝突，需要一個明確的解法。

它提的解法很完整：App 自己永遠不刪、刪除前要人工總覽待刪清單、實際刪除交給 iOS 系統去執行，系統還會再確認一次，照片進「最近刪除」三十天可以救回。三道防線，技術上無懈可擊。

我看著那三道防線，想的卻是另一件事：為了刪照片，要多做三層保護、多寫兩個畫面、多擔一份風險。那還清理什麼？

於是我回它：

不用清理放到存檔即可。主要需求是擇優以及調整（光線與角度），加上炫耀（重點）。

清理整個拿掉，廢片收進 App 內的存檔匣，相簿一張都不動。照片分成四個標籤：精選、留、存檔、資訊。資訊這個標籤來自我一開始寫的第 8 條規則，展牌、票券、地圖、文物說明，就算拍得爛也預設保留。CC 那句話我很喜歡：展牌票券在別的 App 是垃圾，在這裡預設保留。後來金澤那趟 762 張照片裡，資訊照有 175 張。

CC 接著算出這個決定的連鎖好處：

App Store 審查故事變成「零收集、零網路、零破壞性操作」；行銷語言可以直接寫「絕不刪除、絕不修改你的任何原始照片」。

一個為了省事的決定，變成產品的承諾。

心得

把宏大的需求，變成能力可完成的小規模任務，是這天最好的一個決策，也送給所有 Vibe Coder 初心者。

我們剛開始，不要急躁，選那種一定做得出來的最好。

資源限制是開發初期最好的禮物，珍惜它。

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

前一篇：【Day2】然後呢？（下）
下一篇：【Day4】抉擇的成本