在軟體開發中，我們已經能把規格文件、架構背景與既有程式碼餵給AI，讓它協助梳理設計、生成實作，甚至撰寫測試。但隨著AI產出程式碼的速度遠超以往，一個根本問題浮上檯面：

身為開發者，我們究竟還需要懂什麼？

AI能協助產出可執行的程式碼，但不會替系統的成敗負責。
身為工程師，我們依然要面對開發中必須做出的判斷：

• 實作符合規格，但這項設計真的有解決核心業務問題嗎？
• 當多個請求同時修改同一筆資料，結果是否仍然正確？
• 正常流程暢通無阻，但連線逾時、網路不穩或下游服務故障時，系統是否有適當的容錯與降級能力？

我們對系統運作與業務脈絡理解得越深，就越能提供明確的背景與限制，並衡量AI提出的不同方案各有哪些代價。這正是我想透過這個系列，重新梳理軟體開發基本功的原因。

這個系列預計用至少30天（希望可以順利完賽！），沿著軟體從需求到維護的過程，整理開發者仍然需要懂的事：

需求與問題：我們究竟在替誰解決什麼困難？
程式與設計：如何讓規則、責任與介面清楚可理解？
資料與狀態：如何處理並行操作、重複請求與資料不同步？
測試與安全：如何驗證功能正確，確保具備權限的人能存取資料與執行操作？
部署與營運：軟體上線後，如何觀察運作狀況、處理故障與恢復服務？
協作與維護：如何讓修改有依據，讓接手的人理解我們的決定？

我會從實際情境出發，說明問題為什麼發生、有哪些做法，以及各自的代價。也會討論AI可以如何協助，以及我們該怎麼確認它提出的方案適合眼前的情境。

帶著自己的經驗，一起重新思考

閱讀這個系列時，你可以帶入自己正在開發或維護的系統，想想：

• 當初為什麼這樣設計？哪些限制現在仍然成立？
• 如果AI提出另一種做法，我們會根據什麼接受或否決？

我也想藉由這次鐵人賽，整理自己的經驗，重新檢視那些習以為常的做法。每篇文章不一定都有唯一的答案，但希望能讓我們在面對下一個需求、下一次設計討論時，多一點判斷的依據。

在壓線的最後一刻按下報名，純粹是因為最近工作真的太「充實」
每天都在救火、開會與衡量各種技術債，題目想了又刪、刪了又想

身邊朋友問我：「AI都能寫出八成程式碼了，你下班不休息，還想連續花30天寫文章???」
我想了想回答：「大概是因為……當半夜被老闆Call、連線池被打爆時，AI可能都睡到作夢了，但爬起來看Log的卻是我自己吧。」

玩笑歸玩笑，趁這個機會，把這幾年思考架構、檢查AI提出的方案，以及做取捨的經驗整理下來，也算是替自己留一份紀錄。
畢竟，AI輸出到一半可以停在Max tokens reached...
工程師處理到一半，也不好跟老闆說今天的token用完了對吧！

三十天說長還真的很長，立個flag：希望今年順利完賽，中途不要斷更。大家明天見！