2026 年 11 月 5 日，掘金開發者波兒菜發布了一篇關於 Xcode MCP 的實戰文章，討論的主題很具體：iOS 用戶端最難處理的那類當機，堆疊裡全是系統框架，沒有現成原始碼可以對照。
這種報告長什麼樣子？文章舉了一個例子：EXC_BAD_ACCESS(SIGSEGV)，當機點落在 libdispatch 的 dispatch_source_set_timer，往上依序是 CFNetwork 的 URLConnectionLoader、libdispatch 的佇列排程、libsystem_pthread 的執行緒。整份堆疊沒有一行是你自己的程式碼。這就像家中停電，臺電的紀錄顯示跳脫點在變電所，但你家的電器配置只有你自己知道，問題出在哪一段，得沿線逐步排查。
靜態反組譯工具在這種場景的限制很明顯：多數時候只能推導，無法證實，而且丟失了執行期資訊這類關鍵線索。疑難雜症往往必須回到執行期分析，也就是讓程式真的跑起來，在當機現場一步步觀察。但執行期分析需要環境建構、GUI 操作、業務場景重現，這些工作 AI 難以完全獨立承擔。
文章的核心判斷在這裡：與其讓 AI 全包，不如讓工程師與 AI 協同分工。工具選擇上，IDA 雖然可除錯 iOS，但操作繁瑽、體驗不佳，適配也落後；lldb-mcp 沒有 GUI，更適合純自動化情境；而新版 Xcode 的 mcpbridge 提供 LLDB 呼叫通道，有機會做到無縫協同，工程師在 Xcode 介面裡操作，AI 透過 MCP 通道讀取現場、下指令、整理線索。
這個分工邏輯，與我們先前整理過的老工程師用掛機腳本解讀 MCP 與 Skills的觀點相通：新名詞改變的是交付方式，判斷現場、設計驗證步驟這些基本功仍是工程師的職責。對日常維運 App 的團隊來說，這類配置的實際意義在於縮短「拿到當機報告到定位根因」之間的距離，尤其是那些重現機率低、只出現在特定機型或系統版本的案例。
不過文章也隱含一個前提值得留意：協同分析的效率，取決於 AI 能否穩定取得正確的執行期資訊。通道建好只是起點，怎麼設計驗證順序、怎麼避免 AI 在錯誤的假設上打轉，仍是後續觀察重點。