在過去的二十多天裡，我們幾乎每天都在和 AI協作。大家看到的，是 AI 如同一位完美的家教，有問必答，甚至能產出程式碼。但真實的開發流程，真的是如此順利嗎？

今天，我們要和大家聊聊這個系列文章背後，那個充滿挑戰、令人哭笑不得的真實開發流程。

陷阱一：專案打不開！AI 的「能」與「不能」

當我開始第一個 AI 專案時，我想説：「何不讓 AI 從頭幫我建立整個專案？」我請 AI 幫我規劃資料夾結構、設定 .xcodeproj 檔案。結果是災難性的。專案要嘛打不開，要嘛設定檔充滿錯誤。

• 問題核心：AI 擅長處理純文字的程式碼，但對於複雜、高度關聯的圖形化設定檔（如 .xcodeproj）則力不從心。
• 我的對策：人機職責劃分。
  1. 手動打地基：親自用 Xcode 建立專案，設定好 Target，完成最基礎的 Build Settings，並手動 git init。
  2. 劃定安全區：在 AI 工具的設定中，明確告訴它哪些檔案或資料夾是「禁區」。

陷阱二：畫面能看但不能用！AI 不懂 UX

在開發「夢境視覺化師」時，我請 AI 幫我設計輸入介面。它回傳的程式碼生成的畫面確實很美，但實際一用才發現，鍵盤會擋住輸入框，而且沒有「完成」按鈕可以收起鍵盤。

• 問題核心：AI 沒有主觀的使用者體驗（UX）概念。它能理解「讓按鈕置中」，但無法理解「使用者在輸入完成後，需要一個方便的方式收起鍵盤」。
• 我的對策：我不再給 AI 一個開放性的任務，而是將 UI/UX 設計拆解成最小單元。
  • 一次只給一個焦點：與其說「設計介面」，不如說「幫我建立一個 UITextView，要求有圓角、邊框，並且它的鍵盤上方需要有一個帶完成按鈕的 UIToolbar」。
  • 人類主導體驗：由我來規劃整體的 UX 流程，AI 則作為一個高效的元件產生器。

陷阱三：功能越大，AI 越亂套

當我試圖讓 AI 幫我一次寫完 GeminiAPIService 的所有功能時，它給出的程式碼簡直是一場惡夢。函式互相調用關係混亂，錯誤處理邏輯不一致，完全無法維護。

• 問題核心：AI 極度擅長製作單一功能的模組，但不擅長組織一個完整的產品。它缺乏宏觀的架構思維。
• 我的對策：你當架構師，AI 當實現者。
  1. 拆分任務：將「圖片生成服務」這個大功能，拆解成：「1. 定義 Request/Response 模型」、「2. 建立一個呼叫 API 的函式」等數個小任務。
  2. 逐一餵食：一次只讓 AI 處理一個職責單一的任務。當它完成後，再由我將這些模組正確地組合起來。

陷阱四：AI 的「短期記憶」與「對話污染」

在開發過程一開始，我給了 AI 一個生成圖片的模型，並明確指示：「這是我們的生成模型，接下來的任務中，你絕對不能修改它。」

起初，AI 遵守了這個規則。但在我們來回討論了十幾則訊息，完成了 UI 和其他邏輯後，我請它根據這個 Model 產生最終的整合程式碼。結果，AI 產出的程式碼不僅完成了不能用的功能，還順便修改了那個我一再強調不能更動生成圖片的模型。

• 問題核心：AI 的記憶力就是它的「上下文（Context）」，也就是我們整個對話的歷史。當對話變得過長，早期的關鍵指令（例如「不要修改模型」）的權重，可能會被後面對話中更近的、看似相關的內容所「污染」或覆蓋。
• 我的對策：主動管理 AI 的記憶。
  1. 重複關鍵指令：把 AI 當成一個記憶力很好的金魚。在每一個重要的步驟或請求前，不厭其煩地重申一次最重要的前提。例如：「好的，現在請幫我生成 UI，請記住，絕對不要修改生成圖片的模型。」
  2. 清空上下文，重新開始：如果發現 AI 開始產生混亂或忽略指令的行為，最快也最有效的解決方法就是：立即清空當前的對話歷史。然後，在新對話中，只提供當前任務最必要、最精簡的上下文和指令。這能確保 AI 不會被之前的討論所干擾。

今日總結

與 AI 協同開發，是一門嶄新的藝術。它並非一個能讓我們躺平的「自動化」按鈕，而是一個需要我們學習如何去「駕馭」的強大引擎。

從明天開始，我們將回歸初心，打造一個經典且完整的天氣API APP ！