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

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

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

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

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

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

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