今天是鐵人賽的第 29 天，這趟不可思議的旅程，即將抵達終點。
回首這一個月，彷彿一場夢。我還記得 Day 2 時對 Optional 感到困惑，記得第一次在 Xcode 成功運行 App 的興奮。
這整趟實驗的核心，就是探索 AI 如何改變學習與開發。那麼，經歷了這一切，我認為，作為一個 iOS 開發者，有哪些核心價值是永恆不變的？又有哪些工作模式與所需技能，已經被 AI 徹底顛覆？
AI 並非萬靈丹，它更像一個放大器，只會放大我們已有的能力。穩固的基礎功在 AI 時代變得更加重要。
穩固的基礎知識
如果連 MVC 的基本職責劃分都不懂，我們將無法向 AI 提出正確的問題，也無法判斷它回應的 MVVM 架構是否優質。在Weather Api App 中，正因為我理解了 MVVM，才能指導 AI 寫出職責分離的程式碼。
架構設計與拆解問題的能力
AI 是優秀的「工匠」，但卻是糟糕的「建築師」。將一個模糊的產品需求，拆解成一系列清晰、具體、可執行的技術任務，這依然是人類開發者最重要的價值。如同我們在 Day 25 的心得，直接對 AI 說「幫我做一個天氣 App」會導致災難；但若將任務拆解成「幫我建立對應這個 JSON 的 Codable 模型」、「幫我寫一個呼叫此 API 的 Service」，AI 就能完美勝任。
對使用者體驗 (UX) 的執著
AI 沒有同理心，它無法「感受」一個 App 好不好用。打造流暢、直觀、有溫度的使用者體驗，永遠是開發者的核心追求。在天氣 App 中，決定加入地圖作為入口（Day 28），或是為 AI 專案加上載入動畫與錯誤提示（Day 23），這些都是基於對「人」的考量，而非純粹的技術實現。
AI 徹底改變了我們的工作流程與所需技能，我們應該擁抱這些變化。
從「程式碼工人」到「AI 協調員」
開發者的時間分配發生了轉變。我們花在撰寫重複性、樣板化程式碼（如 Codable 模型、UITableView 代理方法）的時間大幅減少，而更多時間投入到更高層次的系統設計、API 整合與程式碼審查上。
提示工程 (Prompt Engineering)成為核心技能
與 AI 溝通的品質，直接決定了產出的品質。「如何問出好問題」已經從一個軟實力，變成了開發者的硬技能。對比 Day 3 問的「什麼是閉包？」，到 Day 22 我們精心設計的、要求 AI 回傳特定 JSON 格式的複雜 Prompt。這整個過程，就是提示工程能力的成長曲線。
大家應該會看到我的 prompt 都會寫「請簡單說明且並不需要給程式碼」，因為 AI 生成的程式碼並不一定會符合我們的專案架構或需求。雖然可以直接索取程式碼來加速學習，但我認為，先理解原理，再讓 AI 生成程式碼作為參考，會是更為紮實且有效的學習路徑。
學習與原型開發的驚人加速
對初學者而言，最大的改變是「速度」。AI 如同一個 24 小時待命的超強家教和程式碼產生器，極大地降低了學習新知和驗證想法的門檻。整個鐵人賽就是最佳證明。一個新手在 30 天內，從零基礎到完成三個功能各異的 App，這在沒有 AI 的時代幾乎是難以想像的。
我最大的體悟是：AI 並不會讓你跳過學習基礎的過程，它只是給你一輛更快的車，讓你馳騁在學習的道路上。最終，方向盤還是握在我們自己手裡。我們依然需要學習如何如何清晰地描述我的需求、拆解我的任務，因為這個強大的「AI 夥伴」，並不會讀心術。
iThome鐵人賽
看影片追技術