讓 Codex 負責完整的模擬器循環

當 Codex 負責完整循環時，此使用案例的效果最佳：選擇正確的應用程式 target、在模擬器中啟動應用程式、檢查目前畫面、執行重現步驟、蒐集記錄與螢幕截圖、視需要檢查堆疊追蹤、修補程式碼，再沿相同路徑重新執行，以證明 bug 已排除。

若要讓這個循環持續由智慧體自主執行，請使用 Build iOS Apps 外掛程式。其 iOS 偵錯工作流程是以 XcodeBuildMCP 為核心建構，因此 Codex 能與已啟動的模擬器互動，並蒐集原本通常需要人工取得的相同證據。

當 XcodeBuildMCP 設定了模擬器自動化、UI 自動化、偵錯與記錄工作流程後，Codex 就能負責完整的重現、偵錯及驗證循環。如果 Codex 尚未選好專案、scheme 和模擬器，請先要求它找出合適項目，並在工作階段其餘過程中重複使用該設定。

充分運用 XcodeBuildMCP 的功能

實際使用時，可要求 Codex 運用以下幾類功能：

• 專案與模擬器探索：檢查 Codex 是否已知道要使用哪個應用程式 target 與模擬器、找出 Xcode 專案或工作區、列舉 scheme、尋找或啟動模擬器，並讓這項設定保持不變，以供後續的建置和執行步驟使用。
• 建置與啟動控制：建置作用中的應用程式 target、安裝並啟動模擬器建置版本、需要時重新啟動並擷取記錄；若 Codex 需要檢查應用程式專屬的執行階段記錄，則找出應用程式 bundle id。
• UI 檢查與互動：讀取畫面上的輔助使用階層、擷取螢幕截圖、點按控制項、在欄位中輸入、捲動清單，以及執行邊緣滑動或其他模擬器手勢。
• 記錄與偵錯工具狀態：串流模擬器記錄、將 LLDB 附加至執行中的應用程式、設定中斷點、檢查堆疊框架與區域變數，以及在需要深入調查當機或無回應問題時執行偵錯工具指令。

關鍵習慣是要求 Codex 在點按前先檢查檢視樹狀結構。XcodeBuildMCP 會提供輔助使用階層與座標，因此 Codex 可以優先使用穩定的標籤或元素 ID，而不必直接猜測螢幕位置。

將模糊的 bug 轉化為可重現的指令稿

當你的提示詞提供一個具體 bug 和一項預期結果，再讓 Codex 自主操作應用程式並蒐集證據時，iOS 偵錯技能最能發揮效用。如果需要登入、深層連結或測試 fixture，請一開始就說明，並要求 Codex 僅在缺少該資訊導致無法繼續時才暫停。

實用技巧

不只要求修正，也要要求證據

請要求 Codex 提供它用來說明 bug 的確切模擬器、scheme、螢幕截圖、記錄片段及堆疊詳細資料。相較於「我認為這應該能修好」，這些資料能讓最終修補內容更容易審查。

優先使用輔助使用標籤，而非座標

如果控制項沒有穩定的標籤或輔助使用識別碼，導致 Codex 必須依座標點按，請要求它明確指出。這通常表示 bug 修正也應包含小幅的 UI 可測試性改善。

每次執行只處理一個 bug

由模擬器驅動的偵錯循環功能強大，但當一個提示詞只針對一種故障模式時，結果仍然更值得信賴。請 Codex 先完成一次重現、修正及驗證循環，再擴及相關問題。