用AI打造真實產品，卻不迷失方向

一位擁有近三十年軟體開發經驗的工程師，在輔導兒子棒球隊的過程中，因頻繁在球場邊臨時調整陣容而感到沮喪。這激發了他開發一款名為CalledUp的應用。該應用整合了球隊名單、賽程、陣容安排和家長訊息功能，旨在幫助教練從後勤事務中解脫出來，專注於執教本身。

與其他“用AI寫個應用就上線”的做法不同，作者從一開始就設定了一條原則：自己必須能夠長期維護這個專案。這意味著所有關鍵的架構決策——比如資料模型、狀態管理、程式碼邊界——都由他本人決定，AI只負責在已確定的框架內編寫具體程式碼。他形容自己對待AI的方式，就如同對待一位剛入職但技術精湛的新工程師，在他完全瞭解團隊規範之前，需要給予明確的指導。

作者特別強調了一個習慣：將思考與構建分開。很多功能最初都是在球場邊用手機錄下的想法，他會透過AI應用（如Claude）進行對話式的推演，理清問題本質和使用者實際需求。等到回家開啟電腦時，他已經有了清晰的規劃，直接開始編碼。這種分離避免了他同時處理設計和編碼時容易出現的偏差——即功能執行正常但解決的是錯誤的問題。

在開發過程中，作者堅持每步只做一個小功能，比如“標記某個玩家無法參賽，系統自動在陣容中高亮提醒”。他要求AI先生成計劃，然後仔細閱讀輸出，不理解的地方就追問或修改。測試環節也摒棄了演示式的檢查，而是直接用真實手機執行真實場景：先編排陣容，再突然移除一名玩家，觀察系統如何反應。他認為，真正的考驗不是程式碼能否編譯，而是能否應對Jacob在開賽前一小時突然請假的情況。

那麼AI究竟發揮了什麼作用？作者指出，它顯著縮短了從想法到功能的時間。對於一位有日常工作、有孩子的獨立開發者而言，時間是最稀缺的資源，而上下文切換的成本極高。AI減少了編寫樣板程式碼、搜尋佈局、重複構建相似列表等工作所需的時間，將一個原本要花費整個晚上的任務壓縮到大約一小時。這一小時的節省，往往就是一個副業專案能夠順利上線還是永遠停留在半成品分支的關鍵區別。

作者最後總結道：從自己真正遇到的問題出發，在動手編碼前先進行充分思考，將決策權牢牢握在自己手中，只把打字這件事交給AI。保持小步快跑，認真閱讀每一行AI生成的程式碼，像真實使用者一樣測試，然後真正把產品釋出出去——因為只有在真實使用者使用後，才有有意義的反饋。他相信，現在的工具已經足夠強大，一個擁有真正問題且具備一定紀律的人，完全可以在業餘時間打造出精緻的產品。風險不在於AI太弱，而在於它足夠強，以至於容易讓人跳過那些確保產品長久穩固的關鍵步驟。