我為什麼不再讓 AI 一次把整個 App 做完

一開始，我真的很喜歡「全部交給 AI」

那時候我會先寫一段需求，然後把它丟給 AI。畫面要有什麼、按鈕要怎麼動、資料要存在哪裡，最好一次講完。接著看它開始修改檔案，心裡會有一種很奇怪的爽感。幾分鐘前還不存在的東西，現在已經可以點了。

這種方式在做 prototype 的時候很有效。你可以很快知道一個想法到底好不好玩，也可以在半天之內丟掉一個原本以為很棒的方向。問題是，prototype 會留下來。當你沒有真的丟掉它，下一個功能就會建立在前一個快速生成的決定上。

我遇過幾次很典型的情況。AI 改完之後，畫面可以跑，TypeScript 也沒有報錯，但實際操作會發現整個流程怪怪的。它可能把一個原本應該是本地資料的東西放到遠端，也可能為了讓按鈕看起來有反應，偷偷改了狀態管理方式。

最麻煩的不是錯誤很明顯，而是它看起來很合理。你不仔細看，很容易就按下接受，然後繼續做下一件事。等到幾個功能疊在一起，才發現自己已經不太知道這個專案為什麼要這樣寫。

那個時候我才發現，AI 最危險的時候不是它寫不出來，而是它寫出一個看起來可以的版本。

現在我會先把問題拆小。哪些事情是我需要先想清楚的，哪些事情只是重複性的實作，這兩類不再混在同一個指令裡。

產品方向、資料邊界、使用者流程，這些我會自己先做決定。AI 可以幫我比較方案、找出遺漏，甚至挑戰我的想法，但最後的取捨還是由我來做。

等邊界確定之後，才讓 AI 去寫元件、補測試、整理重複程式碼，或處理我已經知道要怎麼改的東西。這樣速度還是很快，只是我不再把整個方向一起丟出去。

我後來做了 keeponfirst-local-brain，也整理自己的 AI coding workflow，不是因為我想再做一套看起來很厲害的自動化系統。比較像是我需要一個煞車。

在 Local Brain 裡，AI 可以分類、整理、提出草稿，但不能直接把東西寫進我的紀錄。一定要先預覽，再由我確認。這個流程一開始覺得有點慢，後來反而讓我比較敢用。因為我知道它不會趁我分心的時候，把一個錯誤的理解變成正式資料。

AI 開始像一個會提 Pull Request 的人。它可以做很多事，但最後要不要 merge，還是要看我。

我還是很在意速度。獨立開發者沒有很大的團隊可以等，也不可能每個決定都開會討論。AI 讓我可以一個人完成以前需要幾個角色一起處理的工作，這件事我很珍惜。

只是速度不能拿來取代理解。如果我連資料怎麼流、狀態為什麼存在、這個功能解決什麼問題都不知道，那 AI 寫得再快，最後還是會變成我的維護成本。

我現在會讓 AI 幫我把已經想清楚的事情做快一點，而不是讓它替我決定我要做什麼。這個差別聽起來很小，實際上差很多。

有時候我還是會叫它一次做一大段，尤其是剛開始驗證想法的時候。但只要要留下來，我就會重新檢查架構、刪掉不需要的部分，再把真正重要的決定寫下來。

我不確定這是不是最有效率的方法。至少到目前為止，它讓我比較知道自己在做什麼，也比較敢把一個 App 繼續做下去。