桌機瀏覽器把視窗縮到手機寬度，版面一切正常；網址一放到 iPhone 上，右邊卻多出一截空白，整頁還能左右晃。這種縮窗看不出來、實機才出事的跑版，原因常常不在 CSS 寫錯，而在 iPhone 上的 Safari 處理視埠、安全區域與網址列的方式跟桌機不一樣。
要查這類問題，最直接的做法是看到 iPhone 上那一頁的 DOM、CSS 與載入記錄。Mac 上的 Safari 內建了這條通道，只要用 Safari 的網頁檢查器連上 iPhone，就能在 Mac 的大螢幕上檢查手機裡正在顯示的網頁。動手接線之前，先弄清楚這個工具能看到什麼、又有哪些前提。
Safari 網頁檢查器是什麼？
Safari 網頁檢查器的英文名稱是 Web Inspector，Apple 的繁體中文說明稱為「網頁檢閱器」，是 Safari 瀏覽器內建的開發者工具，用來檢查與除錯網頁的 HTML、CSS 與 JavaScript。它不是外掛，也不必另外下載。根據 Apple 的說明，它能檢查的對象包括網頁、service worker、Mac 與主畫面的網頁 App，以及 App 內執行的 JavaScript。
Web Inspector 把核心功能拆成不同分頁，跑版排查最常用到的有四個：
- Elements：檢視可編輯的 DOM 標記樹，點選節點就能看到套用在它身上的樣式，是找出哪個元素把版面撐壞的起點。
- Console：列出頁面送出的 log、錯誤與警告，也可以直接輸入 JavaScript 指令查詢頁面狀態。
- Network：列出載入頁面資源的所有網路請求與回應，包含狀態與時間，用來確認 CSS、字型或圖片有沒有真的載入。
- Storage：查看 cookies、localStorage、sessionStorage 這類頁面存放的資料。
除了這四個，Web Inspector 還有 Sources、Timelines、Graphics、Layers、Audit 等分頁，分別對應原始碼除錯、效能記錄、動畫、圖層與稽核，查版面時多半用不到。
對跑版來說，這個工具最有價值的地方是遠端檢查。iPhone 接上 Mac 之後，iPhone 的名稱會出現在 Safari 的開發選單裡，可以檢查 Safari 分頁、加入主畫面的網頁 App，以及開發者部署且設為可檢查的 App 內網頁。畫面是 iPhone 上的 WebKit 引擎真正算出來的結果，不是桌機引擎模擬出來的近似值。
不過這條路有個前提，就是必須有一台 Mac。Apple 的文件把這個功能描述成從連接的 Mac 檢查 iOS 與 iPadOS 裝置，文件裡沒有只用 iPhone 單獨檢查網頁元素的做法。手上沒有 Mac 的話，遠端檢查就用不上，只能退回其他測試方式。
回應式設計模式只能近似實機的 iPhone 畫面
在 Mac 上縮小視窗跟直接檢查 iPhone，是兩種精確度不同的方法，接線之前要先分清楚。Safari 的回應式設計模式（Responsive Design Mode）從開發選單的「進入回應式設計模式」進入，快捷鍵是 ⌃⌘R。進去之後可以切換視埠尺寸預設、旋轉方向、自訂寬高，以及調整像素比；縮放比例則會依視埠與視窗大小自動顯示，不能直接修改。尺寸是以 screen points 計算，可以直接點寬高數字輸入，也可以拖曳視埠邊緣。
不過 Apple 在文件裡也明講了限制，預設的尺寸只是不錯的近似值，並不代表實機上的版面、渲染與行為，文件舉的例子正是瀏覽器網址列、螢幕鍵盤，以及表單欄位在裝置上的特殊行為。換句話說，縮窗能抓出斷點寫錯、元素過寬這類單純的寬度問題，卻看不出網址列收合或鍵盤彈出時，版面會變成什麼樣子。
Apple 文件也提到 iOS、iPadOS 的渲染行為跟 macOS 不同，建議在需要更準確的預覽時改用模擬器。開發選單裡的 Open Page With 子選單，在裝了 Xcode 之後會列出 iOS 模擬器，可以挑不同機型與 iOS 版本來開同一個網址。要測內建以外的 iOS 版本，得另外加裝模擬器的 Runtime，路徑是 Xcode 的 Settings 裡的 Components。模擬器的 Web Inspector 永遠是啟用狀態，開機中的模擬器會像實機一樣出現在開發選單，所以後面講的檢查流程在模擬器上也一樣能走。
三種方法可以這樣分流：寬度類的問題，例如某個斷點沒生效、某個元素在窄螢幕下撐出去，先在 Mac 縮窗重現就夠了；縮窗正常、只在 iPhone 出現的問題，才值得接線檢查；沒有實機、又想看不同機型與 iOS 版本時，模擬器是中間選項。
連線前，iPhone 與 Mac 兩端都要先開啟檢查功能
遠端檢查要成功，iPhone 與 Mac 兩端的開關缺一不可。iPhone 沒開 Web Inspector 開關，Mac 的開發選單裡就不會出現這台裝置；Mac 沒有開啟網頁開發者功能，選單列連開發選單都沒有。WebKit 的說明文件也特別提到，遠端檢查要求連線的 Mac 上同樣開啟 Web Inspector。
兩端都處理完，接上線之後，就能在 Mac 的開發選單看到自己的 iPhone，再從裡面選出要檢查的那一頁。
iPhone 端要在 Safari 進階設定開啟 Web Inspector
iPhone 要先同意被檢查，Mac 才看得到上面的網頁。Apple 現行文件寫的路徑是 Settings 裡的 Apps，進入 Safari，往下捲到 Advanced，再開啟 Web Inspector 開關。中文介面的實際字樣因版本而異，找 Safari 設定頁最底下的進階區塊即可。
舊版 iOS 的路徑少一層，是設定直接進入 Safari，再到進階。WebKit 的說明文件寫的就是這個舊路徑，兩個版本的差別只在中間有沒有 Apps 這一層。
這個開關的作用是授權，等於 iPhone 的擁有者明確表示願意讓連接的 Mac 檢查這台裝置上的網頁內容。沒開的話，不管線接得多正確，Mac 那邊都找不到可以選的分頁。
Mac 端要先顯示開發選單
Mac 上的 Safari 預設沒有開發選單，也沒有 Web Inspector 的入口。要先在 Safari 的選單列選擇 Safari，進入設定（快捷鍵是 ⌘ 加逗號鍵），切到 Advanced 窗格，勾選 Show features for web developers，中文介面是「顯示網頁開發者的功能」。
勾選後，選單列才會出現「開發」選單。後面的操作幾乎都從這裡出發，包含接上 iPhone 後選分頁、進入回應式設計模式、啟動元素選取、清空快取。
舊版 macOS 的同一個勾選框叫 Show Develop menu in menu bar，中文介面是「在選單列中顯示『開發』選單」，位置在 Safari 偏好設定的進階頁。看到的字樣跟這裡不同時，指的是同一件事。
連線後從開發選單選定要檢查的分頁
用傳輸線把 iPhone 接上 Mac。第一次連線時，iPhone 會跳出是否信任這台 Mac 的提示，要先同意，開發選單裡才會出現這台裝置。這一步容易被誤認為連線失敗，其實只是裝置在等信任的確認。
信任之後，開發選單裡會出現以 iPhone 名稱命名的子選單。iPhone 上 Safari 開著的頁面，會列在這個子選單的 Safari 項目底下；子選單依 App 把網頁與其他內容分組，方便找到想檢查的那一頁。點選該頁，就會開出新的 Web Inspector 視窗。
這個視窗會跟著分頁走。在 iPhone 上換頁導覽時，視窗仍然持續檢查同一個分頁；反過來，如果在 iPhone 上把這個分頁關掉，視窗就會消失。看到視窗不見了，不代表連線掉了，多半只是分頁被關掉。
開發選單裡的 Inspect Apps and Devices 可以開出一個視窗，一次列出 Mac、已配對裝置與執行中的模擬器上所有可檢查的內容，依 App 分組。加入主畫面的網頁 App 則要在 iPhone 前景執行，才會出現在裝置子選單底部的 Home Screen Web Apps 區。
用線配對一次後改走網路無線檢查
接線檢查時，傳輸線會限制拿著手機操作的範圍。用線連過一次之後，就可以改成在同一個網路下無線檢查。
切換的步驟是先在 iPhone 開啟 Web Inspector、用線連上 Mac，再到開發選單裡該裝置的子選單勾選 Connect via Network。Apple 的說明也寫明，Mac 與 iPhone 必須連在同一個網路上。
需要時也可以用同一個子選單裡的 Unpair… 解除配對，解除之後這台裝置就不再出現在開發選單，直到下次重新配對為止。換了手機、或想收回某台裝置的檢查權限時，這是最直接的做法。
社群 App 的內建瀏覽器預設不在清單內
有些跑版只在社群或通訊 App 裡開網頁時出現，而這類內建瀏覽器多半不會出現在開發選單。這不是設定錯了，而是 App 內的 WKWebView 預設不可檢查。
Apple 的說明寫得很明確，WKWebView 的 isInspectable 屬性預設是 false，App 開發者必須主動把它設為 true，內容才會出現在 Mac 的開發選單。這個屬性適用於 macOS 13.3 與 iOS 16.4 起的版本。Apple 也提到，內建瀏覽器的檢視尺寸可能跟 Safari 不一樣，所以開放檢查對 App 開發者與網頁作者雙方都有幫助。
對網站經營者來說，第三方 App 的內建瀏覽器沒辦法由網站這邊自行開啟檢查，是否開放完全取決於那個 App 的開發者，也不該假設任何特定 App 一定開放或一定不開放。能做的是改在 Safari 裡盡量重現相近條件，像是把視窗寬度調成接近的數字，或在需要時調整 User Agent。Apple 在開發選單的說明裡也提醒，網站判斷功能是否可用時，應該使用特性偵測，而不是依賴 User Agent 字串裡的瀏覽器名稱與版本。
在 Elements 分頁鎖定跑版的元素
連上線後的第一個動作，是找出哪個元素把版面撐壞。Elements 分頁在這件事上有四種用法，每一種都在回答一個不同的問題：這個畫面上的東西對應哪個節點、瀏覽器實際算出什麼尺寸、格線或彈性盒怎麼分配空間、哪條規則造成這個結果。
Elements 分頁底下有多個面板，查跑版時只會用到其中四個：Styles、Computed、Layout 與 Changes。Mac 上滑過 DOM 節點時，iPhone 畫面上對應的元素會被標示出來，兩邊的對應關係一眼就看得出來，不必再憑印象猜哪個區塊是哪個節點。
元素選取模式讓 iPhone 畫面與 DOM 互相對應
從 iPhone 畫面反找 DOM，是查跑版最快的起點。開發選單的 Start Element Selection 會開啟元素選取，之後滑過頁面上的元素，就會出現一層覆蓋層，把 margin、padding、border、display 這些 CSS 屬性造成的版面效果視覺化，幫助理解頁面結構。
反方向也行。在 Elements 的 DOM 樹上滑過節點，頁面覆蓋層會同步標示對應位置。DOM 樹區域左上角的麵包屑列則可以快速選到父層，這在追查是哪一層容器把寬度撐出去時特別好用，因為一路往上逐層點，就能看出是誰在擴張。
另外，沒有被渲染出來的節點，例如被 display:none 隱藏的，在 DOM 樹中會以灰階顯示。畫面上找不到某個元素、卻在原始碼裡看得到時，先確認它是不是灰色的。
Computed 面板的盒模型與實際尺寸
Styles 面板列的是設了什麼，Computed 面板列的是瀏覽器實際算出什麼。跑版時看後者才準，因為單位換算、繼承與優先順序的結果都已經落定。
Computed 面板會把 CSS 盒模型畫成圖，並列出所選節點每個 CSS 屬性的計算值。預設只顯示被樣式規則改過的屬性，要看全部屬性可以切換 Show All。Font 面板還能看主要字型的計算值，確認 iPhone 上實際套用了哪一款字型。
實際用法是核對寬度、字級與邊距，看它們在 iPhone 上算出來的結果，跟 Styles 面板設定的值是否一致。兩邊對不上時，通常代表有別的規則覆蓋了它，或是百分比、相對單位的參照基準跟預期不同。
Layout 面板顯示 Grid 與 Flexbox 的格線
版面用到 Grid 或 Flexbox 的頁面，在 iPhone 上若出現折行不對、欄數不對，用覆蓋層直接看軌道與項目，比讀 CSS 數值更快。
DOM 樹上，使用了 Grid 或 Flexbox 的節點旁會有 grid 或 flex 徽章，點一下就會在頁面上開啟對應的覆蓋層。Layout 面板則列出頁面上所有 Grid 與 Flexbox 容器，可以逐一開關覆蓋層，也能改覆蓋層的顏色，多個容器同時開啟時才不會混在一起。
Grid 覆蓋層可選擇顯示軌道尺寸、線編號、線名稱、區域名稱與延伸格線；Flexbox 覆蓋層則可以顯示各項目的順序。軌道尺寸標籤顯示的是 CSS 裡寫的值，沒寫就顯示 auto。例如欄數在窄螢幕下變少，拿這些標籤對照延伸格線畫出的實際分格，就能看出哪一條軌道沒照預期收縮。
Styles 面板即時調整數值以驗證成因
懷疑是哪條規則造成問題時，可以直接在檢查器裡即時改值，看 iPhone 上的版面有沒有變化。先確認成因，再回原始碼修改，比在原始碼和手機之間來回更新快很多。
Styles 面板會依選擇器優先順序與繼承，整理套用到該節點的規則。幾乎每個宣告都可以直接編輯，包含 @media、@supports、@container 的條件文字。無效的宣告會以黃色標示，並有提示說明原因，所以寫錯的屬性值不必靠肉眼找。
要留意的是，新增的規則會存在 Inspector Style Sheet 裡，不會在換頁導覽或重新開啟 Web Inspector 之後保留。Changes 面板會列出這次改過的 CSS 宣告，方便把有效的改法抄回原始碼。另外 Classes 按鈕可以勾選切換該節點的 class，用來確認某個 class 有沒有造成版面變化。
網頁設計的蘋果優化，先查 4 個常見的跑版成因
談網頁設計的蘋果優化，聽起來像一整套專屬寫法，實際上讓版面在 iPhone 上出狀況的，集中在視埠、瀏覽器介面與螢幕形狀這幾個位置。這幾個成因的共通點是桌機縮窗幾乎看不出來，要靠前面接上的檢查器才確認得了；先從症狀對回成因，就知道該打開哪個面板查證。
超出螢幕寬度的元素會讓整頁縮小
整頁看起來縮得很小、右邊多出空白，或是頁面能左右滑動，多半是有某個元素的寬度超出了螢幕。WebKit 說明過這個行為，有些頁面雖然寫了 width=device-width，內容卻排得非常寬，常見超過 1000 像素。瀏覽器如果照字面尊重這個設定，使用者就只會看到內容的左上角，所以 WebKit 會自動調整縮放比例，效果等同頁面載入後使用者把它縮小到看得見全部內容。
此時頁面的縮放比例已經不是 1。這也會連帶影響 iOS 10 起的快速點擊。要啟用快速點擊，頁面必須有 viewport 的 meta 標籤、寬度設為 device-width，而且內容在縮放比例 1 的狀態下，沒有因為太寬而被瀏覽器強制縮小。
排查時，用元素選取模式點選 iPhone 畫面上的元素，再沿著麵包屑列逐層往上，到 Computed 面板比對各層元素的寬度與螢幕寬度，找出寬度最大的那一個。Elements 的 scroll 徽章會標示出可捲動的節點，橫向捲動的容器也藏不住。MDN 的回應式設計指南提到，用固定寬度做出不能伸縮的頁面，在窄螢幕上會出現捲軸；圖片、影片這類媒體則可以加上 max-width: 100%，讓它不超過容器寬度。找到撐寬的元素之後，就照這個方向回原始碼改成相對寬度。
viewport 設定不當時頁面按 980 像素排版
整頁像是縮小的桌機版時，先檢查有沒有 viewport 的 meta 標籤。Apple 早期的 Safari 網頁內容指南（目前已列為封存文件，最後更新於 2016 年）提到，沒有設定時，iOS 上的 Safari 預設的視埠寬度是 980 像素，頁面先以這個寬度排版，再縮放到螢幕上顯示。這個行為的出發點，是讓為桌機設計的頁面不至於只顯示左上角。
正確的寫法是用 device-width 指定寬度，並把初始縮放設為 1：
<meta name="viewport" content="width=device-width, initial-scale=1">Code language: HTML, XML (xml)另一個常見誤解是靠封鎖縮放來解決版面問題。WebKit 說明，從 iOS 10 開始，使用者可以在任何頁面縮放，頁面裡的 user-scalable、minimum-scale、maximum-scale 設定會被忽略。這代表版面必須經得起放大，而不是想辦法讓使用者放不大。
在 Elements 分頁展開 head，確認 viewport 的 meta 標籤存在，值也沒有被改掉。如果範本或外掛輸出了兩組設定，就要查是哪一組實際生效。
100vh 高過可視範圍，改用 svh 與 dvh
全螢幕的區塊底部被切掉，或是多出一截可捲動的空間，常是因為手機瀏覽器的網址列會在捲動時收合，可視高度隨之改變。WebKit 說明，開發者長期需要一種在手機上更好用的視埠單位，因為瀏覽器的視埠尺寸會隨使用者捲動而改變，於是在 Safari 15.4 加入了新的視埠單位。
這組單位有三種：100svh 是最小可能視埠的高度，100lvh 是最大可能視埠的高度，100dvh 是動態視埠的高度，數值會隨著使用者捲動而改變。寬度也有對應的 svw、lvw、dvw。
選用時不必一律套同一個。想要一個穩定的、永遠看得到的範圍，用 svh；想要區塊隨瀏覽器介面收合而伸縮，用 dvh。寫的時候可以保留 100vh 當備援，後面再接新單位，不支援的瀏覽器會忽略後面那行：
.hero {
min-height: 100vh;
min-height: 100dvh;
}Code language: CSS (css)驗證時，在 Styles 面板即時把 100vh 換成 100svh 或 100dvh，看底部是否對齊，並到 Computed 面板確認實際算出的高度。
瀏海與底部橫條遮住內容，需要安全區域設定
固定在頁面最上方或最下方的導覽列，若被瀏海、動態島或底部的 Home 指示條擋住，問題多半跟安全區域有關。WebKit 說明過預設行為，Safari 會自動把內容縮進安全區域，避免被圓角與感測器外殼遮住，空出來的邊則以 body 或 html 的 background-color 填滿。很多單純的頁面這樣就夠了。
一旦把 viewport 設定加上 viewport-fit=cover，頁面就會撐滿整個螢幕，這時就要自己避開遮擋：
<meta name="viewport" content="initial-scale=1, viewport-fit=cover">Code language: HTML, XML (xml)避開的方法是 WebKit 在 iOS 11 加入、iOS 11.2 起定名為 env() 的 CSS 函式，搭配四個預先定義的環境變數 safe-area-inset-top、safe-area-inset-right、safe-area-inset-bottom 與 safe-area-inset-left。要注意，不支援 env() 的瀏覽器會忽略整條宣告，所以要另外寫備援規則。
單用 env() 的副作用是直向時左右兩側安全區域的邊距為 0，文字會貼著螢幕邊緣。搭配 max() 可以保留最小邊距，橫向時安全區域變大，env() 的值就會自動生效：
.content {
padding-left: 12px;
padding-right: 12px;
}
@supports (padding: max(0px)) {
.content {
padding-left: max(12px, env(safe-area-inset-left));
padding-right: max(12px, env(safe-area-inset-right));
}
}Code language: CSS (css)驗證時，在 Styles 面板即時修改 padding，再到 Computed 面板檢視 env() 實際算出的數值，直向與橫向各看一次。
Console 與 Network 區分載入失敗與版面錯誤
有些看起來像跑版的問題，其實是 CSS 檔沒載入、字型或圖片失敗，或是 JavaScript 出錯導致版面沒組起來。如果不先分辨是樣式有載入但算錯，還是資源根本沒到，就很容易在 Styles 面板找了半天卻一無所獲。
Console 負責看 JavaScript 的錯誤、警告與頁面輸出的 log，也能直接輸入指令查詢。例如輸入 document.documentElement.scrollWidth，再跟 document.documentElement.clientWidth 比較，就能確認頁面是否真的有橫向溢出。
Network 則列出載入頁面各項資源的請求與回應，包含狀態與時間，所以能看出某個 CSS 或字型檔是不是回傳失敗。已經載入完成的頁面如果看不到請求記錄，重新載入一次頁面再看。
判讀的順序是先看 Console 有沒有紅色錯誤，再看 Network 有沒有失敗的請求，最後才回到 Elements。資源失敗與 JavaScript 錯誤會讓後面所有的樣式檢查失去意義，先把它們修掉，剩下的版面問題才需要回頭從 CSS 處理。
用裝置設定逐項關閉功能來隔離來源
遠端檢查 iPhone 時，Web Inspector 會多出一個裝置設定（device settings）選單。原因是開發選單上的 Disable Images、Disable Styles 這類選項，對遠端的 iOS 裝置或模擬器沒有作用，所以 WebKit 另外做了這個選單，讓這些設定可以只針對遠端那一個分頁切換。裝置設定只在遠端檢查時才會出現。
這些設定在關閉 Web Inspector 或斷線後就恢復原狀，不會在不同的檢查工作階段之間保留；在同一個工作階段內換頁導覽，設定則會保留。這代表不用擔心忘了開回來而影響到之後的使用。
可用的項目包括：
- User Agent：Apple 的繁體中文說明譯為「使用者代理程式」。這個選項提供一份常見的 User Agent 清單，也能輸入自訂值，修改後頁面會自動重新載入。
- Images：阻止後續尚未載入的圖片，已經載入的圖片不受影響。
- Styles：停用頁面上所有的 CSS，包含 style 標籤與 style 屬性。
- JavaScript：讓頁面忽略後續要執行的 JavaScript。
- Site-specific Hacks：控制 WebKit 針對特定網站做的相容性優化。WebKit 建議，網站如果在那份清單內，開發與測試時最好關掉它，免得測到的是被修補過的行為。
- Cross-Origin Restrictions：控制後續網路請求是否套用跨來源限制。
開關之後，頁面要重新載入才會完整反映，因為這些設定針對的是後續載入或執行的內容。
Elements 工具列另有兩個跟版面直接相關的覆寫。「Override user preferences」可以覆寫深色模式、減少動態效果與提高對比，用來檢查這幾種模式下的版面；Force print media styles 則強制套用列印樣式。
有了這些開關，就能用關掉一項看版面變不變的二分法排查。關掉 JavaScript 之後版面恢復正常，代表是腳本在改版面，例如插入元素、切換 class 或延遲載入某個元件；關掉樣式之後，如果內容的順序與層級本身就不對，問題就出在 HTML 結構。這兩項都排除了，再回到 Styles 面板找 CSS 的成因。
即時修改只是暫時的，驗證後要回到原始碼與實機
Inspector 內改的東西不會留下來。前面提過，Styles 面板新增的規則存在 Inspector Style Sheet，換頁導覽或重新開啟 Web Inspector 後就會消失，所以找到有效的改法之後，要透過 Changes 面板列出的清單，把每一項改動抄回原始碼。
改完原始碼、部署到伺服器之後，下一個容易誤判的地方是快取。開發選單的 Empty Caches 可以清掉瀏覽器儲存的快取，Apple 說明它適合用在伺服器讓開發中的內容被快取、導致看不到最新改動的情境。Apple 的說明沒有明講這個選項是否也作用在遠端連線的 iPhone，所以要確認手機上看到的是不是最新版本，較穩的做法是在 iPhone 的 Safari 設定裡也清除一次網站資料。
實機驗證通過之後，再從開發選單的 Open Page With 開啟前面提到的 iOS 模擬器，補測其他機型與 iOS 版本，同一套檢查流程在模擬器上也能照做一次。
整個流程串起來，是先在實機重現問題，再用檢查器即時修改找出成因；成因確認後把改動抄回原始碼；清掉快取讓 iPhone 取得新檔案；然後在實機重新載入頁面，並在開發選單重新選一次分頁確認視窗仍然連著；最後用模擬器補測別的機型。每一步都有存在的理由，跳過其中任何一步，都可能讓最後的確認變成假的通過。
AI 助手透過 MCP 伺服器操作 Mac 上的 Safari
Safari 27 已在 2026 年 9 月 14 日釋出，Apple 的 Safari 27 Release Notes 在 WebDriver 項目下列出一項新功能，允許 AI 助手透過 Safari MCP 伺服器，連接 Safari 瀏覽器進行開發與除錯。Apple 的開發者文件對此的描述是，Safari 27 以上內建 Model Context Protocol（MCP）伺服器，可以把 AI 助手連到一組檢查並操作頁面的工具。
啟用要在 Safari 端完成兩個設定。先用前面提過的 Show features for web developers 啟用開發選單與 Developer 設定分頁，再到 Safari 設定的 Developer 分頁，勾選 Allow remote automation and external agents。AI 助手那端的設定，概念上是在它的 MCP 設定裡指向 Mac 內建的 safaridriver，並加上 --mcp 參數。連上之後，Safari 會在工具列下方顯示橫幅，表示視窗正由 AI 助手控制。
AI 助手可用的工具，涵蓋開分頁與載入頁面、讀取頁面內容、截圖、列出網路請求、讀取 Console 訊息、設定視埠尺寸、切換淺色與深色外觀、減少動態效果、模擬點擊輸入與捲動，以及在頁面中執行 JavaScript。這些工具做的事跟前面講的縮窗檢查屬於同一類，不外乎用不同的視埠寬度截圖比對，或讀取 Console 與 Network 裡的錯誤。
這組工具的適用範圍有明確的界線。Apple 文件只寫到 AI 助手會在 Mac 上的 Safari 開一個新視窗載入網站，視埠大小以 CSS 像素設定，文件裡沒有寫到連接 iPhone 的用法。照文件描述的範圍，它檢查的是 Mac 上的 Safari，受前面講過的近似限制，只能算更自動化的縮窗，不能取代檢查 iPhone 實機。適合拿來先粗篩寬度類的問題，確認問題只出現在 iPhone 上，再接線進入前面那套遠端檢查。
網站只在 iPhone 上跑版時，缺的往往不是更多 CSS 知識，而是一個能看見手機上真實結果的視窗。Safari 把這個視窗做在 Mac 裡，兩端的開關開好、線接上，iPhone 上那一頁的 DOM、樣式與請求記錄就全攤在眼前。
下次遇到只在 iPhone 出現的跑版，先在 Mac 縮窗確認是不是單純的寬度問題，不是的話，就接上線從元素選取模式點下去。從實際算出來的尺寸與資源記錄找原因，比在桌機視窗反覆猜測更直接，也更不容易改錯地方。